สรุปสั้น ๆ (TL;DR)
- Meta ตัดเหตุการณ์ซ้ำระหว่าง pixel กับเซิร์ฟเวอร์ก็ต่อเมื่อ eventID ตรงกับ event_id และชื่อเหตุการณ์ตรงกัน ภายใน 48 ชั่วโมงนับจากเหตุการณ์แรกที่ได้รับ
- event_time ของ Conversions API ย้อนหลังได้ไม่เกินเจ็ดวัน ถ้ามีเหตุการณ์เก่ากว่านั้นแม้หนึ่งรายการ คำขอทั้งชุดจะล้มเหลว และเหตุการณ์บนเว็บต้องมี event_source_url
- อีเมล เบอร์โทร และชื่อ ต้องจัดรูปแบบมาตรฐานและแฮชด้วย SHA-256 ส่วน IP, user agent, fbc และ fbp ต้องส่งแบบไม่แฮช เบอร์โทรต้องมีรหัสประเทศ เช่น 66 สำหรับไทย
- Event Match Quality ให้คะแนนเหตุการณ์ฝั่งเซิร์ฟเวอร์เต็ม 10 และปัจจุบันมีเฉพาะเหตุการณ์บนเว็บ
- ค่า action_source เช่น chat, phone_call และ business_messaging ช่วยให้รายงาน Conversion ที่ยืนยันใน LINE, Messenger หรือทางโทรศัพท์กลับไปยัง Meta ได้
Meta pixel และ Conversions API คือสองช่องทางในการส่งเหตุการณ์ Conversion ชุดเดียวกันไปยัง Meta โดย pixel ส่งจากเบราว์เซอร์ของผู้เข้าชม ส่วน Conversions API ส่งจากเซิร์ฟเวอร์ของคุณ Meta แนะนำให้ใช้ทั้งสองอย่างคู่กัน และใส่ Event ID เดียวกันในแต่ละเหตุการณ์เพื่อให้ Meta นับเพียงครั้งเดียว เพราะการติดตามจากเบราว์เซอร์อย่างเดียวพลาดเหตุการณ์ที่เซิร์ฟเวอร์ยังรายงานได้
บทความนี้อธิบายว่าแต่ละส่วนทำอะไร ทำไมการติดตามจากเบราว์เซอร์อย่างเดียวจึงทำให้เหตุการณ์หาย Conversions API ให้อะไรเพิ่มนอกจากการอุดช่องว่างนั้น การตัดข้อมูลซ้ำ (deduplication) ทำงานอย่างไรในรายละเอียด และวิธีตรวจการตั้งค่าทั้งหมดใน Events Manager เหมาะสำหรับผู้ลงโฆษณาและนักพัฒนาที่ใช้โฆษณา Meta อยู่แล้ว และต้องการให้ระบบวัดผลเบื้องหลังเชื่อถือได้
Meta pixel ทำอะไร
Meta pixel คือโค้ด JavaScript ที่ติดไว้ทุกหน้าของเว็บไซต์ เมื่อหน้าเว็บโหลด โค้ดฐานจะยิงเหตุการณ์ PageView และโค้ดเพิ่มเติมจะยิงเหตุการณ์มาตรฐานเมื่อผู้เข้าชมทำสิ่งที่มีความหมาย เช่น ViewContent บนหน้าสินค้า AddToCart, InitiateCheckout, Purchase, Lead หรือ CompleteRegistration เป็นต้น แต่ละเหตุการณ์ส่งพารามิเตอร์ได้ เช่น มูลค่า สกุลเงิน และรหัสสินค้า
pixel ยังตั้งคุกกี้ของบุคคลที่หนึ่งด้วย คุกกี้ _fbp เก็บรหัสเบราว์เซอร์ และเมื่อมีคนคลิกโฆษณา Meta เข้ามาพร้อมพารามิเตอร์ fbclid ใน URL คุกกี้ _fbc จะเก็บรหัสการคลิก ตัวระบุเหล่านี้ รวมกับที่อยู่ IP และ user agent ที่เบราว์เซอร์ส่งไป ช่วยให้ Meta จับคู่เหตุการณ์กับบุคคลที่เห็นหรือคลิกโฆษณา
Meta ใช้เหตุการณ์เหล่านี้ในสามงาน คือรายงาน Conversion ใน Ads Manager ปรับการส่งโฆษณาไปหาคนที่มีแนวโน้มทำเหตุการณ์ที่เลือก และสร้าง Custom audience เช่น ผู้เข้าชมล่าสุดหรือคนที่ทิ้งตะกร้า ใน Events Manager ปัจจุบัน pixel อยู่ภายใน dataset ซึ่งเป็นที่รวมที่รับเหตุการณ์ได้จากเบราว์เซอร์ เซิร์ฟเวอร์ และแหล่งอื่นพร้อมกัน
ทำไมการติดตามจากเบราว์เซอร์อย่างเดียวทำให้เหตุการณ์หาย
pixel รายงานได้เฉพาะสิ่งที่เกิดในเบราว์เซอร์ที่โหลดและรันสคริปต์ของมันได้ สถานการณ์ทั่วไปหลายแบบทำให้สิ่งนั้นไม่เกิดขึ้น
- ตัวบล็อกโฆษณาและส่วนขยายด้านความเป็นส่วนตัว บล็อกคำขอไปยังโดเมนของ Meta ทำให้เหตุการณ์ไม่เคยออกจากเบราว์เซอร์
- ระบบป้องกันการติดตามของเบราว์เซอร์ จำกัดอายุคุกกี้ที่ตั้งโดยสคริปต์และตัดตัวระบุการคลิกบางส่วน การซื้อที่เกิดหลายวันหลังคลิกจึงอาจเชื่อมกลับไปหาคลิกนั้นไม่ได้
- การเลือกให้ความยินยอม ทำให้ pixel ไม่ยิงเลยสำหรับผู้เข้าชมที่ปฏิเสธการติดตาม ในกรณีที่แบนเนอร์ความยินยอมควบคุม pixel อยู่
- ปัญหาหน้าเว็บและเครือข่าย เช่น ผู้เข้าชมปิดแท็บก่อนหน้าขอบคุณโหลดเสร็จ อินเทอร์เน็ตมือถือช้า หรือช่องทางชำระเงินที่ไม่ส่งผู้ซื้อกลับมาที่เว็บไซต์
- Conversion ที่เกิดนอกเว็บไซต์ทั้งหมด เช่น คำสั่งซื้อที่ยืนยันทางโทรศัพท์ ในแชต หรือที่หน้าร้าน ซึ่ง pixel มองไม่เห็นอยู่แล้วโดยธรรมชาติ
ทุกเหตุการณ์ที่หายทำให้เสียสองต่อ รายงานนับผลได้น้อยกว่าจริง และระบบส่งโฆษณามีสัญญาณให้เรียนรู้น้อยลง จึงปรับตามกลุ่มตัวอย่างลูกค้าที่เล็กกว่าและเอนเอียงกว่า
Conversions API เพิ่มอะไรให้
Conversions API (มักย่อว่า CAPI) คือการเชื่อมต่อแบบเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ เซิร์ฟเวอร์ แพลตฟอร์มอีคอมเมิร์ซ หรือ CRM ของคุณส่งเหตุการณ์ตรงไปยัง Meta ตัวบล็อกโฆษณาและข้อจำกัดคุกกี้ของเบราว์เซอร์จึงไม่กระทบการส่งเหตุการณ์ นอกจากการกู้เหตุการณ์บนเว็บที่หายไป ยังเพิ่มความสามารถสามอย่างที่ pixel ทำไม่ได้
เหตุการณ์จากนอกเว็บไซต์
ทุกเหตุการณ์ฝั่งเซิร์ฟเวอร์ต้องระบุ action_source ค่าที่รับได้มี website, app, phone_call, chat, physical_store, email, system_generated, business_messaging และ other ธุรกิจจึงรายงานยอดขายที่ยืนยันในแชต หรือลีดที่ทีมขายระบุภายหลังว่ามีคุณภาพ กลับไปยังแคมเปญที่สร้างมันได้
จับคู่ได้ดีขึ้นด้วยข้อมูลลูกค้า
เหตุการณ์ฝั่งเซิร์ฟเวอร์ใส่พารามิเตอร์ข้อมูลลูกค้าได้ อีเมล เบอร์โทร ชื่อ นามสกุล วันเกิด เพศ เมือง รัฐ รหัสไปรษณีย์ และประเทศ ต้องจัดรูปแบบให้เป็นมาตรฐานและแฮชด้วย SHA-256 ก่อนส่ง อีเมลต้องตัดช่องว่างหัวท้ายและเป็นตัวพิมพ์เล็ก เบอร์โทรต้องตัดสัญลักษณ์และเลขศูนย์นำหน้า และใส่รหัสประเทศเสมอ พารามิเตอร์บางตัวห้ามแฮช ได้แก่ ที่อยู่ IP ของไคลเอนต์ user agent รหัสการคลิก (fbc) และรหัสเบราว์เซอร์ (fbp) ส่วน External ID ส่งได้เช่นกันและแนะนำให้แฮช
ควบคุมได้ว่าจะส่งอะไร
เพราะเหตุการณ์ถูกสร้างบนเซิร์ฟเวอร์ของคุณ คุณจึงกำหนดได้ว่าฟิลด์ใดออกจากระบบบ้าง สามารถส่งการซื้อหลังยืนยันการชำระเงินแล้วเท่านั้น แทนที่จะส่งตอนหน้าขอบคุณโหลด และแนบมูลค่าที่หักต้นทุนแล้ว หรือสถานะลีดที่เบราว์เซอร์ไม่เคยรู้ได้
มีกฎเรื่องเวลาด้วย event_time ต้องเป็น Unix timestamp ของเวลาที่เหตุการณ์เกิดจริง และย้อนหลังได้ไม่เกินเจ็ดวันจากเวลาที่ส่ง ถ้ามีเหตุการณ์ใดในคำขอเก่ากว่านั้น คำขอทั้งชุดจะล้มเหลว สำหรับเหตุการณ์บนเว็บไซต์ ต้องมีฟิลด์ event_source_url และ Meta แนะนำให้ส่งเหตุการณ์ทันทีที่เกิดขึ้น โดยควรอยู่ภายในหนึ่งชั่วโมง แทนการส่งรวดเดียววันละครั้ง
เปรียบเทียบ Meta pixel กับ Conversions API
| คำถาม | Meta pixel (เบราว์เซอร์) | Conversions API (เซิร์ฟเวอร์) |
|---|---|---|
| ส่งเหตุการณ์จากที่ไหน | เบราว์เซอร์ของผู้เข้าชม | เซิร์ฟเวอร์ แพลตฟอร์ม หรือ CRM ของคุณ |
| ได้รับผลจากตัวบล็อกโฆษณาและข้อจำกัดคุกกี้หรือไม่ | ได้รับผล | ตัวเหตุการณ์ไม่ได้รับผล แต่คุณภาพการจับคู่ยังขึ้นกับตัวระบุที่มี |
| รายงาน Conversion ออฟไลน์ แชต หรือโทรศัพท์ได้หรือไม่ | ไม่ได้ | ได้ ผ่าน action_source |
| ต้องให้นักพัฒนาหรือแพลตฟอร์มตั้งค่าหรือไม่ | วางโค้ดหรือใช้ Tag Manager | ผ่าน Partner integration, ตัวเลือก Gateway ของ Meta หรือเขียนโค้ดเอง |
การตัดข้อมูลซ้ำ (deduplication) ทำงานอย่างไร
Meta แนะนำการตั้งค่าแบบซ้ำซ้อน คือการซื้อครั้งเดียวกันถูกส่งทั้งจาก pixel และเซิร์ฟเวอร์ ถ้าไม่มีการตัดข้อมูลซ้ำ การซื้อนั้นจะถูกนับสองครั้ง Meta จึงต้องมีวิธีจับคู่ทั้งสองเหตุการณ์
วิธีที่แนะนำใช้สองฟิลด์ที่ต้องตรงกัน eventID ของ pixel ต้องเท่ากับ event_id ของเหตุการณ์ฝั่งเซิร์ฟเวอร์ และชื่อเหตุการณ์ของ pixel ต้องเท่ากับ event_name ของเซิร์ฟเวอร์ เมื่อตรงกันทั้งคู่ Meta จะเก็บไว้หนึ่งและทิ้งอีกหนึ่ง กรอบเวลาสำคัญ เหตุการณ์จะถูกตัดซ้ำก็ต่อเมื่อมาถึงภายใน 48 ชั่วโมงนับจากเหตุการณ์แรกที่ Meta ได้รับด้วย event_id นั้น
ในทางปฏิบัติหมายถึงการสร้าง ID หนึ่งตัวต่อหนึ่งเหตุการณ์ ปกติใช้เลขที่คำสั่งซื้อสำหรับการซื้อ หรือสตริงสุ่มที่ไม่ซ้ำสำหรับลีด แล้วส่งค่าเดียวกันนี้ทั้งในการเรียก pixel และในคำขอฝั่งเซิร์ฟเวอร์ ข้อผิดพลาดที่พบบ่อยคือการสุ่ม ID ใหม่แยกกันทั้งในเบราว์เซอร์และบนเซิร์ฟเวอร์ ซึ่งรับประกันได้เลยว่าทั้งสองจะไม่มีวันตรงกัน
มีวิธีทางเลือกที่จับคู่ด้วย event_name ร่วมกับ fbp หรือ external_id แต่อ่อนกว่า วิธีนี้ใช้ได้เฉพาะเมื่อเหตุการณ์จากเบราว์เซอร์มาถึงก่อนและเหตุการณ์จากเซิร์ฟเวอร์มาทีหลัง เหตุการณ์ฝั่งเซิร์ฟเวอร์จะไม่ถูกทิ้งถ้าไม่มีเหตุการณ์จากเบราว์เซอร์ที่ตรงกันในช่วง 48 ชั่วโมงก่อนหน้า แม้จะมีมาถึงภายหลังก็ตาม และไม่ทำงานเลยถ้าใช้แหล่งเดียว ควรมองเป็นทางสำรอง ไม่ใช่แผนหลัก
ตัวอย่างสมมติ
สมมติร้านค้าแห่งหนึ่งได้รับชำระเงินคำสั่งซื้อเลขที่ 10452 หน้าขอบคุณยิง pixel ด้วยเหตุการณ์ Purchase และ eventID 10452 อีกไม่กี่วินาทีต่อมา ระบบชำระเงินส่งเหตุการณ์ฝั่งเซิร์ฟเวอร์ด้วย event_name Purchase และ event_id 10452 Meta ได้รับทั้งสอง เห็นคู่ที่ตรงกันภายใน 48 ชั่วโมง และนับเป็นการซื้อหนึ่งครั้ง ถ้าเบราว์เซอร์ของผู้ซื้อมีตัวบล็อกโฆษณา จะมีเพียงเหตุการณ์ฝั่งเซิร์ฟเวอร์ที่มาถึง และการซื้อก็ยังถูกนับหนึ่งครั้ง เลขคำสั่งซื้อในตัวอย่างนี้สมมติขึ้นเพื่ออธิบายหลักการ
วิธีตรวจการตั้งค่าใน Events Manager
- เปิด dataset ใน Events Manager แล้วดูภาพรวม แต่ละเหตุการณ์แสดงว่ารับผ่านช่องทางการเชื่อมต่อใดบ้าง สำหรับการตั้งค่าแบบซ้ำซ้อน เหตุการณ์หลักอย่าง Purchase และ Lead ควรแสดงทั้งเบราว์เซอร์และเซิร์ฟเวอร์
- ใช้เครื่องมือ Test Events Meta ระบุว่าเป็นที่สำหรับยืนยันว่าเหตุการณ์ฝั่งเซิร์ฟเวอร์ตั้งค่าถูกต้องและถูกรับแล้ว และการตัดข้อมูลซ้ำทำงานได้ ลองสร้าง Conversion ทดสอบบนเว็บไซต์ แล้วดูว่าเหตุการณ์จากเบราว์เซอร์และเซิร์ฟเวอร์มาถึงและถูกจับคู่กัน
- ตรวจ Event Match Quality เหตุการณ์ฝั่งเซิร์ฟเวอร์แต่ละรายการได้คะแนนเต็ม 10 ที่บอกว่าข้อมูลลูกค้าน่าจะจับคู่กับบัญชี Meta ได้ดีแค่ไหน ปัจจุบันมีเฉพาะเหตุการณ์บนเว็บ คะแนนต่ำมักหมายถึงส่งตัวระบุน้อย เช่น ไม่มีอีเมลหรือเบอร์โทรที่แฮชแล้ว และไม่มี fbc หรือ fbp
- อ่านแท็บ Diagnostics เพื่อดูคำเตือนเรื่องพารามิเตอร์ที่ขาด เหตุการณ์ซ้ำที่ไม่ถูกตัด หรือค่าที่ส่งผิดรูปแบบ
- เทียบกับบันทึกของคุณเอง ยอดซื้อที่ Events Manager รายงานในหนึ่งสัปดาห์ควรใกล้เคียงกับคำสั่งซื้อในแพลตฟอร์มของคุณในสัปดาห์เดียวกัน ส่วนต่างที่มากไม่ว่าทางไหน ชี้ว่ามีเหตุการณ์หายหรือการตัดซ้ำล้มเหลว
วิธีติดตั้ง Conversions API
มีสี่เส้นทางที่ใช้กันทั่วไป แพลตฟอร์มอีคอมเมิร์ซอย่าง Shopify และ WooCommerce มี Partner integration ที่ส่งเหตุการณ์ฝั่งเซิร์ฟเวอร์ได้โดยแทบไม่ต้องเขียนโค้ด Conversions API Gateway ของ Meta รันฝั่งเซิร์ฟเวอร์บนคลาวด์ที่คุณควบคุมเอง เหมาะกับทีมที่ไม่มีนักพัฒนา Server-side Google Tag Manager ส่งต่อเหตุการณ์ไปยัง Meta ผ่าน Tag template เหมาะกับเว็บที่ใช้ GTM อยู่แล้ว และการเขียนโค้ดเรียก API โดยตรงให้การควบคุมมากที่สุด เหมาะกับเหตุการณ์จาก CRM และออฟไลน์ ไม่ว่าเลือกทางไหน ให้ตรวจว่าส่ง Event ID ร่วมกับ pixel จริง เพราะการตั้งค่าแบบรวดเร็วบางแบบไม่ได้ทำ
ความหมายสำหรับผู้ลงโฆษณาในประเทศไทย
การค้าในไทยพึ่งพาแชตอย่างมาก คำสั่งซื้อจำนวนมากถูกยืนยันใน LINE, Messenger หรือทางโทรศัพท์หลังจากมีคนคลิกโฆษณา Meta และไม่มีการยืนยันใดเลยที่ไปถึง pixel ค่า action_source สำหรับแชต การส่งข้อความทางธุรกิจ และการโทร ใน Conversions API ช่วยให้ธุรกิจส่งยอดขายเหล่านั้นกลับไปยัง Meta เพื่อให้แคมเปญปรับตามคำสั่งซื้อจริง ไม่ใช่แค่การกรอกฟอร์มบนเว็บ
เบอร์โทรต้องระวังเป็นพิเศษ เบอร์มือถือไทยมักเขียนขึ้นต้นด้วยศูนย์ แต่กฎของ Meta กำหนดให้ตัดเลขศูนย์นำหน้าและใส่รหัสประเทศก่อนแฮช เบอร์ที่เขียนว่า 081 234 5678 จะกลายเป็น 66812345678 แล้วจึงนำไปแฮช การแฮชรูปแบบเบอร์ในประเทศจะได้ค่าที่จับคู่ไม่ได้
พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) ของไทยใช้กับข้อมูลลูกค้าที่ส่งไปยังแพลตฟอร์มโฆษณาด้วย ควรยืนยันฐานทางกฎหมายและข้อความขอความยินยอมกับที่ปรึกษากฎหมายก่อนส่งข้อมูลส่วนบุคคลที่แฮชแล้ว และตรวจให้แน่ใจว่าแบนเนอร์ความยินยอมและการตั้งค่าฝั่งเซิร์ฟเวอร์เคารพตัวเลือกเดียวกัน
การวัดผลของ Meta แทบไม่เคยอยู่โดดเดี่ยว กฎความยินยอมและการตั้งชื่อเหตุการณ์ควรสอดคล้องกับระบบ Analytics ด้วย จึงมักทำการตรวจระบบติดตาม GA4 ไปพร้อมกับโปรเจกต์ Conversions API
คำถามที่พบบ่อย
ถ้าใช้ Conversions API แล้วยังต้องมี Meta pixel อยู่ไหม?
ยังต้องมี Meta แนะนำให้ใช้ pixel และ Conversions API คู่กันแบบซ้ำซ้อน pixel เก็บสัญญาณจากเบราว์เซอร์อย่าง fbp และ fbc ที่ช่วยให้จับคู่ได้ดีขึ้น ส่วนเซิร์ฟเวอร์อุดช่องว่างที่เบราว์เซอร์พลาด
การตัดข้อมูลซ้ำใน Meta pixel และ Conversions API คืออะไร?
การตัดข้อมูลซ้ำคือวิธีที่ Meta นับเหตุการณ์เพียงครั้งเดียวเมื่อมาถึงทั้งจาก pixel และเซิร์ฟเวอร์ โดยจับคู่ eventID และชื่อเหตุการณ์ของ pixel กับ event_id และ event_name ของเซิร์ฟเวอร์ ภายใน 48 ชั่วโมงนับจากเหตุการณ์แรกที่ได้รับ
เหตุการณ์ใน Conversions API ย้อนหลังได้นานแค่ไหน?
event_time ของเหตุการณ์ฝั่งเซิร์ฟเวอร์ย้อนหลังได้ไม่เกินเจ็ดวันก่อนเวลาที่ส่ง ถ้ามีเหตุการณ์ใดในคำขอเก่ากว่านั้น คำขอทั้งชุดจะล้มเหลว
ต้องแฮชข้อมูลลูกค้าก่อนส่งเข้า Conversions API หรือไม่?
ต้องแฮชสำหรับฟิลด์อย่างอีเมล เบอร์โทร ชื่อ เมือง และรหัสไปรษณีย์ ซึ่งต้องจัดรูปแบบมาตรฐานและแฮชด้วย SHA-256 ส่วนที่อยู่ IP ของไคลเอนต์ user agent, fbc และ fbp ต้องส่งแบบไม่แฮช
คะแนน Event Match Quality เท่าไรจึงถือว่าดี?
Event Match Quality ให้คะแนนเต็ม 10 สำหรับเหตุการณ์ฝั่งเซิร์ฟเวอร์บนเว็บ คะแนนสูงหมายถึงข้อมูลลูกค้ามีโอกาสจับคู่กับบัญชี Meta ได้มากขึ้น Meta ไม่ได้ประกาศเกณฑ์ผ่านตัวเดียว เป้าหมายในทางปฏิบัติจึงเป็นการส่งตัวระบุทุกตัวที่คุณถือไว้อย่างถูกกฎหมายในแต่ละเหตุการณ์
ทำระบบวัดผลให้ถูกก่อนเพิ่มงบ
แคมเปญปรับตัวได้จากเหตุการณ์ที่ได้รับเท่านั้น การแก้การตั้งค่า Meta pixel และ Conversions API จึงมักคุ้มกว่าการทดสอบครีเอทีฟอีกรอบ ถ้าต้องการให้ช่วยตรวจ dataset การตัดข้อมูลซ้ำ และคุณภาพการจับคู่ ทีมบริการโฆษณา Facebook ของ Relevant Audience พร้อมตรวจร่วมกับคุณ ระบบวัดผลชุดเดียวกันนี้ยังส่งข้อมูลให้แคมเปญโฆษณา Instagram และงานข้ามช่องทางในRelevant Social Ads ด้วย
![[How to] สอนสร้างแดชบอร์ด Facebook Ads บน Google Data Studio](/_next/image/?url=%2F_next%2Fstatic%2Fmedia%2FCustomer%20Service%20Process%20Automation.2gl0u7hkkquuc.webp&w=3840&q=75)
