તમારા app માં Unknown traffic ને કેવી રીતે સંભાળવું

શું Unknown error છે કે result?

જ્યારે તમે interactions ને Human, Human + AI, Agent અથવા Unknown તરીકે classify કરવાનું શરૂ કરો છો, ત્યારે Unknown bucket ઘણી વખત લોકોની અપેક્ષા કરતાં મોટો હોય છે. તેને ખામી તરીકે છુપાવી દેવાની લાલચ થાય છે, είτε Unknown ને Human માં ભેળવીને અથવા તેને suspicious ગણાવીને. બંને પસંદગીઓ સમસ્યા ઊભી કરે છે.

Unknown નો અર્થ છે કે ઉપલબ્ધ evidence વિશ્વસનીય નિર્ણયને support કરતું નથી. એવું request જે client થી આવે છે અને જેમાં કોઈ JavaScript ચાલતું નથી, endpoint પર એવી call જ્યાં તમે કોઈ signal એકત્રિત કરતા નથી, એક page પછી પૂરી થયેલો session: આ બધું સંપૂર્ણપણે legitimate હોઈ શકે છે, અને આમાંથી કોઈપણ તમને કોણ કે શું acting હતું તે કહેવા માટે પૂરતું નથી.

Unknown ને ઈમાનદારીથી report કરવું જ બાકીના classes ને વિશ્વસનીય રાખે છે. જો તમારી system ક્યારેય Unknown નથી કહેતી, તો દરેક Human result ભાગરૂપે અંદાજ બને છે, અને તમે કયો ભાગ છે તે જાણી શકતા નથી. AI traffic ને classify કરતી વખતે Unknown એક valid result કેમ છે તેના પરનો અમારો post (/blog/why-unknown-is-a-valid-result-for-ai-traffic) વધુ વિગતમાં reasoning સમજાવે છે.

આ guide માં practical રીતે Unknown ને કેવી રીતે સંભાળવું તે આવરી લેવામાં આવ્યું છે: દરેક route માટે explicit fallback, તેને અન્ય classes માં ફેલાતું અટકાવવાના નિયમો, તેને monitor કેવી રીતે કરવું, અને જ્યાં મહત્વ હોય ત્યાં તેને કેવી રીતે ઘટાડવું.

Step 1: ક્યારેય Human ને default ન કરો

સૌથી સામાન્ય ભૂલ એ છે કે classification function automation signal ન મળે ત્યારે Human return કરે. તે યોગ્ય લાગે છે અને ખોટું છે. bot signal ન હોવું human signal હોવું નથી.

// Wrong: silence becomes Human
function classifyWrong(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  return { actor: "human", basis: "inferred" };
}

// Right: Human requires positive evidence, otherwise Unknown
function classify(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  if (e.interactiveSession) return { actor: "human", basis: "inferred" };
  return { actor: "unknown", basis: "unknown" };
}

પરિણામો જ્યાં બને ત્યાં દરેક જગ્યાએ એ જ નિયમ લાગુ કરો: timeout, error, stale cache entry અને missing telemetry બધા Unknown ઉત્પન્ન કરે. આ દરેક path માટે test લખો જેથી behavior શાંતિથી regress ન થઈ શકે. નીચેનું example built-in Node.js test runner નો ઉપયોગ કરે છે.

import { test } from "node:test";
import assert from "node:assert/strict";

test("missing evidence is unknown, not human", () => {
  const r = classify({ signatureValid: false, declaredAgent: false, interactiveSession: false });
  assert.equal(r.actor, "unknown");
});

Step 2: દરેક route ને explicit fallback આપો

Unknown ને નિર્ધારિત behavior જોઈએ છે, અને સાચું behavior route પર આધાર રાખે છે. તેને દરેક route માટે નક્કી કરો, લખી રાખો, અને configuration માં રાખો. આ fallbacks wider policy model માં કેવી રીતે ફિટ થાય છે તે જાણવા માટે humans અને AI agents માટે app-level policies design કરવી જુઓ.

Pattern સરળ છે. ઓછા risk વાળા routes માટે, Unknown સામાન્ય traffic જેવું વર્તે છે. વધારે risk વાળા routes માટે, Unknown ને route પાસે પહેલેથી જે protection છે તે જ મળે છે. બંને સ્થિતિમાં actor result એક unclassified પરંતુ legitimate user માટે બાબતોને વધુ ખરાબ બનાવતો નથી.

type Fallback = "allow" | "standard_limit" | "existing_checks" | "review";

const unknownFallback: Record<string, Fallback> = {
  "GET /docs/*": "allow",
  "GET /api/catalog": "standard_limit",
  "POST /signup": "existing_checks",
  "POST /account/password": "existing_checks",
  "POST /exports": "review",
};

Step 3: timeout અને error ને એકસરખી રીતે treat કરો

Actor evaluation request path પર બેસે છે, તેથી તેનું time budget કડક હોવું જોઈએ. જ્યારે budget વટાવે, ત્યારે Unknown ઉત્પન્ન કરો અને route fallback લાગુ કરો. Evaluation ધીમું હતું તેથી ક્યારેય request ને block ન કરો.

