Facebook Pixel กับ Conversions API (CAPI) ต่างกันยังไง ทำไมต้องใช้ทั้งคู่

Facebook Pixel คืออะไร ทำงานยังไง

Facebook Pixel (ปัจจุบัน Meta เรียกว่า Meta Pixel) คือโค้ด JavaScript ที่วางไว้บนหน้าเว็บ เมื่อผู้เข้าชมเปิดหน้าเว็บ เบราว์เซอร์ของเขาจะโหลดโค้ดนี้แล้วส่งเหตุการณ์ต่าง ๆ กลับไปที่ Meta เช่น PageView, ViewContent, AddToCart, Lead หรือ Purchase พร้อมข้อมูลประกอบอย่างมูลค่าคำสั่งซื้อและสกุลเงิน

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

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

ถ้าเพิ่งเริ่มทำโฆษณา อ่านพื้นฐานได้ที่ ยิงแอด Facebook เริ่มต้น และเพราะ Pixel ทำงานบนหน้าเว็บของคุณ คุณภาพของหน้าปลายทางจึงสำคัญไม่แพ้กัน ดูเพิ่มได้ที่ Landing Page คืออะไร

ทำไม Pixel อย่างเดียวถึงเก็บข้อมูลไม่ครบ

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

• ตัวบล็อกโฆษณาและส่วนขยายด้านความเป็นส่วนตัว — หลายตัวบล็อกการโหลดสคริปต์ของ Meta ตั้งแต่ต้น เหตุการณ์จากผู้ใช้กลุ่มนี้จึงไม่ถูกส่งเลย
• ระบบป้องกันการติดตามของเบราว์เซอร์ — Safari มี Intelligent Tracking Prevention (ITP) และเบราว์เซอร์อื่นก็มีฟีเจอร์คล้ายกัน ซึ่งจำกัดอายุคุกกี้ที่สร้างด้วย JavaScript ทำให้การเชื่อมโยงคลิกโฆษณากับการซื้อที่เกิดทีหลังหลายวันทำได้ยากขึ้น
• การขออนุญาตติดตามบน iOS — ตั้งแต่ Apple เพิ่มการขออนุญาตติดตามข้ามแอป ผู้ใช้จำนวนมากเลือกไม่อนุญาต ข้อมูลที่ Meta ใช้จับคู่ผู้ใช้จึงน้อยลง
• เน็ตหลุดหรือปิดหน้าเร็ว — ผู้ใช้กดจ่ายเงินแล้วปิดแท็บก่อนหน้าขอบคุณโหลดเสร็จ เหตุการณ์ Purchase ก็ไม่ถูกส่ง
• การยินยอมคุกกี้ — ถ้าเว็บมีแบนเนอร์ขอความยินยอม และผู้ใช้ไม่ยินยอม Pixel ก็ไม่ควรทำงานตั้งแต่แรก

Conversions API (CAPI) คืออะไร ต่างจาก Pixel ยังไง

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

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

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

ใช้คู่กันต้องตั้ง Deduplication ด้วย event_id

เมื่อทั้ง Pixel และ CAPI ส่งเหตุการณ์ Purchase เดียวกัน ถ้าไม่บอก Meta ว่าเป็นเหตุการณ์เดียวกัน ยอดขายจะถูกนับสองครั้ง รายงานจะดูดีเกินจริง และระบบโฆษณาจะเรียนรู้จากข้อมูลผิด

วิธีที่ Meta แนะนำคือส่งรหัสเหตุการณ์ชุดเดียวกันจากทั้งสองฝั่ง ฝั่ง Pixel ใส่ eventID ในพารามิเตอร์ตัวที่สี่ของคำสั่ง fbq track ส่วนฝั่ง CAPI ใส่ event_id ค่าต้องตรงกัน และชื่อเหตุการณ์ต้องตรงกันด้วย คือ event ของ Pixel ต้องเท่ากับ event_name ของ CAPI เช่น Purchase ทั้งคู่

ตามเอกสารของ Meta ถ้าได้รับเหตุการณ์ที่มีคู่ event_id กับ event_name ตรงกันจาก Pixel เดียวกันภายใน 48 ชั่วโมง ระบบจะเก็บไว้ตัวเดียวแล้วตัดตัวที่ซ้ำทิ้ง ในทางปฏิบัติรหัสนี้มักใช้เลขคำสั่งซื้อ หรือสร้างเป็นค่าสุ่มตอนผู้ใช้กดปุ่ม แล้วส่งค่าเดียวกันไปให้ทั้งโค้ดหน้าเว็บและเซิร์ฟเวอร์

Event Match Quality และการ hash ข้อมูลลูกค้า

เหตุการณ์ที่ส่งผ่าน CAPI จะมีประโยชน์ก็ต่อเมื่อ Meta จับคู่ได้ว่าเป็นผู้ใช้คนไหน Events Manager มีคะแนน Event Match Quality บอกว่าข้อมูลลูกค้าที่คุณส่งมาช่วยจับคู่ได้ดีแค่ไหน ยิ่งส่งพารามิเตอร์ที่ถูกต้องครบ คะแนนยิ่งสูง

ข้อมูลส่วนตัวอย่างอีเมล เบอร์โทร ชื่อ นามสกุล เมือง รหัสไปรษณีย์ และ external_id ต้องทำให้เป็นรูปแบบมาตรฐานก่อนแล้วค่อย hash ด้วย SHA-256 เช่น อีเมลต้องตัดช่องว่างหัวท้ายและแปลงเป็นตัวพิมพ์เล็ก เบอร์โทรต้องเหลือแต่ตัวเลข ตัดศูนย์นำหน้าออก และใส่รหัสประเทศ เบอร์ไทย 081-234-5678 จึงกลายเป็น 66812345678 ก่อนนำไป hash

