จ่ายเงินผ่านแชท LINE แล้วจะรู้ได้ยังไงว่าใครซื้อจริง

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

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

บทความนี้จะพาดูว่าการวัด Purchase จาก LINE ที่ทำให้เห็นภาพครบตั้งแต่ต้นทุนต่อ Lead ไปจนถึง ROAS ต้องเริ่มต้นจากตรงไหน และต้องระวังอะไรบ้างก่อนเชื่อตัวเลขที่ได้

ทำไม Purchase ที่เกิดในแชทถึงมองไม่เห็นในรายงานแอด

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

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

นิยาม Purchase ของธุรกิจต้องชัดก่อนวัด

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

ธุรกิจที่ต้องรอตรวจสอบสลิปหรือรอเงินโอนหลายวันควรตัดสินใจว่าจะส่ง Event ตอน Order เกิดขึ้นก่อนแล้วปรับ Value ทีหลัง หรือจะรอให้ยืนยันเงินเข้าแล้วค่อยส่ง Event ครั้งเดียว ทั้งสองแบบมีข้อดีข้อเสียต่างกันเรื่องความเร็วกับความแม่นยำ

ขั้นตอนบันทึก Order จนถึงส่ง Purchase Event กลับ

1. แอดมินบันทึก Order พร้อมสินค้า จำนวน และราคารวมทันทีที่ลูกค้าตกลงซื้อ
2. เมื่อได้รับสลิปหรือยืนยันการโอนเงิน อัปเดตสถานะ Order เป็น Payment Confirmed
3. ตรวจว่า Order นี้มี Identifier ต้นทางติดมาด้วยหรือไม่ ถ้าไม่มีให้ระบุ Source เท่าที่ทราบ
4. ส่ง Event Purchase พร้อม Value, Currency และ Identifier กลับไปยังแพลตฟอร์มที่เชื่อมต่อและตั้งค่าไว้
5. ตรวจสอบว่า Event ที่ส่งไปไม่ซ้ำกับ Order เดิมที่เคยส่งไปแล้ว

รวม Cost per Lead, Cost per Sale และ ROAS ไว้ในชุดเดียว

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

อ่าน Cost per Lead กับ Cost per Sale ควบคู่กันยังไง

Cost per Lead คำนวณจากงบโฆษณาหารด้วยจำนวน Lead ส่วน Cost per Sale คำนวณจากงบโฆษณาหารด้วยจำนวน Closed Sale สองตัวเลขนี้ควรดูคู่กันเสมอ เพราะแคมเปญที่มี Cost per Lead ต่ำอาจมี Cost per Sale สูงถ้าคุณภาพ Lead ไม่ดี ในขณะที่แคมเปญที่ Cost per Lead สูงกว่าอาจคุ้มค่ากว่าถ้าปิดการขายได้มากกว่า

จากตารางตัวอย่างข้างต้น Campaign C มี Lead น้อยที่สุดแต่มี ROAS สูงที่สุด สะท้อนว่าปริมาณ Lead ไม่ใช่ตัวชี้วัดเดียวที่ควรใช้ตัดสินใจเรื่องงบ

Data Quality ที่ต้องตรวจก่อนเชื่อ ROAS

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

ข้อจำกัดที่ต้องยอมรับเมื่อวัด Purchase จากแชท

ต่อให้ระบบดีแค่ไหน การวัด Purchase จากแชทยังมีความล่าช้าโดยธรรมชาติ เพราะต้องรอแอดมินยืนยันการชำระเงินก่อนจึงจะส่ง Event ได้ ความล่าช้านี้ต่างจากการซื้อผ่านเว็บไซต์ที่ระบบยืนยันอัตโนมัติทันที จึงไม่ควรคาดหวังว่า Purchase จากแชทจะเห็นผลใน Ads Manager แบบวันต่อวัน

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

ตัวอย่างคำนวณ Conversion Adjustment เมื่อลูกค้าคืนเงินหลังส่ง Purchase Event ไปแล้ว

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

