ลูกค้าทักไลน์วันจันทร์ โอนเงินจริงวันพฤหัส: หน้าต่างเวลาที่แพลตฟอร์มยอมรับ Conversion ย้อนหลัง

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

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

นี่ไม่ใช่ปัญหาที่เกิดจากโค้ดผิด แต่เป็นเรื่องที่ทีมพัฒนาต้องเข้าใจกลไก attribution window ของแต่ละแพลตฟอร์ม แล้วออกแบบระบบให้ส่ง timestamp ที่สื่อความหมายถูกต้อง ไม่ใช่แค่ส่งเวลาที่ระบบยิง event ออกไปเฉย ๆ

ทำไมธุรกิจขายผ่านแชทถึงมี conversion ที่มาช้าเป็นเรื่องปกติ

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

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

attribution window คืออะไร และทำไมยิงช้าเกินไปถึงเสียเครดิต

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

จุดสำคัญที่มักเข้าใจผิดคือ หน้าต่างเวลานี้นับจาก ‘เวลาที่เหตุการณ์เกิดขึ้นจริง’ ไม่ใช่ ‘เวลาที่ event ถูกส่งเข้าระบบ’ ถ้า backend ส่ง timestamp เป็นเวลาที่ยิง event ออกไป (ซึ่งอาจช้ากว่าที่ลูกค้าทักครั้งแรกหลายวัน) แพลตฟอร์มจะเข้าใจว่า conversion เพิ่งเกิดขึ้น ณ ตอนนั้น ทำให้การ attribute ย้อนกลับไปหาแคมเปญต้นทางคลาดเคลื่อนไปด้วย

กรอบหน้าต่างเวลาโดยประมาณของแต่ละแพลตฟอร์ม (ตัวอย่างกรอบคร่าว ๆ ต้องเช็กค่าล่าสุดเสมอ)

ออกแบบระบบให้ส่ง timestamp ที่สื่อความหมายถูกต้อง

1. เก็บ timestamp ของ ‘จุดสัมผัสแรก’ ที่ลูกค้าทักเข้ามา แยกจาก timestamp ของ ‘วันที่ปิดการขาย’ ตั้งแต่ชั้นฐานข้อมูล ไม่ใช่รวมเป็นค่าเดียวกัน เพราะทั้งสองค่ามีความหมายต่างกันสำหรับ attribution
2. ตรวจสอบสเปกของแต่ละแพลตฟอร์มว่ารองรับการส่ง event_time ย้อนหลังได้ไกลแค่ไหน แล้วเลือกส่งเวลาที่ถูกต้องตามความหมายจริง ไม่ใช่ค่า default ที่ระบบสร้างอัตโนมัติตอนยิง event
3. ถ้าธุรกิจมีวงจรขายยาวเกินหน้าต่างเวลาที่แพลตฟอร์มรองรับจริง ให้พิจารณายิง event แบบสองขั้น คือ event เบื้องต้นตอนลูกค้าทักครั้งแรก (เช่น Lead) และ event ปิดการขายจริงตอนภายหลัง (เช่น Purchase) เพื่อให้แพลตฟอร์มมีสัญญาณระหว่างทางไว้ใช้อ้างอิงด้วย
4. ทดสอบว่า conversion ที่ยิงช้ากว่าปกติหลายวันยังถูกระบบรับและประมวลผลถูกต้อง โดยดูจากการตรวจช่องว่างข้อมูลระหว่าง pixel กับ CAPIว่าไม่มี event ตกหล่นในช่วงที่วงจรขายยาวกว่าปกติ

เคสขอบที่ทีมมักลืมตอนออกแบบระบบ

• ลูกค้ายกเลิกแล้วสั่งใหม่ในภายหลัง — ต้องตัดสินใจว่านับเป็น conversion ใหม่ที่มี journey ใหม่ หรือเชื่อมโยงกับ journey เดิม เพราะส่งผลต่อ timestamp ที่ควรใช้
• ปิดการขายข้ามเดือนบัญชี — บางระบบรายงานผลตามรอบบัญชี ทำให้ตัวเลขที่การตลาดใช้ตัดสินใจงบประมาณกับตัวเลขที่แพลตฟอร์ม attribute อาจไม่ตรงรอบเดือนกัน ต้องสื่อสารความต่างนี้ให้ทีมที่ใช้ตัวเลขเข้าใจ
• สินค้าที่ต้องรอสต๊อกก่อนยืนยันออเดอร์ — วันที่ ‘ลูกค้าตกลงซื้อ’ กับวันที่ ‘ระบบบันทึกออเดอร์สำเร็จ’ อาจห่างกันหลายวัน ต้องชัดเจนว่า event Purchase ควรยิงตอนไหนตามนิยามที่ทีมกำหนดไว้ร่วมกัน
• ลูกค้าที่ทักผ่านหลายช่องทางก่อนปิดการขาย — เช่น เห็นโฆษณาใน Feed แล้วทักไลน์ แต่ก่อนปิดการขายจริงกลับไปดูรีวิวใน TikTok อีกรอบ ทำให้การ attribute เครดิตซับซ้อนกว่าการมีจุดสัมผัสเดียว

สรุป

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

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

• attribution window นับจากเวลาที่เหตุการณ์เกิดขึ้นจริง ไม่ใช่เวลาที่ event ถูกยิงเข้าระบบ
• ธุรกิจวงจรขายยาวควรยิง event สองขั้น คือสัญญาณเบื้องต้นตอนทักครั้งแรก และ Purchase ตอนปิดการขายจริง
• แยกเก็บ timestamp ของจุดสัมผัสแรกกับวันปิดการขายตั้งแต่ชั้นฐานข้อมูล เพื่อส่ง event_time ที่ถูกต้องได้เสมอ

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