अज्ञात ट्रॅफिक

अज्ञात स्वयंचलित ट्रॅफिक दृश्यमान करा

बहुतेक applications त्यांच्या स्वयंचलित ट्रॅफिकपैकी मोठा भाग नेमका काय आहे हे सांगू शकत नाहीत. Proof of Actor हा ट्रॅफिक स्वतंत्र वर्ग म्हणून दृश्यमान ठेवते, त्यामुळे तुम्ही त्याचे मोजमाप करू शकता, ते कमी करू शकता आणि जाणीवपूर्वक हाताळू शकता.

लवकर प्रवेश मिळवा ते कसे कार्य करते ते अन्वेषित करा

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

ज्याचे नाव कोणी देऊ शकत नाही असा ट्रॅफिक

एखाद्या application's logs नीट पाहिल्यास तुम्हाला अशी requests सापडतील ज्यांचे स्पष्टीकरण देणे कठीण जाते. त्या browser context नसलेल्या clients कडून येतात. त्यांचे user-agent strings generic, रिकामे किंवा एखाद्या लोकप्रिय browser मधून कॉपी केलेले असतात. ते त्यांच्या requests sign करत नाहीत. ते कोणी पाठवले हे सांगत नाहीत. काही निरुपद्रवी scripts असतात. काही real users साठी काम करणारे agents असतात. काही अशी साधने असतात ज्यांना तुम्हाला मुळीच serve करायचे नसते.

हा अज्ञात स्वयंचलित ट्रॅफिक आहे, आणि बहुतेक teams त्याला दोनपैकी एका पद्धतीने हाताळतात. एक तर त्याची शांतपणे human म्हणून गणना केली जाते, ज्यामुळे analytics विकृत होतात आणि धोकादायक activity पुढे जाऊ शकते, किंवा default ने त्याला hostile मानले जाते, ज्यामुळे legitimate users आणि agents सुद्धा इतर सर्व गोष्टींसह block होतात. दोन्ही दृष्टिकोनांमध्ये एकच flaw आहे: ते missing evidence ऐवजी assumption वापरतात.

Proof of Actor याच्या विरुद्ध भूमिका घेते. जर पुरावा विश्वासार्ह determination ला आधार देत नसेल, तर योग्य उत्तर Unknown आहे, आणि Unknown दृश्यमान, मोजता येण्यासारखा आणि जाणीवपूर्वक हाताळलेला असायला हवा. blog post why Unknown is a valid result for AI traffic मध्ये याचा सविस्तर युक्तिवाद दिला आहे.

Unknown हा प्रथम श्रेणीचा result का आहे

Proof of Actor प्रत्येक interaction ला चार वर्गांपैकी एका वर्गात ठेवते: Human, Human + AI, Agent किंवा Unknown. Unknown हा error state नाही आणि product मधील gap सुद्धा नाही. तो एक जाणीवपूर्वक दिलेला result आहे, ज्याचा नेमका अर्थ असा आहे: उपलब्ध पुरावा विश्वासार्ह determination ला आधार देत नाही.

त्या प्रामाणिकपणाचे व्यवहार्य फायदे आहेत.

तुमची analytics अचूक राहतात. Human आणि Agent counts मध्ये फक्त आधार देणारा पुरावा असलेले interactions समाविष्ट होतात, त्यामुळे त्यांचा अर्थ तसाच राहतो.
तुमचे coverage मोजता येते. प्रत्येक route वरील Unknown चा हिस्सा नेमके कुठे अधिक पुरावा हवा आहे ते दाखवतो.
तुमच्या policies अधिक सुरक्षित होतात. अनिश्चित प्रकरणे तुम्ही निवडलेल्या fallback मध्ये जातात, त्यांना गुपचूप trusted म्हणून किंवा अंदाजावर block म्हणून हाताळले जात नाही.

Unknown कधीच Human मध्ये convert केले जात नाही, आणि default ने त्याला malicious मानले जात नाही. तुम्ही Unknown classification glossary entry मध्ये, Detection & Limitations मध्ये, आणि why Unknown is a valid result for AI traffic मध्ये अधिक वाचू शकता. websites आणि APIs use cases दाखवतात की teams प्रत्यक्षात Unknown fallbacks कसे सेट करतात.

