Pixel กับ Conversion API ต่างกันยังไง ต้องใช้คู่กันไหม และกันนับซ้ำด้วย event_id

Pixel ส่งข้อมูลจากเบราว์เซอร์ของลูกค้า ส่วน Conversion API (CAPI) ส่งจากเซิร์ฟเวอร์ของเรา ควรใช้คู่กัน เพราะแต่ละฝั่งเก็บอีเวนต์ที่อีกฝั่งตกหล่นได้ และกันนับซ้ำได้ด้วยการส่ง event_id ค่าเดียวกันทั้งสองฝั่ง ถ้าชื่ออีเวนต์กับ event_id ตรงกันและมาถึงภายใน 48 ชั่วโมง Meta จะนับเป็นครั้งเดียว

คำถามนี้ผมได้ยินบ่อยจากเจ้าของธุรกิจที่เพิ่งติดตั้ง CAPI แล้วเห็นยอดลีดในแอดพุ่งขึ้นเท่าตัวในวันเดียว ส่วนใหญ่ไม่ได้แปลว่าแอดดีขึ้น แต่แปลว่าอีเวนต์ถูกนับซ้ำ บทความนี้อธิบายความต่างของสองเครื่องมือ วิธีที่ระบบกันนับซ้ำทำงาน และสาเหตุที่ทำให้กันไม่อยู่ โดยอิงจากตอนที่เราตั้งระบบบนเว็บ m-creation.co เอง ถ้ายังไม่รู้จัก CAPI เลย แนะนำให้อ่านคู่มือ Conversion API ฉบับเต็มก่อน

Pixel กับ Conversion API ต่างกันยังไง

พูดง่าย ๆ Pixel เหมือนกล้องวงจรปิดที่ติดไว้หน้าร้าน เห็นทุกอย่างที่ลูกค้าทำในร้าน แต่ถ้ามีคนเอาผ้ามาคลุมกล้องก็ไม่เห็นอะไรเลย ส่วน CAPI เหมือนสมุดบัญชีหลังร้าน ไม่เห็นว่าลูกค้าเดินดูอะไร แต่บิลทุกใบที่ออกไปมีบันทึกอยู่ครบ

เรื่อง	Pixel (ฝั่งเบราว์เซอร์)	Conversion API (ฝั่งเซิร์ฟเวอร์)
ทำงานที่ไหน	โค้ด JavaScript ในเบราว์เซอร์ลูกค้า	เซิร์ฟเวอร์ของเรา ส่งตรงไปหาแพลตฟอร์ม
ติดตั้ง	วางโค้ดหรือใช้ GTM ไม่กี่นาที	ใช้ตัวเชื่อมพาร์ทเนอร์ GTM server-side หรือเขียนโค้ด
โดนตัวบล็อกโฆษณา	โดน สคริปต์ไม่รันเลย	ไม่โดนโดยตรง เพราะไม่ได้ส่งจากเบราว์เซอร์
ผลจากการจำกัดคุกกี้ของ Safari	คุกกี้อาจถูกลบหลัง 7 วันที่ไม่ได้ใช้เว็บ หรืออยู่ได้ 24 ชม. ถ้าเข้ามาจากลิงก์ที่มีพารามิเตอร์ติดตาม (WebKit)	ยังต้องใช้ค่าคุกกี้จากเบราว์เซอร์ แต่ส่งอีเมลกับเบอร์โทรที่แฮชแล้วไปช่วยจับคู่ได้
เห็นพฤติกรรมในหน้าเว็บ	เห็นละเอียด เช่น ดูหน้า เลื่อน กดปุ่ม	เห็นเฉพาะที่เราเลือกส่ง
อีเวนต์นอกเว็บ (โทรปิดการขาย สถานะใน CRM)	ส่งไม่ได้	ส่งได้
ความยินยอมตาม PDPA	คุมด้วยแบนเนอร์คุกกี้	ต้องเขียนเงื่อนไขในโค้ดเอง
คนดูแล	ทีมการตลาดดูแลเองได้	ต้องมีนักพัฒนาหรือผู้ให้บริการช่วย

ต้องใช้ Pixel กับ CAPI คู่กันไหม

สำหรับอีเวนต์บนเว็บ คำตอบคือควรใช้คู่กัน Meta ออกแบบระบบให้รับอีเวนต์เดียวกันจากสองทางแล้วรวมเป็นหนึ่ง เรียกว่า redundant setup ข้อดีคือ

