ข้ามไปยังเนื้อหาหลัก
ทราฟฟิกที่ไม่รู้จัก

ทำให้ทราฟฟิกอัตโนมัติที่ไม่รู้จักมองเห็นได้

แอปพลิเคชันส่วนใหญ่บอกไม่ได้ว่าทราฟฟิกอัตโนมัติจำนวนมากมาจากอะไร Proof of Actor ทำให้ทราฟฟิกนั้นยังคงมองเห็นได้ในฐานะคลาสของตัวเอง เพื่อให้คุณวัด ลดขนาด และจัดการอย่างตั้งใจได้

ขอสิทธิ์เข้าถึงก่อนใครสำรวจวิธีการทำงาน
Toshendra Sharma

โดย Toshendra Sharmaผู้ก่อตั้งและ CEO, AgentCredia · Updated November 13, 2026

ทราฟฟิกที่ไม่มีใครตั้งชื่อได้

ลองดูที่ logs ของแอปพลิเคชันให้ดี แล้วคุณจะพบ requests ที่อธิบายไม่ได้ มันมาจากไคลเอนต์ที่ไม่มีบริบทของเบราว์เซอร์ user-agent string ของมันอาจเป็นแบบทั่วไป ว่างเปล่า หรือคัดลอกมาจากเบราว์เซอร์ยอดนิยม มันไม่ sign request ของตัวเอง และไม่บอกว่าใครเป็นคนส่ง บางส่วนเป็นสคริปต์ที่ไม่มีพิษภัย บางส่วนเป็น agent ที่ทำงานแทนผู้ใช้จริง บางส่วนเป็นเครื่องมือที่คุณไม่อยากให้บริการเลย

นี่คือ ทราฟฟิกอัตโนมัติที่ไม่รู้จัก และทีมส่วนใหญ่มักจัดการมันด้วยหนึ่งในสองวิธี คือเงียบๆ นับเป็น human ซึ่งทำให้ analytics เพี้ยนและปล่อยกิจกรรมเสี่ยงผ่านไป หรือถือว่าเป็นภัยคุกคามตั้งแต่ต้น ซึ่งบล็อกทั้งผู้ใช้และ agent ที่ถูกต้องไปพร้อมกัน ทั้งสองวิธีมีข้อบกพร่องเดียวกัน คือเอาการคาดเดามาแทนหลักฐานที่ขาดหาย

Proof of Actor มองต่างออกไป หากหลักฐานไม่พอที่จะตัดสินได้อย่างน่าเชื่อถือ คำตอบที่ถูกต้องคือ Unknown และ Unknown ควรมองเห็นได้ วัดได้ และจัดการอย่างตั้งใจ บทความ why Unknown is a valid result for AI traffic อธิบายเหตุผลอย่างครบถ้วน

ทำไม Unknown จึงเป็นผลลัพธ์ระดับหลัก

Proof of Actor จัดประเภททุก interaction ให้อยู่ในหนึ่งในสี่คลาส: Human, Human + AI, Agent หรือ Unknown Unknown ไม่ใช่สถานะ error หรือช่องว่างของผลิตภัณฑ์ แต่มันคือผลลัพธ์ที่ตั้งใจออกแบบมาและมีความหมายชัดเจนว่า หลักฐานที่มีอยู่ไม่สนับสนุนการตัดสินอย่างน่าเชื่อถือ

ความตรงไปตรงมานี้มีประโยชน์ในทางปฏิบัติ

  • analytics ของคุณยังคงถูกต้อง จำนวน Human และ Agent จะนับเฉพาะ interaction ที่มีหลักฐานสนับสนุนเท่านั้น จึงหมายถึงสิ่งที่ควรจะหมายถึงจริงๆ
  • coverage ของคุณวัดได้ สัดส่วนของ Unknown ในแต่ละ route บอกได้ชัดเจนว่าคุณต้องการหลักฐานเพิ่มเติมตรงไหน
  • นโยบายของคุณปลอดภัยกว่า กรณีที่ไม่แน่ใจจะไหลไปยัง fallback ที่คุณเลือก แทนที่จะถูกมองว่าเชื่อถือได้หรือถูกบล็อกเพราะการเดา

Unknown จะไม่ถูกแปลงเป็น Human และจะไม่ถูกถือว่าเป็นอันตรายโดยปริยาย คุณสามารถอ่านเพิ่มเติมได้ใน glossary entry Unknown classification, ใน Detection & Limitations และใน why Unknown is a valid result for AI traffic use cases websites และ APIs แสดงให้เห็นว่าทีมต่างๆ ตั้งค่า Unknown fallback อย่างไรในทางปฏิบัติ

Unknown มาจากไหน

