เคสจริง: M Creation วัดผลลีดจากแอด ตั้งแต่คลิกโฆษณาจนปิดการขาย

เว็บ m-creation.co วัดผลลีดจากแอดด้วย 4 ส่วนที่ต่อกัน คือเก็บที่มาของคนตั้งแต่คลิกแอด ส่งเหตุการณ์ผ่าน Meta Pixel คู่กับ Conversions API ส่งลีดเข้า CRM พร้อมที่มาอัตโนมัติ และส่งสถานะการขายกลับไปหา Meta เมื่อลีดมีแวว ปิดการขาย หรือไม่ซื้อ ระบบเปิดใช้จริงวันที่ 25–26 ก.ย. 2569

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

ทำไมเราทำระบบนี้กับเว็บตัวเองก่อน

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

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

ภาพรวมเส้นทางข้อมูล ตั้งแต่คลิกแอดจนปิดการขาย

1. คนคลิกแอด ลิงก์พาข้อมูลแคมเปญ ชุดโฆษณา ตัวโฆษณา และตำแหน่งที่แสดงมาใน URL
2. เว็บเก็บที่มาไว้ในเบราว์เซอร์ ทั้งหน้าแรกที่เข้ามาครั้งแรกและครั้งล่าสุด
3. ผู้ใช้ตอบแบนเนอร์ความยินยอม Pixel จะรอจนกว่าผู้ใช้ยินยอม
4. ผู้ใช้ทำสิ่งที่เราวัด ดูบริการ ดูราคา เปิดฟอร์มขอใบเสนอราคา กดติดต่อทาง LINE WhatsApp หรือโทร และส่งฟอร์ม
5. เหตุการณ์ออกไป 2 ทาง Pixel ในเบราว์เซอร์ และ Conversions API จากฟังก์ชัน serverless บน Cloudflare ใช้ event_id เดียวกัน
6. ลีดเข้า CRM อัตโนมัติ พร้อมข้อมูลที่มาทั้งหมดจากข้อ 2
7. ฝ่ายขายอัปเดตสถานะ ใน Pipeline ตามงานจริง
8. เซิร์ฟเวอร์ส่งสถานะกลับ Meta 3 จุด คือมีแวว ปิดการขาย และไม่ซื้อ

ตารางนี้สรุปว่าแต่ละเหตุการณ์เกิดที่ไหน ส่งจากไหน

เหตุการณ์	เกิดเมื่อ	ส่งจากเบราว์เซอร์	ส่งจากเซิร์ฟเวอร์
ViewContent / ดูราคา / เปิดฟอร์มใบเสนอราคา	ผู้ใช้ดูหน้าบริการ ดูตารางราคา หรือเปิดฟอร์ม	ใช่	ไม่
Contact	กดปุ่ม LINE, WhatsApp หรือโทร	ใช่	ใช่ เฉพาะเมื่อผู้ใช้ยินยอม
Lead	ส่งฟอร์มขอใบเสนอราคา (มี 3 จุดบนเว็บ)	ใช่	ใช่
Potential	เซลส์เปลี่ยนสถานะเป็น qualified หรือ proposal	ไม่	ใช่ ครั้งเดียวต่อลีด
Purchase	เซลส์เปลี่ยนสถานะเป็น won	ไม่	ใช่ พร้อมมูลค่าเป็นบาท
NotPotential	เซลส์เปลี่ยนสถานะเป็น lost	ไม่	ใช่ ครั้งเดียวต่อลีด

ขั้นที่ 1: เก็บที่มาตั้งแต่วินาทีแรกที่เข้าเว็บ

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

ค่าที่เก็บ	มาจากไหน	ใช้ทำอะไร
utm_source, utm_medium, utm_campaign, utm_content, utm_term	พารามิเตอร์ UTM ในลิงก์	แยกช่องทางและแคมเปญ ใช้ได้กับทุกแพลตฟอร์ม
fbclid	Meta ต่อท้ายลิงก์ให้เองเมื่อคนคลิกแอด	ใช้สร้างค่า fbc ให้ Meta จับคู่คนกับการคลิกได้แม่นขึ้น
ad_id, adset_id, campaign_id	พารามิเตอร์แบบ dynamic ของ Meta	รู้ว่าลีดมาจากแอดตัวไหน แม้จะเปลี่ยนชื่อแคมเปญทีหลัง
placement, site_source	พารามิเตอร์แบบ dynamic ของ Meta	แยกว่ามาจาก Feed, Stories, Reels หรือ Facebook กับ Instagram
หน้าแรกที่เข้า (first-touch) และหน้าล่าสุด (last-touch)	เว็บบันทึกเอง	เห็นว่าคนเริ่มจากบทความหรือหน้าบริการ และกลับมากรอกผ่านหน้าไหน

ในช่อง URL parameters ของโฆษณาบน Meta เราใส่ค่าแบบ dynamic เช่น {{ad.id}}, {{campaign.id}}, {{placement}} และ {{site_source_name}} Meta จะแทนค่าจริงให้ตอนคนคลิก เราเลือกใช้ ID แทนชื่อเป็นหลัก เพราะชื่อแคมเปญเปลี่ยนได้ตลอด แต่ ID ไม่เปลี่ยน

