Conversion API (CAPI) คืออะไร? คู่มือ Server-side Tracking ให้แอดเห็นยอดครบ (2026)

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

บทความนี้ผมเขียนจากงานที่ทำจริงบนเว็บ m-creation.co ของเราเอง ที่นี่ยิง Meta Pixel ในเบราว์เซอร์ และส่ง Conversions API ออกจากฟังก์ชันบนเซิร์ฟเวอร์ ใช้กับ 2 อีเวนต์คือ Lead (ส่งฟอร์มขอใบเสนอราคา) และ Contact (กดทัก LINE, WhatsApp หรือโทร) ในบทความจะมีทั้งหลักการ ตารางเทียบวิธีติดตั้ง วิธีตรวจว่าข้อมูลเข้าจริง และจุดที่คนพลาดกันบ่อย ข้อมูลเทคนิคทุกจุดมีลิงก์เอกสารทางการให้เปิดดูเอง

Conversion API คืออะไร อธิบายแบบไม่ใช้ศัพท์เทคนิค

ลองนึกถึงร้านที่นับลูกค้าด้วยสมุดวางไว้หน้าร้าน ให้ลูกค้าเซ็นชื่อเองตอนเดินเข้ามา บางคนเซ็น บางคนไม่เซ็น บางคนรีบจนลืม ตัวเลขในสมุดเลยต่ำกว่าความจริงเสมอ Pixel ก็ทำงานแบบสมุดเล่มนี้ มันเป็นโค้ดที่รันในเบราว์เซอร์ของลูกค้า ถ้าเบราว์เซอร์ไม่ให้รัน ข้อมูลก็หาย (ถ้ายังไม่รู้จัก Pixel อ่านพื้นฐานได้ที่ Facebook Pixel คืออะไร)

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

คำว่า server-side tracking ที่ได้ยินกันบ่อยก็คือแนวคิดเดียวกันในภาพกว้าง คือย้ายการส่งข้อมูลการติดตามจากเบราว์เซอร์มาไว้ที่เซิร์ฟเวอร์ ส่วน Conversion API เป็นชื่อช่องทางรับข้อมูลที่แต่ละแพลตฟอร์มเปิดไว้ให้ส่งเข้าไป

ข้อที่ต้องจำไว้คือ CAPI ไม่ได้มาแทน Pixel ทั้ง Meta และ TikTok แนะนำให้ใช้คู่กัน เพราะแต่ละฝั่งเก็บข้อมูลได้คนละแบบ รายละเอียดเรื่องนี้ผมแยกไว้ในบทความ Pixel กับ Conversion API ต่างกันยังไง และกันนับซ้ำด้วย event_id

ทำไมใช้ Pixel อย่างเดียวแล้วยอดในแอดไม่ครบ

สาเหตุไม่ได้มีแค่ข้อเดียว แต่ละข้อทำให้ข้อมูลหายไปทีละส่วน และหายแบบนี้ทุกวัน

