การแก้ไขปัญหา

หน้านี้ครอบคลุมปัญหาที่พบบ่อยระหว่างการผสานรวม TRACIO และแนวทางแก้ไข TRACIO เป็นบริการคลาวด์แบบจัดการ (managed) ดังนั้นปัญหาส่วนใหญ่จึงเกิดฝั่งไคลเอนต์ (สคริปต์ถูกบล็อก คุกกี้ ฟีเจอร์ความเป็นส่วนตัวของเบราว์เซอร์) มากกว่าจะเป็นปัญหาด้านโครงสร้างพื้นฐาน

คำขอที่ถูกบล็อกหรือถูกปฏิเสธด้วย CORS

อาการ

สคริปต์เอเจนต์หรือคำขอระบุตัวตนโหลดไม่สำเร็จ หรือคอนโซลของเบราว์เซอร์แสดงข้อผิดพลาด CORS ต่อ edge.tracio.ai

สาเหตุและแนวทางแก้ไข

1. Origin ไม่ได้อยู่ในรายการที่อนุญาตสำหรับคีย์ของคุณ

คีย์สาธารณะแต่ละตัวสามารถถูกจำกัดไว้เฉพาะชุด origin ที่อนุญาตได้ หาก origin ของเว็บไซต์ของคุณไม่อยู่ในรายการที่อนุญาต edge จะปฏิเสธคำขอ (403) เพิ่ม origin ของคุณภายใต้ Request Filtering ในแดชบอร์ด หรือยืนยันว่าคีย์ที่คุณใช้ไม่ได้ถูกผูก origin ไว้กับเว็บไซต์อื่น

2. Ad blocker หรือ CSP บล็อกคำขอ

ส่วนขยายด้านความเป็นส่วนตัว (uBlock Origin, AdBlock) หรือ Content-Security-Policy ที่เข้มงวดสามารถบล็อกสคริปต์เอเจนต์หรือคำขอเครือข่ายของมันได้ SDK จะแสดงกรณีนี้เป็นข้อผิดพลาด blocked (ดู การจัดการข้อผิดพลาด) เพื่อทำให้การบล็อกยากขึ้น ให้เสิร์ฟเอเจนต์จากซับโดเมนแบบ first-party โดยใช้ตัวเลือก scriptUrl / endpoint

3. endpoint / region ผิด

ตรวจสอบให้แน่ใจว่าคุณชี้ไปยัง endpoint ที่ถูกต้อง เมื่อคุณตั้งค่า region SDK จะติดต่อกับ edge.us.tracio.ai หรือ edge.eu.tracio.ai หากไม่ได้ตั้งค่า จะใช้ edge.tracio.ai

คะแนนความเชื่อมั่นต่ำ

อาการ

คะแนนความเชื่อมั่นอยู่ต่ำกว่า 0.90 อย่างสม่ำเสมอสำหรับผู้เยี่ยมชมที่กลับมาซ้ำ

สาเหตุที่เป็นไปได้และแนวทางแก้ไข

1. คุกกี้ไม่คงอยู่

คุกกี้ _vid_t อาจถูกตั้งค่าไม่ถูกต้อง ตรวจสอบในเบราว์เซอร์:

// In browser console
document.cookie.split(";").filter((c) => c.includes("_vid_t"))

หากคุกกี้หายไป ดูส่วน คุกกี้ไม่คงอยู่ ด้านล่าง

2. เวิร์กสเปซใหม่

เวิร์กสเปซที่สร้างขึ้นใหม่เอี่ยมจะมีฐานข้อมูลผู้เยี่ยมชมว่างเปล่า ดังนั้นผู้เยี่ยมชมทั้งหมดจะปรากฏเป็น "ผู้เยี่ยมชมใหม่" ด้วยความเชื่อมั่นราว 0.90 หลังจาก 24–48 ชั่วโมง ผู้เยี่ยมชมที่กลับมาซ้ำจะถูกจดจำด้วยความเชื่อมั่นที่สูงขึ้น

3. การเรียกดูแบบไม่ระบุตัวตน/ส่วนตัว

ในโหมดไม่ระบุตัวตน คุกกี้และ localStorage จะถูกล้างเมื่อเซสชันสิ้นสุดลง TRACIO จะย้อนกลับไปใช้การจับคู่ด้วยสัญญาณเพียงอย่างเดียว ซึ่งมีความเชื่อมั่นต่ำกว่า (โดยทั่วไป 0.85–0.95)

