ส่งข้อมูล CRM กลับ Meta: ให้แอดหาคนที่ซื้อจริง ไม่ใช่แค่คนกรอกฟอร์ม (คู่มือ B2B 2026)

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

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

ทำไมตั้งแอดให้หา "Lead" แล้วได้ลีดถูก แต่ไม่ค่อยมีคนซื้อ

เพราะ Meta หาคนตามเหตุการณ์ที่เราสั่งให้หา ถ้าเราบอกว่าเป้าหมายคือเหตุการณ์ Lead ระบบก็จะหาคนที่มีแนวโน้มกรอกฟอร์มมากที่สุดในราคาถูกที่สุด ระบบไม่รู้ว่าคนที่กรอกแล้วรับสายไหม มีงบไหม หรือกรอกเบอร์มั่ว ๆ มา ในมุมของ Meta ลีดทุกคนเท่ากันหมด

งาน B2B เจอปัญหานี้หนักกว่างานขายของออนไลน์ เพราะระยะจากกรอกฟอร์มถึงปิดการขายยาวหลายสัปดาห์หรือหลายเดือน และลีดส่วนใหญ่ไม่ได้ไปถึงขั้นซื้อ ตัวอย่างจากเว็บเราเอง ตอนนำลีดจากฟอร์มบนเว็บ 18 รายแรก (ตั้งแต่ 14 ส.ค. 2569) เข้า Pipeline เราเจอลีดใหม่ที่ใช้ได้จริง 7 ราย ลีดซ้ำ 1 ราย และอีก 10 รายใช้ไม่ได้ เช่น ทดสอบระบบ สแปม หรือกรอกไม่ครบ ถ้าวัดแค่จำนวน Lead ตัวเลขจะดูดีกว่าความจริงเกือบเท่าตัว และ Meta ก็จะเรียนรู้จากคนกลุ่มที่ใช้ไม่ได้ไปด้วย

ตัวเลข 18 รายเป็นตัวอย่างเล็ก ๆ ใช้สรุปเป็นสถิติไม่ได้ แต่พอให้เห็นว่าทำไมต้องส่งคุณภาพลีดกลับไป ไม่ใช่ส่งแค่จำนวน

ส่งสถานะลีดจาก CRM กลับ Meta ทำงานยังไง

หลักการคือทำให้ลีดใน CRM ผูกกับคนที่ Meta รู้จักให้ได้ แล้วทุกครั้งที่ฝ่ายขายเปลี่ยนสถานะลีด ระบบจะส่งเหตุการณ์ใหม่ไปหา Meta ผ่าน Conversions API (CAPI) ลำดับงานเป็นแบบนี้

1. ลีดเข้ามาพร้อมตัวระบุตัวตน ตอนกรอกฟอร์ม เราเก็บอีเมล เบอร์โทร ค่า cookie _fbp และ _fbc (ซึ่งมาจาก fbclid ในลิงก์โฆษณา) ไว้กับลีด ถ้าเป็นฟอร์มในแอด (Instant Form) จะมี Lead ID ของ Meta ให้เก็บแทน
2. ลีดถูกส่งเข้า CRM อัตโนมัติ พร้อมข้อมูลที่มา เช่น แคมเปญ ชุดโฆษณา ตัวโฆษณา
3. ฝ่ายขายอัปเดตสถานะตามงานจริง เช่น โทรคุยแล้ว ส่งใบเสนอราคาแล้ว ปิดได้ หรือไม่ซื้อ
4. เซิร์ฟเวอร์ส่งเหตุการณ์ไปหา Meta เฉพาะสถานะที่เรากำหนดไว้ พร้อมข้อมูลผู้ใช้ที่ hash แล้ว และ event_id ที่กันการนับซ้ำ
5. Meta จับคู่เหตุการณ์กับคนที่เห็นหรือคลิกแอด แล้วนำไปใช้ทั้งในรายงานและในการหาคนกลุ่มใหม่ ถ้าเราตั้งแคมเปญให้หาเหตุการณ์นั้น

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

Conversion Leads ของ Meta คืออะไร ใช้กับฟอร์มบนเว็บได้ไหม

Conversion Leads เป็นเป้าหมายประสิทธิภาพ (performance goal) ของ Meta ที่ให้แอดหาคนที่มีแนวโน้มไปถึงสถานะที่เราเลือกใน CRM ไม่ใช่แค่คนที่กรอกฟอร์ม แต่ตามเอกสารของ Meta ตอนนี้เป้าหมายนี้ใช้ได้กับโฆษณาแบบ Lead Ads (Instant Form) บน Facebook และ Instagram เท่านั้น ใช้กับฟอร์มบนเว็บตรง ๆ ไม่ได้