• ตัวบล็อกโฆษณา (ad blocker) ส่วนขยายเบราว์เซอร์และเบราว์เซอร์บางตัวบล็อกสคริปต์ติดตามของแพลตฟอร์มโฆษณาไว้ตั้งแต่ต้น Pixel เลยไม่ได้รันเลย
• Safari กับการจำกัดคุกกี้ (ITP) ตามเอกสารของ WebKit Safari จะลบคุกกี้ที่สร้างด้วย JavaScript ถ้าผู้ใช้ไม่ได้ใช้งานเว็บนั้นเลยครบ 7 วัน และถ้าผู้ใช้เข้ามาจากลิงก์ที่ติดพารามิเตอร์ติดตาม คุกกี้ที่หน้านั้นสร้างอาจอยู่ได้แค่ 24 ชั่วโมง คนที่คลิกแอดวันนี้แล้วกลับมาซื้ออาทิตย์หน้า จึงอาจถูกนับเป็นคนใหม่ที่ไม่ได้มาจากแอด
• iOS และการขออนุญาตติดตาม ตั้งแต่ iOS 14.5 แอปต้องขออนุญาตผู้ใช้ก่อนติดตามข้ามแอป (App Tracking Transparency) ข้อนี้กระทบข้อมูลฝั่งแอปเป็นหลัก แต่ก็ทำให้แพลตฟอร์มโฆษณาได้สัญญาณจากผู้ใช้ iPhone น้อยลงโดยรวม ถ้าธุรกิจมีแอปด้วย ฝั่งแอปต้องวัดผลด้วย SDK หรือ MMP แทน Pixel ผมแยกเล่าไว้ในบทความวัดผลแอปด้วย SDK, MMP และ iOS ATT
• ความยินยอมตาม PDPA ถ้าเว็บทำแบนเนอร์คุกกี้ถูกต้อง คนที่กดไม่ยอมรับจะไม่ถูกติดตามด้วย Pixel ข้อนี้เป็นเรื่องที่ควรเป็นอยู่แล้ว และ CAPI ก็ไม่ควรเอามาใช้หลบข้อนี้ (อ่านต่อในหัวข้อ PDPA ด้านล่าง)
• หน้าเว็บโหลดไม่ทัน ลูกค้ากดส่งฟอร์มแล้วปิดแท็บทันที หรือเน็ตมือถือหลุด คำสั่ง Pixel อาจยังไม่ทันส่งออกไป แต่ฟอร์มส่งถึงเซิร์ฟเวอร์เราแล้ว
• คอนเวอร์ชันที่เกิดนอกเว็บ ลูกค้าคุยใน LINE แล้วโอนเงิน หรือเซลล์ปิดดีลทางโทรศัพท์ เหตุการณ์แบบนี้ไม่มีเบราว์เซอร์อยู่ตรงนั้นเลย Pixel จึงเห็นไม่ได้ ต้องส่งจากระบบหลังบ้านอย่างเดียว

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

Conversion API ทำงานยังไง ตั้งแต่ลูกค้าคลิกแอดจนแพลตฟอร์มเห็นยอด

ถ้าตั้งค่าแบบที่ Meta แนะนำ (ใช้ทั้ง Pixel และ CAPI) ลำดับการทำงานจะเป็นแบบนี้

1. ลูกค้าคลิกแอดเข้าเว็บ URL ติดรหัสคลิกมาด้วย เช่น fbclid ของ Meta หรือ ttclid ของ TikTok ส่วน Pixel ก็สร้างคุกกี้ระบุเบราว์เซอร์ขึ้นมา (Meta ใช้ชื่อ _fbp และ _fbc)
2. ลูกค้าทำสิ่งที่เรานับเป็นคอนเวอร์ชัน เช่น ส่งฟอร์ม กดโทร หรือสั่งซื้อ
3. เบราว์เซอร์สร้างรหัสอีเวนต์ 1 ตัว (event_id) เป็นรหัสสุ่มที่ไม่ซ้ำกันสำหรับเหตุการณ์ครั้งนี้
4. Pixel ส่งอีเวนต์จากเบราว์เซอร์ พร้อม event_id ตัวนั้น (ถ้าเบราว์เซอร์ไม่บล็อก)
5. เบราว์เซอร์ส่งข้อมูลเดียวกันมาที่เซิร์ฟเวอร์เรา พร้อม event_id ตัวเดิม ค่าคุกกี้ และข้อมูลที่ลูกค้ากรอก
6. เซิร์ฟเวอร์ส่งอีเวนต์ไปที่ Conversion API อีเมลกับเบอร์โทรจะถูกทำให้อยู่ในรูปแบบมาตรฐานแล้วแฮชก่อนส่ง
7. แพลตฟอร์มรวมสองอีเวนต์เป็นหนึ่ง ถ้าชื่ออีเวนต์กับ event_id ตรงกัน ระบบจะนับครั้งเดียว ถ้า Pixel โดนบล็อก ก็ยังมีอีเวนต์จากเซิร์ฟเวอร์ให้นับอยู่