• ถ้า Pixel โดนบล็อก ยังมีอีเวนต์จากเซิร์ฟเวอร์
• ถ้าเซิร์ฟเวอร์มีปัญหาชั่วคราว ยังมีอีเวนต์จาก Pixel
• Pixel ส่งพฤติกรรมในหน้าเว็บที่ใช้ทำกลุ่มเป้าหมาย ส่วน CAPI ส่งข้อมูลจับคู่ที่แม่นกว่า เช่น อีเมลที่แฮชแล้ว

กรณีเดียวที่ใช้ CAPI อย่างเดียวได้เลยคืออีเวนต์ที่ไม่มีเบราว์เซอร์เกี่ยวข้อง เช่น สถานะลีดใน CRM หรือยอดขายหน้าร้าน อย่างที่เราส่งสถานะจาก CRM กลับไปที่ Meta (ผมเล่าไว้ในบทความส่งสถานะ CRM กลับไปที่ Meta) อีเวนต์พวกนี้ไม่มีคู่จาก Pixel จึงไม่ต้องกันนับซ้ำ

Deduplication ด้วย event_id ทำงานยังไง

ตามเอกสารของ Meta วิธีที่แนะนำมีเงื่อนไข 3 ข้อ

1. ชื่ออีเวนต์ตรงกัน event ใน Pixel ต้องตรงกับ event_name ใน CAPI เช่น Lead ทั้งคู่
2. รหัสอีเวนต์ตรงกัน eventID ใน Pixel ต้องตรงกับ event_id ใน CAPI
3. มาถึงภายใน 48 ชั่วโมง นับจากตอนที่ Meta ได้รับอีเวนต์แรกที่มีรหัสนั้น

ถ้าเนื้อหาของสองอีเวนต์ไม่ต่างกันมาก Meta จะเก็บตัวที่มาถึงก่อน อีกวิธีหนึ่งคือใช้ fbp หรือ external_id แทน event_id แต่ Meta ระบุว่าวิธีนี้ใช้ได้เฉพาะกรณีที่อีเวนต์จากเบราว์เซอร์มาถึงก่อนเท่านั้น ถ้าเซิร์ฟเวอร์ส่งมาก่อน อีเวนต์จะไม่ถูกรวม ผมจึงใช้ event_id เป็นหลักเสมอ

แพลตฟอร์มอื่นใช้หลักคล้ายกัน

แพลตฟอร์ม	คีย์ที่ใช้รวมอีเวนต์	กรอบเวลา
Meta	event_name + event_id	48 ชม. นับจากอีเวนต์แรก
TikTok	event + event_id (TikTok Help)	48 ชม. เก็บอีเวนต์ตัวแรกที่ได้รับ
Google Ads	Transaction ID ในคอนเวอร์ชันแอ็กชันเดียวกัน (Google Ads Help)	ไม่ได้ระบุเป็นชั่วโมงแบบ Meta
LINE Ads	Deduplication Key ใน LINE Tag (LINE for Business)	ไม่พบกรอบเวลาในหน้าประกาศ

ตัวอย่างจริง: ส่ง event_id เดียวกันจากเบราว์เซอร์และเซิร์ฟเวอร์

บนเว็บ m-creation.co เราสร้าง event_id ในเบราว์เซอร์ตอนลูกค้าส่งฟอร์ม (อีเวนต์ Lead) หรือกดปุ่ม LINE, WhatsApp, โทร (อีเวนต์ Contact) แล้วส่งรหัสเดียวกันให้ทั้ง Pixel และฟังก์ชันบนเซิร์ฟเวอร์ ฝั่ง Pixel ต้องใส่รหัสในอาร์กิวเมนต์ตัวที่ 4 ไม่ใช่ใส่ปนไปกับข้อมูลอีเวนต์