अज्ञात स्वयंचलित ट्रॅफिक कुठून येतो

स्रोत समजून घेतल्याने तो कसा हाताळायचा हे ठरवायला मदत होते.

Unsigned automated clients

RFC 9421 मध्ये परिभाषित केलेले HTTP Message Signatures वापरून request signing ऐच्छिक आहे, आणि IETF Web Bot Auth working group अजून automated clients ने या पद्धतीने कसे authenticate करावे हे standardize करत आहे. signature नसल्यास, clientची ओळख तो स्वतःबद्दल काय म्हणते यावरच अवलंबून असते.

कॉपी केलेले किंवा generic user agents

User-agent strings सेट करणे अत्यंत सोपे आहे. एखादा client स्वतःला सुप्रसिद्ध browser किंवा crawler म्हणून सांगत असेल, तर तो खरोखरच तो असू शकतो, किंवा त्याची नक्कल करत असू शकतो. user-agent spoofing entry स्पष्ट करते की हा header एकटाच classification वाहून नेऊ शकत नाही. म्हणूनच search engines स्वतंत्र verification methods दस्तऐवजीकरण करतात: Google verifying Googlebot साठी reverse आणि forward DNS lookups तसेच प्रकाशित IP ranges वर्णन करते, आणि Bing verifying Bingbot साठी तोच DNS check वर्णन करते.

Integration नसलेले routes

जर एखाद्या route कडे browser integration नसेल आणि मूलभूत गोष्टींपलीकडे server-side context नसेल, तर निरीक्षण करण्यास कमी गोष्टी उरतात. अशा routes वरील Unknown हा coverage चा संकेत आहे, threat चा नाही.

Missing किंवा delayed evidence

timeout, blocked script किंवा incomplete request मुळे result कडे पुरेसा पुरावा नसू शकतो. Proof of Actor ते भरून काढण्याऐवजी प्रामाणिकपणे तसेच नोंदवते.

Proof of Actor Unknown ला व्यवस्थापित कसे करते

Proof of Actor आपले काम तीन capabilities मध्ये संघटित करते. प्रत्येक capability अज्ञात स्वयंचलित ट्रॅफिकसाठी मदत करते.

Detect: Unknown वेगळा ठेवा

Signals तपासले जातात आणि basis नुसार label केले जातात: verified, declared, inferred किंवा unknown. जेव्हा ते determination ला आधार देत नाहीत, तेव्हा result Unknown म्हणून नोंदवला जातो आणि काय उपलब्ध होते आणि काय नव्हते याचा सारांश दिला जातो. काहीही दुसऱ्या वर्गात अंदाजाने टाकले जात नाही.

Understand: Unknown कुठे आहे ते पाहा

Understand view मध्ये प्रत्येक breakdown मध्ये, routeनुसार आणि काळानुसार Unknown दिसतो. कोणत्या routes वर सर्वाधिक unknown activity आहे, integration जोडल्यावर ते कसे बदलते, आणि individual interactions साठी कोणता पुरावा उपस्थित होता हे तुम्ही पाहू शकता. यामुळे धूसर चिंता एका ठोस नकाशात बदलते.

Route: प्रत्येक route साठी fallback निवडा

वेगवेगळ्या routes ना वेगवेगळे fallbacks योग्य ठरतात. अनेक applications साठी एक वाजवी सुरुवात अशी:

Public pages आणि documentation: तुमच्या standard rate limits सह Unknown ला allow करा.
Signup आणि onboarding: तुमचे विद्यमान checks ठेवा, आणि तुमच्या स्वतःच्या अटी लागू झाल्यावरच review जोडा.
Account changes आणि इतर sensitive actions: तुमच्या विद्यमान authentication आणि step-up controls वर अवलंबून राहा, actor guess वर कधीच नाही.
High-impact API operations: तुमच्या API ने आधीच support केलेली अधिक मजबूत credentials किंवा controls आवश्यक ठेवा.