ขั้นที่ 3 กับ 7 คือหัวใจของทั้งระบบ ตามเอกสารของ Meta อีเวนต์จะถูกรวมเมื่อ event_name กับ event_id ตรงกัน และมาถึงภายใน 48 ชั่วโมงนับจากอีเวนต์แรกที่มี event_id นั้น ถ้ารหัสไม่ตรงกัน ยอดจะถูกนับเป็น 2 เท่าทันที

แพลตฟอร์มไหนมี Conversion API บ้าง

แพลตฟอร์มหลักที่คนไทยยิงแอดมีช่องทางส่งข้อมูลจากเซิร์ฟเวอร์ทั้งหมด แต่ชื่อเรียกกับวิธีกันนับซ้ำไม่เหมือนกัน

แพลตฟอร์ม	ฝั่งเบราว์เซอร์	ฝั่งเซิร์ฟเวอร์	วิธีกันนับซ้ำ
Meta (Facebook, Instagram)	Meta Pixel	Conversions API	event_name + event_id ตรงกัน ภายใน 48 ชม.
TikTok	TikTok Pixel	Events API	event + event_id ตรงกัน ภายใน 48 ชม. (TikTok Help)
Google Ads	Google tag / GTM	Enhanced conversions และการนำเข้าคอนเวอร์ชันออฟไลน์	Transaction ID ตรงกันในคอนเวอร์ชันแอ็กชันเดียวกัน (Google Ads Help)
LINE Ads	LINE Tag	Conversion API	Deduplication Key ที่ใส่ใน LINE Tag (LINE for Business)

Google ต่างจากเจ้าอื่นอยู่หน่อย Enhanced conversions คือการแนบข้อมูลลูกค้าที่แฮชแล้ว (อีเมล เบอร์โทร ชื่อ ที่อยู่) ไปกับคอนเวอร์ชัน ส่งได้ทั้งผ่านแท็ก GTM หรือ Google Ads API ส่วน Enhanced conversions for leads ใช้กับธุรกิจที่ได้ลีดจากเว็บแล้วไปปิดการขายนอกเว็บ ส่วน TikTok ผมเขียนเรื่องฝั่งเบราว์เซอร์แยกไว้ที่ TikTok Pixel

ต้องส่งข้อมูลอะไรไปกับ Conversion API

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

ข้อมูล	ชื่อฟิลด์ (Meta)	ต้องแฮชไหม	มาจากไหน
อีเมล	em	ต้องแฮช SHA-256 ตัดช่องว่าง แปลงเป็นตัวพิมพ์เล็กก่อน	ฟอร์มหรือออเดอร์
เบอร์โทร	ph	ต้องแฮช ใส่รหัสประเทศ ไม่มีขีด ไม่มีเลข 0 นำหน้า เช่น 0812345678 → 66812345678	ฟอร์มหรือออเดอร์
รหัสลูกค้าในระบบเรา	external_id	แนะนำให้แฮช	CRM หรือระบบสมาชิก
คุกกี้เบราว์เซอร์	fbp	ห้ามแฮช	คุกกี้ _fbp
รหัสคลิกแอด	fbc	ห้ามแฮช	คุกกี้ _fbc หรือสร้างจาก fbclid ใน URL
IP และ User Agent	client_ip_address, client_user_agent	ห้ามแฮช	คำขอที่เบราว์เซอร์ส่งมาที่เซิร์ฟเวอร์
รหัสอีเวนต์	event_id	ไม่แฮช	สร้างในเบราว์เซอร์ ใช้ร่วมกับ Pixel