การเข้าใจแหล่งที่มาจะช่วยให้คุณตัดสินใจว่าจะจัดการมันอย่างไร

ไคลเอนต์อัตโนมัติที่ไม่ลงนาม

การ sign request ด้วย HTTP Message Signatures ที่กำหนดไว้ใน RFC 9421 เป็นทางเลือก และ IETF Web Bot Auth working group ก็ยังอยู่ระหว่างการกำหนดมาตรฐานว่าไคลเอนต์อัตโนมัติควรยืนยันตัวตนด้วยวิธีนี้อย่างไร หากไม่มี signature ตัวตนของไคลเอนต์ก็ขึ้นอยู่กับสิ่งที่มันเลือกจะบอกเกี่ยวกับตัวเอง

user agent ที่คัดลอกหรือเป็นแบบทั่วไป

การกำหนด user-agent string ทำได้ง่ายมาก ไคลเอนต์ที่อ้างว่าเป็นเบราว์เซอร์หรือ crawler ที่รู้จักดีอาจเป็นอย่างนั้นจริง หรืออาจกำลังปลอมตัวอยู่ก็ได้ entry user-agent spoofing อธิบายว่าทำไม header นี้เพียงอย่างเดียวจึงไม่สามารถใช้ตัดสินประเภทได้ นี่เป็นเหตุผลเดียวกับที่ search engine จัดทำวิธีตรวจสอบแยกต่างหาก Google อธิบายการทำ reverse และ forward DNS lookups พร้อมช่วง IP range ที่เผยแพร่ไว้สำหรับ verifying Googlebot และ Bing อธิบายการตรวจ DNS แบบเดียวกันสำหรับ verifying Bingbot

route ที่ไม่มี integration

ถ้า route ไม่มี browser integration และไม่มี context ฝั่ง server นอกเหนือจากข้อมูลพื้นฐาน ก็ย่อมมีสิ่งที่สังเกตได้น้อยกว่า Unknown บน route เหล่านั้นจึงเป็นสัญญาณของ coverage ไม่ใช่สัญญาณของภัยคุกคาม

หลักฐานที่หายไปหรือมาช้า

timeout สคริปต์ที่ถูกบล็อก หรือ request ที่ไม่สมบูรณ์ อาจทำให้ผลลัพธ์ไม่มีหลักฐานเพียงพอ Proof of Actor จะแสดงผลตามความจริงแทนที่จะเติมช่องว่างนั้นเอง

Proof of Actor ทำให้ Unknown จัดการได้อย่างไร

Proof of Actor จัดการงานออกเป็นสามความสามารถ แต่ละส่วนช่วยเรื่องทราฟฟิกอัตโนมัติที่ไม่รู้จัก

Detect: แยก Unknown ออกจากอย่างอื่น

สัญญาณจะถูกตรวจและติดป้ายตาม basis: verified, declared, inferred หรือ unknown เมื่อสัญญาณไม่พอจะตัดสินได้ ผลลัพธ์จะเป็น Unknown พร้อมสรุปว่าอะไรมีอยู่และอะไรไม่มี ไม่มีการเดาให้กลายเป็นคลาสอื่น

Understand: ดูว่า Unknown อยู่ตรงไหน

มุมมอง Understand แสดง Unknown ในทุก breakdown แยกตาม route และตามเวลา คุณจะเห็นว่า route ไหนมี activity ที่ไม่รู้จักมากที่สุด มันเปลี่ยนไปอย่างไรหลังจากคุณเพิ่ม integration และหลักฐานใดที่มีอยู่สำหรับ interaction แต่ละรายการ สิ่งนี้เปลี่ยนความกังวลที่คลุมเครือให้กลายเป็นแผนที่ที่จับต้องได้

Route: เลือก fallback แยกตาม route

route ต่างๆ ควรมี fallback ต่างกัน จุดเริ่มต้นที่สมเหตุสมผลสำหรับแอปพลิเคชันจำนวนมากมีดังนี้:

  • หน้า public และเอกสาร: allow Unknown ด้วย rate limits มาตรฐานของคุณ
  • signup และ onboarding: คงการตรวจสอบที่มีอยู่ไว้ และเพิ่ม review เฉพาะเมื่อเงื่อนไขของคุณต้องการเท่านั้น
  • การเปลี่ยนแปลง account และ action ที่อ่อนไหวอื่นๆ: อาศัยการยืนยันตัวตนและ step-up controls ที่คุณใช้อยู่แล้ว ไม่ใช่การเดา actor
  • การทำงาน API ที่มีผลกระทบสูง: ต้องใช้ credentials หรือ controls ที่เข้มงวดกว่าซึ่ง API ของคุณรองรับอยู่แล้ว

