നിങ്ങളുടെ ഡാഷ്ബോർഡുകൾ മാറിയ ലോകത്തെയാണ് എണ്ണുന്നത്
മിക്ക അനലിറ്റിക്സ് സ്റ്റാക്കുകളും ഒരു ചോദ്യം ഉത്തരം പറയാനാണ് നിർമ്മിച്ചത്: എന്റെ സൈറ്റിൽ ആളുകൾ എന്താണ് ചെയ്യുന്നത്? സെഷനുകൾ, പേജ് വ്യൂകൾ, ഫണലുകൾ, കാമ്പെയ്നുകൾ എന്നിവ ഓരോ ഇടപെടലിനും പിന്നിൽ ഒരു വ്യക്തിയുണ്ടെന്ന് കരുതുന്നു.
ആ അനുമാനം ഇനി ഓരോ ഇടപെടലിനും ബാധകമല്ല. AI സഹായികൾ ഉപയോക്താക്കള്ക്കുവേണ്ടി പേജുകൾ തുറക്കുന്നു; ഉദാഹരണത്തിന്, ഉപയോക്താവ് ChatGPTയോട് ഒരു ചോദ്യം ചോദിക്കുമ്പോൾ പേജുകൾ സന്ദർശിക്കുന്ന ഒരു ChatGPT-User ഏജന്റ് OpenAI രേഖപ്പെടുത്തുന്നു (OpenAI crawler documentation). സ്വയംഭരണ ഏജന്റുകൾ പ്രവർത്തനങ്ങൾ പൂർത്തിയാക്കാൻ APIകളും MCP ഉപകരണങ്ങളും വിളിക്കുന്നു. ആളുകൾ അതേ സെഷനിൽ AIയോടൊപ്പം പ്രവർത്തിക്കുന്നു, ചിലപ്പോൾ അത് വ്യക്തമാക്കുകയും ചിലപ്പോൾ ഇല്ലാതിരിക്കുകയും ചെയ്യുന്നു. ക്രോളറുകളും സ്ക്രിപ്റ്റുകളും തങ്ങൾക്ക് എത്താനാകുന്ന എല്ലാം വായിച്ചുകൊണ്ടിരിക്കുന്നു.
ഫലം നിങ്ങളുടെ ടീം ആശ്രയിക്കുന്ന സംഖ്യകളിൽ ഒരു നിശ്ശബ്ദ വ്യതിയാനമാണ്. കാരണം ആരും വിശദീകരിക്കാൻ കഴിയാത്തവിധം കൺവർഷൻ നിരക്കുകൾ മാറുന്നു. പ്രശസ്തമായ ഒരു API റൂട്ടു കുറച്ച് ഓട്ടോമേറ്റഡ് ക്ലയന്റുകളാണ് നയിക്കുന്നത് എന്ന് പിന്നീട് മനസ്സാകുന്നു. മാർക്കറ്റിംഗ് വിജയമായി തോന്നിയ ഒരു കുതിപ്പ് യഥാർത്ഥത്തിൽ ഡോക്യുമെന്റേഷൻ വായിച്ച ഏജന്റുകളായിരുന്നു. actor സാഹചര്യങ്ങളില്ലാതെ, ഓരോ ചാർട്ടും വളരെ വ്യത്യസ്തമായ പെരുമാറ്റങ്ങളെ ഒറ്റ വരിയിലേക്ക് കലർത്തുന്നു. ചില ടൂളുകൾ നിങ്ങൾ കാണുന്നതിന് മുൻപ് തന്നെ ചിത്രത്തിന്റെ ഒരു ഭാഗം നീക്കം ചെയ്യും: അറിയപ്പെടുന്ന ബോട്ടുകളുടെയും സ്പൈഡറുകളുടെയും ട്രാഫിക് Google Analytics സ്വയമേവ ഒഴിവാക്കുന്നു, എത്രത്തോളം ഒഴിവാക്കിയെന്ന് നിങ്ങൾക്ക് കാണാനാകില്ലെന്ന് Google പറയുന്നു (Google Analytics: known bot-traffic exclusion).
AI agent traffic analytics ഓരോ ഇടപെടലിലും ഒരു പുതിയ അളവ് ചേർത്ത് അതിനെ പരിഹരിക്കുന്നു: ആരോ എന്തോ പ്രവർത്തിക്കുന്നുവോ, നിങ്ങൾക്ക് അതിൽ എത്ര ഉറപ്പുണ്ടോ എന്ന്. വെബ്സൈറ്റ് ട്രാഫിക് AI ഏജന്റുകളിൽ നിന്നാണോ എന്ന് എങ്ങനെ തിരിച്ചറിയാം എന്ന ബ്ലോഗ് പോസ്റ്റ് ആ അളവിന് പിന്നിലെ signals ഉൾക്കൊള്ളുന്നു, കൂടാതെ websites use case അത് ഒരു production സൈറ്റിൽ എങ്ങനെ പ്രയോഗിക്കപ്പെട്ടുവെന്ന് കാണിക്കുന്നു.
actor-aware analytics നിങ്ങൾക്ക് കാണിക്കുന്നത്
Proof of Actor നിങ്ങളുടെ ട്രാഫിക്കിനെ നാല് ക്ലാസുകളായി ക്രമീകരിക്കുന്നു. Human, AI-assisted or agent: a taxonomy for app traffic-ൽ ഇത് വിശദീകരിച്ചിരിക്കുന്നു, കൂടാതെ ഓരോന്നിനോടും തെളിവ് ബന്ധിപ്പിച്ചിരിക്കുന്നു.
- Human: ദൃശ്യമാകുന്ന signals മനുഷ്യന്റെ നിയന്ത്രണം സൂചിപ്പിക്കുന്ന ഇടപെടലുകൾ.
- Human + AI: AI സഹായം പ്രഖ്യാപിച്ചതോ പിന്തുണയുള്ള integration വഴി നിരീക്ഷിച്ചതോ ആയ ഇടപെടലുകൾ.
- Agent: പരിശോധിക്കാവുന്ന identity അല്ലെങ്കിൽ സൂക്ഷ്മമായി യോഗ്യമായ inference പിന്തുണയ്ക്കുന്ന, automated അല്ലെങ്കിൽ agent-origin ഇടപെടലുകൾ.
- Unknown: വിശ്വസനീയമായ നിർണ്ണയത്തെ പിന്തുണയ്ക്കാൻ തെളിവ് പര്യാപ്തമല്ലാത്ത ഇടപെടലുകൾ.
ഓരോ ഫലത്തിനും ഒരു basis ഉണ്ട്: verified, declared, inferred അല്ലെങ്കിൽ unknown. അനലിറ്റിക്സ് വിശ്വസനീയമാക്കുന്നത് ഈ രണ്ടാം അളവാണ്. നിങ്ങളുടെ API ട്രാഫിക്കിന്റെ മൂന്നിലൊന്ന് ഏജന്റുകളാണെന്ന് ഒരു ഡാഷ്ബോർഡ് പറഞ്ഞാൽ, അത് verified signatures ആണോ request patterns ൽ നിന്നുള്ള inference ആണോ എന്നതിനെ ആശ്രയിച്ച് അതിന്റെ അർത്ഥം വളരെ വ്യത്യസ്തമാകും. Proof of Actor ഉപയോഗിച്ച് നിങ്ങൾക്ക് രണ്ടും കാണാനും, ഏതിലും അടിസ്ഥാനമാക്കി ഫിൽട്ടർ ചെയ്യാനും കഴിയും.
റൂട്ടും workflow ഉം പ്രകാരം
ഒരു ആപ്ലിക്കേഷനിൽ actor mix വളരെ വ്യത്യാസപ്പെടുന്നു. public documentation, pricing, catalog പേജുകൾ സാധാരണയായി ഏജന്റുകളും സഹായികളും ആകർഷിക്കും. signup, checkout, account settings എന്നിവയ്ക്ക് ഏജന്റുകൾ കുറവായിരിക്കും, പക്ഷേ അവ പ്രത്യക്ഷപ്പെടുമ്പോൾ കൂടുതൽ പ്രധാനമാകും. API routes, MCP tools എന്നിവ automated clients നാൽ ആധിപത്യം നേടാം. Proof of Actor ഫലങ്ങളെ route, workflow പ്രകാരം വിഭജിക്കുന്നു, അതിനാൽ ഓരോ ടീമിനും തങ്ങളുടെ ഉടമസ്ഥതയിലുള്ള ഭാഗം കാണാം.
സമയക്രമത്തിൽ
ട്രെൻഡുകൾ നിങ്ങളുടെ ഉൽപ്പന്നം ഏത് ദിശയിലേക്കാണ് പോകുന്നത് എന്ന് പറയുന്നു. പ്രധാനപ്പെട്ട routes ൽ agent, AI-assisted പ്രവർത്തനങ്ങളുടെ പങ്ക് എങ്ങനെ മാറുന്നു എന്ന് നിരീക്ഷിക്കുക, പുതിയ ഒരു agent operator നിങ്ങളുടെ ഉള്ളടക്കം വായിക്കാൻ തുടങ്ങുന്ന സമയം കാണുക, കൂടുതൽ ക്ലയന്റുകൾ അവരുടെ requests ഒപ്പിടുന്നതോടെ Unknown നിന്ന് verified ലേക്ക് എത്ര ട്രാഫിക് മാറുന്നു എന്നും പിന്തുടരുക.
വിശദീകരണങ്ങളോടെ
ഡാഷ്ബോർഡിലെ ഏത് സംഖ്യയും individual interactions വരെ തുറക്കാം. ഓരോന്നിനും നിങ്ങൾക്ക് class, basis, എന്താണ് അറിയുന്നത്, എന്താണ് അറിയാത്തത്, ഏത് policy output പ്രയോഗിക്കപ്പെടും എന്നിവ കാണാം. ഇതാണ് ഒരു ചാർട്ടിനെ നിങ്ങളുടെ product, platform, security ടീമുകൾ ഒരുമിച്ച് പ്രവർത്തിക്കാനാകുന്ന ഒന്നാക്കി മാറ്റുന്നത്.
ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു
Proof of Actor evidence-first മാർഗം പിന്തുടരുന്നു. പൂർണ്ണ വിശദീകരണം How It Works-ൽ വായിക്കാം.
- നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരു request അല്ലെങ്കിൽ event സ്വീകരിക്കുന്നു: page view, API call, MCP tool call, അല്ലെങ്കിൽ in-app action.
- ആ സന്ദർഭത്തിൽ ലഭ്യമായ signals നിങ്ങളുടെ integration ശേഖരിക്കുന്നു: സർവറിൽ request context, signatures, collector പ്രവർത്തിക്കുന്ന ബ്രൗസറിൽ interaction signals, clients ൽ നിന്നുള്ളതും നിങ്ങളുടെ സ്വന്തം application ൽ നിന്നുള്ളതുമായ declarations.
- signals പരിശോധിക്കുകയും, basis പ്രകാരം ലേബൽ ചെയ്യുകയും, സംയോജിപ്പിക്കുകയും ചെയ്യുന്നു ഒരു വർഗ്ഗീകരണത്തിലേക്ക്.
- ഫലം രേഖപ്പെടുത്തപ്പെടുന്നു അതിന്റെ basis, evidence summary എന്നിവയോടൊപ്പം, അത് നിങ്ങളുടെ analytics ലേക്ക് ഒഴുകുന്നു.
- നിങ്ങളുടെ ആപ്ലിക്കേഷൻ തീരുമാനിക്കുന്നു observe only ചെയ്യണമോ, policy പ്രയോഗിക്കണമോ എന്ന്.
അനലിറ്റിക്സും തീരുമാനങ്ങളും ഒരേ ഫലങ്ങൾ ഉപയോഗിക്കുന്നതിനാൽ, നിങ്ങൾ പഠിക്കുന്ന സംഖ്യകൾ നിങ്ങളുടെ policies പ്രവർത്തിക്കുന്ന അതേ സംഖ്യകളാണ്. ഡാഷ്ബോർഡ് പറയുന്നതും ആപ്ലിക്കേഷൻ ചെയ്യുന്നതും തമ്മിൽ ഒരു വിടവും ഇല്ല.
Detect, Understand, Route
AI agent traffic analytics Proof of Actor-ന്റെ മൂന്ന് capabilities-കളുടെ മധ്യത്തിലാണ്.
Detect
ഓരോ integration-നും ലഭ്യമായ actor signals ശേഖരിക്കുക, verified assertions നെ behavioral inferences ൽ നിന്ന് വേർതിരിക്കുക. Unknown സ്വന്തം class ആയി ദൃശ്യമാകുന്നു, അതിനാൽ coverage gaps മറ്റൊരു സംഖ്യയുടെ ഉള്ളിൽ മറയുന്നില്ല.
Understand
ഇതാണ് analytics പാളി: actor breakdowns, interaction trends, route-level views, explainable classifications. ഏത് routes ലാണ് agents ആശ്രയിക്കുന്നത്, ഒരു workflow എത്ര AI-assisted പ്രവർത്തനം കാണുന്നു, policy പിന്തുണയ്ക്കാൻ തെളിവ് എവിടെയാണ് ശക്തം എന്നതുപോലുള്ള ചോദ്യങ്ങൾക്ക് ടീമുകൾ ഇതുപയോഗിക്കുന്നു.
Route
അനലിറ്റിക്സ് വ്യക്തമായ ഒരു മാതൃക കാണിക്കുമ്പോൾ, നിങ്ങളുടെ സ്വന്തം നിയമങ്ങൾ ഉപയോഗിച്ച് അതിൽ പ്രവർത്തിക്കുക. verified agents നു അവർ ഏറ്റവും കൂടുതൽ വായിക്കുന്ന ഉള്ളടക്കത്തിലേക്കുള്ള ഘടിത പാത നൽകുക. മനുഷ്യർ നയിക്കുന്ന sessions ന് സാധാരണ അനുഭവം നിലനിർത്തുക. നിങ്ങളുടെ സ്വന്തം conditions അത് ന്യായീകരിക്കുമ്പോഴേ sensitive actions ന് review ചേർക്കുക. Unknown നും timeouts നും വ്യക്തമായ fallbacks സജ്ജമാക്കുക.
apps, APIs, MCP servers എന്നിവയ്ക്കായി നിർമ്മിച്ചത്
മഷീനുകൾക്ക് സ്വാഗതമുള്ളിടത്താണ് agent പ്രവർത്തനം കൂടുതലായി കേന്ദ്രീകരിക്കുന്നത്: APIകൾ, ഡോക്യുമെന്റേഷൻ, catalogകൾ, tools. അതുകൊണ്ടാണ് Proof of Actor page views-നെക്കാൾ കൂടുതലിനെ ഉൾക്കൊള്ളുന്നത്.
- SaaS apps and websites browser sessions നും അവയ്ക്കു പിന്നിലെ server routes നും actor context കാണുന്നു. കൂടുതൽ അറിയാൻ SaaS Apps & Websites വായിക്കുക.
- APIകൾ signed client identity നെ API credentials, authorization എന്നിവയിൽ നിന്ന് വേർതിരിക്കുന്ന request-level context നേടുന്നു. കൂടുതൽ അറിയാൻ APIs വായിക്കുക.
- MCP servers ഓരോ tool call-നും actor context ലഭിക്കുന്നു, അതിനാൽ ഏത് clients ഏത് tools ഉപയോഗിക്കുന്നു എന്ന് നിങ്ങൾക്ക് കാണാം. കൂടുതൽ അറിയാൻ MCP Servers വായിക്കുക.
Founding ടീമുകൾ ഞങ്ങളുടെ engineers ന്റെ നേരിട്ടുള്ള സഹായത്തോടെയാണ് integration ചെയ്യുന്നത്. Node.js app-ലേക്ക് actor context ചേർക്കുന്നത് എന്ന guide സാധാരണ request handler-ൽ integration എവിടെയാണ് ഇരിക്കുന്നതെന്ന് കാണിക്കുന്നു.
വാളിയത്തിനേക്കാൾ തെളിവ് പ്രധാനമാണ്
agent traffic നു ഒരു വലിയ സംഖ്യ ഉണ്ടാക്കുന്നത് എളുപ്പമാണ്. browser fingerprint ഇല്ലാത്ത ഓരോ request-ഉം എണ്ണി അതിനെ automation എന്ന് വിളിക്കുക. പ്രശ്നം അത്തരം ഒരു സംഖ്യക്ക് തീരുമാനത്തെ പിന്തുണയ്ക്കാനാവില്ല എന്നതാണ്, കാരണം അതിൽ എത്ര ഭാഗമാണ് യഥാർത്ഥം എന്ന് ആർക്കും അറിയില്ല.
Proof of Actor ഓരോ സംഖ്യയും ന്യായീകരിക്കാവുന്നതാക്കുന്ന വിധത്തിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്. verified results യഥാർത്ഥത്തിൽ കടന്നുപോയ checks-ൽ നിന്നാണ് വരുന്നത്. Declarations പ്രഖ്യാപനങ്ങളായാണ് ലേബൽ ചെയ്യപ്പെടുന്നത്. Inferences inferences ആയും ലേബൽ ചെയ്യപ്പെടുന്നു. Unknown Unknown ആയി റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു. നിങ്ങൾ agent traffic നിങ്ങളുടെ leadership, security team, അല്ലെങ്കിൽ customers മുമ്പിൽ അവതരിപ്പിക്കുമ്പോൾ, ഓരോ സംഖ്യയും എവിടെ നിന്നാണ് വന്നത് എന്ന് കൃത്യമായി വിശദീകരിക്കാൻ കഴിയും.
ഇത് സമയത്തിനൊപ്പം analytics-നെ കൂടുതൽ പ്രയോജനപ്രദമാക്കുകയും ചെയ്യുന്നു. agent operators RFC 9421 HTTP Message Signatures അടിസ്ഥാനമാക്കിയ signed requests സ്വീകരിക്കുന്നതിനും, Web Bot Auth പോലുള്ള standards പ്രവർത്തനം IETF webbotauth working group-ൽ പുരോഗമിക്കുന്നതിനും ഒപ്പം, നിങ്ങളുടെ ട്രാഫിക്കിന്റെ കൂടുതൽ ഭാഗം verified basis ലേക്ക് മാറുന്നു. നിങ്ങൾ വായിക്കുന്ന രീതി മാറ്റാതെ തന്നെ നിങ്ങളുടെ ചാർട്ടുകൾ കൂടുതൽ വ്യക്തതയാർജ്ജിക്കുന്നു.
ആദ്യം observation, പിന്നെ തീരുമാനം
ഓരോ Proof of Actor deployment-ും observation mode-ൽ നിന്നാണ് ആരംഭിക്കുന്നത്. ഫലങ്ങൾ രേഖപ്പെടുത്തപ്പെടുന്നു, analytics നിറയുന്നു, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ മുമ്പുപോലെ തന്നെ പ്രതികരിച്ചുകൊണ്ടിരിക്കുന്നു. നിങ്ങളുടെ ടീം ആ കാലയളവ് ഒരു baseline നിർമ്മിക്കാൻ, നിങ്ങൾക്ക് ഇതിനകം അറിയാവുന്ന outcomes നോട് ഫലങ്ങൾ താരതമ്യം ചെയ്യാൻ, policy യഥാർത്ഥത്തിൽ സഹായിക്കുന്ന ആദ്യ routes കണ്ടെത്താൻ എന്നിവയ്ക്കായി ഉപയോഗിക്കുന്നു.
നിങ്ങൾ തയ്യാറാകുമ്പോൾ, ഒരു workflow-ക്കായി policy പ്രവർത്തനക്ഷമമാക്കുക, അതിന്റെ ഫലം അളക്കുക, തുടർന്ന് അതിൽ നിന്ന് വ്യാപിപ്പിക്കുക. Proof of Actor ഇൻസ്റ്റാൾ ചെയ്തതുകൊണ്ട് ഒന്നും തടയപ്പെടുന്നില്ല. എല്ലാ enforcement തീരുമാനങ്ങളും നിങ്ങളുടേതാണ്.
founding developer program-ിൽ ചേരുക
Proof of Actor private beta-യിലാണ്. തിരഞ്ഞെടുത്ത founding developer ടീമുകൾക്ക്, കൈമോശം product feedback ന്റെ പ്രതിഫലമായി, കരാറിൽ നിശ്ചയിച്ച usage limits ഉള്ളിൽ 12 മാസം വരെ സൗജന്യ access ലഭിക്കാം. നിങ്ങൾക്ക് നേരിട്ടുള്ള integration support, പുതിയ capabilities-ലേക്കുള്ള early access, roadmap-ിൽ സ്വാധീനം എന്നിവ ലഭിക്കും.
നിങ്ങളുടെ മുഴുവൻ ടീമിനും വിശ്വസിക്കാനാകുന്ന AI agent traffic analytics വേണമെങ്കിൽ, early access ന് അപേക്ഷിക്കുക. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ, നിങ്ങൾക്ക് ഏറ്റവും പ്രധാനമായ routes, നിങ്ങളുടെ analytics ഉത്തരം പറയണമെന്നു നിങ്ങൾ ആഗ്രഹിക്കുന്ന ചോദ്യങ്ങൾ എന്നിവ ഞങ്ങളോട് പറയുക.
Proof of Actor അന്വേഷിക്കുക, how it works കാണുക, അല്ലെങ്കിൽ തെളിവ് എന്താണ് സ്ഥാപിക്കാനാകുന്നത് വായിക്കുക.
Sources
- OpenAI crawlers-ന്റെ അവലോകനം, OpenAI.
- Known bot-traffic exclusion, Google Analytics Help.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.