GA4 DebugView: วิธีเปิดโหมดดีบักและทดสอบเหตุการณ์

GA4 DebugView คือรายงานใน Google Analytics 4 ที่แสดงทีละเหตุการณ์ว่าอุปกรณ์เครื่องหนึ่งที่เปิดโหมดดีบักกำลังส่งข้อมูลอะไรเข้ามาในพร็อพเพอร์ตี้ ทำให้ตรวจการติดตามได้ก่อนที่ข้อมูลจะเข้าไปอยู่ในรายงานจริง เปิดได้จากเมนูผู้ดูแลระบบ (Admin) ในส่วนการแสดงข้อมูล (Data display) และจะแสดงเฉพาะอุปกรณ์ที่เปิดโหมดดีบักผ่าน Tag Assistant, การแสดงตัวอย่างของ Google Tag Manager หรือพารามิเตอร์ debug_mode เท่านั้น

บทความนี้อธิบายว่า DebugView อยู่ตรงไหน วิธีเปิดโหมดดีบักแบบต่าง ๆ ทำไมบางครั้งรายงานว่างเปล่า วิธีตรวจเหตุการณ์ พารามิเตอร์ และพร็อพเพอร์ตี้ผู้ใช้ก่อนเผยแพร่ ทราฟฟิกดีบักไปปนอยู่ในรายงานมาตรฐานหรือไม่ และ DebugView ต่างจากรายงานเรียลไทม์และ GTM Preview อย่างไร Google มีการย้ายเมนูเป็นระยะ เส้นทางเมนูด้านล่างจึงอ้างอิงตามเอกสารช่วยเหลือปัจจุบันของ Google และอาจดูต่างไปเล็กน้อยในพร็อพเพอร์ตี้ของคุณ

DebugView ใน GA4 คืออะไร และอยู่ตรงไหน

DebugView คือสตรีมข้อมูลแบบสดแยกตามอุปกรณ์ แสดงเหตุการณ์ที่ GA4 ได้รับจากเบราว์เซอร์หรือแอปที่เปิดโหมดดีบัก หน้าช่วยเหลือของ Google ระบุตำแหน่งไว้ที่ ผู้ดูแลระบบ (Admin) แล้วไปที่การแสดงข้อมูล (Data display) แล้วเลือก DebugView รายงานนี้ไม่ได้แสดงผู้ใช้ทั้งหมด แสดงเฉพาะอุปกรณ์ที่ถูกตั้งค่าให้ดีบัก ซึ่งเป็นสิ่งที่ทำให้มีประโยชน์ เพราะคุณติดตามเซสชันทดสอบของตัวเองได้โดยไม่มีข้อมูลของผู้เข้าชมคนอื่นมาปน

รายงานมีหลายส่วน ตามที่ Google อธิบายไว้

• สตรีมวินาที (Seconds stream): เหตุการณ์ที่บันทึกใน 60 วินาทีล่าสุด คุณจะเห็นเหตุการณ์ปรากฏขึ้นภายในไม่กี่วินาทีหลังจากทำการทดสอบ
• สตรีมนาที (Minutes stream): วงกลมหนึ่งวงต่อหนึ่งนาทีสำหรับ 30 นาทีล่าสุด แต่ละวงแสดงจำนวนเหตุการณ์ในนาทีนั้น การคลิกวงกลมจะโหลดเหตุการณ์ของนาทีนั้นเข้าสู่สตรีมวินาที
• เหตุการณ์ยอดนิยม (Top events): เหตุการณ์ที่บันทึกบ่อยที่สุดในช่วง 30 นาที
• พร็อพเพอร์ตี้ผู้ใช้ปัจจุบัน (Current user properties): ค่าพร็อพเพอร์ตี้ผู้ใช้ล่าสุดของอุปกรณ์ที่เลือก
• ตัวเลือกอุปกรณ์ดีบัก: อยู่มุมซ้ายบน มีป้าย DEBUG DEVICE หากมีหลายอุปกรณ์อยู่ในโหมดดีบัก เช่น เพื่อนร่วมงานทดสอบพร้อมกัน ให้เลือกอุปกรณ์ของคุณที่นี่

