ทำไมทดสอบ Meta CAPI ผ่านแล้ว แต่ Event ยังไม่ขึ้นใน Events Manager จริง

ทีมบรรณาธิการ linli12 ส.ค. 04:51อัปเดต 12 ส.ค. 04:51อ่าน 5 นาที

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

สรุปสั้น ๆ

server side Meta CAPI LINE คือการส่ง Event จากเซิร์ฟเวอร์ธุรกิจตรงไปยัง Meta ผ่าน Conversions API แทนที่จะพึ่ง Pixel บนหน้าเว็บอย่างเดียว การทดสอบผ่าน Diagnostics ที่ไม่มี Error ไม่ได้แปลว่า Event จะขึ้นใน Events Manager เสมอ เพราะปัญหามักซ่อนอยู่ที่ Event ID, Action Source หรือ Deduplication ที่ตั้งค่าไม่ตรงกับที่ Meta คาดไว้

ทีมพัฒนาของธุรกิจขายคอร์สออนไลน์แห่งหนึ่งใช้เวลาทั้งสัปดาห์ตั้งค่า server-side Meta CAPI เพื่อส่ง Event Lead กลับไปยัง Meta หลังจากมีคนทักเข้า LINE และกลายเป็น Lead ในระบบขาย ตอนทดสอบผ่านเครื่องมือ Test Events ทุกอย่างดูปกติ ไม่มี Error สีแดงขึ้นเลย แต่พอปล่อยใช้งานจริงแล้วเปิดดู Events Manager กลับไม่เห็น Event เหล่านั้นปรากฏขึ้นมาสักตัว

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

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

ทำไม Test Events ผ่าน แต่ข้อมูลจริงไม่ขึ้น

Test Events เป็นเครื่องมือที่ตรวจว่ารูปแบบข้อมูลที่ส่งมาถูกต้องตามโครงสร้างที่ Meta กำหนดหรือไม่ เช่น มี Field ที่จำเป็นครบไหม ค่าที่ส่งมาเป็นชนิดข้อมูลที่ถูกต้องหรือไม่ แต่มันไม่ได้ตรวจว่า Event นั้นจะถูกจับคู่กับผู้ใช้จริงและถูกนับเป็น Conversion ที่ใช้ Optimize ได้หรือไม่ ซึ่งเป็นคนละขั้นตอนกัน

ความต่างนี้ทำให้ทีมจำนวนมากเข้าใจผิดว่าถ้า Test Events ไม่มี Error แปลว่าระบบพร้อมใช้งานจริงแล้ว ทั้งที่จริง ๆ ต้องตรวจเพิ่มอีกหลายจุด ทั้งเรื่อง Action Source ที่ต้องตรงกับบริบทของ Event, Event Match Quality ที่ Meta ประเมินจาก Identifier ที่ส่งมา และ Deduplication ที่อาจทำให้ Event ถูกกรองทิ้งไปเงียบ ๆ โดยไม่มี Error แจ้งเตือน

Action Source ตั้งผิดบริบท จุดที่ทำให้ Event หายบ่อยที่สุด

Action Source คือ Field ที่บอก Meta ว่า Event นี้เกิดขึ้นจากที่ไหน เช่น เกิดจาก Website, App, Chat หรือ System Generated ถ้าตั้งค่าผิดบริบท เช่น ส่ง Event ที่เกิดขึ้นในระบบขายฝั่งเซิร์ฟเวอร์แต่ระบุ Action Source เป็น Website ทั้งที่ผู้ใช้ไม่ได้อยู่บนหน้าเว็บตอนนั้นแล้ว Meta อาจปฏิเสธหรือลดคุณภาพของ Event นั้นโดยไม่แจ้งเตือนชัดเจนว่าเป็นเพราะเหตุนี้

