ดีบัก Google Consent Mode ด้วย DevTools ของเบราว์เซอร์: การอ่านพารามิเตอร์ gcs
เหตุใดต้องตรวจสอบในเบราว์เซอร์
แบนเนอร์ความยินยอมที่ดูถูกต้องไม่ใช่หลักฐานว่าแท็กของคุณทำงานถูกต้อง ปัญหาของ Consent Mode เกิดขึ้นอย่างเงียบๆ: หน้าเว็บโหลด โฆษณาแสดง รายงานมีข้อมูล แต่สัญญาณที่ส่งไปยัง Google อาจผิด เครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ช่วยให้คุณตรวจสอบสิ่งที่เกิดขึ้นจริงได้ภายในไม่กี่นาที โดยไม่ต้องใช้ซอฟต์แวร์เพิ่มเติม
ขั้นตอนที่ 1: เปิดแท็บ Network ให้สะอาด
- เปิดหน้าเว็บในหน้าต่างส่วนตัว เพื่อไม่ให้มีตัวเลือกก่อนหน้าถูกเก็บไว้
- เปิด DevTools แล้วไปที่แท็บ Network
- ติ๊ก Preserve log เพื่อให้คำขอคงอยู่เมื่อเปลี่ยนหน้า
- โหลดหน้าซ้ำ และอย่าแตะแบนเนอร์ในตอนนี้
ขั้นตอนที่ 2: หาสถานะความยินยอมในคำขอ
แท็ก Google เพิ่มพารามิเตอร์ gcs ในคำขอของตน คุณกรองรายการเครือข่ายด้วย collect หรือ google แล้วเปิดรายการใดก็ได้เพื่ออ่านสตริงคิวรีของมัน ค่าจะมีลักษณะเป็น G100 หรือ G111
- G100 — ทั้งพื้นที่จัดเก็บโฆษณาและพื้นที่จัดเก็บการวิเคราะห์ถูกปฏิเสธ
- G111 — ทั้งสองอย่างได้รับอนุญาต
- G101 และ G110 — อย่างหนึ่งอนุญาตและอีกอย่างปฏิเสธ
อ่านตัวอักษรจากซ้ายไปขวาหลัง G1: ตัวเลขแรกคือสถานะพื้นที่จัดเก็บโฆษณา และตัวที่สองคือสถานะพื้นที่จัดเก็บการวิเคราะห์ โดย 1 หมายถึงอนุญาต และ 0 หมายถึงปฏิเสธ การติดตั้งรุ่นใหม่ยังส่งพารามิเตอร์ gcd ที่มีสถานะเข้ารหัสยาวกว่า ซึ่งรวมสัญญาณเพิ่มเติมของ Consent Mode v2
ขั้นตอนที่ 3: สิ่งที่ควรเห็นก่อนมีการเลือกใดๆ
ในภูมิภาคที่ต้องได้รับความยินยอม คำขอแรกๆ ที่ส่งก่อนที่ผู้เข้าชมจะโต้ตอบควรแสดงสถานะปฏิเสธ หากคุณเห็น G111 ทั้งที่ผู้เข้าชมยังไม่ได้คลิกอะไรเลย แสดงว่าค่าเริ่มต้นของคุณผิด หรือแท็กทำงานก่อนที่จะตั้งค่าเริ่มต้น
ขั้นตอนที่ 4: สิ่งที่ควรเห็นหลังกดยอมรับ
คลิกยอมรับ แล้วดูคำขอใหม่ สถานะควรเปลี่ยนเป็นอนุญาตและแท็กควรทำงานต่อ หากแบนเนอร์บอกว่ายอมรับแล้วแต่คำขอยังมีสถานะปฏิเสธ แสดงว่าการเรียก update ไปไม่ถึงแท็ก Google หรือทำงานช้าเกินไป
ขั้นตอนที่ 5: ตรวจสอบ Data Layer
ในคอนโซล พิมพ์ dataLayer แล้วขยายรายการ คุณมองหาสองสิ่งตามลำดับ:
- รายการ consent ที่ใช้คำสั่ง default โดยระบุทุกสัญญาณเป็นปฏิเสธสำหรับภูมิภาคที่ต้องได้รับความยินยอม
- รายการ consent ที่ตามมาซึ่งใช้คำสั่ง update หลังผู้ใช้เลือก
สัญญาณของ Consent Mode v2 ได้แก่ ad_storage, analytics_storage, ad_user_data และ ad_personalization หากสองตัวหลังหายไป แสดงว่าเป็นการตั้งค่าแบบ v1
ข้อผิดพลาดที่พบบ่อยที่สุด
- ตั้งค่าเริ่มต้นช้าเกินไป คำสั่ง default ต้องทำงานก่อนที่แท็ก Google หรือคอนเทนเนอร์ Tag Manager จะโหลด
- ไม่เคยส่ง update แบนเนอร์เก็บตัวเลือกไว้แต่ไม่เคยเรียกคำสั่ง update
- มีแค่สองสัญญาณ สัญญาณ v2 สำหรับข้อมูลผู้ใช้และการปรับให้เป็นส่วนตัวหายไป
- ตรรกะภูมิภาคผิด ผู้เข้าชมจากภูมิภาคที่ต้องได้รับความยินยอมถูกถือว่าอนุญาตโดยค่าเริ่มต้น
- ถูกส่วนขยายบล็อก ส่วนขยายความเป็นส่วนตัวในเบราว์เซอร์ของคุณเองซ่อนคำขอ ให้ทดสอบโดยปิดส่วนขยาย
- ตัวเลือกที่ถูกแคช คุณทดสอบในหน้าต่างปกติที่เก็บตัวเลือกก่อนหน้าไว้แล้ว
ขั้นตอนที่ 6: ตรวจโหมดตัวอย่างของ Tag Manager
หากคุณใช้ Google Tag Manager โหมดตัวอย่างจะแสดงสถานะความยินยอมของแต่ละเหตุการณ์บนหน้า และแท็กใดทำงานหรือถูกบล็อก เปรียบเทียบกับสิ่งที่คุณเห็นในแท็บเครือข่าย ทั้งสองมุมมองควรสอดคล้องกัน
ทำให้เป็นกิจวัตร
ทำการตรวจห้านาทีนี้หลังการเปลี่ยนแบนเนอร์ การเผยแพร่คอนเทนเนอร์ หรือการปล่อยไซต์ทุกครั้ง จดค่า gcs ที่คาดหวังสำหรับสี่กรณี: เข้าชมครั้งแรก หลังยอมรับ หลังปฏิเสธ และหลังเปลี่ยนตัวเลือกภายหลัง สิ่งใดที่ไม่ตรงคือบั๊กที่ต้องแก้ก่อนที่รายงานของคุณจะบอกเสียเอง
FlexyConsent อยู่ตรงไหน
FlexyConsent เป็น CMP ที่ได้รับการรับรองจาก Google (CMP ID 317) รองรับ Google Consent Mode v2 โดยส่งสัญญาณ default และ update ให้คุณ คุณยังควรตรวจสอบบนเบราว์เซอร์นี้กับหน้าของคุณเอง เพราะลำดับแท็กและการตั้งค่าคอนเทนเนอร์เป็นเรื่องเฉพาะของไซต์คุณ
ประเด็นสำคัญ
- ทดสอบในหน้าต่างส่วนตัวพร้อมเก็บบันทึกเครือข่ายไว้
- อ่านค่า gcs: G100 คือปฏิเสธ G111 คืออนุญาต
- ค่าเริ่มต้นแบบปฏิเสธต้องมองเห็นได้ก่อนที่ผู้เข้าชมจะเลือก
- update ต้องเปลี่ยนสถานะทันทีหลังการเลือก
- ยืนยันว่าสัญญาณ Consent Mode v2 ทั้งสี่ปรากฏใน data layer