การคลิกเหตุการณ์แต่ละรายการจะเปิดพารามิเตอร์ของเหตุการณ์นั้น ซึ่งเป็นจุดที่การตรวจสอบจริงส่วนใหญ่เกิดขึ้น

เปิดโหมดดีบักอย่างไร

เอกสารของ Google แบ่งวิธีไว้สองกลุ่ม คือวิธีที่ทำให้เฉพาะอุปกรณ์ของคุณเข้าสู่โหมดดีบัก และวิธีที่เปิดโหมดดีบักในการตั้งค่าแท็กโดยตรง

อุปกรณ์ของคุณเอง: Tag Assistant หรือการแสดงตัวอย่างของ Tag Manager

วิธีที่เร็วที่สุดคือ Google Tag Assistant ที่ tagassistant.google.com หรือปุ่ม Preview ใน Google Tag Manager ซึ่งจะเปิด Tag Assistant ให้ เมื่อเชื่อมต่อกับเว็บไซต์ Tag Assistant จะเพิ่มพารามิเตอร์ใน URL ของหน้าเว็บ และ GA4 จะถือว่าข้อมูลจากเซสชันนั้นเป็นทราฟฟิกดีบัก นี่เป็นตัวเลือกที่ปลอดภัยที่สุดสำหรับการทดสอบประจำวัน เพราะไม่มีอะไรเปลี่ยนในแท็กที่ใช้งานจริง และมีผลเฉพาะเซสชันเบราว์เซอร์ของคุณ

พารามิเตอร์ debug_mode ใน gtag.js

หากติดแท็กเว็บไซต์ด้วย gtag.js หน้าช่วยเหลือของ Google แนะนำให้เพิ่ม debug_mode: true ในคำสั่ง config เพื่อติดตามทุกเหตุการณ์ หรือเพิ่มในคำสั่ง event แต่ละรายการเพื่อติดตามเฉพาะเหตุการณ์นั้น วิธีนี้เหมาะกับเว็บไซต์ทดสอบ (staging) หรือการทดสอบระยะสั้น แต่สิ่งที่เพิ่มใน config จะมีผลกับผู้เข้าชมทุกคนที่โหลดโค้ดนั้น จึงไม่ควรปล่อยทิ้งไว้บนเว็บไซต์จริง

พารามิเตอร์ debug_mode ใน Google Tag Manager

ใน GTM หน้าช่วยเหลือของ Google แนะนำให้ตั้ง debug_mode เป็น true ในแท็ก Google (Google tag) สำหรับทุกเหตุการณ์ หรือในแท็ก Google Analytics: GA4 Event สำหรับเหตุการณ์เฉพาะ เช่นเดียวกัน เมื่อเผยแพร่คอนเทนเนอร์แล้ว การตั้งค่านี้จะมีผลกับทุกคนที่ทำให้แท็กนั้นทำงาน จึงควรใช้ใน workspace ทดสอบหรือสภาพแวดล้อม staging

การปิดโหมดดีบัก

Google ระบุรายละเอียดที่หลายคนพลาด คือการปิดโหมดดีบักต้องลบพารามิเตอร์ debug_mode ออก การตั้งค่าเป็น false ไม่ได้ปิดโหมดดีบัก หากเว็บไซต์ยังส่งทราฟฟิกดีบักอยู่หลังจากมีคน "ปิดแล้ว" นี่คือจุดแรกที่ควรตรวจ

แอปและส่วนขยาย Chrome