คู่มือ handling unknown traffic อธิบายการออกแบบ fallback เหล่านี้ รวมถึงตัวเลือก fail-open และ fail-closed สำหรับแต่ละระดับความเสี่ยง

ลด Unknown ลงเมื่อเวลาผ่านไป

เป้าหมายไม่ใช่กำจัด Unknown ให้หมดในข้ามคืน แต่คือทำให้มันเล็กลงทุกเดือนด้วยเหตุผลที่ถูกต้อง

  • เพิ่ม integration ในจุดที่สำคัญ browser integration บนหน้าหลักและ server-side integration บน route สำคัญจะเพิ่มหลักฐานที่มีอยู่
  • รองรับ signed requests เมื่อผู้ดูแล agent นำ HTTP message signatures มาใช้ ทราฟฟิกที่เคยเป็น Unknown จะกลายเป็น verified Agent traffic
  • บันทึก declaration ในแอปของคุณเอง เมื่อแอปของคุณรู้ว่ามีการช่วยเหลือจาก AI ให้ระบุให้ชัด หลักฐานนั้นแม่นยำและต้นทุนต่ำ
  • เปิดประตูหน้าให้ agent การเผยแพร่เส้นทางแบบมีโครงสร้างสำหรับ agent จะช่วยกระตุ้นให้พวกมันระบุตัวเองแทนที่จะกลืนไปกับทราฟฟิกทั่วไป

เพราะ Proof of Actor ติดตาม Unknown แยกตาม route คุณจึงมองเห็นการเปลี่ยนแปลงเหล่านี้ในตัวเลขได้

วิธีการทำงาน

ทุก interaction เดินตามเส้นทางที่ให้หลักฐานมาก่อนเหมือนกัน ซึ่งอธิบายไว้อย่างครบถ้วนใน How It Works: แอปพลิเคชันของคุณรับ request หรือ event, integration รวบรวมสัญญาณที่มีอยู่ในบริบทนั้น, สัญญาณถูกทำให้เป็นมาตรฐานและจัดประเภทด้วย basis ที่ชัดเจน, ผลลัพธ์ถูกบันทึกเพื่อใช้กับ analytics, และแอปพลิเคชันของคุณใช้นโยบายของตัวเองหรือเพียงแค่สังเกต

timeout และ telemetry ที่หายไปจะถูกจัดการอย่างชัดเจน integration ของคุณใช้ fallback ที่คุณเลือกไว้สำหรับ route นั้น และผลลัพธ์จะไม่ถูกอัปเกรดเป็น Human เพียงเพราะหลักฐานหายไป

หน้าตาที่ดีหลังจากผ่านไปสองสามเดือน

ทีมที่จัดการทราฟฟิกอัตโนมัติที่ไม่รู้จักได้ดีมักจะไปถึงสภาวะที่ดีคล้ายกัน Unknown เป็นจำนวนที่รู้ชัดบน route สำคัญทุกเส้น และถูกติดตามใน dashboard เดียวกับกิจกรรมของ human และ agent แต่ละ route มี fallback ที่เป็นลายลักษณ์อักษรซึ่งทีม product, platform และ security เห็นพ้องร่วมกัน verified agent traffic เติบโตขึ้นเมื่อผู้ดูแลระบบของ agent ลงนาม request มากขึ้น และ agent เหล่านั้นถูกให้บริการผ่านเส้นทางแบบมีโครงสร้างแทนที่จะ scrape หน้าเว็บ การกระทำที่อ่อนไหวได้รับการปกป้องด้วยการยืนยันตัวตนและ step-up controls ที่แอปพลิเคชันเชื่อถืออยู่แล้ว โดยมีบริบทของ actor เป็นข้อมูลเพิ่มเติม ไม่ใช่ด่านหน้าตัดสิน

ที่สำคัญที่สุดคือไม่มีใครต้องเดาอีกต่อไป เมื่อมีคนถามว่าทราฟฟิกเมื่อสัปดาห์ที่แล้วเป็นอัตโนมัติมากน้อยแค่ไหน คำตอบจะมาพร้อม basis ของมัน: เท่านี้เป็น verified, เท่านี้เป็น declared, เท่านี้เป็น inferred และเท่านี้ยังคงเป็น Unknown นั่นคือจำนวนที่ทีมใช้วางแผนได้ และยังเปลี่ยนบทสนทนากับผู้บริหารด้วย เพราะคำถามจะไม่ใช่ว่า bots เป็นปัญหาหรือไม่อีกต่อไป แต่กลายเป็นว่า route ไหนควรได้หลักฐานเพิ่ม และ fallback ไหนควรปรับปรุง