จุดที่คนพลาดบ่อยคือเบอร์โทร เบอร์ไทยที่ขึ้นต้นด้วย 0 ต้องตัด 0 ทิ้งแล้วเติม 66 ก่อนแฮช ถ้าแฮชทั้ง 0812... ไปตรง ๆ ค่าที่ได้จะไม่ตรงกับที่แพลตฟอร์มเก็บไว้ ส่งไปเท่าไหร่ก็จับคู่ไม่ได้ อีกเรื่องคือ fbc ถ้าคุกกี้ _fbc ยังไม่มี แต่ URL มี fbclid Meta ให้สร้างค่าเองในรูปแบบ fb.1.เวลาเป็นมิลลิวินาที.ค่า fbclid ได้

1. 1event_id = รหัสกันนับซ้ำค่าที่เบราว์เซอร์ส่งมา ต้องตรงกับ eventID ของ Pixel ทุกตัว ถ้ามีค่าอยู่แล้วห้ามสุ่มใหม่ที่เซิร์ฟเวอร์
2. 2em = อีเมลที่แฮชแล้วตัดช่องว่าง แปลงเป็นตัวพิมพ์เล็ก แล้วแฮช SHA-256 แพลตฟอร์มได้รับแค่รหัสนี้ ไม่ใช่อีเมลตัวจริง
3. 3ph = เบอร์โทรที่แฮชแล้วตัดขีด ตัด 0 ตัวแรก เติม 66 แล้วค่อยแฮช ดูขั้นตอนที่แถบล่างของภาพ
4. 4client_ip_address / client_user_agent = IP และเบราว์เซอร์ของลูกค้าส่งค่าดิบ เว็บเราอยู่หลัง Cloudflare จึงอ่าน IP จาก header CF-Connecting-IP ไม่ใช่ IP ของเซิร์ฟเวอร์
5. 5fbp / fbc = คุกกี้ของ Metaส่งค่าดิบ ห้ามแฮช fbc คือรหัสคลิกที่บอกว่าลูกค้ามาจากการคลิกแอด
6. 6custom_data = ที่มาของแอดแนบ utm_campaign กับ ad_id ไว้ไล่ดูใน Events Manager ว่าอีเวนต์มาจากแอดไหน

ข้อ 2–3 ต้องแฮชก่อนส่ง · ข้อ 4–5 ส่งค่าดิบ ห้ามแฮช · ข้อ 1 ต้องเป็นค่าเดียวกับฝั่ง Pixel

อีกข้อที่ต้องรู้คือ event_time ย้อนหลังได้ไม่เกิน 7 วัน ถ้าในชุดที่ส่งไปมีอีเวนต์ไหนเก่ากว่านั้น Meta จะตีกลับทั้งคำขอ ยกเว้นอีเวนต์ประเภทหน้าร้านจริงที่ย้อนได้ 62 วัน Meta แนะนำให้ส่งทันทีที่เกิดเหตุการณ์ ไม่ต้องรอรวบส่งทีเดียว

ติดตั้ง Conversion API ได้กี่วิธี แบบไหนเหมาะกับใคร

Meta แบ่งทางเลือกไว้หลัก ๆ คือเชื่อมผ่านพาร์ทเนอร์ ใช้ Conversions API Gateway หรือเขียนเชื่อมตรงเอง ผมเพิ่ม GTM server-side เข้ามาด้วย เพราะเป็นทางที่หลายทีมเลือกใช้เมื่อต้องส่งข้อมูลให้หลายแพลตฟอร์มพร้อมกัน

