สรุปสั้น ๆ
Event ที่ควรเก็บใน GA4 สำหรับธุรกิจขายผ่าน LINE แบ่งเป็นสามระดับคือ Micro (LINE Click, Add Friend) Mid-funnel (Lead, Qualified Lead) และ Macro (Order, Purchase) แต่ละ Event ต้องมี Trigger, Timestamp, Identifier, Value/Currency และ Deduplication Key ครบ ไม่ใช่แค่ยิงชื่อ Event ให้ครบตามตัวอย่างที่หาอ่านทั่วไป
แอดมินคนหนึ่งเคยถามผมว่า “ผมยิง Event ครบทุกตัวที่ในคู่มือบอกแล้ว ทำไมรายงาน GA4 ยังดูไม่ช่วยตัดสินใจอะไรเลย” พอไปดูจริง ๆ พบว่า Event ที่ยิงไปมีแต่ชื่อกับเวลา ไม่มี Value ไม่มี Transaction ID ไม่มีอะไรที่บอกว่า Event นี้เชื่อมกับ Lead คนไหน กลายเป็นข้อมูลกองใหญ่ที่วิเคราะห์อะไรต่อไม่ได้
ปัญหานี้เกิดขึ้นบ่อยเพราะหลายคนโฟกัสที่ “ชื่อ Event ต้องตรงกับที่ Google แนะนำ” มากกว่าโฟกัสที่ “Event นี้ต้องพกข้อมูลอะไรไปด้วยถึงจะเอาไปใช้งานต่อได้จริง” บทความนี้จะไล่ทีละ Event ที่ธุรกิจสาย LINE ควรเก็บ พร้อมบอกว่าแต่ละตัวต้องมีข้อมูลอะไรติดไปด้วย
ทำไมต้องออกแบบ Event เอง ไม่ใช้ Default ทั้งหมด
GA4 มี Event มาตรฐานให้ใช้ เช่น generate_lead หรือ purchase แต่ Event เหล่านี้ถูกออกแบบมาให้ครอบคลุมธุรกิจหลากหลายรูปแบบ ไม่ได้ผูกกับกระบวนการขายผ่านแชทโดยเฉพาะ ธุรกิจที่ขายผ่าน LINE จึงมักต้องเสริม Custom Event เข้าไปเพื่อให้สะท้อนขั้นตอนจริง เช่น Qualified Lead หรือ Deposit Paid ที่ไม่มี Event มาตรฐานรองรับตรง ๆ
หลักที่ต้องยึดคือ Event ต้องตอบโจทย์ LINLI-20 ในมิติของ Lead Definition และ Conversion Definition ของธุรกิจตัวเองก่อน แล้วค่อยแมปเข้ากับชื่อ Event มาตรฐานของ GA4 เท่าที่ทำได้ ไม่ใช่ยึดชื่อ Event มาตรฐานเป็นตัวตั้งแล้วบิดกระบวนการขายให้เข้ากับมัน
Event ต้นทางที่ยังไม่ใช่ยอดขาย
- line_click — เกิดเมื่อลูกค้ากดปุ่มหรือลิงก์ที่พาไปยัง LINE ควรยิงทันทีตอนกด ไม่ใช่รอผลว่าเปิดแอปสำเร็จหรือไม่
- add_friend — เกิดเมื่อลูกค้ากดเพิ่มเพื่อน ต้องแยกออกจาก line_click ชัดเจน เพราะคนกด Click ไม่ใช่ทุกคนที่จะเพิ่มเพื่อนจริง
- chat_started — เกิดเมื่อมีการเริ่มบทสนทนาจริงในแชท ไม่ใช่แค่เพิ่มเพื่อนเฉย ๆ โดยไม่พิมพ์อะไรเลย
- การเก็บ Event กลุ่มนี้ช่วยให้เห็น Drop-off ระหว่างแต่ละขั้น แต่ห้ามใช้จำนวน Event กลุ่มนี้แทนคำว่า Lead หรือยอดขาย เพราะมันยังห่างไกลจากรายได้มาก
Event กลางทางที่บอกคุณภาพของ Lead
- generate_lead — เกิดเมื่อบทสนทนากลายเป็น Lead ตามเกณฑ์ที่ธุรกิจกำหนด เช่น ตอบคำถามขั้นต่ำครบหรือให้ข้อมูลติดต่อ
- qualify_lead (Custom Event) — เกิดเมื่อ Lead ผ่านเกณฑ์ Qualified เช่น ตรงสินค้า ตรงพื้นที่ มีงบ และมี Timeline ที่ชัดเจนพอ
- appointment_set (Custom Event) — สำหรับธุรกิจที่ต้องนัดหมายก่อนปิดการขาย เช่น คลินิกหรือธุรกิจบริการ
- Event กลุ่มนี้มีประโยชน์มากในการวิเคราะห์ว่า Campaign ไหนสร้าง Lead ที่ “คุณภาพดี” ไม่ใช่แค่ Lead ที่ “จำนวนเยอะ” ซึ่งเป็นสองเรื่องที่มักถูกสับสนกัน
Event ปลายทางที่ผูกกับรายได้จริง
| Event | Trigger | ข้อมูลที่ต้องแนบ |
|---|---|---|
| purchase | ปิดการขายและยืนยันชำระเงินแล้ว | Transaction ID, Value, Currency, Item/Service, client_id |
| deposit_paid (Custom) | ลูกค้าวางมัดจำแต่ยังไม่ชำระเต็มจำนวน | Deposit Amount, Order ID, วันครบกำหนดชำระส่วนที่เหลือ |
| refund | มีการคืนเงินหรือยกเลิกออเดอร์ภายหลัง | Transaction ID เดิม, จำนวนที่คืน, เหตุผล |
Key Event ต่างจาก Conversion แบบเดิมยังไง
ใน GA4 คำว่า Key Event คือ Event ที่ธุรกิจกำหนดว่ามีความสำคัญเชิงธุรกิจ และสามารถนำไปใช้อ้างอิงในรายงานหรือส่งต่อไปยัง Google Ads ได้ ต่างจากยุค Universal Analytics ที่ใช้คำว่า Goal และมีวิธีตั้งค่าต่างออกไป
สิ่งที่ต้องระวังคือไม่ควรตั้งทุก Event ที่ยิงเข้าไปเป็น Key Event ทั้งหมด เพราะจะทำให้ระบบและทีมสับสนว่าอะไรคือเป้าหมายหลักจริง ๆ ควรเลือกเฉพาะ Event ที่ใกล้รายได้หรือมีความหมายตัดสินใจได้จริง เช่น purchase หรือ qualify_lead เป็น Key Event หลัก ส่วน Event อื่นเก็บไว้เป็นข้อมูลประกอบ
เริ่มจากไม่กี่ Event ก่อน แล้วค่อยขยาย ดีกว่าเริ่มครบทีเดียว
ธุรกิจที่เพิ่งเริ่มวาง Event Taxonomy มักอยากเก็บให้ครบทุก Event ตั้งแต่วันแรก แต่ในทางปฏิบัติ วิธีที่ปลอดภัยกว่าคือเริ่มจาก Event สามตัวที่สำคัญที่สุดก่อน คือ line_click, generate_lead และ purchase เพราะสามตัวนี้ครอบคลุมต้นทาง กลางทาง และปลายทางของ Funnel แล้ว ยังพอบริหารจัดการได้ด้วยทีมเล็ก ๆ โดยไม่ต้องมีระบบซับซ้อน
เมื่อสามารถเก็บสาม Event นี้ได้สม่ำเสมอและครบถ้วนแล้ว ค่อยขยายไปเก็บ Event กลางทางเพิ่มเติม เช่น add_friend, chat_started หรือ qualify_lead ตามลำดับ การขยายทีละขั้นแบบนี้ช่วยให้ทีมมีเวลาปรับตัวกับกระบวนการอัปเดตสถานะใหม่ และลดความเสี่ยงที่จะเก็บ Event จำนวนมากแต่ข้อมูลไม่ครบถ้วนตั้งแต่ต้น ซึ่งจะทำให้วิเคราะห์ผิดพลาดมากกว่าการมี Event น้อยแต่ข้อมูลแม่นยำ
สิ่งที่ต้องมีในทุก Event ไม่ว่าจะเป็น Event อะไร
- Event Name ที่สื่อความหมายชัดเจนและใช้ชื่อเดียวกันตลอด ไม่สลับชื่อไปมาระหว่างทีม
- Timestamp ที่ตรงเขตเวลาจริงของธุรกิจ ไม่ใช่เขตเวลาของเซิร์ฟเวอร์ที่อาจต่างกัน
- Identifier ที่เชื่อมกลับไปหา Session ต้นทางได้ เช่น client_id หรือ Lead ID
- Deduplication Key เพื่อป้องกันการยิง Event เดิมซ้ำเมื่อมีการอัปเดตสถานะดีลหลายรอบ
- Value และ Currency สำหรับ Event ที่เกี่ยวกับมูลค่า เพื่อให้รายงานคำนวณตัวเลขทางธุรกิจได้ถูกต้อง
ข้อผิดพลาดเรื่อง Duplicate และ Time Zone ที่พบบ่อย
ข้อผิดพลาดที่พบบ่อยที่สุดคือการยิง Event purchase ซ้ำเมื่อแอดมินกดอัปเดตสถานะดีลเดิมหลายรอบ เช่น เปลี่ยนจาก “รอชำระ” เป็น “ชำระแล้ว” แล้วมีการยิง Event ซ้ำโดยไม่ได้ตรวจว่า Transaction ID นี้เคยถูกส่งไปแล้วหรือยัง ผลคือรายได้ในรายงานสูงเกินความจริง
อีกจุดที่พบบ่อยคือการตั้ง Time Zone ของ Property ไม่ตรงกับพฤติกรรมจริงของธุรกิจ ทำให้ Event ที่เกิดตอนดึกไปตกอยู่ในวันถัดไปในรายงาน ส่งผลต่อการวิเคราะห์ Dayparting และการเทียบผลรายวันคลาดเคลื่อน
ควรมีกระบวนการตรวจสอบการตั้งค่า Key Eventเป็นระยะ และสุ่มเช็กการนับ Conversion ซ้ำอย่างน้อยเดือนละครั้ง เพราะปัญหาพวกนี้มักไม่ถูกสังเกตจนกว่าจะสะสมนานพอที่ตัวเลขเริ่มดูผิดปกติชัดเจน
ใครควรเป็นคนยิง Event แต่ละตัว ไม่ใช่ทุก Event มาจากที่เดียวกัน
ตารางนี้ชี้ให้เห็นว่า Event Taxonomy ที่ดีไม่ใช่แค่เรื่องเทคนิคของทีมพัฒนาเว็บอย่างเดียว แต่เกี่ยวข้องกับหลายทีมพร้อมกัน ถ้าไม่มีการตกลงล่วงหน้าว่าใครรับผิดชอบยิงหรืออัปเดต Event ไหน ก็มีความเสี่ยงสูงที่บาง Event จะขาดหายหรือถูกยิงผิดจังหวะโดยไม่มีใครรู้ตัวจนกว่าจะเปิดรายงานมาดูแล้วเจอความผิดปกติ
| Event | ใครเป็นคนยิง/อัปเดต | ความเสี่ยงถ้าไม่มีเจ้าของชัดเจน |
|---|---|---|
| line_click | Tracking Script บนเว็บ/ลิงก์ | นับซ้ำถ้าคนกดลิงก์เดิมหลายครั้งโดยไม่กันซ้ำ |
| add_friend / chat_started | LINE OA / ระบบ Webhook | ข้อมูลหายถ้า Webhook ล่มหรือไม่ได้ผูก Identifier ไว้ก่อน |
| generate_lead | แอดมินหรือระบบหลังบ้าน | นิยาม Lead ไม่ตรงกันระหว่างทีมเทคนิคกับทีมขาย |
| qualify_lead | ฝ่ายขาย | ล่าช้าถ้าไม่มีรอบเวลาชัดเจนว่าต้องอัปเดตภายในกี่ชั่วโมง |
| purchase | ฝ่ายขาย/ระบบบันทึกยอด | นับซ้ำถ้าอัปเดตสถานะดีลเดิมหลายรอบโดยไม่มี Deduplication Key |
สรุป
Event ที่ดีไม่ได้วัดกันที่จำนวนหรือความครบตามคู่มือ แต่วัดกันที่ว่าแต่ละ Event พกข้อมูลพอให้เอาไปตัดสินใจต่อได้จริงหรือไม่ ทั้ง Trigger ที่ชัดเจน Identifier ที่เชื่อมย้อนกลับได้ และ Deduplication Key ที่กันการนับซ้ำ
ก่อนจะไล่เก็บ Event ตามลิสต์ในบทความนี้ทั้งหมด ลองกลับไปถามตัวเองก่อนว่าธุรกิจของคุณมีทีมที่จะอัปเดตสถานะ Lead และ Order สม่ำเสมอพอไหม เพราะ Event ที่ดีที่สุดในทางทฤษฎีก็ไร้ประโยชน์ถ้าไม่มีใครยิงมันเข้ามาอย่างต่อเนื่อง
- แบ่ง Event เป็นสามระดับ Micro/Mid-funnel/Macro และห้ามปนความหมายกัน
- ทุก Event ต้องมี Timestamp, Identifier และ Deduplication Key ที่ถูกต้อง ไม่ใช่แค่ชื่อ Event
- เลือก Key Event เฉพาะตัวที่ใกล้รายได้จริง อย่าตั้งทุก Event เป็น Key Event พร้อมกันหมด
คำถามที่พบบ่อย
ควรใช้ชื่อ Event ตามมาตรฐาน GA4 เสมอไปไหม
ควรใช้ชื่อมาตรฐานเมื่อ Event นั้นตรงกับความหมายจริง เช่น purchase หรือ generate_lead แต่ถ้าธุรกิจมีขั้นตอนเฉพาะที่ไม่มี Event มาตรฐานรองรับ เช่น Qualified Lead หรือ Deposit Paid ควรสร้าง Custom Event ที่สื่อความหมายชัดเจนแทนการยัดใส่ Event มาตรฐานที่ความหมายไม่ตรง
จำเป็นต้องเก็บทุก Event ที่กล่าวถึงในบทความนี้ไหม
ไม่จำเป็น ควรเลือกเฉพาะ Event ที่สะท้อนขั้นตอนจริงของธุรกิจตัวเองและมีคนรับผิดชอบอัปเดตสถานะได้สม่ำเสมอ การเก็บ Event มากเกินความสามารถในการดูแลจะทำให้ข้อมูลไม่ครบและวิเคราะห์ผิดพลาดมากกว่าไม่เก็บเลย
Deduplication Key ควรใช้ค่าอะไร
ควรใช้ค่าที่ไม่ซ้ำกันแน่นอนสำหรับแต่ละดีล เช่น Order ID หรือ Lead ID ที่ระบบหลังบ้านสร้างขึ้น ไม่ควรใช้ค่าที่อาจซ้ำได้ เช่น ชื่อสินค้า หรือวันที่เพียงอย่างเดียว เพราะอาจมีหลายดีลเกิดวันเดียวกันได้
ทำไมจำนวน generate_lead ใน GA4 ไม่ตรงกับจำนวน Lead ที่ทีมขายนับ
มักเกิดจากนิยาม Lead ที่ต่างกันระหว่างฝั่งเทคนิคที่ยิง Event กับฝั่งทีมขายที่บันทึกในระบบ CRM หรือเกิดจาก Event ถูกยิงซ้ำ/ขาดหาย ควรนัดคุยทั้งสองฝ่ายให้ใช้นิยาม Lead เดียวกัน แล้วสุ่มตรวจสอบเป็นระยะ
ควรตั้งค่า Value ของ Event ที่ไม่มีมูลค่าชัดเจนอย่างไร เช่น Add Friend
ไม่จำเป็นต้องใส่ Value ให้ทุก Event โดยเฉพาะ Event ต้นทางอย่าง Add Friend ที่ยังไม่มีมูลค่าทางธุรกิจจริง การพยายามยัด Value ประมาณการเข้าไปอาจทำให้รายงานเข้าใจผิดว่า Event นั้นมีมูลค่าเทียบเท่า Order จริง
ถ้าไม่มีทีมเทคนิค จะออกแบบ Event Taxonomy เองได้ไหม
ทำได้ในระดับพื้นฐาน โดยเริ่มจากนิยาม Lead, Qualified Lead และ Order ของธุรกิจให้ชัดก่อน แล้วค่อยหาทีมเทคนิคหรือระบบที่ช่วยแปลงนิยามเหล่านั้นเป็น Event จริง การมีนิยามที่ชัดเจนล่วงหน้าจะช่วยลดความผิดพลาดตอนตั้งค่าได้มาก
บทความที่เกี่ยวข้อง
