ส่ง conversion จากฝั่ง LINE เข้า GA4 ตรง ๆ ด้วย Measurement Protocol: คู่มือฉบับลงมือทำ
สรุปสั้น ๆ
GA4 ฝั่งเบราว์เซอร์เห็นได้แค่ถึงตอนคนกดปุ่มทัก LINE พอเข้าห้องแชทแล้วมันตาบอด Measurement Protocol คือช่องทางให้ระบบฝั่ง server ยิง event เข้า GA4 ได้เอง เช่นตอนแอดมินกดปิดการขาย หรือระบบยืนยันสลิป ทำให้ยอดจริงในแชทไหลกลับเข้า GA4 มาต่อภาพกับ session เดิมของคนคนนั้นได้ แต่ต้องแนบ client_id หรือ user_id ให้ถูก ไม่งั้น event จะกลายเป็นคนแปลกหน้าที่ไม่เชื่อมกับ session ไหนเลย
ร้านขายเครื่องสำอางเจ้าหนึ่งบ่นกับผมว่า GA4 บอกว่าแคมเปญ A ดีที่สุดเพราะคนกดทักเยอะ เขาเลยทุ่มงบไปกับมันเต็มที่ พอปิดเดือนมาดูยอดจริงกลับพบว่าแคมเปญ A ได้แต่คนถามเล่น ส่วนแคมเปญ B ที่คนทักน้อยกว่ากลับปิดการขายจริงเยอะกว่าเท่าตัว ปัญหาคือ GA4 เห็นแค่ตอนคนกดทัก แล้วก็ตาบอดสนิทตั้งแต่คนเข้าห้องแชทเป็นต้นไป
นี่คือกำแพงที่ทุกคนที่ปิดการขายในแชทต้องเจอ เพราะ GA4 แบบมาตรฐานทำงานในเบราว์เซอร์ พอลูกค้าเด้งออกจากเว็บเข้าแอป LINE ไปคุยกับแอดมิน เหตุการณ์ทั้งหมดหลังจากนั้น ทั้งการต่อรอง การโอนเงิน การซื้อซ้ำ เกิดในที่ที่ GA4 มองไม่เห็นเลยสักนิด
Measurement Protocol คือประตูหลังที่ Google เปิดไว้ให้ ระบบฝั่ง server ยิง event เข้า GA4 ได้โดยตรงโดยไม่ต้องผ่านเบราว์เซอร์ บทความนี้จะลงลึกตั้งแต่แนวคิด ไปจนถึงโครงสร้าง payload จริงและกับดักที่ทำให้คนส่วนใหญ่ทำแล้วข้อมูลไม่เชื่อมกัน เพราะถ้าทำถูก คุณจะเห็นภาพยาวตั้งแต่คลิกโฆษณาไปจนถึงสลิปโอนในหน้าเดียว
Measurement Protocol คืออะไร ต่างจาก tag ปกติยังไง
tag GA4 ปกติที่ฝังในเว็บทำงานฝั่งเบราว์เซอร์ พอมีคนเปิดหน้า มันก็ยิง event ผ่าน JavaScript ในเครื่องคนนั้น ข้อจำกัดคือมันทำงานได้เฉพาะตอนคนอยู่บนหน้าเว็บที่มี tag เท่านั้น พอออกไปแล้วก็จบ
Measurement Protocol ตรงข้ามเลย มันคือการที่ server ของคุณส่งคำสั่ง HTTP ตรงเข้าไปที่ GA4 ว่า ‘มี event นี้เกิดขึ้นนะ’ โดยไม่เกี่ยวกับว่าคนนั้นกำลังเปิดเว็บอยู่หรือไม่ ทำให้คุณยิง event ตอนไหนก็ได้ เช่นตอนแอดมินกดปิดการขายในระบบหลังบ้าน หรือตอนระบบตรวจสลิปเสร็จตอนตีสอง
จุดที่ทำให้มันทรงพลังคือมันเป็นเทคนิคเดียวกับที่ใช้ทำการส่งข้อมูลแบบ server-to-server คือข้อมูลไหลจากระบบสู่ระบบ ไม่ต้องพึ่งเบราว์เซอร์ที่โดนบล็อกคุกกี้หรือปิดแท็บได้ตลอดเวลา ความน่าเชื่อถือจึงสูงกว่าการเก็บฝั่งหน้าเว็บอย่างเดียวมาก
หัวใจอยู่ที่ client_id กาวที่เชื่อม session เข้าด้วยกัน
จุดที่คนทำพลาดกันเยอะที่สุดไม่ใช่การยิง event แต่คือการทำให้ event ที่ยิงจาก server ไปเชื่อมกับคนคนเดิมที่เคยเข้าเว็บ ถ้าไม่แนบตัวระบุตัวตนไปด้วย GA4 จะมองว่า event นั้นมาจากคนแปลกหน้าคนใหม่ ทำให้เส้นทางขาดตอน เหมือนมีต้นทางกับปลายทางแต่ไม่มีเส้นเชื่อม
ตัวเชื่อมที่ GA4 ใช้คือ client_id ซึ่งเป็นรหัสที่ GA4 สร้างให้เบราว์เซอร์แต่ละเครื่องตอนคนเข้าเว็บครั้งแรก กลไกที่ถูกต้องคือ ตอนคนกดปุ่ม LINE ในเว็บ ให้ดักเก็บ client_id ของเขาส่งติดไปกับลิงก์หรือเก็บลงฐานข้อมูล ผูกกับ user ID ในระบบแชทของคุณ พอวันหลังคนนั้นปิดการขาย server ก็หยิบ client_id เดิมมาแนบตอนยิง event purchase เข้า GA4
เมื่อ client_id ตรงกัน GA4 จะเย็บ event purchase จาก server เข้ากับ session เดิมที่คนนั้นเคยมาจากโฆษณาได้อย่างสวยงาม กลายเป็นเส้นทางเดียวที่ต่อเนื่อง ถ้าอยากเข้าใจภาพว่าทำไมการผูก id ถึงสำคัญ ลองดูเรื่องช่องว่างระหว่างคลิกกับการทักเข้า LINEประกอบ จะเห็นว่ารอยต่อตรงนี้คือจุดที่ข้อมูลรั่วบ่อยที่สุด
โครงสร้าง payload ที่ server ต้องส่ง
การยิง Measurement Protocol คือการส่ง HTTP POST ไปที่ปลายทางของ GA4 พร้อมแนบพารามิเตอร์สองตัวใน URL คือ measurement_id (รหัส G- ของคุณ) และ api_secret ที่สร้างได้ในหน้า Admin ส่วนตัว body เป็น JSON ที่บอกว่า event ชื่ออะไร ของใคร และมีค่าอะไรบ้าง โครงสร้างหลักมีดังนี้
| field | หน้าที่ | ตัวอย่างค่า |
|---|---|---|
| client_id | เชื่อม event เข้ากับ session เดิม | รหัสที่ดักจากเบราว์เซอร์ตอนกดทัก |
| events[].name | ชื่อ event ที่จะยิง | purchase หรือ chat_closed |
| events[].params.value | มูลค่าการซื้อจริง | ยอดปิดจากแชท เช่น 2500 |
| events[].params.currency | สกุลเงิน | THB |
| events[].params.transaction_id | รหัสอ้างอิงกันซ้ำ | เลขออเดอร์ในระบบคุณ |
อย่าลืมกันการนับซ้ำและใส่มูลค่าจริง
เสน่ห์ของ Measurement Protocol คือคุณส่งมูลค่าการซื้อจริงเข้าไปได้ ไม่ใช่แค่นับหัวว่ามีคนทัก ทำให้ GA4 บอกได้ว่าแคมเปญไหนสร้างเงินจริงกี่บาท ไม่ใช่แค่สร้างคนทักกี่คน ซึ่งเป็นคนละเรื่องกันอย่างที่ร้านเครื่องสำอางในต้นเรื่องเจอมา
แต่ดาบสองคมคือถ้า server ยิงซ้ำ เช่นระบบ retry ตอนเน็ตหลุด คุณจะได้ยอดซ้อน วิธีกันคือใส่ transaction_id ที่ไม่ซ้ำในทุก event GA4 จะใช้ค่านี้ตัดตัวที่ซ้ำออกเอง หลักการเดียวกับการกันเหตุการณ์ซ้ำในระบบอื่น ถ้าละเลยจุดนี้ ยอดขายในรายงานจะพองจนคุณตัดสินใจงบผิด
อีกจุดที่ควรระวังคือเรื่องเวลา ถ้ายอดปิดเกิดหลังคนคลิกโฆษณาไปหลายวัน ต้องดูว่ามันยังอยู่ในกรอบเวลาการให้เครดิตของแคมเปญไหม เพราะถ้าเลยกรอบ GA4 อาจให้เครดิตช่องทางอื่นแทน ทำให้ภาพการวัดผลเพี้ยนได้
ควรลงทุนทำเองไหม หรือมีทางที่ง่ายกว่า
พูดตามตรง Measurement Protocol ไม่ใช่ของที่เจ้าของร้านคนเดียวจะกดตั้งเสร็จในบ่ายวันเดียว มันต้องมีคนเขียนโค้ดฝั่ง server ที่ดักเก็บ client_id ผูกกับ user แล้วยิง event กลับ ถ้าร้านคุณมีทีมเทคหรือระบบหลังบ้านที่แก้ได้ นี่คือวิธีที่ให้ข้อมูลลึกและแม่นที่สุด
แต่ถ้าไม่มีทีมเทค การลงทุนเขียนเองอาจไม่คุ้มกับเวลาที่เสีย ทางเลือกคือใช้เครื่องมือที่จัดการรอยต่อระหว่างแชทกับการวัดผลให้อยู่แล้ว เช่นระบบอย่าง linli ที่เชื่อมยอดปิดในแชทกลับไปหาที่มาของโฆษณาให้โดยไม่ต้องเขียน Measurement Protocol เอง ซึ่งช่วยประหยัดเวลาทีมไปได้มาก
ไม่ว่าจะเลือกทางไหน แก่นเดียวกันคือคุณต้องปิดช่องว่างระหว่าง ‘คนกดทัก’ กับ ‘คนที่จ่ายเงินจริง’ ให้ได้ เพราะตราบใดที่ GA4 เห็นแค่ครึ่งทาง คุณก็จะเทงบไปกับแคมเปญที่สร้างคนถามเล่น แล้วปล่อยแคมเปญที่สร้างเงินจริงให้ตายไปเงียบ ๆ
สรุป
Measurement Protocol คือกุญแจที่เปิดให้ GA4 มองเห็นสิ่งที่เกิดในห้องแชท ซึ่งเป็นที่ที่เงินจริงเกิดขึ้น มันเปลี่ยนรายงานจากการนับหัวคนทัก ให้กลายเป็นการวัดมูลค่าการซื้อจริงที่ผูกกลับไปหาแคมเปญต้นทางได้
แต่มันไม่ใช่ของฟรี ต้องแลกด้วยงานฝั่ง server และวินัยเรื่อง client_id กับการกันนับซ้ำ ถ้าทีมพร้อมนี่คือวิธีที่แม่นที่สุด ถ้าไม่พร้อมก็เลือกเครื่องมือที่ทำรอยต่อนี้ให้แล้ว แก่นสำคัญคืออย่ายอมให้ระบบวัดผลของคุณตาบอดครึ่งทาง เพราะครึ่งทางที่มองไม่เห็นนั่นแหละคือครึ่งที่ทำเงิน
- GA4 มาตรฐานตาบอดตั้งแต่คนเข้าห้องแชท MP คือทางให้ server ยิง event เอง
- client_id คือกาวที่เชื่อม event จาก server กลับเข้า session เดิม ห้ามลืม
- ใส่ transaction_id กันนับซ้ำ และส่งมูลค่าจริงเพื่อวัดเงิน ไม่ใช่วัดหัว
คำถามที่พบบ่อย
Measurement Protocol ต่างจาก server-side GTM ยังไง
Measurement Protocol คือการยิง HTTP ตรงเข้า GA4 จากโค้ดฝั่ง server ส่วน server-side GTM คือการตั้ง container ตัวกลางบน server ที่รับ event แล้วกระจายต่อ สองอย่างนี้ใช้ร่วมกันได้ แต่ Measurement Protocol เบากว่าเพราะไม่ต้องตั้ง container เพิ่ม เหมาะกับการยิง event เฉพาะจุดอย่างการปิดการขาย
ถ้าไม่ได้เก็บ client_id ไว้จะยิงได้ไหม
ยิงได้แต่ไม่คุ้ม เพราะ event จะกลายเป็นคนแปลกหน้าที่ไม่เชื่อมกับ session ที่มาจากโฆษณา ทำให้คุณรู้ว่ามีการซื้อ แต่ไม่รู้ว่ามาจากแคมเปญไหน ซึ่งเสียประโยชน์หลักของการทำไปเกือบหมด การเก็บ client_id ตอนคนกดทักจึงเป็นขั้นที่ห้ามข้าม
api_secret หาได้จากที่ไหน
สร้างได้ในหน้า Admin ของ GA4 ที่ Data Streams เลือก stream ของเว็บคุณ แล้วมองหาเมนู Measurement Protocol API secrets กดสร้างใหม่ได้เลย เก็บค่านี้ให้ดีเหมือนรหัสผ่าน อย่าเผยแพร่ในโค้ดฝั่งหน้าเว็บเพราะคนอื่นเอาไปยิงข้อมูลปลอมใส่ property คุณได้
ยิงยอดปิดย้อนหลังหลายวันได้ไหม
ได้ในระดับหนึ่ง GA4 รับ event ที่มี timestamp ย้อนหลังได้ประมาณ 3 วันเท่านั้น ถ้ายอดปิดเกิดหลังคลิกโฆษณานานกว่านั้น การให้เครดิตอาจไม่ตรง จึงควรยิง event ให้เร็วที่สุดหลังปิดการขาย และวางระบบให้ยอดไหลกลับแบบใกล้เรียลไทม์
จะรู้ได้ยังไงว่ายิงเข้าถูกต้อง
GA4 มีปลายทางสำหรับทดสอบชื่อ debug endpoint ที่จะตอบกลับมาว่า payload คุณผิดตรงไหนบ้างก่อนยิงจริง และเมื่อยิงเข้าโหมด debug แล้ว event จะโผล่ใน DebugView ให้เห็นสด ๆ ควรทดสอบด้วยสองทางนี้ก่อนปล่อยขึ้นใช้งานจริงทุกครั้ง
ทำแล้วยอดใน GA4 จะตรงกับยอดขายจริงเป๊ะไหม
ไม่ควรคาดหวังให้ตรงเป๊ะทุกบาท เพราะมีปัจจัยอย่างคนที่ลบคุกกี้ เปลี่ยนเครื่อง หรือปิดการติดตาม ทำให้บาง event เชื่อมไม่ได้ เป้าหมายที่สมจริงคือให้สัดส่วนใกล้เคียงพอที่จะเห็นว่าแคมเปญไหนสร้างเงินมากกว่ากัน ไม่ใช่การทำบัญชีที่ต้องตรงทุกหน่วย
บทความที่เกี่ยวข้อง