วิธี	เหมาะกับ	ข้อดี	ข้อจำกัด
Partner integration (Shopify, WooCommerce, Wix ฯลฯ)	ร้านออนไลน์บนแพลตฟอร์มสำเร็จรูป	กดเชื่อมไม่กี่คลิก ไม่ต้องเขียนโค้ด Meta บอกว่าไม่มีค่าใช้จ่ายเพิ่ม	ปรับแต่งได้น้อย ส่งได้เฉพาะอีเวนต์ที่ปลั๊กอินรองรับ ใช้กับลีดที่ปิดนอกเว็บไม่ได้
Conversions API Gateway	เว็บที่ใช้ Meta อย่างเดียวและไม่มีนักพัฒนา	ตั้งค่าจาก Events Manager ไม่ต้องเขียนโค้ด อัปเดตตัวเองตามฟีเจอร์ใหม่	ต้องมีบัญชีคลาวด์ (AWS หรือ GCP) และจ่ายค่าเซิร์ฟเวอร์เอง ใช้กับ Meta เท่านั้น
GTM server-side	ทีมที่ยิงแอดหลายแพลตฟอร์ม และมีคนดูแล GTM อยู่แล้ว	เก็บครั้งเดียวแล้วแจกไป Meta, TikTok, Google ได้ มีเทมเพลตให้เลือก	ต้องเช่าเซิร์ฟเวอร์เอง (มีค่าใช้จ่ายรายเดือน) ต้องเข้าใจ GTM ลึกพอสมควร ดูแลยาก
เขียนโค้ดเอง / serverless function	เว็บที่เขียนเอง หรือธุรกิจที่มีลีดไหลเข้า CRM	ควบคุมได้ทุกฟิลด์ ส่งจากหลังบ้านหรือ CRM ได้ด้วย ค่าเซิร์ฟเวอร์ต่ำถ้าใช้ serverless	ต้องมีนักพัฒนา ต้องตามอัปเดต API และดูแลโค้ดเองระยะยาว

ถ้าเว็บเป็น Shopify หรือ WooCommerce และยอดขายจบในเว็บ ผมแนะนำให้เริ่มจากตัวเชื่อมของพาร์ทเนอร์ก่อน เพราะเร็วและพังยาก แต่ถ้าธุรกิจได้ลีดจากเว็บแล้วไปปิดการขายทางโทรศัพท์หรือแชต ตัวเชื่อมสำเร็จรูปมักไม่พอ ต้องมีโค้ดที่ส่งอีเวนต์จากระบบหลังบ้านได้ ถ้าไม่อยากดูแลเอง ทีมเรารับติดตั้ง Conversion API ให้ทั้ง Meta, TikTok, Google และ LINE โดยเริ่มจากตรวจบัญชีแอดกับเว็บก่อนว่าตอนนี้ข้อมูลหายตรงไหน

ตัวอย่างจริง: เราตั้ง CAPI บนเว็บ m-creation.co ยังไง

เว็บเราเป็นเว็บบริการ ไม่มีตะกร้าสินค้า คอนเวอร์ชันที่เราสนใจคือลีด เลยเลือกเขียนเอง โดยใช้ฟังก์ชัน serverless บน Cloudflare ส่วนที่ทำมีประมาณนี้

• 2 อีเวนต์หลัก Lead ยิงตอนส่งฟอร์มขอใบเสนอราคา และ Contact ยิงตอนกดปุ่ม LINE, WhatsApp หรือเบอร์โทร
• event_id ตัวเดียวใช้สองฝั่ง สร้างในเบราว์เซอร์ตอนเกิดเหตุการณ์ แล้วส่งให้ทั้ง Pixel และฟังก์ชันบนเซิร์ฟเวอร์ Meta จึงรวมสองอีเวนต์เป็นหนึ่งได้
• เก็บที่มาของแอดตั้งแต่หน้าแรกที่ลูกค้าเข้า ได้แก่ utm_*, fbclid, ad_id, adset_id, campaign_id, placement และคุกกี้ _fbp/_fbc เก็บทั้งครั้งแรกที่เข้ามา (first-touch) และครั้งล่าสุด (last-touch) แล้วบันทึกไว้คู่กับลีดทุกราย
• เคารพความยินยอม Pixel ใช้คำสั่ง consent แบบ revoke/grant ตามที่ผู้ใช้เลือกในแบนเนอร์ PDPA ส่วนอีเวนต์ Contact ฝั่งเซิร์ฟเวอร์จะส่งเฉพาะเมื่อผู้ใช้กดยอมรับแล้ว
• ตรวจด้วย Test Events ก่อนเปิดใช้จริง เราส่งอีเวนต์ทดสอบแล้วดูในแท็บ Test Events ของ Events Manager ว่าอีเวนต์จากเซิร์ฟเวอร์เข้ามาครบ

