Mixpanel ഒരു product analytics platform ആണ്. ആളുകൾ ഏതെല്ലാം features സ്വീകരിക്കുന്നു, funnel-ിൽ എവിടെയാണ് അവർ വിട്ടുപോകുന്നത്, അടുത്ത ആഴ്ച ആരാണ് തിരികെ വരുന്നത് എന്നത് കാണാൻ ടീമുകൾ ഇത് ഉപയോഗിക്കുന്നു. ആ ജോലിയിൽ ഇത് മികച്ചതാണ്, കൂടാതെ പല product ടീമുകൾക്കും user behavior സംബന്ധിച്ച ചോദ്യങ്ങൾക്ക് ഉത്തരങ്ങൾ ലഭിക്കുന്ന സ്ഥലം ഇതാണ്.
ഇപ്പോൾ അതിന് അടുത്തായി ഒരു പുതിയ ചോദ്യം നിലകൊള്ളുന്നു. നിങ്ങളുടെ product-ിലെ ചില events ഇനി ഒരു person click ചെയ്യുന്നതിലൂടെ അല്ല driven ആകുന്നത്. യഥാർത്ഥ customers-നായി പ്രവർത്തിക്കുന്ന AI agents-ൽ നിന്നാണ് അവ വരുന്നത്, AI assistant-ോടെ പ്രവർത്തിക്കുന്ന ആളുകളിൽ നിന്നാണ്, കൂടാതെ ഇപ്പോഴും നിങ്ങൾക്ക് വിശദീകരിക്കാനാകാത്ത automation-ൽ നിന്നുമാണ്. ഒരു funnel വായിക്കുന്നതിന് മുമ്പ്, അതിൽ events സൃഷ്ടിച്ചത് ആരോ എന്തോ ആണോ എന്ന് increasingly അറിയേണ്ടതുണ്ട്, അതിനോടൊപ്പം പ്രതികരിക്കാൻ application-ിനും തത്സമയം അതേ കാര്യം അറിയേണ്ടതുണ്ട്. അതിനായാണ് AgentCredia-യിൽ നിന്നുള്ള Proof of Actor നിർമ്മിച്ചിരിക്കുന്നത്.
ഈ പേജ് രണ്ടിനെയും ന്യായമായി താരതമ്യം ചെയ്യുന്നു. താഴെയുള്ള Mixpanel കാര്യങ്ങൾ November 2026-ലെ Mixpanel-ന്റെ സ്വന്തം documentation-ൽ നിന്നുള്ളവയാണ്.
ചുരുക്കം
| Mixpanel | Proof of Actor | |
|---|---|---|
| മുഖ്യ ചോദ്യം | Users എങ്ങനെ adopt ചെയ്യുന്നു, convert ചെയ്യുന്നു, retain ചെയ്യുന്നു? | ഈ interaction-ിൽ പ്രവർത്തിക്കുന്നത് ആരോ എന്തോ ആണോ, തെളിവ് എന്താണ്? |
| ഇത് എവിടെ collect ചെയ്യുന്നു | Client, server SDKകൾ, കൂടാതെ ingestion APIs; സാധ്യമെങ്കിൽ server-side tracking Mixpanel ശുപാർശ ചെയ്യുന്നു | Server middleware, edge, HTTP API, MCP servers, കൂടാതെ അംഗീകരിച്ച browser collector |
| Agent, bot ലേബലുകൾ | $mp_actor_type ആയി agent, bot, അല്ലെങ്കിൽ none, user agent-ൽ നിന്ന് തരംതിരിച്ചത് |
Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown, പറഞ്ഞ basis-ോടെ |
| Verified agent identity | Mixpanel-ന്റെ bot traffic documentation-ൽ വിവരിച്ചിട്ടില്ല | Request signature പ്രസിദ്ധീകരിച്ച key-നോട് പരിശോധിച്ച് പൊരുത്തപ്പെടുമ്പോൾ Verified basis |
| AI-സഹായിത ആളുകൾ | വേറെ class ആയി വിവരിച്ചിട്ടില്ല | ആദ്യനിര result: Human + AI |
| വ്യക്തമല്ലാത്ത traffic | ഏജന്റ് അല്ലെങ്കിൽ bot match ഇല്ലെങ്കിൽ none ആയി ലേബൽ ചെയ്യുന്നു | നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന fallback-ോടെ Unknown ആയി റിപ്പോർട്ട് ചെയ്യുന്നു |
| Traffic-ിൽ പ്രവർത്തിക്കുന്നുണ്ടോ | ഇല്ല, events വിശകലനം ചെയ്യുന്നു | Observation-ിന് ശേഷം നിങ്ങളുടെ സ്വന്തം code-ിൽ policies അനുസരിച്ച് route ചെയ്യുന്നു |
ഈ പേജിന്റെ ശേഷിപ്പിൽ ഓരോ വരിയും വിശദീകരിക്കുന്നു.
Mixpanel-ന്റെ event model എന്തിനായി നിർമ്മിച്ചതാണ്
Mixpanel events-നും അവയോട് ചേർത്തിരിക്കുന്ന properties-നും ചുറ്റുമാണ് നിർമ്മിച്ചിരിക്കുന്നത്. Sign up, create project, invite teammate പോലുള്ള actions നിങ്ങൾ instrument ചെയ്യുന്നു, plan അല്ലെങ്കിൽ platform പോലുള്ള properties ചേർക്കുന്നു, തുടർന്ന് those properties അടിസ്ഥാനമാക്കി funnels, retention curves, flows, cohorts എന്നിവ നിർമ്മിക്കുന്നു. Mixpanel-ിലെ ഓരോ analysis ചോദ്യം ഒടുവിൽ ഏത് events സംഭവിച്ചു, ആരോടാണ്, ഏതെല്ലാം property values-ോടെ എന്നതിനെക്കുറിച്ചുള്ള ചോദ്യം ആകുന്നു.
ആ model-ലേക്ക് actor context ഇത്ര നന്നായി ചേരുന്നതും അതാണ്. ഒരു actor label മറ്റൊരു property മാത്രമാണ്, അത് നിങ്ങളുടെ events-ൽ വന്നാൽ, എല്ലാ funnel-ും retention chart-ഉം അതിനാൽ split ചെയ്യാം. Mixpanel സ്വന്തം actor labelling-ോടെ തന്നെ ഈ ദിശയിലേക്ക് നീങ്ങിയിട്ടുണ്ട്. തുറന്ന ചോദ്യം ഈ property എന്തിനെ അടിസ്ഥാനമാക്കിയാണ് എന്നതും, request ഇപ്പോഴും കൈകാര്യം ചെയ്യപ്പെടുന്ന സമയത്ത് നിങ്ങളുടെ application-ന് അതേ ഉത്തരം ഉപയോഗിക്കാനാകുമോ എന്നതുമാണ്.
Proof of Actor ആ ഉത്തരം request path-ൽ സൃഷ്ടിക്കുന്നു. ഓരോ interaction-നും നാല് classകളിലൊന്നാണ് ലഭിക്കുന്നത്: signals ഒരു person-നെ സൂചിപ്പിക്കുമ്പോൾ Human, ഒരു supported integration-ിലൂടെ declared ചെയ്തതോ observed ചെയ്തതോ ആയ AI സഹായത്തോടെ ഒരു person പ്രവർത്തിക്കുമ്പോൾ Human + AI, automated അല്ലെങ്കിൽ agent-origin interaction-കൾക്ക് Agent, reliable determination പിന്തുണയ്ക്കാൻ തെളിവ് മതിയാകാത്തപ്പോൾ Unknown. ഓരോ result-ും അതിന്റെ evidence basis, verified, declared, inferred അല്ലെങ്കിൽ unknown, വ്യക്തമാക്കുന്നു, അതോടെ property ഒരു label-ൽ നിന്ന് പറഞ്ഞ ശക്തിയുള്ള label-ആകുന്നു.
ഓരോന്നും എവിടെ പ്രവർത്തിക്കുന്നു
Mixpanel client-side, server-side tracking രണ്ടും നൽകുന്നു. അതിന്റെ tracking method തിരഞ്ഞെടുക്കൽ സംബന്ധിച്ച documentation, കഴിയുന്നത്ര servers-ൽ നിന്ന് track ചെയ്യുകയും ആവശ്യമായപ്പോൾ client-side tracking-ോടെ supplement ചെയ്യുകയും ചെയ്യാൻ ശുപാർശ ചെയ്യുന്നു, client-side tracking-നെ ad blockers ബാധിക്കുമെന്ന് ചൂണ്ടിക്കാട്ടി.
Proof of Actorയും server-side ആയി പ്രവർത്തിക്കുന്നു, പക്ഷേ അതിന്റെ സ്ഥാനം വ്യത്യസ്തമാണ്. ഇത് നിങ്ങളുടെ application-ന്റെ request path-ിൽ ഇരിക്കുന്നു: Node.js middleware, Next.js, നിങ്ങൾ നിയന്ത്രിക്കുന്ന edge layer, generic HTTP API അല്ലെങ്കിൽ നിങ്ങളുടെ MCP server, കൂടാതെ അംഗീകരിച്ച pages-ൽ optional browser collector. അതിലൂടെ request നിമിഷത്തിൽ തന്നെ signals കാണാനാകും, ഉദാഹരണത്തിന് ഒരു client signature അവതരിപ്പിച്ചോ, ഒരു client സ്വയം declared ചെയ്തോ, നിങ്ങളുടെ സ്വന്തം assistant action എടുത്തോ എന്നത്. മുഴുവൻ പട്ടികയ്ക്കായി integrations page കാണുക.
Mixpanel bots-ിനെയും AI agents-നെയും എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു
Mixpanel ഇവിടെ യഥാർത്ഥ support ചേർത്തിട്ടുണ്ട്, അത് പ്രശംസനീയമാണ്. അതിന്റെ bot traffic documentation പ്രകാരം:
- Mixpanel JavaScript library Googlebot, Bingbot ഉൾപ്പെടെ അറിയപ്പെടുന്ന crawlers-ന്റെ ഒരു ചെറിയ പട്ടിക default ആയി filter ചെയ്യുന്നു.
$ignoreproperty set ചെയ്ത് അയക്കുന്ന ഏതൊരു event-ഉം ingestion-ൽ drop ചെയ്യപ്പെടുന്നു, അതിനാൽ നിങ്ങൾക്ക് സ്വന്തം filtering logic എഴുതാം.- Mixpanel-ന്റെ ingestion APIs ഓരോ event-ിന്റെയും user agent തരംതിരിച്ച്, ഒരു human user-ന്റെ behalf-ൽ പ്രവർത്തിക്കുന്ന LLM-ൽ നിന്നുള്ള requests-ന്
$mp_actor_type(Actor Type) ആയിagent, crawlers, search indexers പോലുള്ള generic automated traffic-ിന്bot, അല്ലെങ്കിൽ ഒന്നും ബാധകമല്ലെങ്കിൽnoneആയി സജ്ജമാക്കുന്നു. typeagentഅല്ലെങ്കിൽbotആണെങ്കിൽ,$mp_actor_name(Actor Name) GPTBot അല്ലെങ്കിൽ ClaudeBot പോലുള്ള തരംതിരിച്ച identity സൂക്ഷിക്കുന്നു. - Server-side tracking-ൽ, classification Mixpanel-ിലെത്തിയ request-ന്റെ user agent ഉപയോഗിച്ചാണ്, അഥവാ നിങ്ങളുടെ server-ന്റെ HTTP library, നിങ്ങൾ end user's user agent മുന്നോട്ടയച്ചില്ലെങ്കിൽ, ഉദാഹരണത്തിന്
$mp_raw_user_agent-ൽ. അല്ലാതെ classification തെറ്റായിരിക്കാമെന്ന് Mixpanel കുറിക്കുന്നു. - Mixpanel-ിലെ events immutable ആണ്, അതിനാൽ ഇതിനകം രേഖപ്പെടുത്തിയ bot events analysis-ൽ നിന്ന് അവ ഒഴിവാക്കുന്നതിലൂടെയാണ് കൈകാര്യം ചെയ്യുന്നത്, delete ചെയ്യുന്നതിലൂടെ അല്ല.
അത് ഒരു ഉപകാരപ്രദമായ reporting label ആണ്. അതുപോലെ തന്നെ, നിർവചനപ്രകാരം, അത് user agent string-ൽ നിന്നുള്ള ഒരു label കൂടിയാണ്. User agent strings self-reported ആണ്, കൂടാതെ എളുപ്പത്തിൽ അനുകരിക്കാനാകും, ഈ പ്രശ്നം user agent spoofing എൻട്രിയിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. കൂടാതെ AI സഹായത്തോടെ പ്രവർത്തിക്കുന്ന ആളുകൾക്കായുള്ള ഒരു class-നെക്കുറിച്ചോ, evidence വളരെ കുറവായാൽ വിളിക്കാൻ കഴിയില്ല എന്ന് പറയാനുള്ള മാർഗ്ഗത്തെക്കുറിച്ചോ documentation വിവരിക്കുന്നില്ല.
$mp_actor_type ഉം Proof of Actor class ഉം, ഒപ്പം ഒപ്പം
രണ്ടും അതേ Mixpanel event-ൽ നിലകൊള്ളാനാകുന്നതിനാൽ, അവ തമ്മിലുള്ള ബന്ധം കാണുന്നത് സഹായകരമാണ്:
$mp_actor_type |
ഇത് എന്തിനെ അടിസ്ഥാനമാക്കുന്നു | Proof of Actor class എന്ത് ചേർക്കാം |
|---|---|---|
agent |
ഒരു user-നായി പ്രവർത്തിക്കുന്ന LLM-ിനുള്ള user agent match | Request valid signature വഹിക്കുമ്പോൾ verified basis-ോടെ Agent, അല്ലെങ്കിൽ അതല്ലെങ്കിൽ declared അല്ലെങ്കിൽ inferred basis |
bot |
crawlers, indexers എന്നിവയ്ക്കുള്ള user agent match | തെളിവ് അതിനെ പിന്തുണയ്ക്കുമ്പോൾ Agent, അല്ലെങ്കിൽ crawler-style user agent-ന് മറ്റൊന്നും പിന്തുണയില്ലെങ്കിൽ Unknown |
none |
user agent-ിൽ agent അല്ലെങ്കിൽ bot match ഇല്ല | Human, Human + AI അല്ലെങ്കിൽ Unknown, അതിനാൽ സഹായിത ആളുകളും വിശദീകരിക്കാനാകാത്ത traffic-ഉം അതേ bucket-ിൽ മറഞ്ഞുനിൽക്കില്ല |
പ്രധാന വ്യത്യാസങ്ങൾ ഓരോ answer ഉം എവിടെ നിന്നാണ് ഉണ്ടാകുന്നത് എന്നതാണ്.
User agent string-ിനെക്കാൾ കൂടുതലായ തെളിവ്. $mp_actor_type user agent-ിൽ നിന്നാണ് derived ചെയ്യുന്നത്, അത് self-reported ആണും അനുകരിക്കാൻ എളുപ്പമാണും, user agent spoofing എൻട്രി വിശദീകരിക്കുന്നതുപോലെ. Verified Proof of Actor result എന്നതിന്റെ അർത്ഥം, പ്രസിദ്ധീകരിച്ച key-നോട് ഒരു request signature പരിശോധിച്ചതാണ്, RFC 9421-ൽ നിർവചിച്ചതും Web Bot Auth-ൽ ഉപയോഗിക്കുന്നതുമായ HTTP Message Signatures ഉപയോഗിച്ച്.
AI-സഹായിത ആളുകൾക്കായുള്ള ഒരു class. $mp_actor_type-ൽ, ഒരു assistant-ോടെ drafting ചെയ്യുന്ന person none-ലേക്ക് തന്നെ വീഴും, മറ്റ് എല്ലാ users-ോടൊപ്പം. Supported integration-ിലൂടെ assistance declared ആയപ്പോഴും observed ആയപ്പോഴും Proof of Actor Human + AI റിപ്പോർട്ട് ചെയ്യുന്നു, അതിനാൽ ഒരു Mixpanel funnel-ൽ AI-സഹായിത users എവിടെയാണ് വേഗത്തിൽ activate ചെയ്യുന്നത്, അല്ലെങ്കിൽ എവിടെയാണ് മുടങ്ങുന്നത് എന്ന് കാണാൻ കഴിയും.
none-ന് പകരം Unknown. none എന്നത് match ഒന്നും കണ്ടെത്തിയില്ല എന്നർത്ഥം. Unknown എന്നത് വിളിക്കാൻ മതിയായ ശക്തി തെളിവിന് ഇല്ലായിരുന്നു എന്നർത്ഥം, അത് വ്യത്യസ്തവും കൂടുതൽ ഉപകാരപ്രദവുമായ ഒരു പ്രസ്താവനയാണ്. നിങ്ങൾക്ക് route അനുസരിച്ച് Unknown rate track ചെയ്യാം, Unknown traffic കൈകാര്യം ചെയ്യൽ എന്ന ഗൈഡ് fallback patterns ഉൾക്കൊള്ളുന്നു.
നിങ്ങളുടെ tracking-ിലൂടെ ഒരിക്കലും കടന്നുപോകാത്ത events. Agents പലപ്പോഴും UI-യിലൂടെ click ചെയ്യുന്നതിന് പകരം APIs, MCP servers എന്നിവ call ചെയ്യുന്നു. Proof of Actor അവ നടക്കുന്ന സ്ഥലത്തുതന്നെ ആ interactions തരംതിരിക്കുന്നു, MCP tool calls ഉൾപ്പെടെ; MCP servers use case കാണുക.
Request സമയത്തെ ഒരു തീരുമാനം. Mixpanel events immutable ആണ്, report കഴിഞ്ഞാണ് വിശകലനം ചെയ്യുന്നത്, analytics-ിനായി അത് ശരിയാണ്. Proof of Actor നിങ്ങളുടെ application-ന് ഓരോ route, class, basis എന്നിവ അനുസരിച്ച് allow, adapt, challenge, review-ലേക്ക് അയയ്ക്കുക അല്ലെങ്കിൽ rate-limit ചെയ്യുക എന്നും അനുവദിക്കുന്നു. ഇത് observation mode-ൽ തുടങ്ങുന്നു, അതിനാൽ enforce ചെയ്യാൻ നിങ്ങൾ തീരുമാനിക്കുന്നതുവരെ ഒന്നും മാറില്ല.
Mixpanel-ഉം Proof of Actor-ഉം ഒരുമിച്ച് ഉപയോഗിക്കൽ
- Request-ൽ classify ചെയ്യുക. നിങ്ങളുടെ application-ൽ, API-യിൽ അല്ലെങ്കിൽ MCP server-ൽ ഓരോ interaction-നുമുള്ള class-ഉം basis-ഉം Proof of Actor തിരികെ നൽകുന്നു.
- രണ്ട് event properties ചേർക്കുക. നിങ്ങൾ ഇതിനകം അയക്കുന്ന Mixpanel events-ൽ, ഉദാഹരണത്തിന് നിങ്ങൾ
actor_class,actor_basisഎന്ന് പേരിടുന്ന properties ആയി, class-ും basis-ും ചേർക്കുക. Server-side tracking ഇത് ലളിതമാക്കുന്നു, കാരണം result നിങ്ങളുടെ application-ൽ തന്നെ ഉണ്ടാകും. $mp_actor_typeയും നിലനിർത്തുക. End user's user agent മുന്നോട്ടയച്ച് Mixpanel-ന്റെ സ്വന്തം label കൃത്യമാക്കുക, പിന്നെ രണ്ട് properties താരതമ്യം ചെയ്യുക. അവ ഭിന്നിക്കുമ്പോൾ, Proof of Actor basis ഏത് തെളിവിൽ വിശ്വാസം വയ്ക്കണമെന്ന് പറയുന്നു.- നിങ്ങൾ ഇതിനകം ഉപയോഗിക്കുന്ന reports വിഭജിക്കുക. Funnel-ുകൾ, retention, flows എന്നിവയെ actor class അനുസരിച്ച് split ചെയ്ത് agent-driven sign ups human ones പോലെ retain ചെയ്യുന്നുണ്ടോ, അല്ലെങ്കിൽ AI-സഹായിത users activation-ൽ വേഗമാണോ എന്ന് കാണുക. SaaS apps use case ഇത് എവിടെയാണ് ഏറ്റവും പ്രാധാന്യമുള്ളത് എന്ന് കാണിക്കുന്നു.
- പ്രധാനപ്പെട്ടിടത്ത് പ്രവർത്തിക്കുക. actor class experience മാറ്റേണ്ട routes-കൾക്കായി policies എഴുതുക. actor-aware policies സുരക്ഷിതമായി rollout ചെയ്യൽ എന്ന ഗൈഡ് പ്രക്രിയ ഉൾക്കൊള്ളുന്നു.
ഏത് തിരഞ്ഞെടുക്കണം, എപ്പോഴാണ്
Mixpanel തിരഞ്ഞെടുക്കുക, നിങ്ങളുടെ ചോദ്യം product behavior സംബന്ധിച്ചിരിക്കുമ്പോൾ: activation, conversion, retention, feature adoption, users പോകുന്ന path-ുകൾ. അതിന്റെ $mp_actor_type label ആ analysis-ൽ agents-നും bots-നും ഇടയിൽ ആദ്യഘട്ട വിഭജനമായി നല്ലതാണ്.
Proof of Actor ചേർക്കുക, ആ label-ിന് തെളിവ് ഉണ്ടായിരിക്കേണ്ടപ്പോൾ, AI-സഹായിത users നിങ്ങളുടെ product-ിന് പ്രധാനപ്പെട്ടപ്പോൾ, നിങ്ങളുടെ agent traffic-ന്റെ വലിയ ഭാഗം APIs അല്ലെങ്കിൽ MCP servers വഴി എത്തുമ്പോൾ, അല്ലെങ്കിൽ നിങ്ങളുടെ application-ന് report-ൽ അല്ല, request സമയത്ത് പ്രതികരിക്കേണ്ടപ്പോൾ. Mixpanel നിങ്ങളുടെ product എങ്ങനെ ഉപയോഗിക്കപ്പെടുന്നു എന്ന് പറയുന്നു. ഓരോ interaction-ലും അത് ആരാണ് ഉപയോഗിക്കുന്നത് എന്നത് തെളിവോടെ Proof of Actor പറയുന്നു, കൂടാതെ അതിന്മേൽ പ്രവർത്തിക്കാൻ നിങ്ങളുടെ code-ിന് ഒരു വഴി നൽകുന്നു.
ആരംഭിക്കുക
Proof of Actor private beta-യിലാണ്. founding developer program വഴി, തിരഞ്ഞെടുത്ത ടീമുകൾക്ക് agreed usage limits ഉള്ളിൽ, automatic billing ഇല്ലാതെ, 12 months വരെ free access ലഭിക്കാം. early access-ിന് അപേക്ഷിക്കുക and tell us about your product and the interactions you want to understand.
Mixpanel Mixpanel, Inc.-ന്റെ trademark ആണ്.