ส่วนข้อมูลบางตัวต้องส่งแบบไม่ hash ได้แก่ client_ip_address, client_user_agent, fbp (คุกกี้ _fbp ที่ระบุเบราว์เซอร์) และ fbc (ค่าที่มาจาก fbclid ตอนผู้ใช้คลิกโฆษณา) และสำหรับเหตุการณ์จากเว็บไซต์ Meta กำหนดให้ต้องส่ง client_user_agent ด้วย

• em, ph, fn, ln, ct, zp, country, external_id — ทำให้เป็นมาตรฐานแล้ว hash ด้วย SHA-256
• client_ip_address, client_user_agent — ส่งค่าจริงแบบไม่ hash ดึงมาจาก request ของผู้ใช้
• fbp, fbc — อ่านจากคุกกี้ของผู้ใช้แล้วส่งต่อแบบไม่ hash ช่วยให้เหตุการณ์ฝั่งเซิร์ฟเวอร์จับคู่กับฝั่งเบราว์เซอร์ได้แม่นขึ้น

วิธีติดตั้ง Conversions API มีกี่แบบ เลือกแบบไหนดี

ไม่มีวิธีที่ดีที่สุดสำหรับทุกคน ขึ้นกับว่าเว็บคุณสร้างด้วยอะไร มีนักพัฒนาในทีมไหม และอยากคุมข้อมูลเองแค่ไหน ตารางนี้สรุปสี่ทางเลือกหลัก

VPS เข้ามาช่วยตรงไหน และต้องใช้สเปคเท่าไหร่

ตัวอย่างการส่งเหตุการณ์ด้วย curl

สองวิธีหลังในตารางต้องมีเซิร์ฟเวอร์ที่เปิดตลอดเวลาและมี HTTPS ถ้าเซิร์ฟเวอร์ล่ม เหตุการณ์ฝั่ง CAPI จะหายไปทั้งหมดในช่วงนั้น นี่คือจุดที่ VPS เข้ามาช่วย

Server-side GTM แบบติดตั้งเอง Google มีคู่มือ manual setup ที่ให้รันเซิร์ฟเวอร์ติดแท็กเป็น Docker image บนเครื่องที่คุณเลือกได้ โดยต้องมีทั้ง tagging server และ preview server ชี้ซับโดเมน HTTPS ของเว็บคุณเข้ามา Google ระบุว่าแต่ละเครื่องไม่ควรเกิน 1 vCPU เพราะ vCPU ที่เกินไม่ได้ถูกใช้ และแนะนำให้รันเป็นคลัสเตอร์เมื่อทราฟฟิกสูง สำหรับเว็บขนาดเล็กถึงกลาง VPS ที่มี 2 vCores / 4 GB RAM รันทั้งสองตัวพร้อม reverse proxy ได้สบาย

ถ้าเขียน endpoint รับเหตุการณ์เองแล้วส่งต่อไป Meta งานนี้เบามาก VPS เล็กที่สุดก็รันได้ถ้าทราฟฟิกไม่สูง แต่ควรมีคิวหรือการลองส่งใหม่เผื่อ Meta ตอบกลับช้า ส่วน Conversions API Gateway ตามเอกสารของ Meta ต้องรันบนบัญชี AWS หรือ GCP จึงไม่ใช่ตัวเลือกสำหรับ VPS ทั่วไป

การรัน sGTM หรือ endpoint ของคุณเองด้วย Docker ทำให้ย้ายเครื่องและอัปเดตง่ายกว่ามาก อ่านพื้นฐานได้ที่ Docker คืออะไร และถ้าอยากรู้ว่า VPS ช่วยงานสายโฆษณาด้านอื่นอะไรอีก ดูต่อที่ VPS สำหรับคนยิงแอด

• ส่งแบบ POST ไปที่ https://graph.facebook.com/vXX.0/PIXEL_ID/events โดยแทน vXX.0 ด้วยเวอร์ชันของ Graph API ที่ใช้อยู่ และแนบ access_token ที่สร้างจาก Events Manager
• คำสั่งตัวอย่าง: curl -X POST "https://graph.facebook.com/vXX.0/PIXEL_ID/events?access_token=TOKEN" -H "Content-Type: application/json" -d @event.json
• ในไฟล์ event.json ใส่ data เป็นอาร์เรย์ของเหตุการณ์ แต่ละตัวมี event_name, event_time (Unix timestamp หน่วยวินาที), event_id, action_source เป็น website, event_source_url และ user_data ที่มี em แบบ hash, client_ip_address, client_user_agent, fbp, fbc
• ช่วงทดสอบเพิ่ม test_event_code ในระดับบนสุดของ payload แล้วลบออกก่อนใช้งานจริง

ทดสอบด้วย Test Events และข้อผิดพลาดที่เจอบ่อย

หลังติดตั้งเสร็จ เข้า Events Manager เลือก Pixel ของคุณ แล้วเปิดแท็บ Test events ฝั่ง Pixel ให้เปิดเว็บผ่านช่องทดสอบแล้วลองทำเหตุการณ์จริง ฝั่ง CAPI ให้คัดลอกรหัสทดสอบไปใส่ใน test_event_code ของ payload เหตุการณ์จะขึ้นให้เห็นแทบทันทีพร้อมบอกว่ามาจากเบราว์เซอร์หรือเซิร์ฟเวอร์ และถูกตัดซ้ำหรือไม่

ถ้าเห็นเหตุการณ์เดียวกันขึ้นทั้งสองฝั่งและระบบระบุว่าตัดซ้ำแล้ว แปลว่า event_id ตั้งถูก จากนั้นดูคะแนน Event Match Quality ในหน้าภาพรวมหลังมีข้อมูลจริงเข้ามาสักพัก