สรุปสั้น ๆ (TL;DR)
- โทเคนออกระหว่างท่องเว็บปกติโดยเว็บไซต์ที่ลงทะเบียนเท่านั้น และใช้ได้ครั้งเดียวต่อเว็บไซต์ในเซสชันส่วนตัว ผ่าน header Sec-Private-Verification-Token ในคำขอที่ไม่มีคุกกี้
- การออกแบบจำกัดโทเคนไว้ที่หนึ่งบิต จำกัดเซสชันส่วนตัวไว้ที่สองโดเมนที่ลงทะเบียน และโทเคนใช้ได้เฉพาะโดเมนที่จดทะเบียนได้ (eTLD+1) ที่ออกโทเคนเท่านั้น
- การลงทะเบียนต้องยอมรับนโยบายที่จำกัดการใช้ไว้ที่ความน่าเชื่อถือ การจำกัดอัตรา และการตรวจจับ invalid traffic ส่วนขั้นตอนการลงทะเบียนยังรอกำหนด
- Chrome Platform Status อัปเดตล่าสุดวันที่ 3 กันยายน 2569 บันทึกว่ายังไม่มีสัญญาณจาก Firefox หรือ WebKit และการตรวจสอบของ TAG ยังรอดำเนินการ
ทีม Chrome ของ Google กำลังทดลอง Private Verification Tokens (PVT) แบบ origin trial ตั้งแต่ Chrome 154 ถึง Chrome 165 กลไกนี้ให้เว็บไซต์ส่งต่อความน่าเชื่อถือขนาดหนึ่งบิตที่ได้จากการท่องเว็บปกติ ไปใช้ในเซสชัน Incognito บนเว็บไซต์เดียวกัน เพื่อให้คนจริงข้าม CAPTCHA ได้ รายการบน Chrome Platform Status สร้างขึ้นเมื่อวันที่ 2 เมษายน 2569 และอัปเดตล่าสุดวันที่ 3 กันยายน 2569 ส่วนเอกสารออกแบบระบุว่าฟีเจอร์นี้ยังไม่ได้รับอนุมัติให้เปิดใช้จริง ตามรายงานของ PPC Land ที่เผยแพร่เมื่อวันที่ 12 กันยายน 2569
สำหรับนักการตลาดและเจ้าของเว็บไซต์ เรื่องนี้แตะปัญหาประจำวัน 3 เรื่อง ได้แก่ CAPTCHA ที่ทำให้คนกรอกฟอร์มไม่จบ บอตและทราฟฟิกไม่ถูกต้อง (invalid traffic) ที่ทำให้รายงานเพี้ยน และผู้เข้าชมผ่านโหมดส่วนตัวที่ดูเหมือนบอต แต่ก็ตีความเกินจริงได้ง่ายเช่นกัน PVT เป็นการทดลอง ใช้ได้เฉพาะเว็บไซต์ที่ลงทะเบียน และออกแบบมาให้บรรจุข้อมูลแทบไม่มีเลย บทความนี้อธิบายว่ามันทำอะไร ทำอะไรไม่ได้ และทีมการตลาดหรือทีมวิเคราะห์ข้อมูลควรทำอะไรตอนนี้ ซึ่งส่วนใหญ่คือเฝ้าดู
ปัญหาที่ Private Verification Tokens พยายามแก้
เว็บไซต์แยกคนที่ท่องเว็บใน Incognito ออกจากบอตที่เพิ่งล้างหน่วยความจำตัวเองได้ยาก ทั้งสองแบบมาถึงโดยไม่มีคุกกี้และไม่มีประวัติที่เก็บไว้ จึงมักเจอ CAPTCHA แบบเดียวกัน ส่วนแรงจูงใจในเอกสารอธิบาย (explainer) ระบุว่าการที่เว็บไซต์เพิ่มด่านตรวจสอบมากขึ้นมาจากระบบอัตโนมัติที่เพิ่มขึ้นอย่างมากในช่วง 1 ถึง 2 ปีที่ผ่านมา ซึ่งส่วนใหญ่ขับเคลื่อนโดย AI ตามรายงานของ PPC Land
คำตอบของข้อเสนอนี้คือให้เว็บไซต์มอบตั๋วเข้ารหัสขนาดเล็กให้เบราว์เซอร์ระหว่างที่คนคนนั้นท่องเว็บตามปกติ เมื่อต่อมาเขาเปิดเว็บเดียวกันในหน้าต่างส่วนตัว เบราว์เซอร์จะแสดงตั๋วนั้นหนึ่งครั้ง ตั๋วบอกได้เพียงเรื่องเดียว ไม่มีชื่อผูกอยู่ และใช้ได้กับเว็บไซต์ไม่เกินสองแห่งต่อหนึ่งเซสชันส่วนตัว
กลไกทำงานอย่างไร อธิบายแบบง่าย
เอกสารนิยาม PVT ว่าเป็นกลไกข้อมูลต่ำ (low-entropy) ที่ให้ผู้ใช้ส่งต่อความน่าเชื่อถือที่สร้างไว้ระหว่างท่องเว็บปกติไปยังโหมดท่องเว็บแบบส่วนตัว เพื่อลดความยุ่งยากที่เจอในโหมดนั้น กลไกนี้สร้างบนโปรโตคอลเข้ารหัสชื่อ Anonymous Tokens with Hidden Metadata หรือ ATHM
มีคุณสมบัติสองข้อที่กำหนดขอบเขต ข้อแรกคือทิศทาง โทเคนออกให้ในเซสชันปกติและนำไปใช้ในเซสชันส่วนตัว และ explainer ระบุว่าข้อมูลเข้าไปในโหมดส่วนตัวได้อย่างเดียว ไม่สามารถถูกดึงกลับออกมา ข้อที่สองคือขอบเขต โทเคนผูกกับ eTLD+1 ของ origin ระดับบนสุด ซึ่งคือโดเมนที่จดทะเบียนได้ เช่น example.co.th การออกและการใช้โทเคนจำกัดอยู่กับ origin ที่ใช้โดเมนเดียวกัน โทเคนที่ได้จากผู้เผยแพร่รายหนึ่งจึงนำไปใช้กับอีกรายไม่ได้
ต้องลงทะเบียนก่อน
เว็บไซต์ไม่ได้สิทธิ์ใช้งานโดยอัตโนมัติ เว็บไซต์ระดับบนสุดต้องลงทะเบียนเพื่อออก PVT และการลงทะเบียนต้องยอมรับนโยบายที่ระบุว่าโทเคนใช้เพื่อความน่าเชื่อถือ การจำกัดอัตรา (rate limiting) และการตรวจจับ invalid traffic ตาม explainer ขั้นตอนจะคล้ายการลงทะเบียน Private State Token แต่ขั้นตอนการลงทะเบียนเองยังระบุว่ารอกำหนด เว็บไซต์ถือว่าลงทะเบียนแล้วหาก eTLD+1 ของเว็บลงทะเบียน และรายชื่อโดเมนที่ลงทะเบียนจะถูกส่งไปยังเบราว์เซอร์พร้อมกุญแจสาธารณะผ่านกลไกคล้าย component updater ของ Chrome
เงื่อนไข 4 ข้อก่อน Chrome ขอโทเคน
การออกโทเคนไม่ได้เกิดทุกครั้งที่เปิดหน้าเว็บ เบราว์เซอร์จะสร้าง token challenge ก็ต่อเมื่อเงื่อนไข 4 ข้อเป็นจริงพร้อมกัน ตามเอกสารออกแบบที่ PPC Land รายงาน
- คำขอส่งไปยัง origin แบบ https ที่ eTLD+1 อยู่ในรายชื่อที่ลงทะเบียน
- คำขอมาจากเซสชันท่องเว็บปกติ ซึ่งนิยามว่าเป็นบริบทที่เหมาะจะเก็บข้อมูลไว้หลังปิดหน้าเว็บ
- จำนวนโทเคนที่มีอยู่แล้วสำหรับ eTLD+1 นั้นต่ำกว่าเกณฑ์ ซึ่งเอกสารอธิบายว่าเพื่อให้โทเคนสดใหม่ ไม่ใช่ปล่อยให้เบราว์เซอร์กักตุน
- โทเคนที่มีอยู่ใกล้หมดอายุ เบราว์เซอร์จึงเติมก่อนหมด ไม่ใช่หลังหมด
การแลกเปลี่ยนใช้โครงสร้างเว็บแบบธรรมดา token challenge คือคำขอ POST ไปยัง path ที่หน้าเว็บกำหนด โดยมี Accept header เป็น application/private-token-response และ Content-Type เป็น application/private-token-request การตอบกลับที่สำเร็จจะคืน HTTP 200 พร้อม token response เบราว์เซอร์ตรวจสอบหลักฐาน เก็บโทเคนไว้ในข้อมูลเว็บไซต์ และเขียนลงดิสก์เพื่อให้อยู่รอดหลังรีสตาร์ต ผู้ออกโทเคนเป็นผู้เลือก hidden metadata ซึ่งคือข้อมูลหนึ่งบิตนั้น แล้ว origin ดึงออกมาตอนนำไปใช้ ส่งผลการตัดสินกลับ และถ้าผ่านก็ข้ามด่านตรวจสอบ
การนำไปใช้: หนึ่งโทเคน หนึ่ง header เฉพาะคำขอที่ไม่มีคุกกี้
ในหน้าต่างส่วนตัว คำขอแรกไปยังเว็บไซต์ที่ลงทะเบียนย่อมไม่มีคุกกี้ และคำขอนั้นเองที่พาโทเคนไปด้วย โทเคนเดินทางใน HTTP header ใหม่ชื่อ Sec-Private-Verification-Token ซึ่งบรรจุโทเคนหนึ่งชิ้นที่ถูก serialize และเข้ารหัสแบบ base64 การ serialize ใช้ตามหัวข้อ 5.3 ของ RFC 9578
การนำไปใช้ก็มีเงื่อนไข 4 ข้อเช่นกัน คือคำขอไม่มีคุกกี้ scheme เป็น https โปรไฟล์หลักมีโทเคนสำหรับเว็บไซต์นั้นอย่างน้อยหนึ่งชิ้น และโทเคนยังไม่หมดอายุ ในหนึ่งเซสชันท่องเว็บแบบส่วนตัว จะส่ง PVT ไปยัง origin ที่ลงทะเบียนเพียงชิ้นเดียว
เว็บไซต์ต้องตั้งคุกกี้ ไม่อย่างนั้นโทเคนจะหมด
เพราะเบราว์เซอร์แนบโทเคนไปกับทุกคำขอที่ไม่มีคุกกี้ไปยังเว็บไซต์ที่ลงทะเบียน เว็บไซต์ที่ไม่เคยตั้งคุกกี้จะทำให้โทเคนสำรองหมด explainer ให้เว็บไซต์เป็นฝ่ายแก้ origin หยุดการเผาโทเคนได้ด้วยการตั้งคุกกี้ทันทีที่ได้รับโทเคน ถ้าไม่ทำ เบราว์เซอร์จะแนบโทเคนไปเรื่อยๆ จนหมด สำหรับทีมที่วางแผนเข้าร่วม นี่คือรายละเอียดการติดตั้งที่ควรจดไว้ตั้งแต่ต้น
ข้อจำกัดคือตัวสเปก
ตารางด้านล่างสรุปข้อจำกัดหลักที่เอกสารออกแบบระบุไว้ ตามรายงานของ PPC Land
| ข้อจำกัด | สิ่งที่เอกสารออกแบบกำหนด |
|---|---|
| ความจุของโทเคน | หนึ่งบิต (nBuckets เท่ากับสอง) ไม่มีคะแนน ระดับ หรือประวัติ |
| จำนวนเว็บไซต์ต่อเซสชันส่วนตัว | ใช้โทเคนได้กับโดเมนที่ลงทะเบียน (eTLD+1) ไม่เกินสองโดเมนต่อเซสชัน |
| โทเคนต่อเว็บไซต์ต่อเซสชัน | ส่ง PVT หนึ่งชิ้นไปยัง origin ที่ลงทะเบียนต่อหนึ่งเซสชันท่องเว็บแบบส่วนตัว |
| ทิศทางข้อมูล | เข้าสู่โหมดส่วนตัวเท่านั้น ไม่มีข้อมูลไหลกลับออกมา |
| ช่วงทดลอง | origin trial ตั้งแต่ Chrome 154 ถึง Chrome 165 บนเดสก์ท็อปและ Android ยังไม่ได้รับอนุมัติให้เปิดใช้จริง |
เพดานสองเว็บไซต์เป็นแบบกำหนดตายตัว เฉพาะโดเมนที่ลงทะเบียนสองโดเมนแรกที่เซสชันส่วนตัวเจอเท่านั้นที่ได้โทเคน explainer เทียบกฎนี้กับมาตรการป้องกัน bounce tracking ของ Firefox โดยระบุว่ากฎของตนเป็นแบบกำหนดตายตัว ไม่ใช่แบบประมาณการ และวางไว้เป็นการป้องกันไม่ให้บริษัทเดียวใช้หลายโดเมนที่ลงทะเบียนเพื่อสะสมสัญญาณเกินกว่าที่ตั้งใจ
การเชื่อมโยงกลับไม่ได้ (unlinkability) มาจาก ATHM โทเคนที่มี hidden metadata เหมือนกันแยกจากกันไม่ออก เว็บไซต์ที่ได้รับโทเคนจึงเชื่อมผู้เข้าชมกลับไปยังตอนที่ออกโทเคนไม่ได้ หากอาศัยตัวโทเคนอย่างเดียว
อายุการใช้งานถูกจำกัดทั้งสองด้าน โทเคนหมดอายุเมื่อกุญแจหมดอายุ และเบราว์เซอร์ถูกกำหนดให้ปฏิเสธกุญแจที่ใกล้หมดอายุเกินไป เพราะกุญแจอายุสั้นจะทำให้เว็บไซต์จัดกลุ่มผู้ใช้ตามเวอร์ชันกุญแจที่ถืออยู่ได้ การควบคุมของผู้ใช้เขียนไว้ชัด กฎการเก็บข้อมูลที่มีอยู่ยังใช้ เว็บไซต์ที่ถูกบล็อกไม่ให้เก็บข้อมูลจะเก็บโทเคนไม่ได้ และเบราว์เซอร์ควรมีตัวควบคุมให้ล้างโทเคนที่เก็บไว้และปิดกลไกนี้ทั้งหมด
ซ่อนโหมดส่วนตัวจากเว็บไซต์: การดึงโทเคนล่วงหน้าและพร็อกซี
การออกแบบนี้สร้างความเสี่ยงด้านการตรวจจับ ซึ่งเอกสารเขียนไว้ตรงๆ ถ้าโทเคนมีอยู่เฉพาะในโหมดส่วนตัว การมีโทเคนก็จะเผยว่าเซสชันนั้นเป็นแบบส่วนตัว วิธีลดความเสี่ยงที่เสนอคือดึงโทเคนล่วงหน้า (prefetch) ตอนเปิดเบราว์เซอร์ เพื่อให้มีโทเคนอยู่ทั้งสองโหมดและตั้งแต่การเข้าเว็บไซต์ครั้งแรก
แต่วิธีนี้สร้างปัญหาที่สอง ถ้า Chrome ทุกเครื่องดึงโทเคนล่วงหน้าโดยตรง ในทางทฤษฎีเว็บไซต์อาจนับจำนวนเบราว์เซอร์ทั้งหมดได้ มาตรการแก้คือส่งคำขอ prefetch ผ่าน PVT proxy server ที่ผู้ผลิตเบราว์เซอร์เป็นผู้ดูแล พร็อกซีระบุตัวเองชัดเจน endpoint ของ PVT ต้องตอบคำขอโทเคนจากพร็อกซี และเบราว์เซอร์ต้องจัดตารางคำขอไม่ให้พร็อกซีหรือ endpoint ของเว็บไซต์รับภาระเกิน PPC Land อธิบายผลลัพธ์ว่าเป็นการจัดวางสามฝ่าย Chrome เห็นปริมาณคำขอ ส่วนเว็บไซต์เห็นการนำโทเคนไปใช้
PVT เกี่ยวข้องกับ Private State Tokens และ PACT อย่างไร
แหล่งข่าวไม่ได้อธิบายว่า PVT มาแทน Private State Tokens API explainer ระบุว่าการลงทะเบียน PVT จะคล้ายการลงทะเบียน Private State Token และ PPC Land ระบุว่า Private State Tokens คือกลไกต่อต้านการฉ้อโกงที่ Google เก็บไว้ตอนยุติ Privacy Sandbox ส่วนใหญ่ในเดือนตุลาคม 2568 ความสัมพันธ์ที่แหล่งข่าวอธิบายมีเท่านี้ คือใช้รูปแบบการลงทะเบียนร่วมกัน ในกลุ่มเครื่องมือต่อต้านการฉ้อโกงเดียวกัน
explainer ยังวาง PVT ไว้เป็นคำตอบบางส่วนของข้อเสนอที่กว้างกว่าชื่อ PACT ซึ่งบ่มเพาะใน Anti-Fraud Community Group และมีตารางเทียบทีละข้อกำหนด แทนที่จะอ้างว่าเทียบเท่ากัน
- ตอบว่าใช่: ด่านตรวจสอบที่ไม่สร้างความยุ่งยาก การเชื่อมโยงกลับไม่ได้ การรั่วไหลของข้อมูลน้อยที่สุด ประสิทธิภาพการคำนวณ (เมื่อเทียบกับ proof of work) และการต้านการสมรู้ร่วมคิด (ให้เครดิตกับเพดานสองโดเมน) โดยคำตอบเรื่องการรั่วไหลมีหมายเหตุว่า PACT ยังไม่ได้กำหนดเพดาน entropy
- ตอบว่าไม่: การบล็อก และการส่งฟีดแบ็ก
- ตอบว่าบางส่วน: การเปิดให้เข้าร่วม ซึ่งถูกจำกัดด้วยนโยบายการลงทะเบียนและคาดว่าผู้ออกโทเคนจะน้อยกว่า และการจำกัดอัตราอย่างได้ผล ซึ่งผู้เผยแพร่ควบคุมได้ทางอ้อมผ่านการคุมจำนวนโทเคน
- ไม่เกี่ยวข้อง: การประสานงานให้น้อยที่สุด เพราะผู้เผยแพร่ ผู้ออกโทเคน และผู้รับโทเคนเป็นฝ่ายเดียวกัน
ความต่างเชิงสถาปัตยกรรมคือจุดสำคัญที่สุดสำหรับคนที่คิดเรื่องโฆษณา PACT คาดว่าจะมีสัญญาณข้อมูลต่ำที่ใช้ได้ทั้งในระดับบนสุดและในบริบทของบุคคลที่สาม แต่ PVT ใช้ได้เฉพาะระดับบนสุดของเว็บไซต์เดียว และข้ามเข้าสู่โหมดส่วนตัวทางเดียว ข้อมูลน้อยเข้าไป ไม่มีข้อมูลออกมา
สถานะงาน: เป็น origin trial ไม่ใช่การเปิดตัว
Chrome Platform Status ระบุช่วง origin trial เป็นเวอร์ชัน 154 ถึง 165 บนเดสก์ท็อป และช่วงเดียวกันบน Android ส่วนแถว iOS และ WebView ว่างเปล่า Firefox, WebKit และนักพัฒนาเว็บถูกบันทึกว่ายังไม่ส่งสัญญาณใดๆ และการตรวจสอบสเปกโดย TAG ยังรอดำเนินการ มีอีเมล Google 5 รายการระบุเป็นเจ้าของ
ช่องแผนการเปิดตัวระบุว่าฟีเจอร์จะเปิดใช้ให้ผู้ใช้ทุกคน PPC Land อ่านบรรทัดนี้ว่าเป็นเจตนาที่ปลายทางของกระบวนการ ไม่ใช่สถานะปัจจุบัน และเอกสารออกแบบระบุชัดว่างานนี้ยังไม่ได้รับอนุมัติให้เปิดใช้จริง
เป้าหมายการทดลองที่ระบุไว้แคบ การทดลองมุ่งตรวจว่าชื่อเสียงเชิงบวกที่ผู้ใช้สร้างบนเว็บไซต์ระหว่างท่องเว็บปกติ จะทำให้ได้ประสบการณ์ที่ยุ่งยากน้อยลงบนเว็บไซต์เดียวกันในโหมดส่วนตัวหรือไม่ ผู้เข้าร่วมคาดว่าจะปรับวิธีออกโทเคนไปตลอดการทดลอง และจะตรวจสอบความสัมพันธ์ระหว่างชื่อเสียงที่ส่งต่อกับสัญญาณการใช้งานปกติที่มีอยู่ เป้าหมายรวมคือลดความยุ่งยาก แต่เป้าหมายของการทดลองเองคือยืนยันว่าสัญญาณนี้ช่วยระบบป้องกันบอตได้จริงหรือไม่
ตามโพสต์ Intent to Experiment ในเมลลิงลิสต์ blink-dev ฟีเจอร์นี้อยู่หลัง flag ชื่อ kEnablePrivateVerificationTokens ไม่รองรับ WebView และไม่มีการทดสอบใน web-platform-tests ส่วน repository ของ explainer ที่เปิดสาธารณะมี 24 commits, 9 stars, 2 forks และผู้ร่วมพัฒนา 5 คน ณ ตอนที่ PPC Land บันทึกไว้
มุมมองจากคนนอก
Stan Sadokov ประธานเจ้าหน้าที่บริหารของ NodeMaven ผู้ให้บริการพร็อกซี โพสต์ความเห็นบน LinkedIn เมื่อวันที่ 11 กันยายน 2569 ว่า "If it ships to production, it will change how scraping works." หรือถ้าเปิดใช้จริง มันจะเปลี่ยนวิธีการ scrape ข้อมูล เขายังระบุว่า Chrome 154 เข้าสู่ช่วงเบตาเมื่อวันที่ 2 กันยายน 2569 ซึ่งเป็นวันที่ไม่ปรากฏในรายการ Chrome Platform Status PPC Land ชี้ว่ามุมมองของเขาเป็นมุมมองเชิงพาณิชย์ และเขาเองยอมรับว่าข้อเสนอนี้เป็นร่างช่วงแรกที่จำกัดอยู่ใน Incognito และ Chrome และยังไม่เปลี่ยนแปลงอะไรในระบบจริง
สิ่งที่ PVT ไม่ได้ทำ
ความสับสนเรื่องสัญญาณความน่าเชื่อถือของเบราว์เซอร์ส่วนใหญ่มาจากการมองว่าเป็นเครื่องมือระบุตัวตนหรือกำหนดกลุ่มเป้าหมาย PVT ไม่ใช่ทั้งสองอย่าง และการออกแบบก็ระบุไว้หลายจุด
- ไม่มีตัวตน โทเคนบรรจุหนึ่งบิต ไม่มี user ID ไม่มีคะแนน และไม่มีประวัติการท่องเว็บ
- ใช้ข้ามเว็บไม่ได้ โทเคนที่ออกบนโดเมนหนึ่งใช้ได้เฉพาะบนโดเมนเดียวกันนั้น
- ไม่มีบริบทบุคคลที่สาม PVT ทำงานเฉพาะระดับบนสุด ต่างจากแนวคิด PACT ที่กว้างกว่า
- ไม่มีข้อมูลออกจากโหมดส่วนตัว ข้อมูลเข้าไปในเซสชันส่วนตัว และไม่มีอะไรไหลกลับ
- ไม่มีการบล็อกหรือฟีดแบ็ก ตาราง PACT ของ explainer เองตอบว่าไม่ทั้งสองข้อ
ข้อสรุปของ PPC Land คือคนที่มองกลไกความน่าเชื่อถือระดับเบราว์เซอร์นี้เป็นตัวแทนคุกกี้ จะพบว่าเอกสารไม่ช่วยอะไรในประเด็นนั้น และตั้งใจให้เป็นอย่างนั้น PPC Land ยังชี้ว่านโยบายการลงทะเบียนระบุชัดว่าการตรวจจับ invalid traffic เป็นการใช้งานที่อนุญาต ทำให้สัญญาณจากเบราว์เซอร์เองเข้ามาอยู่ในพื้นที่ปัญหาเดียวกับเครื่องมือตรวจสอบทราฟฟิก แม้โทเคนจะปรากฏเฉพาะในคำขอแรกที่ไม่มีคุกกี้ในเซสชันส่วนตัวก็ตาม
ทีมการตลาดและทีมวิเคราะห์ข้อมูลควรทำอะไรตอนนี้
สำหรับทีมส่วนใหญ่ ยังไม่มีอะไรต้องติดตั้ง PVT เป็น origin trial เว็บไซต์ต้องลงทะเบียน ขั้นตอนการลงทะเบียนยังรอกำหนด และฟีเจอร์ยังไม่ได้รับอนุมัติให้เปิดใช้จริง ขั้นตอนในทางปฏิบัติจึงเป็นเรื่องความเข้าใจและการเตรียมตัว
- อย่าเปลี่ยนระบบกรองบอตหรือ CAPTCHA เพราะ PVT โทเคนออกได้เฉพาะเว็บไซต์ที่ลงทะเบียน ขั้นตอนลงทะเบียนยังรอกำหนด และการทดลองอาจจบลงโดยไม่ได้เปิดใช้จริง
- อย่าคาดหวังมิติข้อมูลใหม่ในระบบวิเคราะห์ แหล่งข่าวไม่ได้อธิบายถึงรายงาน ตัวระบุ หรือข้อมูลที่ไหลเข้าเครื่องมือวัดผล ผู้เข้าชมผ่านโหมดส่วนตัวจะยังมาโดยไม่มีคุกกี้เหมือนเดิม
- รู้ว่าความยุ่งยากสร้างความเสียหายตรงไหน ถ้าเว็บไซต์ตั้งด่านตรวจสอบที่ฟอร์มลีด หน้าเข้าสู่ระบบ หรือหน้าชำระเงิน ควรรู้ว่าทราฟฟิกส่วนนั้นมาแบบไม่มีคุกกี้มากเท่าไร เพื่อให้ทีมประเมินได้ภายหลังว่าสัญญาณหนึ่งบิตจะมีผลหรือไม่
- ให้ทีมนักพัฒนาติดตามการทดลอง สิ่งที่ควรติดตามคือขั้นตอนการลงทะเบียน การเปลี่ยนแปลงในรายการ Chrome Platform Status สัญญาณจาก Firefox และ WebKit และการตรวจสอบของ TAG
- จดกฎเรื่องคุกกี้ไว้หากเข้าร่วม เว็บไซต์ที่ลงทะเบียนแต่ไม่ตั้งคุกกี้หลังได้รับโทเคนจะใช้โทเคนสำรองจนหมด
สิ่งที่แหล่งข่าวไม่ได้บอก
PPC Land ไม่ได้บอกว่าการลงทะเบียนจะทำงานอย่างไร ใครจะได้รับอนุญาตให้ลงทะเบียน หรือจะเปิดเมื่อไร ไม่ได้รายงานเว็บไซต์ที่เข้าร่วม ผลการทดลอง หรือผลต่ออัตราการผ่าน CAPTCHA ไม่มีกำหนดการเปิดใช้จริงนอกจากช่วงทดลองถึง Chrome 165 และไม่ได้บอกว่า Chrome บน iOS หรือ WebView จะถูกรวมเข้ามาหรือไม่ รายงานยังไม่ได้อธิบายความเชื่อมโยงใดๆ ระหว่าง PVT กับ Google Analytics การกรองคลิกไม่ถูกต้องของ Google Ads หรือผลิตภัณฑ์โฆษณาอื่น
ความหมายสำหรับนักการตลาดไทย
แหล่งข่าวไม่ได้พูดถึงประเทศไทย และการทดลองครอบคลุม Chrome บนเดสก์ท็อปและ Android ทั่วโลก โดยไม่มีกฎเฉพาะตลาดใดที่ระบุไว้ สำหรับแบรนด์ไทยที่ฟอร์มลีดและหน้าชำระเงินพึ่ง CAPTCHA ข้อเสนอนี้ควรติดตาม เพราะมุ่งไปที่กลุ่มผู้เข้าชมที่เจอด่านตรวจสอบหนักที่สุด คือคนที่ใช้หน้าต่างส่วนตัว สำหรับทีมที่รายงานคุณภาพทราฟฟิกในระบบ GA4 หรือดูแลปัญหา invalid traffic ในแคมเปญ Google Ads จุดยืนที่ตรงไปตรงมาในวันนี้คือ PVT ยังไม่เปลี่ยนอะไรในข้อมูล มันอาจมีผลในภายหลังถ้าเปิดใช้จริงและเปิดการลงทะเบียน และด้วยเพดานสองเว็บไซต์กับข้อมูลหนึ่งบิต ตามการออกแบบแล้วมันจะไม่กลายเป็นสัญญาณกำหนดกลุ่มเป้าหมายหรือการวัดที่มาของคอนเวอร์ชัน
คำถามที่พบบ่อย (FAQ)
Private Verification Tokens ของ Chrome คืออะไร
คือกลไกที่ Chrome เสนอเพื่อส่งต่อความน่าเชื่อถือหนึ่งบิตจากการท่องเว็บปกติไปยังเซสชันท่องเว็บแบบส่วนตัวบนเว็บไซต์เดียวกัน เว็บไซต์ที่ลงทะเบียนออกโทเคนระหว่างท่องเว็บปกติ และ Chrome แสดงโทเคนหนึ่งครั้งใน Incognito เพื่อให้เว็บไซต์ข้ามด่านตรวจสอบอย่าง CAPTCHA ได้
Private Verification Tokens เปิดใช้ใน Chrome แล้วหรือยัง
ยัง ตอนนี้อยู่ใน origin trial ตั้งแต่ Chrome 154 ถึง Chrome 165 และยังไม่ได้รับอนุมัติให้เปิดใช้จริง เอกสารออกแบบระบุไว้ตรงๆ และการตรวจสอบของ TAG ยังรอดำเนินการ
Private Verification Tokens ระบุตัวตนหรือติดตามผู้ใช้ข้ามเว็บไซต์ได้หรือไม่
ไม่ได้ ตามการออกแบบ โทเคนบรรจุข้อมูลหนึ่งบิต ใช้ได้เฉพาะโดเมนที่ออกโทเคน ใช้ได้กับโดเมนที่ลงทะเบียนไม่เกินสองโดเมนต่อเซสชันส่วนตัว และไม่มีข้อมูลไหลออกจากเซสชันส่วนตัว
ทุกเว็บไซต์ใช้ Private Verification Tokens ได้หรือไม่
ไม่ได้ เฉพาะเว็บไซต์ที่ลงทะเบียนเท่านั้นที่ออกโทเคนได้ การลงทะเบียนต้องยอมรับนโยบายที่จำกัดการใช้ไว้ที่ความน่าเชื่อถือ การจำกัดอัตรา และการตรวจจับ invalid traffic และขั้นตอนการลงทะเบียนเองยังรอกำหนด
ควรเปลี่ยนระบบวิเคราะห์ข้อมูลหรือระบบกรองบอตตอนนี้หรือไม่
ไม่ต้อง ยังไม่มีอะไรให้เปลี่ยน แหล่งข่าวไม่ได้อธิบายว่าการทดลองสร้างข้อมูลวิเคราะห์ใหม่ สิ่งที่มีประโยชน์คือเฝ้าดูรายการ Chrome Platform Status และข่าวเรื่องการลงทะเบียน
Private Verification Tokens เป็นการทดลองขนาดเล็กที่ถูกล้อมรั้วแน่นหนา มุ่งแก้ปัญหาที่น่ารำคาญที่สุดข้อหนึ่งของเว็บ หากทีมของคุณต้องการความช่วยเหลือในการทำความเข้าใจว่าทราฟฟิกบอต ความยุ่งยากจาก CAPTCHA และการท่องเว็บแบบส่วนตัวส่งผลต่อข้อมูลวิเคราะห์ของคุณอย่างไร ก่อนที่สิ่งเหล่านี้จะเปิดใช้จริง Relevant Audience พร้อมไล่ดูข้อมูลไปด้วยกัน