สำหรับแอป Android และ iOS Google แนะนำให้ดูเอกสารของ Firebase เพราะโหมดดีบักของแอปเปิดผ่าน Firebase SDK ไม่ใช่ผ่านแท็กบนเว็บ คุณอาจเจอส่วนขยาย Google Analytics Debugger สำหรับ Chrome ในคู่มือรุ่นเก่า ซึ่งเป็นวิธีระบุเซสชันจากฝั่งเบราว์เซอร์ แต่หน้าช่วยเหลือ DebugView ปัจจุบันของ Google ระบุ Tag Assistant, GTM preview และ debug_mode เป็นวิธีหลัก จึงควรใช้วิธีเหล่านี้เป็นหลัก

ทำไม DebugView ว่างเปล่าหรือไม่แสดงอุปกรณ์

DebugView ที่ว่างเปล่ามักมีสาเหตุง่าย ๆ ให้ไล่ตรวจตามลำดับนี้

1. โหมดดีบักยังไม่ได้เปิดจริง ตรวจว่า Tag Assistant แสดงเซสชันที่เชื่อมต่อแล้ว หรือมีพารามิเตอร์ debug_mode อยู่ในแท็กที่ทำงาน
2. ดูผิดพร็อพเพอร์ตี้ รหัสการวัด (Measurement ID) ในแท็กต้องตรงกับพร็อพเพอร์ตี้ที่เปิด DebugView อยู่ เว็บไซต์ที่มีหลายพร็อพเพอร์ตี้หรือมีพร็อพเพอร์ตี้สำหรับทดสอบมักสับสนได้ง่าย
3. ยังไม่ได้ให้ความยินยอม หน้าช่วยเหลือของ Google ระบุว่าเหตุการณ์จะไม่ปรากฏหากใช้โหมดความยินยอม (consent mode) และผู้ใช้ยังไม่ยินยอมให้ใช้คุกกี้ Analytics ระหว่างทดสอบ ให้กดยอมรับคุกกี้วิเคราะห์ในแบนเนอร์ของคุณก่อน
4. การควบคุมความเป็นส่วนตัวฝั่งไคลเอนต์ Google ระบุว่าเหตุการณ์จะไม่แสดงในโหมดดีบัก หากคุณใช้การควบคุมความเป็นส่วนตัวฝั่งไคลเอนต์
5. เลือกอุปกรณ์ผิด หากมีอุปกรณ์มากกว่าหนึ่งเครื่องอยู่ในโหมดดีบัก ให้ใช้ตัวเลือก DEBUG DEVICE เลือกเครื่องของคุณ
6. ส่วนขยายเบราว์เซอร์บล็อกคำขอ ตัวบล็อกโฆษณาและการติดตามอาจหยุดคำขอของ GA4 ไม่ให้ออกจากเบราว์เซอร์ ให้ทดสอบในโปรไฟล์เบราว์เซอร์ที่ไม่มีส่วนขยาย
7. ดูเร็วเกินไป รอสักครู่หลังเหตุการณ์แรก แล้วลองทำอีกการกระทำหนึ่งบนหน้าเว็บ

หาก Tag Assistant แสดงว่าแท็ก GA4 ทำงาน แต่ DebugView ยังไม่แสดงอะไร ประเด็นเรื่องความยินยอมและการควบคุมความเป็นส่วนตัวข้างต้นคือคำอธิบายที่เป็นไปได้มากที่สุด เพราะแท็กอาจทำงานแต่ยังถูกกันไม่ให้ส่งเหตุการณ์

ตรวจเหตุการณ์ พารามิเตอร์ และพร็อพเพอร์ตี้ผู้ใช้ก่อนเผยแพร่อย่างไร

จุดประสงค์ของ DebugView คือจับปัญหาการติดตามก่อนที่จะกลายเป็นข้อมูลผิดหลายเดือน ขั้นตอนทดสอบที่ใช้ได้จริงสำหรับเหตุการณ์ใหม่หรือการแก้ไขใน GTM มีดังนี้