1. 1mcAttr() = สร้าง event_idสุ่มรหัสใหม่ 1 ค่า ตอนลูกค้ากดส่งฟอร์ม ใช้ crypto.randomUUID() จึงไม่ซ้ำกับครั้งอื่น
2. 2mcFire() = ยิง Pixel พร้อมรหัสส่ง Lead จากเบราว์เซอร์โดยแนบ eventID ตัวเดียวกัน
3. 3fetch() = ส่งรหัสเดิมไปเซิร์ฟเวอร์แนบ event_id ไปกับข้อมูลฟอร์ม ไม่สร้างรหัสใหม่ที่ฝั่งเซิร์ฟเวอร์
4. 4รับรหัสจากเบราว์เซอร์ใช้ค่าที่ส่งมา ถ้าไม่มี (เช่น สคริปต์ถูกบล็อก) ค่อยสร้างใหม่ ยอดยังไม่หาย แค่ไม่ได้รวมกับ Pixel
5. 5sendCapi() = ส่ง Conversion APIส่ง Lead เดียวกันจากเซิร์ฟเวอร์ ชื่อ event และ event_id ตรงกับข้อ 2 ทุกตัว

หัวใจคือสร้างรหัสครั้งเดียวในข้อ 1 แล้วส่งค่าเดิมไปทั้งสองทาง ห้ามสร้างใหม่ที่ฝั่งเซิร์ฟเวอร์ถ้ามีค่าอยู่แล้ว

// เบราว์เซอร์
const eventId = crypto.randomUUID();
fbq('track', 'Contact', {}, { eventID: eventId });

// payload ที่เซิร์ฟเวอร์ส่งไป Conversions API
{ "event_name": "Contact", "event_id": "<eventId เดิม>",
  "action_source": "website", "event_time": 1790000000,
  "user_data": { "fbp": "...", "fbc": "...",
                 "client_ip_address": "...", "client_user_agent": "..." } }

อีเวนต์ Contact ฝั่งเซิร์ฟเวอร์จะส่งเฉพาะเมื่อผู้ใช้กดยอมรับคุกกี้ในแบนเนอร์ PDPA แล้ว ส่วน Pixel ใช้คำสั่ง consent แบบ revoke/grant ตามที่ผู้ใช้เลือก พอติดตั้งเสร็จเราก็ส่งอีเวนต์ทดสอบแล้วดูในแท็บ Test Events ว่าอีเวนต์จากเซิร์ฟเวอร์เข้ามาจริง

ตรวจยังไงว่าอีเวนต์ถูกนับซ้ำ

1. เทียบกับหลังบ้าน นับลีดหรือออเดอร์ในระบบเราช่วง 7 วัน แล้วเทียบกับยอดใน Events Manager ถ้าฝั่ง Meta สูงกว่าเกือบเท่าตัว มีโอกาสสูงว่าอีเวนต์เบิ้ล
2. ดูใน Test Events ส่งฟอร์มทดสอบ 1 ครั้ง ควรเห็นอีเวนต์เดียวกันจาก Browser และ Server ที่ถูกรวมกัน (Deduplicated) ถ้าทั้งสองตัวขึ้นว่าประมวลผลแยกกัน (Processed) แปลว่ากำลังนับ 2 ครั้ง
3. ดู Deduplication key feedback ในข้อมูลคุณภาพชุดข้อมูลของ Meta บอกว่าอีเวนต์กี่เปอร์เซ็นต์ที่มี event_id ติดมา ถ้าฝั่งใดฝั่งหนึ่งต่ำ ต้องหาว่าอีเวนต์ไหนไม่ได้ใส่รหัส
4. ดู Event coverage สัดส่วนอีเวนต์จาก Pixel ที่มีอีเวนต์จาก CAPI คู่กันและใช้คีย์เดียวกัน Meta ตั้งเป้าไว้ที่ 75%
5. เปิด Meta Pixel Helper ส่วนขยายของ Chrome ใช้ดูว่า Pixel ยิงอีเวนต์เดียวกันซ้ำ 2 ครั้งในหน้าเดียวหรือเปล่า ซึ่งเป็นปัญหาฝั่งเบราว์เซอร์ล้วน ๆ ไม่เกี่ยวกับ CAPI

7 สาเหตุที่ทำให้ deduplication ไม่ทำงาน