4. เบราว์เซอร์ที่มีการต่อต้าน fingerprinting อย่างเข้มข้น

Brave, Firefox (โหมดเข้มงวด) และ Safari (ITP) จะแก้ไขหรือบล็อกสัญญาณบางส่วนของเบราว์เซอร์ สิ่งนี้ลดชุดสัญญาณที่พร้อมใช้สำหรับการจับคู่ TRACIO จะตรวจจับเบราว์เซอร์เหล่านี้และปรับความเชื่อมั่นให้สอดคล้องกัน

การวินิจฉัยความเชื่อมั่นต่ำ

ตรวจสอบการระบุตัวตนใน แดชบอร์ด (Visitors / Events) หรือดำเนินการตาม การส่งมอบผ่าน webhook ซึ่งนำพา identification.confidence, identification.incognito และ verdict bot สำหรับแต่ละเหตุการณ์

การตรวจจับบอตผิดพลาด (False Positive)

อาการ

ผู้เยี่ยมชมที่เป็นมนุษย์จริงถูกทำเครื่องหมายว่าเป็นบอต

สาเหตุที่เป็นไปได้และแนวทางแก้ไข

1. ส่วนขยายเบราว์เซอร์แก้ไขคุณสมบัติของ navigator

ส่วนขยายด้านความเป็นส่วนตัวบางตัวแก้ไข navigator.userAgent, navigator.platform หรือคุณสมบัติอื่น ๆ สิ่งนี้สามารถกระตุ้นตัวตรวจจับการดัดแปลง (tampering) ได้ แต่ไม่ควรกระตุ้นการตรวจจับบอตเพียงลำพัง

ตรวจสอบฟิลด์ bot.type เพื่อดูว่าการตรวจจับคลาสใดทำงาน (ดูคำศัพท์ทั้งหมดได้ที่ ประเภทของบอต):

ในแพ็กเกจ Business และ Enterprise อาร์เรย์ reasons ใน webhook จะระบุคลาสของข้อสังเกตที่อยู่เบื้องหลังผลตัดสิน — เป็นทางที่เร็วที่สุดในการทำความเข้าใจ false positive ดู รหัสเหตุผล

2. สภาพแวดล้อมองค์กรที่เรนเดอร์ด้วยซอฟต์แวร์

สภาพแวดล้อม Citrix, VDI และเทอร์มินัลเซิร์ฟเวอร์เรนเดอร์โดยไม่มี GPU จริง ซึ่งคล้ายกับรันไทม์แบบ headless หากผู้ใช้ของคุณทำงานในสภาพแวดล้อมเหล่านี้ ให้ใช้นโยบายที่ผ่อนปรนกว่าเมื่อ webhook แสดงชนิดบอตเป็น headless:

// `event` is the webhook delivery body (/docs/webhooks)
if (event.bot?.result === "bot" && event.bot.type === "headless") {
  // VDI and remote-desktop users render without a real GPU and can trip the
  // headless classification — consider applying a softer policy for these.
}

3. การทดสอบอัตโนมัติในโปรดักชัน

หากทีม QA ของคุณรันการทดสอบ Selenium/Playwright กับโปรดักชัน สิ่งเหล่านั้นจะถูกตรวจจับว่าเป็นบอตอย่างถูกต้อง ให้ใช้คีย์แยกต่างหากสำหรับทราฟฟิกทดสอบ

คุกกี้ไม่คงอยู่

อาการ

คุกกี้ _vid_t หายไประหว่างการเยี่ยมชม ทำให้ทุกการเยี่ยมชมปรากฏเป็นผู้เยี่ยมชม "ใหม่"

สาเหตุที่เป็นไปได้และแนวทางแก้ไข

1. เว็บไซต์ที่ไม่ใช่ HTTPS

คุกกี้ _vid_t ใช้แฟล็ก Secure และจะถูกตั้งค่าผ่าน HTTPS เท่านั้น ตรวจสอบให้แน่ใจว่าเว็บไซต์ของคุณใช้ HTTPS

2. การโหลดแบบ cross-site

TRACIO ตั้งค่า SameSite=Lax บนคุกกี้ หากเอเจนต์ถูกโหลดในบริบท cross-site อย่างเข้มงวด คุกกี้อาจถูกบล็อกได้ การเสิร์ฟเอเจนต์จากซับโดเมนแบบ first-party (ผ่าน scriptUrl / endpoint) ช่วยให้คุกกี้ยังคงเป็น same-site

