เบราว์เซอร์บล็อกคุกกี้จนข้อมูลหาย Microsoft Ads Conversions API แก้ปัญหานี้อย่างไร

ทีมการตลาดรายหนึ่งเล่าให้ฟังว่า ตั้งแต่เปลี่ยนมาใช้ Safari กับ Browser ที่เข้มงวดเรื่องความเป็นส่วนตัวมากขึ้น ตัวเลข Conversion ที่เคยเห็นใน Microsoft Advertising เริ่มลดลงทั้งที่ยอดขายจริงไม่ได้ลดตาม พอไล่ดูถึงพบว่า UET Tag ที่ฝังไว้บนเว็บไซต์ถูกบล็อกไม่ให้ทำงานเต็มที่ในบางเบราว์เซอร์ ทำให้ Conversion หายไปบางส่วนโดยไม่รู้ตัว

นี่คือปัญหาที่ทำให้แพลตฟอร์มโฆษณาหลายเจ้ารวมถึง Microsoft Advertising เริ่มเปิดทางให้ธุรกิจส่งข้อมูล Conversion ผ่านเซิร์ฟเวอร์โดยตรง แทนที่จะพึ่งแค่โค้ดที่รันบนเบราว์เซอร์ของลูกค้า วิธีนี้เรียกว่า Conversions API หรือบางทีเรียกรวมกับแนวคิด Server Side Tracking

บทความนี้จะอธิบายว่า Conversions API คืออะไรในทางปฏิบัติ ต่างจาก UET Tag แบบเดิมตรงไหน และธุรกิจแบบไหนที่ควรเริ่มพิจารณาย้ายมาใช้ช่องทางนี้

อาการข้อมูล Conversion หายไปจากฝั่งเบราว์เซอร์ เกิดจากอะไร

การเก็บ Conversion แบบเดิมของ Microsoft Advertising อาศัย UET Tag ที่เป็นโค้ด JavaScript ฝังอยู่บนหน้าเว็บ ทำงานเมื่อเบราว์เซอร์ของลูกค้าโหลดหน้าเว็บนั้นแล้วรันสคริปต์สำเร็จ ปัญหาคือเบราว์เซอร์รุ่นใหม่จำนวนมากเริ่มบล็อก Third Party Cookie หรือจำกัดอายุของ Cookie ที่ใช้ติดตามผู้ใช้ ทำให้บางครั้งสคริปต์ทำงานไม่ครบ หรือค่าที่เก็บไว้หมดอายุเร็วกว่าที่ควร

นอกจากนี้ยังมีปัจจัยอื่นที่ทำให้ข้อมูลฝั่งเบราว์เซอร์หายไปได้ เช่น ผู้ใช้ปิดกั้นสคริปต์ด้วย Ad Blocker เปิด Private Browsing หรือใช้แอปในเครือข่ายที่จำกัดการเชื่อมต่อบางประเภท สถานการณ์เหล่านี้ทำให้ข้อมูลที่ Microsoft Advertising มองเห็นเป็นเพียงบางส่วนของความจริง ไม่ใช่ภาพทั้งหมดของ Conversion ที่เกิดขึ้นจริง

สำหรับธุรกิจที่พาลูกค้าจากโฆษณาเข้าสู่ LINE ปัญหานี้ยิ่งซ้ำเข้าไปอีกชั้น เพราะเส้นทางลูกค้าสั้นและออกจากเว็บไซต์เร็วอยู่แล้ว ถ้าสคริปต์บนเบราว์เซอร์ทำงานไม่ทันหรือถูกบล็อกเพียงเสี้ยววินาที ข้อมูลที่ควรถูกเก็บก็หายไปพร้อมกับ session นั้นทันที

Conversions API คืออะไร ต่างจาก UET Tag ตรงไหน