สำหรับ Event ที่เกิดจากการเปลี่ยนสถานะในระบบขาย เช่น Lead กลายเป็น Qualified Lead หลังผ่านไปหลายวัน ควรตรวจเอกสารล่าสุดของ Meta ว่า Action Source ใดเหมาะสมกับบริบทนี้ ไม่ควรเดาจากประสบการณ์เก่าหรือใช้ค่าเดียวกับ Event อื่นที่เคยใช้งานได้โดยไม่ตรวจสอบ

Deduplication ที่ตั้งผิด ทำให้ Event หายแบบไม่มี Error

เมื่อธุรกิจใช้ทั้ง Pixel บนหน้าเว็บและ CAPI จากฝั่งเซิร์ฟเวอร์พร้อมกัน Meta ต้องอาศัย Event ID เดียวกันในการเทียบว่า Event สองตัวนี้เป็นเหตุการณ์เดียวกันหรือไม่ ถ้า Event ID ที่ส่งจากสองฝั่งไม่ตรงกันเป๊ะ Meta จะนับเป็นสอง Event แยกกัน แต่ถ้า Event ID ตรงกันแต่ Field อื่นไม่สอดคล้องกัน บางกรณี Meta อาจกรอง Event ที่มาทีหลังทิ้งไปเงียบ ๆ โดยไม่มี Error ให้เห็น ทำให้ทีมเข้าใจผิดว่า Event ไม่เคยถูกส่งเลย

วิธีตรวจคือดูที่ Event Match Quality Tool ใน Events Manager ว่า Event ที่ส่งมาถูกจัดเป็น Deduplicated หรือไม่ ถ้าเห็นว่า Event ถูก Deduplicate ไปแล้วแต่ทีมคาดว่าควรเห็นเป็น Event แยก แสดงว่า Event ID ที่ตั้งไว้อาจตรงกันโดยไม่ได้ตั้งใจ ต้องกลับไปตรวจ Logic การสร้าง Event ID ทั้งฝั่ง Pixel และ CAPI ให้สอดคล้องกับสิ่งที่ต้องการจริง

ปัจจัยที่ส่งผลต่อ Event Match Quality

Event Match Quality คือคะแนนที่ Meta ให้กับความสามารถในการจับคู่ Event กับผู้ใช้จริง ยิ่งมี Identifier ที่ตรงกันมากเท่าไร คะแนนก็ยิ่งสูงขึ้น

Identifier	ผลต่อ Match Quality	ข้อควรระวัง
Click ID (fbclid)	ช่วยจับคู่ได้แม่นเมื่อมาจากคลิกโฆษณาโดยตรง	หายง่ายถ้าไม่เก็บก่อนออกจากหน้าเว็บ
Email / Phone (Hashed)	เสริมคุณภาพเมื่อ Click ID ไม่มี	ต้อง Normalize ก่อน Hash ตามรูปแบบที่ Meta กำหนด
IP Address / User Agent	ช่วยยืนยันบริบทของ Event	ต้องเป็นค่าจริงของผู้ใช้ ไม่ใช่ของเซิร์ฟเวอร์
External ID	ช่วยผูก Event กับ Lead ID ภายในระบบ	ต้องสอดคล้องกันทั้ง Pixel และ CAPI

ลำดับการไล่ตรวจเมื่อ Event ไม่ขึ้นทั้งที่ Test ผ่าน

เมื่อเจอสถานการณ์แบบนี้ ควรไล่ตรวจตามลำดับต่อไปนี้แทนที่จะรื้อโค้ดทั้งหมดทันที เพื่อหาจุดที่แท้จริงก่อนแก้ไข