handling unknown traffic या guide मध्ये हे fallbacks कसे डिझाइन करायचे, तसेच प्रत्येक risk tier साठी fail-open आणि fail-closed निवडी, याबद्दल स्पष्ट केले आहे.

Unknown कालांतराने कमी करणे

ध्येय Unknown पूर्णपणे एका रात्रीत काढून टाकणे नाही. योग्य कारणांसाठी ते दर महिन्याला छोटे होत जाणे हे ध्येय आहे.

महत्त्वाच्या ठिकाणी integrations जोडा. मुख्य pages वर browser integration आणि महत्त्वाच्या routes वर server-side integration उपलब्ध पुरावा वाढवतात.
Signed requests ला समर्थन द्या. agent operators HTTP message signatures स्वीकारत गेल्यावर, पूर्वी Unknown असलेला ट्रॅफिक verified Agent traffic बनतो.
तुमच्या स्वतःच्या app मध्ये declarations नोंदवा. तुमच्या application ला AI assistance सहभागी आहे हे माहीत असल्यास, तसे सांगा. तो पुरावा अचूक आणि स्वस्त असतो.
Agents साठी front door द्या. संरचित path प्रकाशित केल्याने agents स्वतःची ओळख देण्यास प्रोत्साहित होतात, लपून मिसळण्याऐवजी.

Proof of Actor routeनुसार Unknown ट्रॅक करत असल्यामुळे, तुम्हाला या प्रत्येक बदलांचे परिणाम संख्यांमध्ये दिसतात.

ते कसे काम करते

प्रत्येक interaction तोच evidence-first path अनुसरतो, ज्याचे संपूर्ण वर्णन How It Works येथे आहे: तुमचे application request किंवा event प्राप्त करते, integration त्या context मध्ये उपलब्ध signals गोळा करते, signals normalize आणि classify केले जातात आणि explicit basis दिला जातो, result analytics साठी नोंदवला जातो, आणि तुमचे application स्वतःची policy लागू करते किंवा फक्त observe करते.

Timeouts आणि missing telemetry स्पष्टपणे हाताळले जातात. तुमचे integration त्या route साठी तुम्ही निवडलेला fallback वापरते, आणि पुरावा नसल्यामुळे result कधीच Human मध्ये upgrade केला जात नाही.

काही महिन्यांनंतर चांगली स्थिती कशी दिसते

अज्ञात स्वयंचलित ट्रॅफिक चांगल्या प्रकारे हाताळणाऱ्या teams सहसा त्याच आरोग्यदायी स्थितीपर्यंत पोहोचतात. Unknown हा प्रत्येक महत्त्वाच्या route वर एक ज्ञात quantity असतो, human आणि agent activity च्या त्याच dashboard मध्ये tracked. प्रत्येक route साठी एक लिखित fallback असतो, ज्यावर product, platform आणि security teams यांनी एकत्र सहमती दिलेली असते. अधिक operators त्यांच्या requests sign करत गेल्याने verified agent traffic वाढतो, आणि त्या agents ना pages scrape करण्याऐवजी संरचित path द्वारे serve केले जाते. संवेदनशील actions वर authentication आणि step-up controls वापरले जातात, ज्यांवर application आधीच विश्वास ठेवते, आणि actor context हे gatekeeper न राहता एक अतिरिक्त input बनते.

सर्वात महत्त्वाचे म्हणजे, कोणीही अंदाज लावत नाही. जेव्हा कोणी विचारते की गेल्या आठवड्यातील ट्रॅफिकपैकी किती भाग स्वयंचलित होता, तेव्हा उत्तर त्याच्या basis सह येते: इतका verified, इतका declared, इतका inferred, आणि इतका अजूनही Unknown. हा असा आकडा आहे ज्याभोवती टीम नियोजन करू शकते. तो नेतृत्वाशी होणारा संवादही बदलतो, कारण प्रश्न bots समस्या आहेत का यावरून हटून कोणत्या routes ना अधिक पुरावा हवा आहे आणि कोणत्या fallbacks ना सुधारणा हवी आहे याकडे वळतो.

