Facebook Conversion API (CAPI) คืออะไร? วิธีติดตั้งและเพิ่มประสิทธิภาพโฆษณา

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

ชื่ออย่างเป็นทางการที่ Meta ใช้ในปัจจุบันคือ Meta Conversions API แต่ผู้ลงโฆษณาจำนวนมากยังเรียกว่า Facebook Conversion API หรือ Facebook CAPI

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

Conversion API คืออะไร? ทำไมต้องใช้ในยุค Cookieless

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

ตัวอย่าง Event หรือเหตุการณ์ที่สามารถส่งผ่าน CAPI ได้แก่

• การเปิดดูสินค้า
• การเพิ่มสินค้าลงตะกร้า
• การเริ่มชำระเงิน
• การสั่งซื้อสำเร็จ
• การกรอกแบบฟอร์ม
• การสมัครสมาชิก
• การยืนยันว่า Lead มีคุณภาพ
• การปิดการขายผ่านระบบ CRM

คำว่า Cookieless หมายถึงสภาพแวดล้อมที่การติดตามผู้ใช้งานด้วย Cookie และตัวระบุจากบุคคลที่สามทำได้จำกัดมากขึ้น ไม่ได้หมายความว่า Cookie ทุกประเภทหายไปทั้งหมด ปัจจุบัน Chrome ยังคงเปิดทางให้ผู้ใช้จัดการ Third Party Cookie ตามการตั้งค่าของตน ขณะที่หลายเบราว์เซอร์และอุปกรณ์มีมาตรการจำกัดการติดตามอยู่แล้ว

ดังนั้น ธุรกิจจึงควรพัฒนาระบบข้อมูลที่ใช้ First Party Data หรือข้อมูลที่ได้รับจากลูกค้าโดยตรง ภายใต้การแจ้งวัตถุประสงค์และการขอความยินยอมที่เหมาะสม

ปัญหาของ Facebook Pixel ในยุค iOS 14.5+ และ Cookie deprecation

Facebook Pixel ซึ่งปัจจุบันเรียกว่า Meta Pixel เป็นโค้ดที่ทำงานผ่านเบราว์เซอร์ เมื่อผู้ใช้เปิดหน้าเว็บไซต์หรือทำกิจกรรมที่กำหนด Pixel จะส่ง Event ไปยัง Meta

ข้อจำกัดคือ Pixel ต้องพึ่งพาสภาพแวดล้อมบนอุปกรณ์ของผู้ใช้ ข้อมูลจึงอาจไม่ถูกส่งในกรณีต่อไปนี้

• ผู้ใช้ปฏิเสธ Cookie สำหรับการโฆษณา
• เบราว์เซอร์จำกัดการติดตามข้ามเว็บไซต์
• ผู้ใช้ติดตั้งระบบปิดกั้นโฆษณาหรือสคริปต์
• หน้าเว็บไซต์ปิดก่อนสคริปต์ทำงานเสร็จ
• การเชื่อมต่ออินเทอร์เน็ตไม่เสถียร
• ระบบจัดการ Consent สั่งไม่ให้ Pixel ทำงาน
• การตั้งค่า Pixel หรือ Tag บนเว็บไซต์ผิดพลาด

ตั้งแต่ iOS 14.5 แอปต้องขออนุญาตผ่าน App Tracking Transparency ก่อนติดตามผู้ใช้ข้ามแอปหรือเข้าถึงตัวระบุโฆษณาของอุปกรณ์ หากไม่ได้รับอนุญาต ระบบจะไม่สามารถเข้าถึงตัวระบุดังกล่าวได้ตามปกติ

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

Conversion API แก้ปัญหานี้อย่างไรด้วย Server Side Tracking

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

ตัวอย่างเช่น เมื่อลูกค้าชำระเงินสำเร็จ ระบบร้านค้าสามารถสร้าง Purchase Event จากคำสั่งซื้อจริง แล้วส่งข้อมูลดังกล่าวไปยัง Meta ผ่าน CAPI การส่งข้อมูลจึงไม่ต้องพึ่งการโหลดหน้าขอบคุณหลังชำระเงินเพียงอย่างเดียว

ประโยชน์ที่สำคัญประกอบด้วย