เงื่อนไขที่ Meta เขียนไว้ใน เอกสาร Conversions API for CRM (ตรวจเมื่อ 27 ก.ย. 2569) มีดังนี้

เงื่อนไข	ค่าที่ Meta กำหนด	ความหมายในงานจริง
จำนวนลีด	อย่างน้อย 200 ลีดต่อเดือน	ธุรกิจ B2B ขนาดเล็กหลายรายยังไม่ถึง
อัตราไปถึงสถานะที่เลือก	1% ถึง 40% ของลีด	เลือกสถานะที่ไม่ง่ายเกินไปและไม่ยากเกินไป
ระยะเวลา	สถานะนั้นต้องเกิดภายใน 28 วันหลังได้ลีด	ถ้าปิดการขายใช้เวลา 3 เดือน ให้เลือกสถานะก่อนหน้า เช่น ส่งใบเสนอราคา
ความถี่ในการส่ง	อย่างน้อยวันละครั้ง	ส่งทันทีตอนเปลี่ยนสถานะจะดีที่สุด
รูปแบบข้อมูล	action_source = system_generated, custom_data.event_source = crm, ใส่ lead_event_source เป็นชื่อ CRM และแนะนำให้ส่ง lead_id	ชื่อ event ตั้งเป็นชื่อสถานะใน CRM ได้เลย

รายละเอียดรูปแบบข้อมูลอยู่ในหน้า Payload Specification ซึ่งบอกด้วยว่าควรส่งทุกสถานะที่เปลี่ยน รวมทั้งสถานะลีดแรก และ event_time ย้อนหลังได้ไม่เกิน 7 วัน

ถ้าลีดมาจากฟอร์มบนเว็บ ทำอะไรได้บ้าง

ลีดจากเว็บก็ส่งสถานะกลับได้ แต่ส่งเข้าไปเป็นเหตุการณ์ปกติใน dataset เดียวกับ Pixel ใช้ Purchase ซึ่งเป็น standard event สำหรับการปิดการขาย และใช้ custom event สำหรับสถานะอื่น จากนั้นถ้าจะให้แคมเปญหาเหตุการณ์ไหน ก็เลือกเหตุการณ์นั้นเป็น conversion event ของชุดโฆษณา หรือสร้าง custom conversion จากเหตุการณ์นั้นก่อน (บัญชีโฆษณาหนึ่งสร้าง custom conversion ได้สูงสุด 100 รายการ)

ข้อที่ต้องยอมรับคือทางนี้ไม่มีโมเดลเฉพาะแบบ Conversion Leads มาช่วย Meta จะใช้เหตุการณ์ที่เราส่งเหมือนเหตุการณ์ทั่วไป ผลจึงขึ้นกับจำนวนเหตุการณ์ที่ส่งไปล้วน ๆ Meta แนะนำไว้ใน หน้าอธิบาย learning phase ว่าชุดโฆษณาควรมีเหตุการณ์ที่ใช้ optimize ประมาณ 50 ครั้งหลังแก้ไขครั้งใหญ่ล่าสุด ต้นทุนถึงจะนิ่ง ถ้าเดือนหนึ่งปิดการขายได้ 5 ดีล การตั้งแคมเปญให้หา Purchase ตรง ๆ แทบจะไม่มีวันออกจาก learning phase

ควรส่งกี่สถานะ ทำไมเราเลือกแค่ 3

เราส่งแค่ 3 สถานะ เพราะชุดโฆษณาหนึ่งชุดเลือกเหตุการณ์ที่จะ optimize ได้ทีละเหตุการณ์ ถ้าเราแตก CRM เป็น 6–7 ขั้นแล้วส่งเป็นเหตุการณ์คนละชื่อทั้งหมด แต่ละเหตุการณ์จะมีจำนวนน้อยจนไม่พอให้ระบบเรียนรู้ สัญญาณกระจายออกไปหลายชื่อแทนที่จะรวมกันเป็นก้อนเดียว

3 สถานะที่เราเลือกมีหน้าที่ต่างกันชัดเจน

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

ชื่อ Potential กับ NotPotential เป็นชื่อที่เราตั้งเอง ไม่ใช่ชื่อที่ Meta กำหนด ส่วน NotPotential ผมขอบอกตรง ๆ ว่ายังไม่เจอเอกสารของ Meta ที่ยืนยันว่าระบบจะใช้เหตุการณ์ "ไม่ซื้อ" เพื่อหลบคนกลุ่มนั้นโดยอัตโนมัติ ตอนนี้เราใช้มันเพื่อรายงานของเราเองเป็นหลัก