เริ่มจากโหมดสังเกตการณ์

Proof of Actor ไม่บล็อกอะไรเป็นค่าเริ่มต้น ในโหมดสังเกตการณ์ ผลลัพธ์จะถูกบันทึกในขณะที่แอปพลิเคชันของคุณตอบสนองเหมือนเดิม ทีมของคุณจะเห็นว่าทราฟฟิกอัตโนมัติที่ไม่รู้จักในแต่ละ route มีมากแค่ไหน เปรียบเทียบกับผลลัพธ์ที่คุณรู้อยู่แล้ว และออกแบบ fallback จากรูปแบบจริง นโยบายจะถูกเปิดใช้งานทีละ route เฉพาะเมื่อทีมของคุณมั่นใจว่าเหมาะสม

เข้าร่วม Founding Developer Program

Proof of Actor อยู่ใน private beta ทีม Founding Developer ที่ได้รับคัดเลือกสามารถใช้งานได้ฟรีสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงกันไว้ แลกกับข้อเสนอแนะเกี่ยวกับผลิตภัณฑ์จากการใช้งานจริง พร้อมการสนับสนุนการเชื่อมต่อโดยตรงจากวิศวกรของเรา

หากทราฟฟิกอัตโนมัติที่ไม่รู้จักกำลังทำให้ analytics หรือการตัดสินใจด้านความปลอดภัยของคุณคลุมเครือ ให้ apply for early access เล่าให้เราฟังเกี่ยวกับแอปพลิเคชันของคุณและ route ที่ Unknown สำคัญที่สุด

สำรวจ Proof of Actor, อ่าน how it works หรือดู what the evidence can establish

แหล่งอ้างอิง

สำหรับนักพัฒนา

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
สัญญาณที่อยู่เบื้องหลังผลลัพธ์ เพื่อให้ทีมของคุณเห็นเหตุผล

เริ่มในโหมด observation: บันทึกผลลัพธ์ไว้ข้าง log ของคุณ และไม่เปลี่ยนแปลงอะไรจนกว่าคุณจะเลือกนโยบาย อ่านคู่มือการเชื่อมต่อ Node.js

คำถามที่พบบ่อย

ทราฟฟิกอัตโนมัติที่ไม่รู้จักคืออะไร?

คือกิจกรรมที่หลักฐานที่มีอยู่ไม่แสดงอย่างน่าเชื่อถือว่ามีคน คนที่ใช้ AI หรือ agent อัตโนมัติเป็นผู้กระทำ มักเป็นไคลเอนต์ที่ไม่ลงนาม ไม่มีบริบทของเบราว์เซอร์ และมี user-agent string แบบทั่วไปหรือถูกคัดลอกมา

ทำไมไม่บล็อกทราฟฟิกที่ไม่รู้จักไปเลย?

Unknown ไม่ได้เท่ากับเป็นอันตรายเสมอไป มันรวมถึงไคลเอนต์ที่ถูกต้องตามปกติ เบราว์เซอร์ที่เน้นความเป็นส่วนตัว และเครื่องมือที่แค่อีกฝ่ายไม่ระบุตัวตน หากบล็อกทั้งหมดทันทีจะสร้างความเสียหายจริง การมี fallback ที่ตั้งใจไว้แยกตาม route ใช้งานได้ดีกว่ามาก

Proof of Actor เคยเปลี่ยน Unknown ให้เป็น Human ไหม?

ไม่เคย ผลลัพธ์ Unknown จะยังคงเป็น Unknown รวมถึงกรณีที่หลักฐานขาดหายหรือการตรวจสอบหมดเวลา นโยบายของคุณเป็นตัวเลือก fallback สำหรับแต่ละ route

ทราฟฟิกที่ไม่รู้จักลดลงได้ไหมเมื่อเวลาผ่านไป?

ได้ การเพิ่ม integration ใน route มากขึ้น การรองรับ signed requests และการบันทึก declaration ในแอปของคุณเอง ล้วนช่วยให้ทราฟฟิกย้ายจาก Unknown ไปเป็นคลาสที่มี basis ชัดเจน

ฉันดูทราฟฟิกที่ไม่รู้จักได้ที่ไหน?

ในมุมมอง Understand Unknown จะมีคลาสของตัวเองในทุก breakdown แยกตาม route และตามเวลา พร้อมหลักฐานที่มีอยู่สำหรับแต่ละ interaction

รู้ว่าใครกำลังใช้แอปของคุณ

private beta สำหรับกลุ่มเล็กๆ ของ founding developers

ขอสิทธิ์เข้าถึงก่อนใครดูราคา

อยากคุยก่อนหรือไม่ พูดคุยกับผู้ก่อตั้ง