Conversions API เป็นช่องทางที่ให้ธุรกิจส่งข้อมูล Conversion จากฝั่งเซิร์ฟเวอร์ของตัวเองตรงไปยัง Microsoft Advertising แทนที่จะพึ่งแค่โค้ดที่รันบนเบราว์เซอร์ของลูกค้าเพียงอย่างเดียว หมายความว่าต่อให้เบราว์เซอร์บล็อกสคริปต์หรือ Cookie หมดอายุไปแล้ว ธุรกิจก็ยังมีอีกช่องทางหนึ่งในการยืนยันว่า Conversion นั้นเกิดขึ้นจริง

ความต่างสำคัญคือ UET Tag ทำงานที่ฝั่ง Client หรือฝั่งเบราว์เซอร์ผู้ใช้ ขณะที่ Conversions API ทำงานที่ฝั่ง Server ของธุรกิจเอง ซึ่งควบคุมได้เองมากกว่าและไม่ขึ้นกับข้อจำกัดของแต่ละเบราว์เซอร์ แต่แลกมาด้วยความซับซ้อนทางเทคนิคที่สูงขึ้น เพราะต้องมีระบบหลังบ้านที่พร้อมยิงข้อมูลออกไปในรูปแบบและความปลอดภัยตามที่แพลตฟอร์มกำหนด

สิ่งที่ต้องเข้าใจให้ชัดคือ Conversions API ไม่ได้มาแทนที่ UET Tag ทั้งหมด ในทางปฏิบัติหลายธุรกิจใช้สองช่องทางนี้ควบคู่กัน โดยให้ระบบของ Microsoft Advertising ทำ Deduplication เพื่อไม่ให้นับ Conversion เดียวกันซ้ำสองครั้งจากสองช่องทาง

องค์ประกอบที่ต้องมีก่อนเริ่มใช้ Conversions API

การเปิดใช้งาน Conversions API ไม่ใช่แค่การกดปุ่มเปิดในหน้าตั้งค่า แต่ต้องมีโครงสร้างพื้นฐานฝั่งธุรกิจรองรับให้ครบก่อน

• เซิร์ฟเวอร์หรือระบบหลังบ้านที่ยิง Request ได้ — ต้องมีความสามารถส่งข้อมูลไปยัง Endpoint ของ Microsoft Advertising ตามรูปแบบที่เอกสารล่าสุดกำหนด
• Credential สำหรับยืนยันตัวตน — ต้องมีการขอสิทธิ์เข้าถึงบัญชีโฆษณาและเก็บรักษา Token หรือ Key อย่างปลอดภัย ไม่เปิดเผยในโค้ดฝั่ง Client
• Event Mapping ที่ชัดเจน — ต้องกำหนดว่า Event แบบไหนในระบบธุรกิจตรงกับ Conversion Event แบบไหนที่ตั้งไว้ใน Microsoft Advertising เช่น Lead, Qualified Lead หรือ Purchase
• Identifier สำหรับจับคู่ — ยังต้องมีตัวเชื่อมอย่าง MSCLKID หรือข้อมูลที่ผ่านการเข้ารหัสแนบไปกับ Request เพื่อให้ระบบจับคู่ Conversion กับคลิกโฆษณาต้นทางได้ถูกต้อง

ขั้นตอนคร่าว ๆ ในการส่งข้อมูลผ่าน Conversions API

1. เก็บ MSCLKID ไว้ตั้งแต่ลูกค้าคลิกโฆษณาเข้ามา เช่นเดียวกับการเตรียมข้อมูลสำหรับ Offline Conversion Import ทั่วไป
2. ผูก MSCLKID กับ Lead ที่เกิดขึ้นใน LINE และติดตามสถานะจนกว่าจะปิดการขายหรือยกเลิก
3. เมื่อเกิด Event ที่ต้องการนับ เช่น ปิดออเดอร์ ให้ระบบหลังบ้านสร้าง Request ตามรูปแบบที่ Microsoft Advertising กำหนด พร้อม Identifier มูลค่า และเวลา
4. ยิง Request ผ่าน Credential ที่ตั้งค่าไว้ แล้วตรวจสอบ Response ว่าระบบรับข้อมูลสำเร็จหรือมีข้อผิดพลาด
5. ตั้งกลไก Retry หรือ Queue สำหรับกรณีที่ส่งไม่สำเร็จในครั้งแรก เพื่อไม่ให้ข้อมูลตกหล่นถาวร