ตรวจ Event Match Quality ใน Events Manager ว่า Event ที่ส่งมาได้คะแนนเท่าไร และ Identifier ตัวไหนที่ขาดหายไปบ่อยที่สุด
ตรวจว่า Action Source ที่ส่งมาตรงกับบริบทจริงของ Event นั้นหรือไม่ โดยเทียบกับเอกสารล่าสุดของ Meta
ตรวจว่า Event ถูก Deduplicate ไปแล้วหรือไม่ ผ่านการดู Log ของทั้งฝั่ง Pixel และ CAPI ว่ามี Event ID ซ้ำกันโดยไม่ตั้งใจหรือไม่
ตรวจ Timestamp ของ Event ว่าห่างจากเวลาจริงเกินขอบเขตที่ Meta ยอมรับหรือไม่ เพราะ Event ที่ส่งช้าเกินไปอาจถูกปฏิเสธ
ถ้ายังไม่พบสาเหตุ ให้ลองส่ง Event ใหม่ที่มี Identifier ครบที่สุดเท่าที่ทำได้ เพื่อแยกว่าปัญหาคือ Identifier ไม่พอ หรือเป็นปัญหาที่ Field อื่นของ Event

ทำไมยอดใน Ads Manager ยังไม่ตรงกับยอดขายจริงแม้ Event ขึ้นแล้ว

แม้ Event จะขึ้นใน Events Manager ถูกต้องแล้ว ก็ยังมีความเป็นไปได้ที่ยอดใน Ads Manager จะไม่ตรงกับยอดขายจริงในระบบบัญชี เพราะ Ads Manager นับ Conversion ตาม Attribution Model ที่ตั้งไว้ ซึ่งอาจให้เครดิตกับแคมเปญที่ต่างจากที่ทีมคาดไว้ โดยเฉพาะเมื่อลูกค้าเห็นโฆษณาหลายชิ้นก่อนตัดสินใจซื้อ

อีกสาเหตุคือ Ads Manager นับ Conversion ตามเวลาที่ Event เกิดขึ้นจริง ไม่ใช่เวลาที่ทีมดูรายงาน ทำให้ตัวเลขของวันล่าสุดมักดูต่ำกว่าความจริงเพราะ Event บางส่วนยังไม่ถูกส่งเข้าระบบ ต้องรอสองสามวันให้ข้อมูลนิ่งก่อนเปรียบเทียบกับยอดขายจริง ไม่ควรสรุปจากตัวเลขของวันที่เพิ่งผ่านไปทันที

user_data ควรส่งพารามิเตอร์ไหนบ้าง แล้วต้อง Hash/Normalize อย่างไรก่อนอัปโหลด

หลายทีมโฟกัสที่การส่ง Event ให้ครบ แต่ลืมว่าคุณภาพของ Object user_data ต่างหากที่กำหนดว่า Meta จะจับคู่ Event กับผู้ใช้จริงได้แม่นแค่ไหน พารามิเตอร์ที่ใช้บ่อยที่สุดเมื่อธุรกิจส่ง Event จากฝั่งระบบขายหลังลูกค้าทักเข้า LINE ได้แก่ Email, เบอร์โทร, External ID ที่ผูกกับ Lead ในระบบ, IP Address และ User Agent ของอุปกรณ์ที่ผู้ใช้ใช้ตอนเกิดเหตุการณ์ต้นทาง รวมถึง Click ID อย่าง fbclid ที่เก็บไว้ตั้งแต่หน้าเว็บถ้ามี

ก่อน Hash ต้อง Normalize ให้ตรงรูปแบบที่ Meta กำหนดก่อนเสมอ ไม่ใช่ Hash ค่าที่ได้มาดิบ ๆ เช่น Email ต้องแปลงเป็นตัวพิมพ์เล็กทั้งหมดและตัดช่องว่างหัวท้ายออกก่อน ส่วนเบอร์โทรต้องตัดอักขระที่ไม่ใช่ตัวเลขออกให้หมด แล้วใส่รหัสประเทศนำหน้าตามมาตรฐานสากล เช่น เบอร์ไทยต้องขึ้นต้นด้วย 66 ไม่ใช่ 0 ถ้า Normalize ผิดตั้งแต่ต้น ต่อให้ Hash ด้วยอัลกอริทึมที่ถูกต้อง ค่าที่ได้ก็จะไม่ตรงกับที่ Meta เก็บไว้ฝั่งเขา และ Event นั้นจะจับคู่ไม่ได้เงียบ ๆ โดยไม่มี Error แจ้งเตือน