ตาราง mapping สถานะ CRM เป็นเหตุการณ์ที่ส่ง Meta

นี่คือตารางที่เราใช้จริงกับ Pipeline ของเรา ธุรกิจอื่นชื่อสถานะอาจต่างกัน แต่หลักคิดเหมือนกัน คือรวมหลายสถานะที่ความหมายใกล้กันให้เป็นเหตุการณ์เดียว

สถานะใน CRM	เหตุการณ์ที่ส่ง Meta	ส่งกี่ครั้ง	เหตุผล
new (ลีดใหม่)	ไม่ส่ง	-	ตอนลีดเข้า เว็บส่งเหตุการณ์ Lead ไปแล้ว
contacted (ติดต่อแล้ว)	ไม่ส่ง	-	ยังไม่รู้ว่าลีดดีหรือไม่ดี
qualified (มีแวว)	Potential	ครั้งเดียวต่อลีด	จุดแรกที่ฝ่ายขายยืนยันว่าลีดใช้ได้
proposal (ส่งใบเสนอราคา)	Potential	ไม่ส่งซ้ำถ้าเคยส่งแล้ว	ความหมายใกล้กับ qualified รวมเป็นเหตุการณ์เดียวจะได้จำนวนมากขึ้น
won (ปิดการขาย)	Purchase + มูลค่าเป็นบาท	ครั้งเดียวต่อลีด	ผลลัพธ์ที่ธุรกิจต้องการจริง
lost (ไม่ซื้อ)	NotPotential	ครั้งเดียวต่อลีด	เก็บสัญญาณด้านลบไว้วิเคราะห์
nurture (ติดตามระยะยาว)	ไม่ส่ง	-	ยังไม่มีข้อสรุป
ลีดซ้ำ / ใช้งานไม่ได้	ไม่ส่ง	-	ไม่ใช่ลูกค้าคนใหม่ ส่งไปจะทำให้สัญญาณเพี้ยน

ลีดที่ไปจาก qualified ถึง proposal จะส่ง Potential แค่ครั้งแรก ถ้าส่งทั้ง 2 ครั้ง ลีดคนเดียวจะนับเป็นลีดมีแวว 2 คน และแคมเปญที่ตั้งให้หา Potential ก็จะคิดว่าได้ผลดีกว่าความจริง

ใส่มูลค่าดีลให้เหตุการณ์ Purchase ยังไง

ใส่ใน custom_data เป็นตัวเลข value คู่กับ currency ที่เป็น THB เราดึงค่านี้จากช่อง "มูลค่าโอกาส" ของลีดใน CRM ซึ่งฝ่ายขายกรอกไว้ตอนคุยงาน

{
  "event_name": "Purchase",
  "event_time": 1790000000,
  "event_id": "crm-<รหัสลีด>-Purchase",
  "user_data": {
    "em": ["<อีเมลที่ hash ด้วย SHA-256>"],
    "ph": ["<เบอร์โทรที่ hash ด้วย SHA-256>"],
    "fbp": "<ค่า _fbp ที่เก็บไว้ตอนลีดเข้า>",
    "fbc": "<ค่า _fbc ที่เก็บไว้ตอนลีดเข้า>"
  },
  "custom_data": {
    "value": 150000,
    "currency": "THB"
  }
}

โค้ดข้างบนเป็นตัวอย่างเพื่ออธิบายโครงสร้าง ตัวเลขและค่าในวงเล็บเป็นค่าสมมติ มีข้อควรระวัง 3 ข้อเรื่องมูลค่า

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

1. 1สถานะ = จุดที่ยิงเหตุการณ์เซลส์กดเปลี่ยนสถานะที่นี่ ถ้าเป็นมีแนวโน้ม เสนอราคา ปิดการขาย หรือไม่สำเร็จ เซิร์ฟเวอร์จะส่งเหตุการณ์ไป Meta ทันที
2. 2มูลค่าโอกาส = value ของ Purchaseตัวเลขนี้คือมูลค่าที่ส่งไปตอนปิดการขาย แก้ให้ตรงกับยอดที่ตกลงจริงก่อนกดปิดการขาย
3. 3ที่มา = ลีดจากเว็บหรือไม่มีคำว่าฟอร์มเว็บไซต์กับค่า UTM แปลว่ามีข้อมูลให้ Meta จับคู่ ลีดที่ไม่ได้มาจากเว็บจะไม่ถูกส่ง
4. 4ส่งกลับ Meta แล้ว = บันทึกกันส่งซ้ำเหตุการณ์ไหนส่งไปแล้วจะขึ้นที่นี่พร้อมเวลา ครั้งหน้าที่สถานะวนกลับมา ระบบจะข้ามไป

