ทราฟฟิกส่วนที่ตัวบล็อกโฆษณากินไปเท่าไหร่ และควรชดเชยตัวเลขอย่างไร

สมมติ Ads Manager บอกว่าแอดพาคนคลิกเข้า Landing Page 1,000 ครั้ง แต่ GA4 เห็น session จาก Meta แค่ 780 มีเดียบายเออร์สรุปทันทีว่า ‘ตัวบล็อกโฆษณากินไป 22 เปอร์เซ็นต์’ ฟังดูสมเหตุสมผล และเป็นข้อสรุปที่มักผิด เพราะส่วนต่างนั้นประกอบด้วยหลายอย่างปนกัน

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

ส่วนต่างของตัวเลขมีหลายสาเหตุ และตัวบล็อกเป็นหนึ่งในนั้น

วัดช่องว่างจริงด้วย log ของเซิร์ฟเวอร์ 14 วัน

1. เลือกหน้าเดียวที่รับทราฟฟิกจากแอดเป็นหลัก แล้วตั้ง utm_campaign เฉพาะสำหรับการวัด เช่น cov-test เพื่อให้นับจากทั้งสองฝั่งได้ตรงกัน
2. ดึง log จากเซิร์ฟเวอร์หรือ CDN นับคำขอ HTML ของหน้านั้นที่มี utm_campaign ดังกล่าว ตัดบอตตาม user agent และคำขอซ้ำจากอุปกรณ์เดียวกันที่ห่างกันไม่กี่วินาที
3. ดึง session ของ GA4 สำหรับหน้าและแคมเปญเดียวกันในช่วงเวลาเดียวกัน ตรวจเขตเวลาของรายงานทั้งสองให้ตรงกัน
4. หาร session ของ GA4 ด้วยจำนวนจาก log ได้สัดส่วนครอบคลุม แล้วแยกซ้ำตามกลุ่มอุปกรณ์และเบราว์เซอร์
5. ทำซ้ำอีกช่วงหนึ่งเพื่อดูว่าสัดส่วนนิ่งหรือไม่ ถ้าแกว่งมาก แปลว่าบอตหรือแคมเปญกำลังเปลี่ยนจังหวะ

อ่านผลทีละกลุ่มก่อนจะเอาตัวเลขรวมไปใช้

จากตัวอย่างสมมติข้างบน GA4 ครอบคลุม 85 เปอร์เซ็นต์ และ Meta pixel ครอบคลุม 78 เปอร์เซ็นต์ ตัวเลขสองตัวไม่เท่ากันเป็นเรื่องปกติ เพราะรายการบล็อกของแต่ละเครื่องมือไม่ตรงกัน บางตัวบล็อกโดเมนของโฆษณา บางตัวบล็อกทั้งโดเมนวิเคราะห์ และเบราว์เซอร์บางตัวจำกัดอายุคุกกี้ที่สคริปต์เขียนเอง

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

ชดเชยตัวเลขโดยไม่หลอกตัวเอง

ตัวคูณชดเชยคือหนึ่งหารด้วย coverage ถ้า coverage คือ 0.85 ตัวคูณจะเป็นราว 1.18 แต่การคูณทั้งรายงานมีกับดัก คนที่ใช้ตัวบล็อกไม่จำเป็นต้องมีพฤติกรรมซื้อเหมือนคนที่ไม่ใช้ เรารู้เพียงจำนวนที่หายไป ไม่รู้ว่าคนที่หายไปซื้อบ่อยแค่ไหน

• คูณเฉพาะตัวเลขปริมาณ เช่น session หรือ click เพื่อประเมินต้นทุนต่อการเข้าเว็บ ไม่คูณอัตราแปลง
• ใช้ตัวคูณแยกตามกลุ่มอุปกรณ์ ไม่ใช้ตัวเดียวทั้งเว็บ
• ตรวจย้อนด้วยจำนวนแชทใหม่ใน LINE OA ซึ่งฝั่งเรานับเองโดยตัวบล็อกแตะไม่ได้ ถ้าตัวเลขที่ปรับแล้วขยับไปทางเดียวกับแชทใหม่ จึงค่อยเชื่อ
• เขียนวิธีคำนวณลงในรายงานทุกครั้ง ให้คนอ่านเห็นว่านี่คือตัวเลขที่ปรับ ไม่ใช่ข้อมูลดิบ

ย้ายจุดวัดมาที่โดเมนของตัวเอง ดีกว่าคูณเลขทุกเดือน

ตัวบล็อกทำงานจากรายการโดเมนและรูปแบบ URL ของเครื่องมือโฆษณา จุดวัดที่ส่งไปยังโดเมนของคุณเองจึงรอดมากกว่า วิธีที่เห็นผลตรงที่สุดคือให้ลิงก์ไป LINE วิ่งผ่านปลายทางบนโดเมนตัวเอง เช่น /go/line ที่นับคลิกบนเซิร์ฟเวอร์ แล้วค่อยเด้งไป LINE ซึ่งไม่ต้องพึ่งสคริปต์ของใคร ส่วนการย้ายแท็กไปรันบน server container ใต้โดเมนย่อยของตัวเอง อ่านรายละเอียดที่ server container สำหรับ LINE และเปรียบเทียบวิธีที่ tracking ฝั่งเบราว์เซอร์กับฝั่งเซิร์ฟเวอร์

มีข้อควรระวังเรื่องจริยธรรมและกฎหมายด้วย ตัวบล็อกบางส่วนคือการเลือกของผู้ใช้เรื่องความเป็นส่วนตัว การเก็บข้อมูลฝั่งเซิร์ฟเวอร์ยังต้องอยู่ในขอบเขตที่ประกาศไว้และขอความยินยอมตามที่ต้องขอ ไม่ใช่ช่องทางหลบการปฏิเสธ ปัญหาจากสคริปต์ที่ค่อย ๆ เสื่อมสภาพอธิบายไว้ใน เรื่อง cookie และ pixel เสื่อม

สรุป

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

การคูณชดเชยทำได้ชั่วคราวและเฉพาะตัวเลขปริมาณ ส่วนตัวเลขที่ใช้ตัดสินงบ ให้อิงจำนวนแชทและยอดขายที่นับในฝั่ง LINE ซึ่งตัวบล็อกไม่มีผล

• ส่วนต่างระหว่าง Ads Manager กับ GA4 มีหลายสาเหตุ ตัวบล็อกเป็นแค่หนึ่ง
• วัด coverage ด้วย log เซิร์ฟเวอร์ที่กรองบอตแล้ว เทียบหน้าเดียวกัน 14 วัน
• ชดเชยเฉพาะตัวเลขปริมาณ แยกตามกลุ่มอุปกรณ์ ไม่ชดเชยอัตราแปลง
• ย้ายจุดวัดมาที่โดเมนของตัวเอง และยังต้องเคารพขอบเขตความยินยอม

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