การ Hash เองต้องใช้ SHA-256 กับค่าที่ Normalize แล้วทีละ Field ห้าม Hash ทั้ง Object รวมกันเป็นก้อนเดียว เพราะ Meta คาดหวังค่า Hash แยกรายฟิลด์เพื่อนำไปเทียบกับข้อมูลที่ผู้ใช้เคยให้ไว้กับแพลตฟอร์ม และไม่ควรส่งข้อมูลที่ไม่เกี่ยวกับการจับคู่ตัวตน เช่น เนื้อหาการสนทนาในแชทหรือรายละเอียดคำสั่งซื้อ ไปปนอยู่ใน user_data เด็ดขาด เพราะนอกจาก Meta จะไม่ใช้ข้อมูลเหล่านี้ในการจับคู่แล้ว ยังเป็นความเสี่ยงด้านความเป็นส่วนตัวที่ไม่จำเป็น

Field	ต้อง Normalize อย่างไรก่อน Hash	ข้อควรระวัง
Email	ตัวพิมพ์เล็กทั้งหมด ตัดช่องว่างหัวท้าย	ห้ามส่ง Email สำรองที่ไม่ได้ใช้งานจริง
เบอร์โทร	ตัดอักขระที่ไม่ใช่ตัวเลข ใส่รหัสประเทศนำหน้า	เบอร์ที่ไม่มีรหัสประเทศทำให้ Match Rate ตก
External ID	ใช้ Lead ID/Customer ID ภายในระบบตรง ๆ ไม่ต้อง Hash	ต้องเป็นค่าเดียวกับที่ผูกไว้ฝั่ง Pixel
Client IP / User Agent	ส่งค่าจริงของอุปกรณ์ผู้ใช้ ไม่ Hash	ห้ามส่งค่าของเซิร์ฟเวอร์ธุรกิจแทน

เมื่อจำนวน Event จาก Pixel กับจาก Server ไม่เท่ากัน ควรไล่ดูจุดไหนก่อน

Events Manager มีมุมมองที่แยกแหล่งที่มาของ Event ให้เห็นว่าตัวไหนมาจาก Browser (Pixel) และตัวไหนมาจาก Server (CAPI) ทีมที่เพิ่งเริ่มใช้ทั้งสองทางพร้อมกันมักตกใจเมื่อเห็นตัวเลขสองฝั่งไม่เท่ากัน ทั้งที่ควรจะเป็น Event เดียวกันที่ถูก Deduplicate จนเหลือหนึ่งเดียว ความจริงคือตัวเลขสองฝั่งไม่จำเป็นต้องเท่ากันเป๊ะเสมอไป เพราะมันสะท้อนพฤติกรรมของผู้ใช้ที่ต่างกัน

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

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

ทำไมทิ้ง Test Event Code ค้างไว้ในโค้ด Production ถึงอันตรายกว่าที่คิด

ตอนพัฒนา ทีมส่วนใหญ่ใส่ test_event_code ไปกับ Event ที่ส่งเพื่อให้เห็นผลทันทีในแท็บ Test Events ของ Events Manager ปัญหาเกิดขึ้นเมื่อโค้ดชุดนี้ถูก Deploy ขึ้น Production โดยไม่มีใครลบออก เพราะ Event ที่แนบ Test Event Code จะไม่ถูกนำไปใช้ Optimize แคมเปญจริง ต่อให้ Event นั้นมี Identifier ครบและจับคู่ได้ดีแค่ไหนก็ตาม ทีมจึงเห็นตัวเลขใน Test Events สวยงาม แต่แคมเปญกลับไม่ดีขึ้นเลย และมักเข้าใจผิดว่าปัญหาอยู่ที่การตั้งค่า Bidding แทนที่จะสงสัยโค้ดที่ยังไม่ได้ทำความสะอาด