ลีดนี้ส่ง Potential ไปแล้วตอนเสนอราคา ถ้าเซลส์กดปิดการขาย ระบบจะส่ง Purchase มูลค่า 150,000 บาทเพิ่มอีกครั้งเดียว

กันไม่ให้ส่งเหตุการณ์เดียวกันซ้ำ

ต้องทำ 2 ชั้น คือตั้ง event_id ให้คงที่ และบันทึกในฐานข้อมูลของเราเองว่าส่งไปแล้ว ชั้นแรกอย่างเดียวไม่พอ

หลายคนเข้าใจว่าใส่ event_id เดิมแล้ว Meta จะตัดตัวซ้ำให้เสมอ แต่ใน เอกสารเรื่อง deduplication Meta เขียนไว้ว่าการตัดตัวซ้ำทำเฉพาะเหตุการณ์ที่มาจากเบราว์เซอร์กับเซิร์ฟเวอร์คู่กัน ภายใน 48 ชั่วโมง ถ้าส่งจากเซิร์ฟเวอร์อย่างเดียว 2 ครั้ง Meta จะไม่ทิ้งตัวไหนเลย เหตุการณ์จาก CRM ส่งจากเซิร์ฟเวอร์อย่างเดียวทั้งหมด จึงต้องกันซ้ำเอง

1. ตั้ง event_id แบบคงที่ สร้างจากรหัสลีดบวกชื่อเหตุการณ์ เช่น crm-<รหัสลีด>-Potential ไม่ว่าจะส่งกี่รอบ ลีดเดิมกับเหตุการณ์เดิมจะได้ id เดิมเสมอ
2. บันทึกผลการส่ง พอ Meta ตอบกลับว่ารับแล้ว ให้บันทึกไว้กับลีดว่าเหตุการณ์นี้ส่งแล้ว ครั้งหน้าที่สถานะเปลี่ยนกลับไปกลับมา ระบบจะเห็นว่าส่งไปแล้วและข้ามไป
3. ส่งตอนเปลี่ยนสถานะ อย่ารอส่งรวดเดียวตอนปลายเดือน เพราะ event_time ย้อนหลังได้ไม่เกิน 7 วัน

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

1. 1FEEDBACK_EVENT = ตาราง mappingสถานะที่ไม่อยู่ในตารางนี้ เช่น ใหม่ ติดต่อแล้ว ลีดซ้ำ จะไม่ถูกส่งเลย
2. 2isWebLead = ส่งเฉพาะลีดจากเว็บลีดที่เพิ่มเองหรือมาจากช่องทางอื่นไม่มีข้อมูลให้จับคู่ จึงหยุดตั้งแต่บรรทัดนี้
3. 3meta_feedback = เคยส่งแล้วหรือยังชั้นกันซ้ำที่เราทำเอง เพราะ Meta ไม่ตัดเหตุการณ์ซ้ำที่มาจากเซิร์ฟเวอร์อย่างเดียว
4. 4event_id = รหัสคงที่สร้างจากรหัสลีดกับชื่อเหตุการณ์ ส่งกี่รอบก็ได้ค่าเดิม
5. 5action_source = system_generatedบอก Meta ว่าเหตุการณ์นี้มาจากระบบของเรา ไม่ได้เกิดบนหน้าเว็บ
6. 6custom_data = ชื่อ CRM และมูลค่าใส่ชื่อ CRM ใน lead_event_source และมูลค่าจากช่องมูลค่าโอกาสเป็นบาท

ข้อ 3 กับข้อ 4 ต้องมีคู่กัน ข้อ 4 ทำให้รหัสไม่เปลี่ยน ส่วนข้อ 3 ทำให้ไม่ส่งซ้ำตั้งแต่ต้น

ลีดซ้ำกับลีดที่ใช้ไม่ได้ ควรทำอะไร

ควรแยกเป็นสถานะของตัวเองใน CRM และไม่ส่งกลับไปหา Meta เลย ใน Pipeline ของเราเพิ่ม 2 สถานะนี้เข้าไปโดยเฉพาะ

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

ทั้ง 2 สถานะถูกตัดออกจากรายงานใน CRM ด้วย ไม่อย่างนั้นอัตราปิดการขายจะต่ำกว่าความจริง และต้นทุนต่อลีดจะดูถูกกว่าความจริง ข้อนี้กลับไปที่ตัวเลข 18 รายข้างบน ถ้าไม่แยก 11 รายที่เป็นลีดซ้ำและใช้ไม่ได้ออก เราจะเข้าใจผิดว่าแอดได้ลีดดีกว่าที่เป็นจริงมาก

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