• ลดการสูญหายของ Event จากข้อจำกัดในเบราว์เซอร์
• ส่งข้อมูลจากระบบหลังบ้านหรือ CRM ได้
• ควบคุมข้อมูลที่จะส่งออกจากระบบได้ละเอียดขึ้น
• เพิ่มข้อมูลสำหรับจับคู่ Event กับบัญชี Meta
• ช่วยให้การวัดผลและการ Attribution มีความครบถ้วนขึ้น
• ส่ง Event ที่สะท้อนผลลัพธ์ทางธุรกิจจริง เช่น Qualified Lead หรือ Closed Sale

ในมุมของการทำ AI Marketing คุณภาพข้อมูลมีผลโดยตรงต่อระบบเรียนรู้ของโฆษณา หาก Meta ได้รับเพียงข้อมูลการกรอกแบบฟอร์ม แต่ไม่ได้รับข้อมูลว่า Lead ใดมีคุณภาพ ระบบอาจเรียนรู้จากจำนวน Lead มากกว่าคุณค่าทางธุรกิจ CAPI จึงมีประโยชน์มากเมื่อเชื่อมต่อข้อมูลจากขั้นตอนปลายทางกลับเข้าสู่ระบบโฆษณา

Conversion API vs. Facebook Pixel ต่างกันอย่างไร

Pixel และ CAPI มีหน้าที่เก็บและส่ง Event เหมือนกันบางส่วน แต่ใช้แหล่งข้อมูลและวิธีการส่งที่แตกต่างกัน

ตารางเปรียบเทียบ Browser Side vs. Server Side

ทำไมต้องใช้ทั้งคู่ด้วย Redundant Tracking

Redundant Tracking คือการส่ง Event เดียวกันผ่านมากกว่าหนึ่งช่องทาง เพื่อให้ยังมีข้อมูลสำรองเมื่อช่องทางหนึ่งทำงานไม่สมบูรณ์ ในกรณีนี้คือการใช้ Meta Pixel และ CAPI ร่วมกัน

Pixel เหมาะกับการจับพฤติกรรมบนหน้าเว็บแบบทันที เช่น PageView, ViewContent และ AddToCart ส่วน CAPI เหมาะกับข้อมูลจากเซิร์ฟเวอร์ เช่น Purchase ที่ยืนยันแล้ว การชำระเงินสำเร็จ หรือสถานะ Lead จาก CRM

การใช้ทั้งสองระบบร่วมกันมีข้อดีดังนี้

• เพิ่มความครอบคลุมของ Event
• รักษาข้อมูลจาก Pixel ที่มีรายละเอียดเกี่ยวกับเบราว์เซอร์
• เพิ่มข้อมูลจากระบบหลังบ้านที่ Pixel เข้าถึงไม่ได้
• มีช่องทางสำรองเมื่อ Pixel ถูกปิดกั้น
• ช่วยให้ Meta ได้รับสัญญาณสำหรับวัดผลและปรับโฆษณามากขึ้น

Meta แนะนำให้ดูแลสัดส่วน Event Coverage ของ CAPI เทียบกับ Pixel พร้อมตั้งค่า Deduplication ให้ถูกต้อง โดยแนวทางของ Meta ระบุเป้าหมาย Event Coverage ที่ประมาณ 75 เปอร์เซ็นต์ขึ้นไปสำหรับ Event ที่ส่งร่วมกัน แนวทางการปรับปรุง CAPI จาก Meta

วิธีติดตั้ง Conversion API แบบ Step by Step

ก่อนเลือกวิธีติดตั้ง ควรจัดทำ Measurement Plan หรือแผนการวัดผลก่อน โดยกำหนดว่าแต่ละ Event เกิดขึ้นเมื่อใด ใช้ข้อมูลจากระบบใด และ Event ใดคือผลลัพธ์หลักของธุรกิจ

Event พื้นฐานสำหรับเว็บไซต์ E Commerce มักประกอบด้วย ViewContent, AddToCart, InitiateCheckout และ Purchase ส่วนธุรกิจบริการอาจใช้ ViewContent, Contact, Lead, QualifiedLead และ ConvertedLead

วิธีที่ 1 ผ่าน Partner Integration สำหรับ Shopify, WooCommerce และ WordPress