อีกความเสี่ยงที่มองข้ามบ่อยคือการใช้ Access Token หรือ Dataset เดียวกันทั้งฝั่งทดสอบและฝั่งใช้งานจริง ทำให้เวลาทีมพัฒนาทดสอบฟีเจอร์ใหม่บนระบบจริงโดยไม่ตั้งใจ Event ทดสอบเหล่านั้นจะปนเข้าไปในข้อมูลที่ใช้ตัดสินใจทางธุรกิจ แนวทางที่ปลอดภัยกว่าคือแยกสภาพแวดล้อมทดสอบออกจากทราฟฟิกจริงให้ชัดเจน เช่น ใช้ Test Event Code เฉพาะตอนรันบน Staging หรือเครื่องพัฒนาเท่านั้น และมีขั้นตอนตรวจสอบก่อนปล่อยขึ้น Production ทุกครั้งว่าไม่มีค่านี้หลงเหลืออยู่ในโค้ดที่รันกับผู้ใช้จริง

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

ในทางปฏิบัติควรระบุใน Privacy Notice ให้ชัดว่าข้อมูลบางส่วนอาจถูกส่งต่อในรูปแบบที่ผ่านการเข้ารหัสไปยังแพลตฟอร์มโฆษณาเพื่อวัตถุประสงค์การวัดผล พร้อมกำหนดระยะเวลาการเก็บรักษาข้อมูลที่ใช้สำหรับ Matching และมีช่องทางให้เจ้าของข้อมูลขอให้ลบหรือหยุดใช้ข้อมูลของตนได้ ธุรกิจยังต้องจำกัดสิทธิ์การเข้าถึงข้อมูลดิบก่อน Hash ให้เฉพาะทีมที่จำเป็นเท่านั้น และไม่ควรเก็บข้อมูลดิบเหล่านี้ไว้นานเกินความจำเป็นของกระบวนการส่ง Event

ทำแบบนี้แล้วพัง เพราะ… รวมรูปแบบพลาดที่พบบ่อยเวลาตั้ง CAPI เอง

นอกจากปัญหาที่ลึกอย่าง Action Source หรือ Deduplication ยังมีความผิดพลาดพื้นฐานที่ทำให้ระบบดูเหมือนพังทั้งที่จริงแล้วเกิดจากรายละเอียดเล็ก ๆ ตารางนี้รวมรูปแบบที่พบบ่อยจากทีมที่เพิ่งเริ่มตั้ง server side Meta CAPI LINE เอง เพื่อให้เช็กย้อนกลับไปได้เร็วขึ้นเมื่อเจอปัญหาคล้ายกัน

ทำแบบนี้	พังยังไง	สาเหตุที่แท้จริง
Hash ทั้ง Object รวมกันเป็นก้อนเดียว	Match Rate ต่ำผิดปกติ	Meta ต้องการค่า Hash แยกรายฟิลด์ ไม่ใช่ก้อนเดียว
ลืมลบ test_event_code ก่อนขึ้น Production	Event ไม่ถูกใช้ Optimize ทั้งที่ดูขึ้นปกติ	Event ที่แนบ Test Event Code ไม่ถูกนับเป็น Conversion จริง
ใช้ Event ID ซ้ำกันข้าม Event คนละความหมาย	เห็น Event น้อยกว่าจริงในรายงาน	Meta มองว่าเป็น Event เดียวกันแล้ว Deduplicate ทิ้ง
ส่ง Timestamp ผิด Time Zone ของเซิร์ฟเวอร์	Event บางส่วนหายไปเงียบ ๆ	Event ที่ Timestamp ห่างจากเวลาจริงเกินขอบเขตอาจถูกปฏิเสธ

สรุป

Event ที่ผ่าน Test Events แล้วแต่ไม่ขึ้นใน Events Manager จริง ไม่ได้แปลว่าโค้ดผิดทั้งหมดเสมอไป ส่วนใหญ่ปัญหาซ่อนอยู่ที่ Action Source ไม่ตรงบริบท Deduplication ที่กรอง Event ทิ้งไปเงียบ ๆ หรือ Event Match Quality ที่ต่ำจนแพลตฟอร์มไม่นับเป็น Conversion ที่มีคุณภาพพอ