ความเป็นส่วนตัว: hash ข้อมูลและ PDPA

อีเมลกับเบอร์โทรต้อง hash ด้วย SHA-256 หลังจัดรูปแบบให้เป็นมาตรฐานก่อนส่ง เช่น อีเมลตัวพิมพ์เล็กทั้งหมดและตัดช่องว่าง เบอร์โทรใส่รหัสประเทศและเหลือแต่ตัวเลข Meta จะนำค่าที่ hash แล้วไปจับคู่กับบัญชีผู้ใช้ ไม่ได้รับอีเมลตัวจริงจากเรา

แต่ hash แล้วไม่ได้แปลว่าพ้นจาก PDPA ค่าที่ hash ยังชี้กลับไปหาตัวบุคคลได้เมื่อจับคู่กับข้อมูลอื่น ความเห็นของผมคือควรทำอย่างน้อย 3 อย่างนี้ (ส่วนการตีความทางกฎหมายควรถามที่ปรึกษาด้านกฎหมายของบริษัท)

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

Google Ads มีระบบแบบเดียวกันไหม

มี Google Ads มี 2 วิธีที่ทำหน้าที่ใกล้เคียงกัน

• Offline conversion import เก็บค่า GCLID จากลิงก์โฆษณาไว้กับลีด แล้วอัปโหลดกลับไปเมื่อลีดปิดการขาย
• Enhanced conversions for leads ตอนลีดกรอกฟอร์ม เว็บส่งอีเมลที่ hash แล้วไปให้ Google ก่อน พอลีดปิดการขายค่อยส่งอีเมลที่ hash แบบเดียวกันกลับไป Google จะจับคู่กับบัญชี Google ที่ล็อกอินอยู่ ตาม หน้าช่วยเหลือของ Google Ads วิธีนี้เสริมการนำเข้าด้วย GCLID และ Google ยังแนะนำให้ส่ง GCLID ไปด้วยทุกครั้งที่มี

ถ้ายิงโฆษณาทั้ง 2 แพลตฟอร์ม ควรออกแบบ mapping สถานะใน CRM ครั้งเดียวแล้วใช้ร่วมกัน สถานะที่ถือว่ามีแววหรือปิดการขายควรมีความหมายเหมือนกันทั้ง Meta และ Google ตัวเลขจะได้เทียบกันได้

ข้อจำกัดที่ควรรู้ก่อนเริ่ม

• ลีดน้อยก็ได้ประโยชน์น้อยในแง่การ optimize ถ้าเดือนหนึ่งมีลีดไม่กี่สิบราย การส่งสถานะกลับยังช่วยเรื่องรายงานกับการวิเคราะห์ได้เต็มที่ แต่อย่าคาดหวังว่าแอดจะฉลาดขึ้นทันที
• ขึ้นกับวินัยของทีมขาย ถ้าเซลส์ไม่อัปเดตสถานะ หรือปล่อยลีดค้างที่ contacted ไปตลอด ระบบก็ไม่มีอะไรส่ง
• จับคู่ไม่ได้ทุกลีด ลีดที่ไม่ได้มาจากแอด หรือเข้ามาโดยไม่มี cookie ของ Meta อาจจับคู่ไม่ได้ ตัวเลขใน Events Manager จะน้อยกว่าใน CRM เสมอ
• เปลี่ยนเป้าหมายแคมเปญแล้วเริ่ม learning phase ใหม่ ถ้าวันนี้ตั้งให้หา Lead แล้วพรุ่งนี้เปลี่ยนเป็น Potential ต้องเผื่อเวลาให้ระบบเรียนรู้ใหม่

เริ่มจากตรงไหนดี

ถ้ายังไม่มีอะไรเลย ผมแนะนำให้เริ่มจาก 3 อย่างตามลำดับ ติดตั้ง Pixel คู่กับ CAPI ให้ครบก่อน (อ่านเพิ่มได้ที่ คู่มือ Conversion API และ Pixel กับ CAPI ต่างกันยังไง และกันนับซ้ำ) จากนั้นให้ลีดทุกรายเข้า CRM พร้อมที่มา แล้วค่อยเพิ่มการส่งสถานะกลับเป็นขั้นสุดท้าย การวางภาพรวมทั้งเส้นทางตั้งแต่เห็นแอดจนปิดการขาย ดูได้ที่ คู่มือ Marketing Funnel

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