1. แก้ไขใน workspace ของ GTM โดยยังไม่เผยแพร่ แล้วคลิก Preview เพื่อเริ่มเซสชัน Tag Assistant บนเว็บไซต์
2. เปิด DebugView ในอีกแท็บหนึ่งแล้วเลือกอุปกรณ์ของคุณ
3. ทำการกระทำที่ต้องการติดตาม เช่น ส่งฟอร์ม หรือเพิ่มสินค้าลงตะกร้า
4. หาเหตุการณ์ในสตรีมวินาทีแล้วคลิก ตรวจว่าชื่อเหตุการณ์สะกดตรงตามแผนทุกตัวอักษร เพราะชื่อเหตุการณ์ใน GA4 แยกตัวพิมพ์เล็กและใหญ่
5. เปิดพารามิเตอร์และตรวจทีละค่า ทั้งหน้าที่ถูกต้อง รหัสสินค้าที่ถูกต้อง มูลค่าและสกุลเงินในเหตุการณ์อีคอมเมิร์ซ และไม่มีค่าว่างหรือค่า "undefined"
6. ตรวจแผงพร็อพเพอร์ตี้ผู้ใช้ปัจจุบัน หากระบบของคุณตั้งค่าพร็อพเพอร์ตี้ผู้ใช้ เช่น ประเภทลูกค้าหรือสถานะการเข้าสู่ระบบ
7. หากเหตุการณ์นั้นเป็นเหตุการณ์สำคัญ (key event) ใน GA4 ให้ยืนยันว่าถูกระบุเป็นเหตุการณ์สำคัญในสตรีม
8. ทดสอบกรณีขอบเขตด้วย การส่งฟอร์มที่ล้มเหลวไม่ควรทำให้เหตุการณ์สำเร็จทำงาน และการรีโหลดหน้าไม่ควรส่งการซื้อซ้ำ
9. หลังจากนั้นจึงเผยแพร่คอนเทนเนอร์ GTM และตรวจว่าไม่มี debug_mode ค้างอยู่ในแท็กที่ใช้งานจริง

ตัวอย่างสมมุติ: คุณเพิ่มเหตุการณ์ generate_lead ให้กับฟอร์มติดต่อ ใน DebugView คุณเห็นเหตุการณ์ทำงาน แต่พารามิเตอร์ form_name ว่างเปล่า เพราะทริกเกอร์อ่านค่าจากช่องที่ไม่มีอยู่ในหน้าขอบคุณ การแก้ก่อนเผยแพร่ใช้เวลาไม่กี่นาที แต่หากไปพบในรายงานประจำเดือน พารามิเตอร์นี้จะหายไปสำหรับลีดทุกรายในช่วงนั้น เพราะ GA4 ไม่เขียนข้อมูลย้อนหลังใหม่ สถานการณ์นี้เป็นตัวอย่างประกอบ ไม่ได้มาจากบัญชีจริง

ทราฟฟิกดีบักถูกนับในรายงานมาตรฐานหรือไม่

หน้าช่วยเหลือ DebugView ของ Google ไม่ได้ระบุว่าเหตุการณ์ดีบักถูกตัดออกจากรายงานมาตรฐาน สิ่งที่ระบุไว้คือควรกรองทราฟฟิกของนักพัฒนา เพื่อไม่ให้ข้อมูลดีบักกระทบผลในรายงาน เครื่องมือสำหรับเรื่องนี้คือตัวกรองข้อมูล (data filter)

ตามหน้าช่วยเหลือของ Google เรื่องตัวกรองทราฟฟิกนักพัฒนา ให้ไปที่ ผู้ดูแลระบบ แล้วไปที่การเก็บรวบรวมและแก้ไขข้อมูล (Data collection and modification) แล้วเลือกตัวกรองข้อมูล (Data filters) คลิกสร้างตัวกรอง แล้วเลือกทราฟฟิกของนักพัฒนา (Developer Traffic) คุณต้องมีบทบาทผู้แก้ไข (Editor) ในพร็อพเพอร์ตี้ ตัวกรองมีสามสถานะ