Partner Integration เหมาะกับเว็บไซต์ที่ใช้แพลตฟอร์มสำเร็จรูปและไม่มีทีมพัฒนาเฉพาะ เป็นวิธีที่เริ่มต้นได้เร็วและลดการเขียนโค้ดด้วยตนเอง

ขั้นตอนทั่วไปมีดังนี้

• เข้า Meta Events Manager
• เลือก Data Source หรือ Dataset ที่ต้องการใช้งาน
• เปิดเมนู Settings
• ไปยังส่วน Conversions API
• เลือก Set Up Through a Partner Integration หรือเมนูเลือก Partner
• เลือกแพลตฟอร์มของเว็บไซต์
• เชื่อมต่อบัญชี Meta Business, Ad Account และ Dataset
• เปิดการแชร์ข้อมูลตามระดับที่แพลตฟอร์มรองรับ
• ตรวจสอบ Event ใน Test Events
• ตรวจสอบ Diagnostics, Event Match Quality และ Deduplication หลังเริ่มรับข้อมูลจริง

Meta มี Partner Integration สำหรับแพลตฟอร์มเว็บไซต์และระบบร้านค้าหลายประเภท โดยขั้นตอนจริงอาจแตกต่างกันตามแพลตฟอร์มและเวอร์ชันของส่วนเสริม คู่มือ Partner Integration ของ Meta

ข้อควรระวังคือไม่ควรสรุปว่าติดตั้งส่วนเสริมแล้วระบบจะถูกต้องทั้งหมด ควรทดสอบคำสั่งซื้อจริง ตรวจสอบมูลค่า สกุลเงิน Content ID และ Event ID เพราะเว็บไซต์ที่ปรับแต่งระบบ Checkout อาจส่งข้อมูลไม่เหมือนการตั้งค่ามาตรฐาน

วิธีที่ 2 ผ่าน Google Tag Manager แบบ Server Side

วิธีนี้เหมาะกับธุรกิจที่ต้องการควบคุมข้อมูลมากขึ้น มีหลายแพลตฟอร์มการตลาด หรือมีทีมที่เข้าใจ Google Tag Manager และระบบ Cloud

Google อธิบายว่า Server Side Tagging เป็นการประมวลผลข้อมูลผ่าน Server Container ที่ธุรกิจควบคุม แทนการให้ Tag ทุกตัวทำงานและส่งข้อมูลออกจากเบราว์เซอร์โดยตรง คู่มือ Server Side Tagging จาก Google

ขั้นตอนหลักประกอบด้วย

• สร้าง Server Container ใน Google Tag Manager
• ติดตั้ง Tagging Server บน Google Cloud หรือผู้ให้บริการที่รองรับ
• เชื่อม Custom Domain เช่น data.example.com
• กำหนดให้ Web Container หรือระบบเว็บไซต์ส่ง Event มายัง Server Container
• เพิ่ม Client เพื่อรับและแปลงข้อมูลที่เข้ามา
• เพิ่ม Tag สำหรับส่ง Event ไปยัง Meta Conversions API
• ใส่ Dataset ID และ Access Token
• จับคู่ Event Name, Event Time, Action Source และ Event Source URL
• จับคู่ User Data และ Custom Data ที่จำเป็น
• ส่ง Event ID เดียวกับ Pixel เพื่อใช้ Deduplication
• ทดสอบด้วย Preview Mode และ Test Events
• ตรวจสอบ Consent ก่อนให้ Tag ส่งข้อมูล
• เผยแพร่ทั้ง Web Container และ Server Container
• ตรวจสอบค่าใช้จ่าย ความเสถียร และความสามารถรองรับ Traffic ของเซิร์ฟเวอร์

ข้อดีของวิธีนี้คือสามารถตรวจสอบ เพิ่ม ลบ หรือแก้ไขพารามิเตอร์ก่อนส่งให้แพลตฟอร์มปลายทางได้ แต่ Server Side GTM ไม่ได้สร้างข้อมูลขึ้นมาเอง เว็บไซต์ยังต้องส่ง Event และข้อมูลที่จำเป็นเข้าสู่ Server Container ก่อน

วิธีที่ 3 Direct API Integration สำหรับ Developer

Direct API Integration คือการให้ระบบของธุรกิจส่งข้อมูลไปยัง Meta Graph API โดยตรง เหมาะกับองค์กรที่มีระบบ E Commerce, CRM, Mobile Application หรือ Data Warehouse ของตนเอง