Conversions API เหมาะกับธุรกิจแบบไหน ไม่เหมาะกับใคร

ธุรกิจที่เหมาะกับการลงทุนทำ Conversions API มักเป็นธุรกิจที่มีทีมเทคนิคหรือมีเอเจนซี่ที่ดูแลระบบหลังบ้านอย่างต่อเนื่อง มีปริมาณ Conversion ต่อเดือนมากพอที่จะเห็นผลต่างชัดเจนเมื่อข้อมูลแม่นขึ้น และใช้งบโฆษณากับ Microsoft Ads ต่อเนื่องในระดับที่ความแม่นยำของข้อมูลส่งผลต่อการตัดสินใจจัดงบจริง

ในทางกลับกัน ธุรกิจขนาดเล็กที่ยังไม่มีทีมเทคนิค งบโฆษณาต่อเดือนยังน้อย หรือยังไม่ได้ทำ Offline Conversion Import ผ่าน MSCLKID ให้เสถียรก่อน ไม่ควรกระโดดไปทำ Conversions API เป็นอันดับแรก เพราะความซับซ้อนของการดูแลระบบเซิร์ฟเวอร์และ Credential อาจสูงเกินความจำเป็นของสเกลธุรกิจในตอนนี้ ควรทำรากฐานให้มั่นคงก่อนแล้วค่อยขยับมาทำ Server Side Tracking เมื่อพร้อมจริง

ข้อจำกัดและความเสี่ยงที่ต้องรู้ก่อนเริ่มใช้งาน

ข้อจำกัดแรกคือความรับผิดชอบด้านความปลอดภัยของ Credential ตกอยู่ที่ธุรกิจเองทั้งหมด ถ้า Token หรือ Key รั่วไหลออกไป อาจถูกนำไปใช้ส่งข้อมูลปลอมเข้าระบบโฆษณาได้ จึงต้องมีการจัดเก็บและหมุนเวียน Credential อย่างรัดกุม

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

ข้อจำกัดที่สามคือ Conversions API ไม่ได้แก้ปัญหาการจับคู่ Conversion ให้แม่นขึ้นเองโดยอัตโนมัติ ถ้าข้อมูลต้นทางอย่าง MSCLKID หรือ Identifier ยังไม่ครบตั้งแต่แรก การส่งผ่าน Server ก็ยังจับคู่ไม่ได้อยู่ดี Conversions API แก้เรื่องความเสถียรของช่องทางส่งข้อมูล ไม่ใช่แก้เรื่องคุณภาพของข้อมูลต้นทาง

ตัวอย่างสมมติ เปรียบเทียบก่อนและหลังเริ่มใช้ Conversions API

สมมติธุรกิจหนึ่งยิงแอด Microsoft Ads เข้า LINE แล้วเก็บ MSCLKID ผ่าน UET Tag เพียงอย่างเดียว ในเดือนหนึ่งเกิด Lead 150 ราย ปิดออเดอร์ได้ 20 เคส แต่พอตรวจสอบใน Microsoft Advertising กลับเห็น Conversion ที่จับคู่สำเร็จเพียง 14 เคส ตัวเลขนี้เป็นตัวอย่างสมมติเพื่อประกอบกรอบวิเคราะห์เท่านั้น ไม่ใช่ค่าเฉลี่ยของธุรกิจจริง