async function withBudget<T>(work: Promise<T>, ms: number, onTimeout: T): Promise<T> {
  let timer: NodeJS.Timeout;
  const timeout = new Promise<T>((resolve) => {
    timer = setTimeout(() => resolve(onTimeout), ms);
  });
  try {
    return await Promise.race([work, timeout]);
  } finally {
    clearTimeout(timer!);
  }
}

const result = await withBudget(evaluateActor(req), 150, { actor: "unknown", basis: "unknown" });

Result કેમ Unknown છે તે record કરો: no evidence, timeout, evaluation error અથવા stale evidence. આ કારણો તમને શું fix કરવું તે કહે છે.

Step 4: Unknown ને suspicious ન ગણો

Unknown કોઈ risk score નથી. ઘણા legitimate clients કેટલાક routes પર હંમેશા Unknown જ રહેશે: command-line tools, server-side integrations without signatures, accessibility tools, privacy-focused browsers અને simple feed readers. આજકાલ મોટા AI operators પણ પોતાના fetchers ને મુખ્યત્વે user agent અને published IP ranges દ્વારા ઓળખાવે છે. ઉદાહરણ તરીકે, OpenAI's crawler documentation November 2026 સુધી તેના દરેક bot માટે user agent string અને published IP address file યાદ કરે છે.

જો તમને suspicious behavior પર કાર્યવાહી કરવી હોય, તો તે behavior પર આધાર રાખો જેને તમે વર્ણવી શકો, જેમ કે request rates, failed login patterns અથવા abuse reports, અને તેના માટે પોતાનું evidence રાખો. આ logic ને actor class થી અલગ રાખો જેથી એક બીજાને વાંકો ન પાડે.

Step 5: તમારો unknown rate કેવી રીતે monitor કરશો?

Unknown rate એટલે Unknown તરીકે classify થયેલી interactions નો હિસ્સો. તેને દરેક route માટે, દરેક integration context માટે અને સમય સાથે track કરો. આ તમારા હાથમાં રહેલા સૌથી ઉપયોગી health metrics માંનું એક છે.

type Row = { route: string; actor: string };

export function unknownRate(rows: Row[]) {
  const byRoute = new Map<string, { total: number; unknown: number }>();
  for (const r of rows) {
    const s = byRoute.get(r.route) ?? { total: 0, unknown: 0 };
    s.total += 1;
    if (r.actor === "unknown") s.unknown += 1;
    byRoute.set(r.route, s);
  }
  return [...byRoute].map(([route, s]) => ({ route, rate: s.unknown / s.total, total: s.total }));
}

આ numbers શું કહે છે:

• Route પર ઊંચો, સ્થિર rate સામાન્ય રીતે એ દર્શાવે છે કે ત્યાં signal ગુમ છે. જે page કદી તમારી browser integration load નથી કરતી, અથવા જે API કદી signed requests નથી જોતી, તે મોટા ભાગે Unknown જ રહેશે.
• અચાનક વધારો ઘણી વખત દર્શાવે છે કે તમારા stack માં કંઈક બદલાયું છે, જેમ કે header છોડતી release, signature headers strip કરતી CDN rule, અથવા એવી frontend change કે જેણે તમારા app ની declarations મોકલવાનું બંધ કર્યું.
• અચાનક ઘટાડો પણ ચકાસવા જેવો છે. જો Unknown ઘટે અને Human વધે, તો ખાતરી કરો કે નવી evidence આવી છે, કોઈ fallback શાંતિથી બદલાઈ નથી.

Absolute levels પર નહીં, sharp changes પર alert કરો. દરેક application નો પોતાનો normal હોય છે.

Step 6: જ્યાં મહત્વ હોય ત્યાં Unknown કેવી રીતે ઘટાડશો?

તમારે Unknown ને શૂન્ય સુધી લાવવા જરૂરી નથી. જ્યાં નિર્ણયો મહત્વના હોય ત્યાં પૂરતું evidence હોવું જરૂરી છે. અસરના ક્રમમાં આગળ વધો:

1. સૌપ્રથમ high-impact routes પર evidence ઉમેરો. જો account changes મોટાભાગે Unknown છે, તો ત્યાં browser integration અથવા server-side check સૌથી વધુ ફાયદાકારક છે.
2. Automated clients ને પોતે ઓળખાવવા કહો. તમારા API માટે documentation પ્રકાશિત કરો, જે સમજાવે કે agents HTTP Message Signatures અને IETF Web Bot Auth conventions સાથે requests કેવી રીતે sign કરી શકે, અને verified clients ને better experience આપો, જેમ કે higher limits અથવા structured responses. Verify કરી શકતા clients એવું કરવાનું શરૂ કરશે.
3. તમારું own application knowledge વાપરો. જો users તમારા built-in assistant સાથે interact કરે છે, તો તેને declaration તરીકે record કરો. તમારી app ઘણી વખત network કરતાં વધુ જાણતી હોય છે.
4. Plumbing સુધારો. ખાતરી કરો કે proxies તમે rely કરો છો તે headers forward કરે છે અને evaluation પૂરી કરવા માટે પૂરતો time budget ધરાવે છે.