ขั้นตอนสำคัญมีดังนี้

• กำหนด Dataset และ Event ที่ต้องการส่ง
• สร้าง Access Token และจัดเก็บในระบบที่ปลอดภัย
• สร้างคำขอไปยัง Events Endpoint ของ Meta Graph API
• ส่ง Event Name ให้ตรงกับมาตรฐานของ Meta
• ส่ง Event Time เป็นเวลาที่เหตุการณ์เกิดขึ้นจริง
• ระบุ Action Source เช่น website หรือ app
• ส่ง Event Source URL สำหรับ Event จากเว็บไซต์
• ส่ง User Data ที่ได้รับอนุญาตให้ใช้งาน
• ส่ง Custom Data เช่น Value, Currency, Content ID และ Order ID
• ส่ง Event ID เพื่อป้องกัน Event ซ้ำ
• ใช้ Test Event Code ระหว่างการทดสอบ
• บันทึก Response และ Error จาก API เพื่อใช้ตรวจสอบย้อนหลัง
• วางระบบส่งซ้ำเมื่อเกิดปัญหาเครือข่ายโดยไม่สร้าง Event ID ใหม่
• ตรวจสอบข้อมูลใน Events Manager หลังเปิดใช้งานจริง

ข้อมูลส่วนบุคคลบางประเภท เช่น อีเมลและหมายเลขโทรศัพท์ ต้องปรับรูปแบบให้ถูกต้องและเข้ารหัสด้วย SHA 256 ก่อนส่ง ส่วนข้อมูลอย่าง fbp, fbc, IP Address และ User Agent ต้องส่งตามรูปแบบที่ Meta กำหนดและไม่ควรเข้ารหัสแบบเดียวกับอีเมล รายละเอียดพารามิเตอร์ CAPI จาก Meta

ไม่ควรใส่ Access Token ไว้ในโค้ดที่ทำงานบนเบราว์เซอร์ เพราะผู้ใช้สามารถตรวจพบและนำ Token ออกไปใช้ได้ Token ควรอยู่ในระบบฝั่งเซิร์ฟเวอร์หรือ Secret Manager เท่านั้น

Event Match Quality (EMQ) คืออะไร และทำยังไงให้สูง

Event Match Quality หรือ EMQ คือคะแนนที่แสดงว่าข้อมูลลูกค้าที่ส่งมากับ Server Event มีประสิทธิภาพเพียงใดในการช่วยให้ Meta จับคู่ Event กับบัญชีผู้ใช้งาน

Meta คำนวณคะแนนตั้งแต่ 0 ถึง 10 โดยพิจารณาทั้งประเภทของพารามิเตอร์ คุณภาพของข้อมูล และสัดส่วน Event ที่มีข้อมูลดังกล่าว คำอธิบาย Event Match Quality จาก Meta

EMQ ไม่ได้วัดว่า Event ส่งมาถึงครบหรือไม่ และไม่ได้หมายถึงอัตรา Conversion คะแนนนี้เน้นความสามารถในการจับคู่ข้อมูลเท่านั้น จึงควรตรวจร่วมกับ Event Coverage, Deduplication, Diagnostics และความถูกต้องของมูลค่าธุรกรรม

คะแนน EMQ ที่ดีควรเป็นเท่าไหร่

เป้าหมายที่เหมาะสมคือให้ Events Manager แสดงสถานะ Good หรือ Great สำหรับ Event สำคัญ โดยคะแนนประมาณ 8 ถึง 10 ถือเป็นระดับที่แข็งแรงในเชิงการปฏิบัติงาน ส่วนคะแนน 4 ถึง 7 แสดงว่ายังมีโอกาสปรับปรุงข้อมูลที่ใช้จับคู่

อย่างไรก็ตาม ไม่ควรเพิ่มคะแนนด้วยการเก็บข้อมูลที่ไม่จำเป็นหรือไม่มีสิทธิ์ใช้งาน คะแนน 10 ไม่ได้รับประกันว่า CPA จะลดลง และคะแนนที่ต่ำกว่า 8 ไม่ได้แปลว่าแคมเปญจะทำงานไม่ได้