การไล่ตรวจอย่างเป็นระบบตามลำดับ Action Source, Deduplication และ Identifier ที่ส่งไป ช่วยหาสาเหตุจริงได้เร็วกว่าการรื้อโค้ดทั้งหมดแล้วเขียนใหม่ตั้งแต่ต้น ซึ่งมักไม่ใช่ทางแก้ที่ตรงจุด

Test Events ตรวจแค่รูปแบบข้อมูล ไม่ได้ตรวจว่า Event จะถูกนับเป็น Conversion จริง
Action Source ที่ไม่ตรงบริบทเป็นสาเหตุที่พบบ่อยที่สุดของ Event ที่หายไปเงียบ ๆ
Deduplication ที่ตั้งผิดอาจกรอง Event ทิ้งโดยไม่มี Error แจ้งเตือน
ยอดใน Ads Manager อาจไม่ตรงกับยอดขายจริงแม้ Event ขึ้นแล้ว เพราะ Attribution Model และเวลาที่ข้อมูลนิ่ง

คำถามที่พบบ่อย

Test Events ผ่านแล้วแปลว่า CAPI ทำงานถูกต้อง 100 เปอร์เซ็นต์หรือไม่

ไม่ใช่ Test Events ตรวจแค่รูปแบบข้อมูลว่าถูกต้องตามโครงสร้างหรือไม่ ไม่ได้ตรวจ Event Match Quality, Deduplication หรือว่า Event จะถูกนับเป็น Conversion ที่ใช้ Optimize ได้จริงหรือไม่

ต้องใช้ Pixel คู่กับ CAPI เสมอไปหรือไม่

ไม่จำเป็นเสมอไป แต่ Meta แนะนำให้ใช้คู่กันเพื่อเพิ่มโอกาสจับคู่ Event ถ้าใช้คู่กัน ต้องตั้ง Event ID ให้ตรงกันเพื่อให้ Deduplication ทำงานถูกต้อง ไม่นับ Event ซ้ำ

Event Match Quality ควรอยู่ระดับไหนถึงจะถือว่าดี

ไม่มีตัวเลขตายตัวที่ใช้ได้กับทุกธุรกิจ ควรดูแนวโน้มเทียบกับช่วงก่อนหน้าของตัวเอง และพยายามเพิ่ม Identifier ที่ส่งไปให้ครบที่สุดเท่าที่ทำได้ตามข้อมูลที่มีจริง

ทำไม Event บางตัวขึ้นช้ากว่า Event อื่น

เกิดได้จากหลายสาเหตุ เช่น ระบบฝั่งธุรกิจส่งข้อมูลล่าช้าจากคิวประมวลผล หรือ Meta ใช้เวลาประมวลผล Event บางประเภทนานกว่า ควรรอให้ข้อมูลนิ่งสองสามวันก่อนสรุปว่า Event หายไปจริง

ควรส่งข้อมูลส่วนบุคคลแบบไหนไปช่วย Match ได้บ้าง

ควรส่งเฉพาะข้อมูลที่ผ่านการ Hash ตามรูปแบบที่ Meta กำหนด เช่น อีเมลหรือเบอร์โทรที่ Normalize แล้ว ไม่ควรส่งข้อมูลดิบหรือข้อมูลที่ละเอียดอ่อนอย่างเนื้อหาการสนทนาไปด้วย

ธุรกิจที่ใช้ linli ต้องตั้งค่า CAPI เองทั้งหมดหรือไม่

ขึ้นอยู่กับ Integration ที่เปิดใช้งานและการตั้งค่า Credential ของแต่ละบัญชี ธุรกิจยังต้องตรวจสอบ Event Mapping และ Conversion ที่ต้องการส่งกลับให้ตรงกับ Conversion Action ที่ตั้งไว้ในบัญชีโฆษณาของตัวเอง

ลองตรวจด้วยตัวเอง