• ทดสอบ (Testing): ข้อมูลที่ตรงเงื่อนไขจะถูกติดป้ายแทนการลบ และแสดงในมิติ "Test data filter name" ในรายงานและการสำรวจ คุณจึงตรวจได้ว่าตัวกรองจะจับข้อมูลอะไรบ้าง
• ใช้งาน (Active): ตัวกรองมีผลกับข้อมูลที่เข้ามา และผลนั้นถาวร
• ไม่ใช้งาน (Inactive): ตัวกรองไม่ถูกประมวลผล

Google ยังระบุว่าพร็อพเพอร์ตี้หนึ่งมีตัวกรองข้อมูลได้สูงสุด 10 ตัว ตัวกรองไม่เปลี่ยนข้อมูลย้อนหลัง ข้อมูลที่ถูกตัดออกจะไม่ถูกประมวลผลและจะไม่มีให้ใช้ใน Google Analytics หรือ BigQuery อีก และตัวกรองอาจใช้เวลา 24 ถึง 36 ชั่วโมงจึงจะมีผล เนื่องจากตัวกรองที่ใช้งานแล้วมีผลถาวร ให้รันในสถานะทดสอบก่อนและยืนยันว่าจับเฉพาะข้อมูลที่ต้องการ

อีกประเด็นจากหน้าช่วยเหลือ DebugView คือการระบุแหล่งที่มา (attribution) ใน DebugView มีข้อจำกัด หากต้องการข้อมูลแหล่งที่มาและสื่อที่แม่นยำ ให้ใช้รายงานการได้มาซึ่งผู้ใช้ (Acquisition)

DebugView เทียบกับรายงานเรียลไทม์และ GTM Preview: แต่ละตัวใช้ทำอะไร

เครื่องมือทั้งสามมีส่วนที่ซ้อนกัน แต่แต่ละตัวตอบคำถามต่างกัน

ในทางปฏิบัติจะใช้ต่อเนื่องกัน GTM Preview บอกว่าแท็กทำงานหรือไม่ DebugView บอกว่า GA4 ได้รับเหตุการณ์ที่ถูกต้องพร้อมพารามิเตอร์ที่ถูกต้องหรือไม่ และรายงานเรียลไทม์บอกหลังเผยแพร่ว่าผู้เข้าชมจริงกำลังสร้างเหตุการณ์นั้น หน้าช่วยเหลือของ Google เรื่องรายงานเรียลไทม์ระบุว่ารายงานนี้ครอบคลุม 30 นาทีล่าสุด ขณะที่ DebugView แสดงกิจกรรมในช่วงเวลาที่ยาวกว่านั้นได้สำหรับอุปกรณ์ที่อยู่ในโหมดดีบัก

ความหมายสำหรับตลาดไทย

เว็บไซต์ภาษาไทยมีประเด็นการดีบักเฉพาะบางอย่าง เว็บไซต์จำนวนมากมีทั้งเวอร์ชันภาษาไทยและภาษาอังกฤษ บางครั้งอยู่ใต้พาธ /th/ หรือแยกซับโดเมน จึงควรทดสอบเหตุการณ์ทั้งสองภาษา แทนที่จะคิดว่าการตั้งค่าเดียวครอบคลุมทั้งหมด ข้อความภาษาไทยในค่าพารามิเตอร์ เช่น ชื่อหน้าหรือชื่อสินค้า ควรตรวจใน DebugView ว่าเข้ามาเป็นข้อความที่อ่านได้ ไม่ใช่ตัวอักษรเพี้ยน เพราะรายงานและกลุ่มเป้าหมายที่สร้างจากค่าเหล่านี้จะถูกต้องก็ต่อเมื่อค่าเข้ามาครบ อีกเรื่องหนึ่งคือ พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) ของไทยทำให้แบนเนอร์ขอความยินยอมพบได้ทั่วไปบนเว็บไซต์ไทย ซึ่งเชื่อมโยงโดยตรงกับประเด็นเรื่องความยินยอมข้างต้น หากผู้ทดสอบลืมกดยอมรับคุกกี้วิเคราะห์ DebugView จะดูว่างเปล่าแม้แท็กจะทำงานปกติ สุดท้าย ธุรกิจไทยจำนวนมากรับลีดผ่าน LINE หรือโทรศัพท์มากกว่าฟอร์ม จึงควรวางแผนและทดสอบเหตุการณ์คลิกของปุ่มเหล่านี้ เพราะมักเป็นคอนเวอร์ชันหลัก