ควรให้ความสำคัญกับ Purchase, Lead, QualifiedLead และ Event ที่ใช้เป็น Optimization Event ก่อน เพราะ Event เหล่านี้มีผลต่อการเรียนรู้และการรายงานของแคมเปญโดยตรง

วิธีเพิ่ม EMQ ด้วยการส่งพารามิเตอร์ให้ครบ

พารามิเตอร์ที่ช่วยในการจับคู่ประกอบด้วย

• Email หรืออีเมล
• Phone หรือหมายเลขโทรศัพท์
• External ID หรือรหัสลูกค้าจากระบบของธุรกิจ
• First Name และ Last Name
• City, State, Postal Code และ Country
• Client IP Address
• Client User Agent
• fbp ซึ่งเป็นค่าที่เกี่ยวข้องกับ Browser ID ของ Meta
• fbc ซึ่งเชื่อมโยงกับ Facebook Click ID เมื่อผู้ใช้มาจากโฆษณา

แนวทางเพิ่ม EMQ ที่ควรทำคือ

• ส่งข้อมูลเฉพาะที่ได้รับอนุญาตและเกี่ยวข้องกับวัตถุประสงค์
• ปรับรูปแบบข้อมูลก่อนเข้ารหัส เช่น ตัดช่องว่างและใช้รูปแบบตัวอักษรที่ Meta กำหนด
• ส่ง External ID ที่มีความคงที่ ไม่สร้างค่าใหม่ทุก Session
• เก็บ fbp และ fbc ตั้งแต่หน้า Landing Page แล้วส่งต่อไปยังขั้นตอน Conversion
• ส่ง IP Address และ User Agent จากคำขอของผู้ใช้จริง ไม่ใช้ค่าของเซิร์ฟเวอร์แทน
• ตรวจสอบ Coverage ของแต่ละพารามิเตอร์ ไม่ดูเพียงว่ามีการตั้งค่า Field แล้วหรือไม่
• แก้ Warning ใน Diagnostics อย่างสม่ำเสมอ

จากประสบการณ์ตรวจสอบระบบ Tracking ปัญหาที่พบมากคือเว็บไซต์ส่งอีเมลได้เฉพาะ Purchase แต่ไม่ได้ส่ง fbp หรือ fbc ต่อจาก Session ต้นทาง ทำให้ Meta มีข้อมูลลูกค้าแต่ขาดบริบทของการคลิกโฆษณา การเก็บและส่งข้อมูลให้ต่อเนื่องตลอด Customer Journey จึงสำคัญกว่าการเพิ่มจำนวน Field เพียงอย่างเดียว

Deduplication จัดการ Event ซ้ำระหว่าง Pixel กับ CAPI

เมื่อ Pixel และ CAPI ส่ง Purchase Event จากคำสั่งซื้อเดียวกัน Meta อาจได้รับ Event สองรายการ หากไม่มีระบบ Deduplication รายงานอาจนับยอดซื้อซ้ำและทำให้ข้อมูลที่ใช้ปรับโฆษณาคลาดเคลื่อน

วิธีมาตรฐานคือส่ง Event Name และ Event ID ที่ตรงกันผ่านทั้ง Pixel และ CAPI

ตัวอย่างการทำงานมีดังนี้

• ลูกค้าเริ่มทำรายการสั่งซื้อ
• ระบบสร้าง Event ID ที่ไม่ซ้ำสำหรับคำสั่งซื้อนั้น
• Pixel ส่ง Purchase พร้อม Event ID
• Server ส่ง Purchase ผ่าน CAPI พร้อม Event ID เดียวกัน
• Meta ตรวจพบว่า Event Name และ Event ID ตรงกัน
• ระบบรวมข้อมูลให้เป็น Conversion เดียว

Event ID ควรเชื่อมกับธุรกรรมจริง เช่น Order ID หรือรหัส Event ที่สร้างเพียงครั้งเดียว ไม่ควรสร้างคนละค่าระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์

หากระบบส่ง Event ซ้ำเพราะ API Timeout ต้องใช้ Event ID เดิมในการส่งซ้ำ ไม่เช่นนั้น Meta อาจมองว่าเป็น Conversion คนละรายการ