1. 1mcAttr() = เก็บที่มาของแอดเก็บ utm, fbclid, ad_id ทั้งครั้งแรกและครั้งล่าสุด พร้อมคุกกี้ _fbp/_fbc และสร้าง event_id ตอนเกิดเหตุการณ์
2. 2แบนเนอร์ PDPA = สวิตช์ความยินยอมสิ่งที่ผู้ใช้เลือกถูกส่งเข้า Pixel (grant หรือ revoke) และแนบไปกับข้อมูลที่ส่งให้เซิร์ฟเวอร์
3. 3mcFire() = ยิง Pixelส่ง Lead หรือ Contact จากเบราว์เซอร์ พร้อม eventID ตัวเดียวกับที่ส่งให้เซิร์ฟเวอร์
4. 4/api/quote = รับฟอร์มขอใบเสนอราคาบันทึกลีด ส่ง Lead เข้า CAPI และส่งลีดเข้า CRM พร้อมที่มาของแอด
5. 5/api/track = รับการกดปุ่มติดต่อส่ง Contact เข้า CAPI เฉพาะเมื่อผู้ใช้กดยอมรับคุกกี้แล้ว
6. 6_capi.js = ตัวส่งกลางแฮชอีเมลกับเบอร์ อ่าน IP จริงของลูกค้า แล้วส่งไป Meta แบบเบื้องหลัง ลูกค้าไม่ต้องรอ

ทุกอีเวนต์ผ่านตัวส่งกลางตัวเดียว (ข้อ 6) จะแก้กติกาการแฮชหรือเวอร์ชัน API ก็แก้ที่เดียวจบ

ส่วนที่ผมว่าคุ้มที่สุดไม่ได้อยู่ที่ตัว CAPI แต่เป็นข้อมูลที่มาของแอดที่ติดไปกับลีด พอลีดเข้า CRM เราก็รู้ทันทีว่าลีดนี้มาจากแคมเปญไหน แอดตัวไหน และส่งสถานะการขายกลับไปให้ Meta ต่อได้ ผมเล่าขั้นตอนทั้งหมดไว้ในเคสติดตามลีดของ M Creation

โค้ดฝั่งเบราว์เซอร์ส่วนที่สำคัญมีแค่นี้ คือสร้างรหัสครั้งเดียว แล้วใช้รหัสนั้นทั้งสองทาง

const eventId = crypto.randomUUID();
fbq('track', 'Lead', {}, { eventID: eventId });
fetch('/api/lead', { method: 'POST', body: JSON.stringify({ ...formData, event_id: eventId }) });

ฝั่งเซิร์ฟเวอร์ต้องส่ง event_id ค่าเดียวกันนี้ไปใน payload ของ Conversions API ห้ามสร้างใหม่

ตรวจยังไงว่า Conversion API ทำงานถูกต้อง

ติดตั้งเสร็จแล้วอย่าเพิ่งเชื่อว่าใช้ได้ ผมตรวจตามลำดับนี้ทุกครั้ง