เมื่อไล่ตรวจสาเหตุ พบว่าอีก 6 เคสที่หายไปมาจากลูกค้าที่ใช้เบราว์เซอร์ที่บล็อก Cookie หรือปิด Private Browsing ระหว่างคลิกโฆษณา ทำให้ UET Tag ไม่สามารถเก็บค่าได้ครบตั้งแต่ต้นทาง ต่อให้ทีมส่ง Offline Conversion Import ถูกต้องครบทุกขั้นตอนก็ยังจับคู่ไม่ได้ เพราะข้อมูลต้นทางหายไปตั้งแต่จุดแรก

หลังจากธุรกิจนี้เริ่มใช้ Conversions API ควบคู่กับ UET Tag เดิม จำนวน Conversion ที่จับคู่สำเร็จขยับขึ้นมาอยู่ที่ 18 จาก 20 เคส เพราะบางเคสที่เคยหายไปจากข้อจำกัดของเบราว์เซอร์ ยังมีช่องทางฝั่งเซิร์ฟเวอร์คอยยืนยันข้อมูลซ้ำอีกชั้นหนึ่ง แม้จะยังไม่ถึง 100% แต่ก็ทำให้สัญญาณที่ส่งกลับไปยัง Bidding ใกล้เคียงความจริงมากขึ้นอย่างเห็นได้ชัด

ตารางเปรียบเทียบ Client Side กับ Server Side Tracking

Conversions API เป็นชั้นเสริม ไม่ใช่จุดเริ่มต้นของการวัดผล

ก่อนจะพิจารณาลงทุนทำ Conversions API ธุรกิจควรมีรากฐานของ LINE conversion tracking ที่เสถียรอยู่แล้ว ตั้งแต่การเก็บ MSCLKID ก่อนเข้า LINE การผูก Lead กับ Order และการส่งกลับผ่าน Offline Conversion Import ให้ทำงานได้อย่างถูกต้องก่อน

เมื่อรากฐานเหล่านี้เสถียรแล้ว Conversions API จะเป็นชั้นเสริมที่ช่วยลดการสูญหายของข้อมูลจากฝั่งเบราว์เซอร์ ทำงานคล้ายกับหลักการของ Server to Server Tracking ที่ใช้กันในแพลตฟอร์มอื่น ๆ เช่นกัน แนวคิดโดยรวมคือย้ายความรับผิดชอบของการยืนยัน Conversion จากเบราว์เซอร์ที่ควบคุมไม่ได้ มาไว้ที่เซิร์ฟเวอร์ที่ธุรกิจควบคุมได้เอง

ระบบอย่าง linli ช่วยเก็บ Journey และ Identifier ตั้งแต่คลิกโฆษณาเข้า LINE จนถึง Order ให้อยู่ในที่เดียวกัน ส่วนการเชื่อมต่อแบบ Server Side ไปยังแพลตฟอร์มใดจะขึ้นกับ Integration ที่เปิดใช้งานจริง ณ ช่วงเวลานั้น ควรตรวจสอบรายละเอียดกับทีมเทคนิคก่อนวางแผนงบประมาณสำหรับการพัฒนาเพิ่มเติม

สรุป

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

ธุรกิจที่มีทีมเทคนิครองรับและใช้งบโฆษณาต่อเนื่องในระดับที่ความแม่นยำของข้อมูลส่งผลต่อการตัดสินใจจริง คือกลุ่มที่ควรพิจารณาลงทุนทำเรื่องนี้ก่อนธุรกิจขนาดเล็กที่ยังไม่มีรากฐานพร้อม

• Conversions API ส่งข้อมูล Conversion จากเซิร์ฟเวอร์ธุรกิจ ไม่พึ่ง Cookie บนเบราว์เซอร์
• ยังต้องมี MSCLKID หรือ Identifier อื่นเป็นตัวเชื่อมหลักเหมือนเดิม
• เหมาะกับธุรกิจที่มีทีมเทคนิคและปริมาณ Conversion มากพอ
• ควรทำ Offline Conversion Import ให้เสถียรก่อนค่อยขยับมาทำ Server Side
• ใช้คู่กับ UET Tag ได้ โดยอาศัยกลไก Deduplication ป้องกันการนับซ้ำ

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