1. 1Website URL = ลิงก์หน้าปลายทางใส่ลิงก์เปล่า ๆ ไม่ต้องต่อพารามิเตอร์เอง ระบบจะต่อค่าจากช่องด้านล่างให้
2. 2utm_* = ชื่อที่คนอ่านออกแหล่ง ชื่อแคมเปญ และชื่อแอด ใช้ดูในรายงานได้ทันที และใช้ได้กับทุกแพลตฟอร์ม
3. 3ad_id, campaign_id = รหัสที่ไม่เปลี่ยนต่อให้ทีมแอดแก้ชื่อแคมเปญทีหลัง ลีดเก่ากับลีดใหม่ก็ยังผูกกับแคมเปญเดิม
4. 4placement = ตำแหน่งที่แสดงแยกว่าคนคลิกมาจาก Feed, Stories หรือ Reels

ใส่ชุดนี้ในทุกแอด ถ้าแอดไหนไม่ได้ใส่ ลีดจากแอดนั้นจะเข้า CRM แบบไม่มีที่มา

เหตุผลที่เก็บทั้ง first-touch และ last-touch คือธุรกิจ B2B คนมักเข้าเว็บหลายรอบก่อนติดต่อ บางคนเจอเราจากบทความ แล้วกลับมาอีกทีจากแอด ถ้าเก็บแค่ค่าเดียว เราจะให้เครดิตผิดฝั่งเสมอ

ทั้งหมดนี้ใช้กับแอดที่พาคนเข้าเว็บ ถ้าแอดพาคนไปโหลดแอปมือถือ พารามิเตอร์ใน URL กับ Pixel จะวัดไม่ได้ ต้องใช้ SDK หรือ MMP แทน ผมอธิบายไว้ในวิธีวัดผลแอดโปรโมทแอปด้วย SDK และ MMP

ขั้นที่ 2: Pixel คู่กับ Conversions API ด้วย event_id เดียว

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

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

ฝั่งเซิร์ฟเวอร์เป็นฟังก์ชัน serverless บน Cloudflare ส่งข้อมูลให้ Meta ดังนี้

• อีเมลและเบอร์โทรที่ hash แล้ว
• IP address และ user agent ของผู้ใช้
• ค่า fbp และ fbc จาก cookie ของ Meta

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

ขั้นที่ 3: ขอความยินยอมก่อนยิง Pixel

แบนเนอร์ขอความยินยอมตาม PDPA ของเรามี 4 ภาษา คือไทย อังกฤษ จีน และอาหรับ ตามภาษาที่เว็บรองรับ ตอนหน้าเว็บโหลด Pixel จะอยู่ในสถานะยังไม่ได้รับความยินยอม (ใช้คำสั่ง fbq('consent', 'revoke')) พอผู้ใช้กดยินยอมค่อยเปลี่ยนเป็น grant ส่วนเหตุการณ์ Contact ฝั่งเซิร์ฟเวอร์ ส่งเฉพาะเมื่อผู้ใช้ยินยอมแล้ว

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

ขั้นที่ 4: ลีดทุกรายเข้า CRM พร้อมที่มา

ลีดจากฟอร์มบนเว็บทุกรายถูกเก็บลงฐานข้อมูล และส่งต่ออัตโนมัติเข้า LeadReady ซึ่งเป็น CRM ในระบบหลังบ้าน m-crm ของเรา ค่าที่มาทั้งหมดจากขั้นที่ 1 ติดไปกับลีดด้วย ไม่ต้องมีใครก๊อปวาง

ใน CRM เราทำ 2 จุดให้ทีมเห็นที่มาของลีดโดยไม่ต้องเปิดดูทีละราย

• รายงาน "ที่มาลีด" เป็นแท็บแรกของหน้ารายงาน แยกลีดตามแหล่ง แคมเปญ และแอด
• แถบสรุปบน Pipeline เห็นภาพรวมที่มาของลีดที่อยู่ในแต่ละสถานะ

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

1. 1ที่มาลีด = แท็บแรกเปิดหน้ารายงานมาก็เจอเลย ไม่ต้องกดหลายชั้น
2. 2ตัวเลขสรุป = ภาพรวมก่อนลงรายละเอียดลีดจากเว็บ มาจากโฆษณากี่ราย ปิดการขายกี่ราย และต้นทุนต่อลีดของแอดที่มีลีด
3. 3แคมเปญ / แอด = มาจากแอดตัวไหนดึงจาก utm และ ad_id ที่เก็บไว้ตั้งแต่ขั้นที่ 1 ไม่ต้องมีใครกรอกเอง
4. 4คุณภาพผ่าน / ปิดได้ = ลีดดีจริงไหมเทียบกับคอลัมน์ลีด จะเห็นว่าแอดไหนได้ลีดเยอะแต่ไม่มีคุณภาพ

