Server-to-Server Tracking: อุดรอยรั่วเมื่อลูกค้าบล็อกคุกกี้

เมื่อสองสามปีก่อน การวัดผลโฆษณาง่ายกว่านี้เยอะ แปะ pixel ไว้บนเว็บ คนทำอะไรบราวเซอร์ก็รายงานกลับไปให้แพลตฟอร์มครบ แต่วันนี้โลกเปลี่ยนไปแล้ว บราวเซอร์บล็อก third-party cookie ระบบป้องกันการติดตามตัดพารามิเตอร์ทิ้ง แอด blocker ก็ทำงานหนักขึ้น ผลคือ pixel เก็บยอดได้ไม่ครบเหมือนเดิม

อาการที่ร้านเจอคือ ยอดในหน้าแพลตฟอร์มโฆษณา ‘น้อยกว่า’ ยอดที่ปิดได้จริงเรื่อย ๆ ทั้งที่ขายดีขึ้น ตัวเลขในรายงานกลับหดลง พอตัวเลขเพี้ยน ระบบ auto-bidding ก็เรียนรู้จากข้อมูลที่ขาด ๆ หาย ๆ แล้วตัดสินใจผิด

Server-to-Server คือคำตอบที่แพลตฟอร์มใหญ่ ๆ ผลักดันกันหมดในตอนนี้ แนวคิดมันเรียบง่ายมาก แทนที่จะให้บราวเซอร์ของลูกค้าเป็นคนรายงานยอด ก็ให้เซิร์ฟเวอร์ของคุณเป็นคนรายงานแทน บทความนี้จะเล่าว่ามันอุดรอยรั่วตรงไหน และต่างจากวิธีเดิมยังไง

รอยรั่วมันอยู่ตรงไหน ทำไมยอดถึงหาย

ลองนึกภาพการวัดผลแบบเดิมเป็นการฝากจดหมายไว้กับลูกค้า คุณติด pixel บนเว็บ แล้วหวังว่าบราวเซอร์ของลูกค้าจะช่วยส่งข่าวกลับไปบอกแพลตฟอร์มว่า ‘คนนี้ซื้อแล้วนะ’ ปัญหาคือบุรุษไปรษณีย์คนนี้เอาแน่เอานอนไม่ได้

บราวเซอร์สมัยใหม่ตั้งค่าให้บล็อกการติดตามข้ามเว็บโดยอัตโนมัติ ระบบอย่าง ITP บน iOS ก็ตัดพารามิเตอร์ติดตามทิ้งก่อนที่ข้อมูลจะเดินทางกลับ ยังไม่นับ ad blocker ที่คนลงกันเยอะขึ้น ทุกชั้นเหล่านี้ทำให้ ‘จดหมาย’ ของคุณหายระหว่างทาง

สำหรับธุรกิจที่ปิดการขายใน LINE รอยรั่วยิ่งใหญ่ เพราะยอดจริงเกิดในแชทซึ่งอยู่นอกเว็บอยู่แล้ว การพึ่ง pixel บนบราวเซอร์อย่างเดียวจึงแทบไม่เหลืออะไรให้เก็บ นี่คือเหตุผลที่หลายร้านรู้สึกว่าทราฟฟิกจาก LINE กลายเป็น direct/referralมั่วไปหมด

S2S ทำงานยังไง เทียบกับวิธีเดิมแบบเห็นภาพ

ความต่างหลักคือ ‘ใครเป็นคนส่งข้อมูล’ วิธีเดิมให้บราวเซอร์ลูกค้าส่ง วิธี S2S ให้เซิร์ฟเวอร์ของคุณส่ง ดูตารางเทียบง่าย ๆ นี้:

S2S ไม่ใช่ยาวิเศษ ต้องมีของอยู่ในมือก่อน

ผมอยากให้เข้าใจตรงกันว่า S2S ไม่ได้เสกยอดจากอากาศ มันแค่ช่วย ‘ส่งยอดที่คุณมีอยู่แล้ว’ ให้ถึงมือแพลตฟอร์มได้ครบขึ้น แปลว่าคุณต้องมีข้อมูลตั้งต้นที่ดีก่อน

สิ่งที่ต้องมีคือตัวเชื่อมระหว่าง ‘คนที่กดแอด’ กับ ‘คนที่ปิดการขาย’ เช่น GCLID ของ Google หรือ click id ของแพลตฟอร์มอื่น ถ้าคุณเก็บตัวเชื่อมนี้ไม่ได้ตั้งแต่ต้น S2S ก็ไม่มีอะไรจะส่ง แนวคิดนี้เป็นพี่น้องกับการ import ยอดที่ปิดในแชทกลับ Google Adsที่ต้องเก็บ GCLID เหมือนกัน

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

เริ่มยังไงไม่ให้ท่วมหัว

ผมไม่แนะนำให้กระโดดไปทำ S2S เต็มระบบทั้งหมดในทีเดียว มันจะพังและหาจุดผิดยาก ค่อย ๆ ไล่เป็นสเต็ปแบบนี้จะคุมได้กว่า:

1. ตั้งเป้าก่อนว่าจะส่ง event อะไรกลับ — เริ่มจาก event เดียวที่สำคัญสุดคือ ‘ปิดการขาย’ อย่าเพิ่งส่งทุกอย่าง
2. หาตัวเชื่อมให้ได้ — ตรวจว่าคุณเก็บ GCLID หรือ click id ตอนคนกดแอดเข้ามาได้จริง ทดสอบกับเคสจริงสักสิบเคส
3. เชื่อมเซิร์ฟเวอร์กับแพลตฟอร์ม — ตั้ง endpoint ให้เซิร์ฟเวอร์ยิง event พร้อมตัวเชื่อมและมูลค่ากลับไป
4. เทียบยอดสองทาง — ปล่อยให้ทั้ง pixel เดิมและ S2S ทำงานคู่กันสักพัก เทียบว่ายอดครบขึ้นจริงไหม แล้วค่อยลดการพึ่ง pixel
5. ต่อยอดเพิ่ม event — เมื่อ event แรกนิ่งแล้วค่อยเพิ่ม event อื่นเช่นมูลค่าจากสลิปหรือสถานะลูกค้าเก่า

สรุป

โลกของการวัดผลย้ายจากบราวเซอร์มาที่เซิร์ฟเวอร์เพราะบราวเซอร์เชื่อถือไม่ได้อีกต่อไปในเรื่องการส่งยอด Server-to-Server คือการเอาการรายงานมาไว้ในมือคุณเอง ข้อมูลเลยครบขึ้นและ auto-bidding เรียนรู้ได้ตรงขึ้น

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

• รอยรั่วเกิดจากคุกกี้/pixel ถูกบล็อกและตัด พารามิเตอร์
• S2S ให้เซิร์ฟเวอร์ส่งยอดแทนบราวเซอร์ ข้อมูลจึงครบกว่า
• ต้องมีตัวเชื่อม (GCLID/click id) ก่อน แล้วค่อยเริ่มจาก event เดียว

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