หลังติดตั้งควรตรวจ Event Deduplication ใน Events Manager ว่าทั้ง Browser Event และ Server Event มี Deduplication Key ครบถ้วน Meta มีหน้ารายงานสำหรับตรวจ Coverage และ Overlap ของข้อมูลที่ใช้ป้องกัน Event ซ้ำ แนวทางตรวจสอบ CAPI ใน Events Manager

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

Event ถูกนับซ้ำ

• สาเหตุมักมาจาก Event ID ของ Pixel และ CAPI ไม่ตรงกัน หรือไม่ได้ส่ง Event ID ในช่องทางใดช่องทางหนึ่ง
• วิธีแก้คือสร้าง Event ID จากระบบกลาง ส่งค่าเดียวกันไปทั้งสองช่องทาง และตรวจ Deduplication ใน Events Manager

Purchase Value หรือ Currency ไม่ถูกต้อง

• สาเหตุอาจมาจากการส่ง Value เป็นข้อความ การใช้สกุลเงินผิดรูปแบบ หรือการส่งยอดก่อนหักส่วนลดแทนยอดชำระจริง
• วิธีแก้คืออ้างอิงยอดจากระบบคำสั่งซื้อ ส่ง Currency ตามมาตรฐาน และทดสอบรายการที่มีส่วนลด ค่าจัดส่ง และภาษี

Event Time ไม่ตรงกับเวลาที่เกิดรายการ

• การส่งเวลาที่ API ทำงานแทนเวลาที่ธุรกรรมเกิดจริง อาจทำให้ Attribution คลาดเคลื่อน โดยเฉพาะ Event ที่ส่งจาก CRM ภายหลัง
• วิธีแก้คือบันทึกเวลาที่ Event เกิดขึ้นในระบบต้นทางและส่งเวลานั้นไปยัง Meta

EMQ ต่ำแม้ส่งอีเมลและเบอร์โทรศัพท์แล้ว

• อาจเกิดจากข้อมูลไม่ได้ปรับรูปแบบก่อนเข้ารหัส ค่าเป็นช่องว่าง Coverage ต่ำ หรือขาด fbp และ fbc
• วิธีแก้คือดูรายละเอียดพารามิเตอร์ของแต่ละ Event ตรวจรูปแบบข้อมูล และวัดเปอร์เซ็นต์ Event ที่มีค่าจริง

ส่ง IP Address ของเซิร์ฟเวอร์แทนผู้ใช้

• ทำให้ Event จำนวนมากมี IP Address เดียวกันและลดประสิทธิภาพการจับคู่
• วิธีแก้คือส่ง Client IP จากคำขอต้นทางอย่างถูกต้อง พร้อมตรวจโครงสร้าง Proxy และ Load Balancer

ใช้ Test Event Code ในระบบจริง

• Event อาจปรากฏเฉพาะในส่วนทดสอบและไม่ถูกประมวลผลตามที่คาดหวัง
• วิธีแก้คือลบ Test Event Code ก่อนเปิดใช้งานจริง

Access Token รั่วไหล

• มักเกิดจากการใส่ Token ใน JavaScript หรือเปิดเผยในระบบบันทึกข้อมูล
• วิธีแก้คือเก็บ Token ฝั่งเซิร์ฟเวอร์ จำกัดสิทธิ์การเข้าถึง ใช้ Secret Manager และเปลี่ยน Token เมื่อสงสัยว่าข้อมูลรั่วไหล

ส่งข้อมูลโดยไม่ตรวจ Consent

• CAPI ไม่ได้ทำให้ธุรกิจได้รับสิทธิ์ใช้ข้อมูลโดยอัตโนมัติ
• วิธีแก้คือเชื่อมสถานะ Consent เข้ากับระบบ Tracking กำหนดกฎการส่งข้อมูลตามวัตถุประสงค์ และจัดทำนโยบายความเป็นส่วนตัวให้สอดคล้องกับการใช้งานจริง

ตรวจเฉพาะว่า Event เข้ามาหรือไม่

• การเห็น Purchase ใน Test Events ไม่ได้แปลว่าระบบพร้อมใช้งาน เพราะ Event อาจมีมูลค่าผิด ถูกนับซ้ำ หรือจับคู่ผู้ใช้ไม่ได้
• ควรตรวจพร้อมกันทั้ง Event Name, Event Time, Event ID, Value, Currency, User Data, EMQ, Coverage และ Deduplication