ลีดซ้ำและลีดใช้งานไม่ได้ถูกตัดออกจากทุกตัวเลขในหน้านี้ ตัวเลขจึงไม่เกินความจริง

ขั้นที่ 5: เพิ่มสถานะลีดซ้ำและใช้งานไม่ได้

Pipeline ของเรามีสถานะ new, contacted, qualified, proposal, won, lost และ nurture เราเพิ่ม 2 สถานะเข้าไปเพื่อแยกคุณภาพลีดโดยเฉพาะ

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

2 สถานะนี้ถูกตัดออกจากรายงานทั้งหมด เหตุผลที่ต้องเพิ่มชัดเจนมากตอนเรานำลีดจากฟอร์มบนเว็บ 18 รายแรก (ตั้งแต่ 14 ส.ค. 2569) เข้า Pipeline โดยใช้วันที่กรอกจริง ผลที่ได้คือ

ประเภท	จำนวน	สัดส่วน
ลีดใหม่ที่ใช้ได้	7	39%
ลีดซ้ำ	1	6%
ใช้งานไม่ได้ (ทดสอบ สแปม กรอกไม่ครบ)	10	56%
รวม	18	-

สัดส่วนปัดเศษ จึงรวมกันได้ 101% และลีดใช้งานไม่ได้บางส่วนเป็นการทดสอบของทีมเราเอง ตัวเลขนี้จึงไม่ได้บอกว่าแอดได้ลีดขยะครึ่งหนึ่ง แต่บอกว่าถ้านับทุกแถวเป็นลีด รายงานจะเกินความจริงไปกว่าเท่าตัว และถ้าส่งทั้ง 18 รายเป็นสัญญาณให้ Meta ระบบจะเรียนรู้จากข้อมูลที่ปนกันแบบนี้

ขั้นที่ 6: ส่งสถานะกลับ Meta แค่ 3 จุด

เมื่อเซลส์เปลี่ยนสถานะลีดใน CRM เซิร์ฟเวอร์จะส่งเหตุการณ์ไปหา Meta ตามนี้

• qualified หรือ proposal ส่ง Potential ครั้งเดียว ถ้าลีดผ่านทั้ง 2 สถานะก็ยังส่งครั้งเดียว
• won ส่ง Purchase พร้อมมูลค่าเป็นบาท ดึงจากช่อง "มูลค่าโอกาส" ของลีด
• lost ส่ง NotPotential
• new, contacted, nurture, ลีดซ้ำ, ใช้งานไม่ได้ ไม่ส่ง

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

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

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

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

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

เราทดสอบยังไงว่าใช้ได้จริง

1. ดูเหตุการณ์ใน Test Events ของ Meta ตรวจว่าเหตุการณ์จากเซิร์ฟเวอร์เข้าไปถึง Meta จริง
2. ส่งลีดทดสอบจากฟอร์มบนเว็บ แล้วตามไปดูว่าลีดเข้า CRM พร้อมข้อมูลที่มาครบ
3. ลบลีดทดสอบออก หลังตรวจเสร็จ ไม่ให้ไปปนในรายงาน

สิ่งที่เราเรียนรู้

ต้องทดสอบทั้งเส้นทาง ไม่ใช่แค่ Pixel

ระหว่างไล่ตรวจระบบเดิม เราพบว่าอีเมลแจ้งเตือนเมื่อมีลีดใหม่ไม่เคยถูกตั้งค่าไว้เลย ลีดถูกเก็บลงฐานข้อมูลครบทุกราย แต่ไม่มีใครได้รับอีเมลแจ้ง ปัญหาแบบนี้ไม่มีเครื่องมือวัดผลตัวไหนจับได้ เพราะจากฝั่ง Pixel ทุกอย่างทำงานปกติ Lead ก็ขึ้นใน Events Manager

บทเรียนคือ ต้องทดสอบทั้งเส้นทาง ตั้งแต่ผู้ใช้กดส่งฟอร์ม ลีดเข้าฐานข้อมูล ใครได้รับแจ้ง ลีดไปอยู่ใน CRM หรือยัง จนถึงเหตุการณ์ไปถึง Meta ถ้าตรวจแค่ว่า Pixel ยิงไหม เราจะมั่นใจผิด ๆ ว่าระบบดีแล้ว

ข้อมูลเก่าที่ดูเหมือนดี อาจไม่ได้ดีจริง

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

ออกแบบตามจำนวนลีดที่มีจริง

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

สิ่งที่เรายังไม่รู้

ระบบเปิดใช้เมื่อ 25–26 ก.ย. 2569 ตอนเขียนบทความนี้ยังเร็วเกินไปที่จะบอกผลใด ๆ เรื่องต่อไปนี้เรายังตอบไม่ได้

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

เมื่อมีข้อมูลพอ ผมจะกลับมาอัปเดตบทความนี้ด้วยตัวเลขจริง ทั้งที่ดีและไม่ดี

อยากได้ระบบแบบนี้กับธุรกิจของคุณ

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