คำถามที่พบบ่อยเกี่ยวกับ GA4 DebugView

DebugView ใน GA4 อยู่ตรงไหน

ไปที่ผู้ดูแลระบบ แล้วในส่วนการแสดงข้อมูลให้คลิก DebugView ตามเอกสารช่วยเหลือของ Google รายงานนี้แสดงเฉพาะอุปกรณ์ที่เปิดโหมดดีบัก

ปิดโหมดดีบักใน GA4 อย่างไร

ลบพารามิเตอร์ debug_mode ออกจากการตั้งค่า gtag.js หรือ Google Tag Manager เพราะ Google ระบุว่าการตั้งค่าเป็น false ไม่ได้ปิดโหมดดีบัก สำหรับเซสชัน Tag Assistant ให้ปิดเซสชันนั้น

ทำไม DebugView ไม่แสดงเหตุการณ์ทั้งที่แท็กทำงาน

สาเหตุที่พบบ่อยที่สุดคือ ใช้โหมดความยินยอมแต่ยังไม่ได้ยินยอมคุกกี้วิเคราะห์ มีการควบคุมความเป็นส่วนตัวฝั่งไคลเอนต์ เลือกพร็อพเพอร์ตี้หรืออุปกรณ์ผิด หรือส่วนขยายเบราว์เซอร์บล็อกคำขอ หน้าช่วยเหลือของ Google ระบุเรื่องความยินยอมและการควบคุมความเป็นส่วนตัวฝั่งไคลเอนต์ว่าเป็นเหตุให้เหตุการณ์ไม่ปรากฏ

ทราฟฟิกดีบักถูกลบออกจากรายงาน GA4 อัตโนมัติหรือไม่

หน้าช่วยเหลือ DebugView ของ Google ไม่ได้ระบุเช่นนั้น และแนะนำให้กรองทราฟฟิกนักพัฒนาแทน ให้สร้างตัวกรองข้อมูลทราฟฟิกของนักพัฒนาในเมนูผู้ดูแลระบบ การเก็บรวบรวมและแก้ไขข้อมูล ตัวกรองข้อมูล และทดสอบก่อนเปิดใช้งาน

ควรใช้ DebugView หรือ GTM Preview

ควรใช้ทั้งสองอย่าง GTM Preview แสดงว่าแท็กทำงานหรือไม่และเพราะอะไร ส่วน DebugView แสดงว่า GA4 ได้รับอะไรจริง การตรวจแค่อย่างเดียวอาจพลาดปัญหาในอีกครึ่งหนึ่งของระบบ

ทำให้การติดตาม GA4 ของคุณถูกต้อง

DebugView เปลี่ยนการติดตามจากการเดาให้เป็นสิ่งที่ตรวจได้ทีละบรรทัดก่อนข้อมูลจะเข้าสู่รายงาน หากพร็อพเพอร์ตี้ของคุณต้องการแผนเหตุการณ์ที่เป็นระเบียบขึ้น การตั้งค่าที่รองรับความยินยอม หรือการตรวจสอบทั้งหมดว่ากำลังเก็บข้อมูลอะไรอยู่ บริการติดตั้งและย้ายระบบ GA4 ครอบคลุมทั้งการติดตั้งและการตรวจคุณภาพ เหตุการณ์ GA4 ที่ถูกต้องยังส่งต่อไปเป็นคอนเวอร์ชันที่ใช้ใน บริการบริหารแคมเปญ Google Ads และ บริการตรวจ SEO เชิงเทคนิค สามารถรวมการตรวจว่าแท็กติดตามและแท็กความยินยอมโหลดบนหน้าเว็บของคุณอย่างไรได้ด้วย