observation mode मध्ये सुरू करा

Proof of Actor default ने काहीही block करत नाही. observation mode मध्ये, results नोंदवले जातात, तर तुमचे application पूर्वीप्रमाणेच प्रतिसाद देते. तुमची team प्रत्येक route ला किती अज्ञात स्वयंचलित ट्रॅफिक मिळतो ते पाहते, ते तुम्हाला आधीच माहीत असलेल्या outcomes शी तुलना करते, आणि प्रत्यक्ष patterns वर आधारित fallbacks डिझाइन करते. तुमच्या team ला जेव्हा खात्री वाटते की त्या बसतात, तेव्हा policies एकावेळी एक route वर सक्षम केल्या जातात.

founding developer program मध्ये सहभागी व्हा

Proof of Actor private beta मध्ये आहे. निवडलेल्या founding developer teams ना agreed usage limits अंतर्गत, hands-on product feedback च्या बदल्यात, 12 months free access मिळू शकतो, आणि आमच्या engineers कडून direct integration support मिळते.

जर अज्ञात स्वयंचलित ट्रॅफिक तुमची analytics किंवा सुरक्षा निर्णय ढगाळ करत असेल, तर apply for early access. तुमच्या application बद्दल आणि Unknown सर्वाधिक महत्त्वाचा असलेल्या routes बद्दल आम्हाला सांगा.

Proof of Actor पहा, how it works वाचा, किंवा what the evidence can establish पहा.

स्रोत

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.

विकसकांसाठी

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent किंवा Unknown.
basis: पुरावा किती मजबूत आहे: Verified, Declared, Inferred किंवा Unknown.
evidence: result मागचे signals, जेणेकरून तुमची team कारण पाहू शकेल.

observation mode मध्ये सुरुवात करा: results तुमच्या logs च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

वारंवार विचारले जाणारे प्रश्न

अज्ञात स्वयंचलित ट्रॅफिक म्हणजे काय?

ही अशी क्रिया आहे जिथे उपलब्ध पुरावा एखादी व्यक्ती, AI सोबत असलेली व्यक्ती किंवा autonomous agent कार्यरत आहे की नाही हे विश्वासार्हपणे दाखवत नाही, अनेकदा browser context नसलेले unsigned clients आणि generic किंवा कॉपी केलेले user-agent strings असतात.

फक्त अज्ञात ट्रॅफिक ब्लॉक का करू नये?

Unknown हे malicious सारखेच नसते. त्यात वैध clients, privacy-focused browsers आणि स्वतःची ओळख न देणारी साधने यांचा समावेश असतो. ते थेट block केल्याने प्रत्यक्ष नुकसान होते. प्रत्येक route साठी जाणीवपूर्वक fallback खूप चांगला ठरतो.

Proof of Actor कधीही Unknown ला Human मध्ये बदलते का?

कधीच नाही. पुरावा नसला किंवा एखादी check वेळेत पूर्ण झाली नाही तरी Unknown result Unknownच राहतो. प्रत्येक route साठी fallback तुमची policy ठरवते.

अज्ञात ट्रॅफिक काळानुसार कमी करता येतो का?

हो. अधिक routes वर integrations जोडणे, signed requests ला समर्थन देणे, आणि तुमच्या app मध्ये declarations नोंदवणे - या सगळ्यामुळे ट्रॅफिक Unknown मधून स्पष्ट basis असलेल्या वर्गांमध्ये जातो.

अज्ञात ट्रॅफिक मी कुठे पाहू शकतो?

Understand view मध्ये Unknown प्रत्येक breakdown मध्ये स्वतःच्या वर्गासह दिसतो, routeनुसार आणि काळानुसार, आणि प्रत्येक interaction साठी उपलब्ध असलेला पुरावा देखील दिसतो.

तुमचे app कोण वापरत आहे ते जाणून घ्या.

founding developers च्या छोट्या गटासाठी private beta.

लवकर प्रवेश मिळवा किमती पहा

आधी बोलणे पसंत आहे? founders शी बोला