1. Test Events ใน Events Manager เปิดแท็บ Test Events คัดลอก test code ไปใส่ในพารามิเตอร์ test_event_code แล้วลองส่งฟอร์มจริง ต้องเห็นอีเวนต์เดียวกันขึ้นทั้งจาก Browser และ Server Meta เตือนไว้ว่าอีเวนต์ทดสอบไม่ได้ถูกทิ้ง มันยังถูกนับไปใช้วัดผลด้วย ทดสอบเสร็จแล้วต้องเอา test code ออกจากโค้ดจริง
2. Event Match Quality (EMQ) คะแนน 0–10 ของแต่ละอีเวนต์ บอกว่าข้อมูลลูกค้าที่ส่งจากเซิร์ฟเวอร์จับคู่กับบัญชี Meta ได้ดีแค่ไหน ถ้าคะแนนต่ำ ส่วนใหญ่เป็นเพราะไม่ได้ส่งอีเมล เบอร์โทร หรือ fbc หรือส่งไปแต่รูปแบบผิด
3. Event coverage สัดส่วนอีเวนต์จาก Pixel ที่มีอีเวนต์จาก CAPI คู่กันและใช้คีย์กันนับซ้ำตัวเดียวกัน ในเอกสาร Dataset Quality API ของ Meta ตั้งเป้าไว้ที่ 75%
4. Deduplication key feedback ดูว่าอีเวนต์กี่เปอร์เซ็นต์ที่มี event_id หรือคีย์อื่นติดมา ถ้าฝั่งไหนขาด ยอดจะเสี่ยงนับซ้ำ
5. เทียบกับหลังบ้าน นับลีดในระบบเราช่วง 7 วัน เทียบกับยอดใน Events Manager ถ้าฝั่ง Meta สูงกว่ามาก แปลว่านับซ้ำ ถ้าต่ำกว่ามาก แปลว่ายังมีอีเวนต์หายอยู่

1. 1Test events = หน้าทดสอบใส่ test_event_code แล้วส่งฟอร์มจริง ต้องเห็นอีเวนต์ขึ้นทั้งจาก Browser และ Server ทดสอบเสร็จต้องเอา code ออก
2. 2Integration = ทางที่ข้อมูลเข้ามาต้องขึ้นทั้ง Browser และ Server ถ้ามีแค่ Browser แปลว่า CAPI ยังไม่ส่ง
3. 3Event match quality = คะแนนจับคู่ 0–10คะแนนต่ำส่วนใหญ่มาจากไม่ได้ส่งอีเมล เบอร์โทร หรือ fbc หรือส่งไปแต่รูปแบบผิด
4. 4Event coverage = สัดส่วนที่มีคู่จาก CAPIอีเวนต์จาก Pixel ที่มีอีเวนต์จากเซิร์ฟเวอร์คู่กัน เอกสารของ Meta ตั้งเป้าไว้ 75%
5. 5Deduplication keys = รหัสกันนับซ้ำดูว่าอีเวนต์กี่เปอร์เซ็นต์มี event_id ติดมา ฝั่งไหนขาด ยอดเสี่ยงเบิ้ล

ผ่านเมื่อ: เห็นทั้ง Browser และ Server · coverage ถึง 75% · event_id ครบทั้งสองฝั่ง แล้วค่อยเทียบยอด 7 วันกับหลังบ้าน

ถ้าเจอยอดเบิ้ลหรือไม่แน่ใจว่าระบบกันนับซ้ำทำงานไหม ผมเขียนวิธีไล่หาสาเหตุไว้ละเอียดในบทความเรื่อง Pixel กับ CAPI และ event_id

Conversion API กับ PDPA ต้องระวังอะไร

หลายคนเข้าใจว่าส่งจากเซิร์ฟเวอร์แล้วตัวบล็อกหรือแบนเนอร์คุกกี้ก็ห้ามไม่ได้ เลยส่งข้อมูลทุกคนไปหมด ผมมองว่าคิดแบบนี้เสี่ยง เพราะ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ไม่ได้ดูว่าข้อมูลถูกส่งจากเบราว์เซอร์หรือเซิร์ฟเวอร์ อีเมลกับเบอร์โทรที่แฮชแล้ว แพลตฟอร์มก็ยังเอาไปจับคู่กับตัวคนได้ และการส่งให้แพลตฟอร์มโฆษณาก็คือการเปิดเผยข้อมูลให้บุคคลภายนอก

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

ส่วนนี้ผมเล่าจากมุมคนติดตั้งระบบ ไม่ใช่คำแนะนำทางกฎหมาย ควรให้ที่ปรึกษาด้าน PDPA ตรวจนโยบายอีกรอบ และเก็บ access token ของ CAPI ไว้ฝั่งเซิร์ฟเวอร์เท่านั้น

ความผิดพลาดที่เจอบ่อยตอนติดตั้ง Conversion API