3. Safari ITP

Intelligent Tracking Prevention (ITP) ของ Safari สามารถจำกัดอายุของคุกกี้ที่ตั้งค่าฝั่งไคลเอนต์ได้ TRACIO ยังออก _vid_t ฝั่งเซิร์ฟเวอร์ผ่านเฮดเดอร์ Set-Cookie และสะท้อน UID ไปยัง localStorage ด้วย ดังนั้นตัวตนจึงคงอยู่แม้เมื่อคุกกี้ถูกจำกัดอายุ

4. เบราว์เซอร์ล้างคุกกี้

เบราว์เซอร์บางตัว (Brave, Firefox Focus) ล้างคุกกี้เมื่อเซสชันสิ้นสุด ผู้ใช้ที่ตั้งค่าความเป็นส่วนตัวอย่างเข้มข้นจะปรากฏเป็นผู้เยี่ยมชมใหม่เสมอ

เวลาแฝงสูง (High Latency)

อาการ

tracio.getResult() ใช้เวลาส่งค่ากลับนานกว่าอุปกรณ์ทดสอบและเครือข่ายอื่น ๆ ของคุณอย่างเห็นได้ชัด

สาเหตุที่เป็นไปได้และแนวทางแก้ไข

1. เครือข่ายไปยัง edge ช้า

ตรวจสอบเวลาแฝงไป-กลับ (round-trip) ไปยัง edge ในภูมิภาคของคุณ:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" https://edge.tracio.ai/health

2. การเก็บข้อมูลใช้เวลานานเกินไป

บนอุปกรณ์ที่มีประสิทธิภาพต่ำ การเก็บจะใช้เวลานานกว่า ทุกการตรวจสอบที่อาจช้าถูกจำกัดด้วย timeout ของตัวเอง การเก็บจึงไม่บล็อกอย่างไม่มีกำหนด — การตรวจสอบที่หมดเวลาจะถูกรายงานว่าไม่พร้อมใช้งานเท่านั้น และการระบุตัวตนก็ดำเนินต่อไปโดยไม่มีค่านั้น

การเก็บข้อมูลไม่ครบ

อาการ

การระบุตัวตนสำเร็จ แต่ความเชื่อมั่นต่ำกว่าที่คาดไว้บนเบราว์เซอร์หรือคลาสอุปกรณ์บางประเภท

คำอธิบาย

ไม่ใช่ทุกการตรวจสอบจะทำงานได้ในทุกสภาพแวดล้อม: CSP ที่เข้มงวด ข้อจำกัดของแพลตฟอร์ม และฟีเจอร์ความเป็นส่วนตัวของเบราว์เซอร์ ทำให้บางอย่างใช้ไม่ได้ นี่เป็นเรื่องที่คาดหมายได้และถูกจัดการอย่างนุ่มนวล — ความเชื่อมั่นคำนวณจากสิ่งที่เก็บได้จริง จึงเป็นเหตุผลว่าทำไมเบราว์เซอร์ที่เสริมความแข็งแกร่งจึงถูกระบุตัวตนด้วยความเชื่อมั่นที่ต่ำกว่าเบราว์เซอร์ทั่วไปอย่างชอบธรรม

ไม่จำเป็นต้องดำเนินการใด ๆ จากฝั่งคุณ หากความเชื่อมั่นต่ำอย่างสม่ำเสมอในทราฟฟิกสัดส่วนใหญ่ ให้ติดต่อฝ่ายสนับสนุนพร้อมแจ้ง requestId — เรื่องนี้วินิจฉัยจากบันทึกฝั่งเซิร์ฟเวอร์ ไม่ใช่จากเบราว์เซอร์

การขอความช่วยเหลือ

หากคุณพบปัญหาที่ไม่ได้ครอบคลุมในที่นี้:

1. เปิดใช้การวินิจฉัยแบบละเอียดด้วยตัวเลือก SDK debug: true
2. ตรวจสอบเหตุการณ์ในแดชบอร์ด (Visitors / Events)
3. อ่าน การจัดการข้อผิดพลาด สำหรับรหัสข้อผิดพลาดของ SDK
4. อ่าน Webhooks สำหรับ payload ฝั่งเซิร์ฟเวอร์
5. ติดต่อฝ่ายสนับสนุนพร้อมระบุ requestId ของการระบุตัวตนที่ได้รับผลกระทบ