1. สร้าง event_id คนละตัว Pixel สุ่มรหัสหนึ่ง เซิร์ฟเวอร์สุ่มอีกรหัส เป็นสาเหตุที่เจอบ่อยที่สุด ต้องสร้างครั้งเดียวแล้วส่งต่อ
2. ใส่ eventID ผิดที่ ใส่ไว้ในอาร์กิวเมนต์ตัวที่ 3 (ข้อมูลอีเวนต์) แทนตัวที่ 4 Pixel จะส่งไปเป็นพารามิเตอร์ธรรมดา ไม่ได้ใช้เป็นคีย์กันนับซ้ำ
3. ชื่ออีเวนต์ไม่ตรงกัน ตัวพิมพ์ใหญ่เล็กต่างกัน หรือฝั่งหนึ่งใช้อีเวนต์มาตรฐาน อีกฝั่งใช้ชื่อที่ตั้งเอง
4. ส่งเข้าคนละ Pixel/Dataset เว็บมีหลาย Pixel แล้ว CAPI ส่งเข้า ID ที่ไม่ตรงกับ Pixel ที่ยิงอีเวนต์นั้น
5. มีตัวส่งซ้อนกัน ปลั๊กอินของแพลตฟอร์มร้านค้าส่ง CAPI อยู่แล้ว แล้วยังมี GTM server-side หรือโค้ดที่เขียนเองส่งอีกชุด โดยใช้รหัสคนละแบบ
6. ส่งจากเซิร์ฟเวอร์ช้าเกินไป ถ้ารวบส่งทีหลังเกิน 48 ชั่วโมงนับจากอีเวนต์แรก จะไม่ถูกรวม หรือถ้าพึ่งการรวมด้วย fbp แต่เซิร์ฟเวอร์ส่งถึงก่อนเบราว์เซอร์ ก็จะไม่ถูกรวมเช่นกัน
7. รีเฟรชหน้าขอบคุณแล้วได้รหัสใหม่ ถ้ายิงอีเวนต์ตอนโหลดหน้าขอบคุณ ทุกครั้งที่รีเฟรชจะได้ event_id ใหม่ Meta จึงนับเป็นอีเวนต์ใหม่ วิธีแก้คือใช้เลขออเดอร์หรือเลขลีดเป็นส่วนหนึ่งของ event_id ให้ค่าคงที่ต่อหนึ่งรายการ

สรุปและขั้นต่อไป

Pixel กับ Conversion API ไม่ได้แข่งกัน ใช้คู่กันแล้วได้ข้อมูลครบกว่าใช้ตัวใดตัวหนึ่ง เงื่อนไขมีข้อเดียวคือต้องกันนับซ้ำให้ได้ ส่ง event_id ตัวเดียวกัน ชื่ออีเวนต์ตรงกัน และส่งจากเซิร์ฟเวอร์ให้เร็ว หลังติดตั้งแล้วให้เปิด Test Events ยืนยันทุกครั้ง อย่าดูแค่ว่าอีเวนต์ขึ้น

1. 1Test events = หน้าทดสอบเปิดใน Events Manager เลือกชุดข้อมูลของเว็บ แล้วเข้าแท็บนี้ ใส่ test_event_code ตอนส่งจากเซิร์ฟเวอร์
2. 2ชื่อ event = สิ่งที่เกิดขึ้นกดส่งฟอร์มบนเว็บ 1 ครั้ง ควรเห็น Lead แค่ 1 แถว ถ้าเห็น 2 แถวแยกกันแปลว่ายังนับซ้ำ
3. 3Received from = มาจากทางไหนขึ้นทั้ง Browser และ Server ในแถวเดียว = ได้รับทั้งสองทางและรวมกันแล้ว
4. 4event_id = รหัสที่ใช้รวมเทียบกับค่าที่ส่งจากโค้ด ต้องเป็นค่าเดียวกันทั้งสองทาง

ผ่านเมื่อ: ส่งฟอร์ม 1 ครั้ง เห็น Lead 1 แถว มาจากทั้ง Browser และ Server · ถ้าเห็น 2 แถวให้เช็ค event_id ตามภาพโค้ดด้านบน

ถ้าอยากเห็นภาพรวมทั้งระบบ ตั้งแต่ข้อมูลที่ต้องส่ง วิธีติดตั้ง ไปจนถึง PDPA อ่านต่อได้ที่Conversion API (CAPI) คืออะไร คู่มือ Server-side Tracking ถ้าเช็กแล้วยอดยังเบิ้ลหรือไม่อยากไล่เอง ทีมเรารับตรวจและติดตั้ง Conversion API ให้ทั้ง Meta, TikTok, Google และ LINE เริ่มจากตรวจบัญชีก่อนแล้วค่อยเสนอราคา