ถ้าไม่มีการปรับปรุงตัวเลขนี้ย้อนหลัง แพลตฟอร์มโฆษณาจะยังคงเห็นว่า Order นี้เป็น Purchase มูลค่าสามพันบาทตลอดไป ทั้งที่ในความเป็นจริงเงินได้คืนกลับไปหาลูกค้าหมดแล้ว ธุรกิจจึงควรตรวจสอบวิธีทำ Conversion Adjustment หรือ Restatement ตามเอกสารล่าสุดของแพลตฟอร์มนั้น เพื่อแจ้งว่า Order นี้ถูกยกเลิกหรือปรับมูลค่าลง

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

อีกแนวทางหนึ่งที่บางธุรกิจเลือกใช้คือรอให้พ้นระยะเวลาคืนสินค้ามาตรฐานก่อนค่อยส่ง Purchase Event เช่น รอเจ็ดวันหลังจัดส่งแล้วค่อยยืนยัน วิธีนี้ลดจำนวนครั้งที่ต้องทำ Conversion Adjustment ย้อนหลัง แต่แลกมาด้วย Conversion Lag ที่นานขึ้น ซึ่งอาจไม่เหมาะกับธุรกิจที่ต้องการเห็นผลตอบรับของแคมเปญเร็ว ธุรกิจจึงควรเลือกแนวทางที่สอดคล้องกับอัตราการคืนสินค้าและความเร็วที่ต้องการเห็นผลของตัวเอง

สลิปโอนเงินและข้อมูลการชำระเงิน ต้องเก็บรักษายังไง

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

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

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

ลูกค้าซื้อไม่ครบตามที่คุยไว้ ต้องส่งมูลค่า Purchase เท่าไหร่

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

หลักการที่ควรยึดคือส่งมูลค่า Purchase Event ตามยอดเงินที่ลูกค้าโอนจริงเท่านั้น ไม่ใช่ยอดที่คุยไว้ตอนแรกในแชท ถ้าธุรกิจใช้ระบบที่ดึงยอดจาก Order อัตโนมัติ ควรตรวจสอบว่า Order ถูกอัปเดตให้ตรงกับยอดที่ปิดจริงก่อนที่ Event จะถูกส่งออกไป ไม่ใช่ปล่อยให้ระบบยิงตามยอดตั้งต้นที่อาจเปลี่ยนไปแล้วระหว่างการเจรจา

ลูกค้าโอนเงินเป็นงวด ควรส่ง Purchase Event ตอนไหน

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

แนวทางที่ปลอดภัยกว่าคือส่ง Purchase Event ตามยอดที่ได้รับจริงในแต่ละงวด แล้วอัปเดตอีกครั้งเมื่อได้รับยอดครบ หรือถ้าธุรกิจต้องการความเรียบง่ายกว่านั้น อาจเลือกส่ง Purchase Event เพียงครั้งเดียวเมื่อได้รับเงินครบเต็มจำนวนแล้วเท่านั้น ไม่ส่งตอนได้รับมัดจำงวดแรก วิธีนี้ทำให้ Conversion Lag ยาวขึ้นเล็กน้อย แต่ตัวเลขที่ส่งไปมีความแม่นยำสูงกว่า ไม่ต้องมาตามแก้ Conversion Adjustment ทีหลังหากลูกค้ายกเลิกก่อนโอนครบ

สรุป

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

เมื่อรวม Cost per Lead, Cost per Sale และ ROAS ไว้ในมุมมองเดียวกันแล้ว การตัดสินใจเรื่องงบจะไม่ต้องอาศัยการเดาอีกต่อไป แต่มีตัวเลขจริงรองรับทุกครั้งที่ต้องเลือกว่าจะเพิ่มหรือลดงบให้แคมเปญไหน

• Purchase ที่เกิดในแชทไม่ปรากฏในรายงานแอดเอง ต้องมีคนหรือระบบส่งข้อมูลกลับ
• นิยาม Purchase ให้ชัดก่อน แล้วบันทึก Order ให้ครบทุกขั้นตอน
• ดู Cost per Lead, Cost per Sale และ ROAS พร้อมกัน ไม่ตัดสินใจจากตัวเลขเดียว

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