Unknown માંથી traffic ને બહાર કાઢતા signals નો practical look માટે website traffic AI agents માંથી આવે છે કે નહીં તે કેવી રીતે કહેવું વાંચો.

Step 7: Dashboards માં Unknown ને ઈમાનદારીથી બતાવો

Unknown ને અન્ય classes જેટલું જ visual weight આપીને તેની own series તરીકે બતાવો. તેને "other" bucket માં છુપાવો નહીં, અને તેને alert જેવો રંગ આપશો નહીં. જ્યારે stakeholders મોટો Unknown હિસ્સો જુએ, ત્યારે યોગ્ય પ્રતિભાવ "અમને ક્યાં વધુ evidence જોઈએ" હોવો જોઈએ, "bots ક્યાં છે" નહીં.

Step 8: Assumptions નહીં, outcomes સાથે Unknown ની સમીક્ષા કરો

દર થોડા અઠવાડિયે, તમારા સૌથી મહત્વના routes માંથી Unknown interactions નો sample લો અને ખરેખર શું થયું તે જુઓ. શું session ને purchase પૂર્ણ કર્યું, project બનાવ્યો, ત્રણ articles વાંચ્યાં, કે login પર વારંવાર નિષ્ફળ ગયું? Outcomes તમને bucket માં કયા પ્રકારનો traffic છે તે જણાવે છે, તેના પર સમય પહેલાં label ચોંટાડ્યા વિના.

જે તમે શોધો તેને ત્રણ ઉપયોગી categories માં ગોઠવો:

1. Legitimate અને low risk. Feed readers, link previews, monitoring tools અને privacy settings વાળા લોકો. Route fallback જેમ છે તેમ રાખો.
2. Legitimate automation જે પોતે ઓળખાવી શકે. એવા integrations અને agents જે તમે structured path આપો અથવા requests sign કરવા કહો તો આનંદથી કરે. માર્ગદર્શન પ્રકાશિત કરો અને જ્યાં શક્ય હોય ત્યાં સંપર્ક કરો.
3. એવું behavior જેને પોતાનું control જોઈએ. Credential stuffing અથવા scraping patterns, બંને OWASP Automated Threats to Web Applications project માં catalogued છે. આને એવા behavior-based controls વડે address કરો, જેમને પોતાનું evidence હોય, જેમ કે login failure rates, અને તેમને actor class થી અલગ રાખો.

આ review તમારા fallbacks ને તમારી વાસ્તવિક traffic માં grounded રાખે છે અને તમને આગળ evidence ક્યાં ઉમેરવું તેની સ્પષ્ટ યાદી આપે છે.

સામાન્ય પ્રશ્નો

શું Unknown ને rate limits તરફ ગણવું જોઈએ? તમારા standard limits વાપરો. Verified agents માટે class પ્રમાણે rate limiting યોગ્ય છે, કારણ કે તેઓ higher limits કમાઈ શકે છે, પરંતુ Unknown ને normal limit મળવી જોઈએ, punitive limit નહીં.

શું આપણે Unknown users ને challenge કરી શકીએ? ફક્ત ત્યાં જ્યાં route પહેલેથી જ એ સ્થિતિમાં દરેકને challenge કરે છે. કોઈ result Unknown હોવાથી માત્ર challenge ઉમેરવાથી legitimate users ને દંડ મળે છે જેમના clients ઓછા signals મોકલે છે.

જેમ standards mature થશે તેમ Unknown ઘટશે? વધુ automated clients requests sign કરશે, તેમ વધુ agent traffic Unknown અથવા declared માંથી verified તરફ જશે. તમારું monitoring આ બદલાવને route પ્રમાણે બતાવશે.

Proof of Actor ક્યાં ફિટ થાય છે

Proof of Actor Unknown ને first-class result તરીકે, કારણ સાથે report કરે છે, અને ક્યારેય તેને Human માં ફેરવતું નથી. તમારી application દરેક route માટે fallback પસંદ કરે છે, અને analytics બતાવે છે કે coverage ક્યાં પૂરી થાય છે જેથી તમે જ્યાં મહત્વ હોય ત્યાં evidence ઉમેરી શકો.

આને અમારી ટીમ સાથે production application પર set up કરવા માટે, early access માટે apply કરો. Evidence ખરેખર શું establish કરી શકે છે તે સમજવા માટે, Detection & Limitations વાંચો.

Sources

• RFC 9421: HTTP Message Signatures: standard જેને automated clients requests sign કરવા માટે ઉપયોગ કરી શકે છે
• draft-ietf-webbotauth-httpsig-protocol: signed automated traffic માટે IETF Web Bot Auth draft (November 2026 મુજબ કામ ચાલુ છે)
• OpenAI: Overview of OpenAI Crawlers: OpenAI ના bots માટે user agent strings અને published IP address files
• OWASP Automated Threats to Web Applications: credential stuffing અને scraping જેવા automated threats નું taxonomy
• Node.js test runner: example માં ઉપયોગ થયેલું node:test module