• สร้าง event_id คนละตัว Pixel ใช้ตัวหนึ่ง เซิร์ฟเวอร์สุ่มใหม่อีกตัว ยอดจึงเบิ้ล 2 เท่า
• ชื่ออีเวนต์สองฝั่งไม่ตรงกัน เช่น เบราว์เซอร์ส่ง Lead แต่เซิร์ฟเวอร์ส่ง lead หรือ SubmitForm
• ส่ง IP ของเซิร์ฟเวอร์แทน IP ลูกค้า พบบ่อยเมื่อเว็บอยู่หลัง CDN ต้องอ่านจาก header ที่ CDN ส่งต่อมา ไม่ใช่ IP ที่ต่อเข้ามาโดยตรง
• แฮชผิดรูปแบบ ไม่ได้ตัดช่องว่าง ไม่ได้แปลงตัวพิมพ์เล็ก หรือเบอร์ไม่มีรหัสประเทศ ส่วน fbp/fbc กลับไปแฮชทั้งที่ไม่ควรแฮช
• รวบส่งวันละครั้ง ข้อมูลไม่สด และเสี่ยงหลุดกรอบ 7 วัน
• ไม่เช็ก consent ฝั่งเซิร์ฟเวอร์ Pixel หยุดตามแบนเนอร์ แต่เซิร์ฟเวอร์ยังส่งทุกคน
• ตั้งแล้วไม่มีใครดู เว็บเปลี่ยนฟอร์ม ปลั๊กอินอัปเดต แล้วอีเวนต์หายไปเงียบ ๆ ควรมีคนเปิดดู EMQ และ coverage อย่างน้อยเดือนละครั้ง

หลังจาก CAPI ใช้งานได้ ควรทำอะไรต่อ

เมื่อลีดเข้ามาพร้อมข้อมูลที่มาของแอดแล้ว ขั้นต่อไปคือบอกแพลตฟอร์มว่าลีดไหนคุณภาพดีจริง ลีดไหนไม่ใช่ ที่เราทำอยู่คือให้ CRM ส่งสถานะกลับไปที่ Meta เมื่อลีดผ่านการคัดกรองหรือได้รับใบเสนอราคาก็ส่ง Potential ปิดการขายได้ส่ง Purchase พร้อมมูลค่าดีล และลีดที่ไม่ใช่กลุ่มเป้าหมายส่ง NotPotential วิธีตั้งค่าอยู่ในบทความส่งสถานะ CRM กลับไปที่ Meta ถ้ายังไม่ได้วางว่าแต่ละขั้นของฟันเนลการตลาดจะวัดด้วยอีเวนต์อะไร ควรวางก่อน เพราะสถานะที่ส่งกลับควรตรงกับขั้นของฟันเนล

สรุป: ควรติดตั้ง Conversion API ตอนไหน

ถ้าคุณยิงแอดโดยใช้คอนเวอร์ชันเป็นเป้าหมาย และยอดในแอดไม่ตรงกับยอดในหลังบ้าน ก็ถึงเวลาติดตั้ง CAPI แล้ว เริ่มจากแพลตฟอร์มที่ใช้งบมากที่สุด ตั้ง event_id ให้ตรงกันตั้งแต่แรก ส่งข้อมูลจับคู่ให้ครบ ตรวจด้วย Test Events และดู EMQ กับ coverage เป็นประจำ

ถ้าอยากให้ทีมเราดูให้ เรารับติดตั้งและตรวจ Conversion API เป็นส่วนหนึ่งของงานวางระบบ Tracking ราคาติดตั้งแยกเราจะแจ้งหลังตรวจบัญชีแอดและเว็บแล้ว เพราะงานแต่ละเจ้าไม่เท่ากัน ส่วนลูกค้าแพ็กเกจ Growth System 39,000 บาท/เดือน ได้ Conversion Tracking, Pixel และ CAPI รวมถึงไปป์ไลน์ CRM ครบอยู่แล้ว