ตั้ง Key Event จากปุ่ม LINE ฝั่ง Client กับฝั่ง Server ต่างกันตรงไหน

มีเจ้าของร้านคนหนึ่งถามผมว่า “ทำไมปุ่ม LINE บนเว็บกดจริง 40 ครั้งต่อวัน แต่ใน GA4 ขึ้นแค่ 28” คำถามนี้ผมเจอบ่อยจนเกือบจำสคริปต์ตอบได้ และคำตอบเกือบทุกครั้งไม่ใช่ “GA4 พัง” แต่คือวิธีที่ทีมตั้งค่า Key Event จากปุ่ม LINE ตั้งแต่แรกเลือกทางที่รั่วง่าย

GA4 เปิดให้ทำเครื่องหมาย Event เป็น Key Event (ชื่อเดิมคือ Conversion) เพื่อดึงไปวัดผลและส่งต่อให้ Google Ads ได้ แต่จุดที่คนสับสนคือ Event นั้นจะถูกส่งจากตรงไหน ถ้าส่งจากฝั่ง Client คือรันในเบราว์เซอร์ผู้ใช้ผ่าน Google Tag Manager หรือ gtag.js ถ้าส่งจากฝั่ง Server คือยิงผ่าน Measurement Protocol จากเซิร์ฟเวอร์ของธุรกิจเองหรือของระบบที่เชื่อมต่ออยู่ ซึ่งสองทางนี้ให้ผลลัพธ์ที่ต่างกันจริงในทางปฏิบัติ ไม่ใช่แค่ต่างที่เทคนิคเบื้องหลัง

หลายทีมเลือกฝั่ง Client เพราะตั้งง่าย ลากวางใน GTM ได้ในครึ่งวัน แต่ไม่รู้ว่าตัวเลขที่ได้มามีรอยรั่วซ่อนอยู่ตลอดเวลา บางทีมได้ยินคำว่า Server-side มาแล้วรีบเปลี่ยนทั้งระบบทั้งที่ทราฟฟิกยังน้อยมาก ซึ่งเสียเวลาและงบโดยไม่จำเป็น

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

Key Event ต่างจาก Event ธรรมดายังไง ก่อนจะพูดถึงปุ่ม LINE

ใน GA4 ทุกการกระทำบนเว็บถูกเก็บเป็น Event หมด ไม่ว่าจะเลื่อนหน้าเว็บ คลิกเมนู หรือกดปุ่ม LINE แต่ Event ทั้งหมดไม่ได้มีความหมายเท่ากันสำหรับธุรกิจ การเลื่อนหน้าเว็บบอกแค่ว่าคนอ่านเนื้อหา ส่วนการกดปุ่ม LINE บอกว่าคนคนนั้นตั้งใจจะคุยกับร้าน ซึ่งเป็นสัญญาณความตั้งใจที่ต่างกันคนละระดับ

การทำเครื่องหมาย Event ว่าเป็น Key Event คือการบอก GA4 ว่า “Event นี้แหละที่ธุรกิจแคร์” ซึ่งจะถูกดึงไปแสดงในรายงาน Conversion และถ้าเชื่อม Google Ads ไว้ ก็ส่งต่อไปเป็น Conversion Action ให้ระบบ Bidding เรียนรู้จากมันได้ด้วย นี่คือเหตุผลที่การตั้ง Key Event จากปุ่ม LINE ให้ถูกต้องสำคัญกว่าที่หลายคนคิด เพราะมันไม่ได้ส่งผลแค่รายงานสวย ๆ แต่ส่งผลถึงทิศทางที่ระบบโฆษณาไปหาคนที่ “น่าจะกดปุ่ม LINE” เพิ่ม

คำถามคือ Event ที่ว่านี้ ควรถูกยิงจากตรงไหนถึงจะสะท้อนความจริงมากที่สุด และนี่คือจุดที่ทางเลือก Client-side กับ Server-side เริ่มต่างกัน

ฝั่ง Client ยิง Key Event จากปุ่ม LINE ทำงานยังไงจริง ๆ

ฝั่ง Client คือการให้เบราว์เซอร์ของผู้ใช้เป็นคนส่งข้อมูล เมื่อมีคนคลิกปุ่ม LINE, Google Tag Manager ที่ติดตั้งอยู่บนหน้าเว็บจะดักจับ Click ผ่าน Trigger แล้วยิง Event เข้า GA4 ผ่าน gtag.js ทันทีในเบราว์เซอร์เครื่องนั้น ข้อดีคือตั้งค่าเร็ว ไม่ต้องแตะฝั่งเซิร์ฟเวอร์เลย ทีมการตลาดที่ไม่มีนักพัฒนาประจำก็ทำเองได้ผ่าน GTM Interface

แต่จุดอ่อนของทางนี้คือมันพึ่งพาสภาพแวดล้อมของผู้ใช้ทั้งหมด ถ้าคนคนนั้นเปิด Ad Blocker ที่บล็อก Google Tag Manager, ปิด Cookie ของบุคคลที่สาม, ใช้เบราว์เซอร์ที่บล็อก Tracking Script โดยดีฟอลต์ (เช่น Safari บางเวอร์ชันที่เข้มเรื่อง ITP) หรือแค่กดปุ่ม LINE แล้วสลับแอปเร็วจนสคริปต์ยิงไม่ทันจบ ข้อมูลตรงนั้นก็หายไปเงียบ ๆ โดยที่ GA4 ไม่มีทางรู้ว่ามันเคยเกิดขึ้น

ในเชิงตัวเลข ผมเคยเห็นเว็บที่มีสัดส่วนผู้ใช้มือถือสูง (ซึ่งมักสลับแอปไป LINE เร็ว) มี Event ฝั่ง Client หายไปในระดับหนึ่งในห้าถึงหนึ่งในสามของยอดคลิกจริง ตัวเลขนี้เป็นตัวอย่างประกอบกรอบวิเคราะห์เท่านั้น ไม่ใช่สถิติทางการ แต่ทิศทางที่เจอบ่อยคือยิ่งทราฟฟิกมือถือเยอะ ยิ่งมีโอกาสรั่วเยอะตามไปด้วย

ฝั่ง Server ส่ง Key Event จากปุ่ม LINE ต่างจากฝั่ง Client ตรงไหน

ฝั่ง Server คือการให้เซิร์ฟเวอร์ของธุรกิจ (หรือระบบกลางที่เชื่อมต่ออยู่ เช่นระบบวัดผลอย่าง linli ที่รับ Event จากฝั่งเว็บแล้วส่งต่อ) เป็นคนยิง Event เข้า GA4 ผ่าน Measurement Protocol แทนที่จะให้เบราว์เซอร์ผู้ใช้ยิงตรง วิธีนี้ต้องใช้ Client ID ที่จับคู่กับ Session เดิมของผู้ใช้ ร่วมกับ API Secret ของ GA4 Property เพื่อยืนยันตัวตนของการส่งข้อมูล

ข้อดีคือ Event ไม่ผ่านเบราว์เซอร์โดยตรง จึงไม่ถูก Ad Blocker หรือ ITP บล็อกในจุดเดียวกับฝั่ง Client และยังยิงข้อมูลได้ต่อแม้ผู้ใช้ปิดแท็บไปแล้วก็ตาม เพราะเซิร์ฟเวอร์เป็นคนจัดการเอง แต่ก็ต้องบอกตรง ๆ ว่าฝั่ง Server ไม่ใช่คำตอบที่วัดได้ 100 เปอร์เซ็นต์เช่นกัน มันแค่ลดจุดรั่วบางจุดลง ยังมีเงื่อนไขเรื่อง Consent ของผู้ใช้ที่ต้องจัดการให้ถูกต้องตามกฎหมายอยู่ดี

ข้อควรระวังคือถ้า Client ID ที่ส่งไปไม่ตรงกับ Session เดิมของ GA4 ข้อมูลจะกลายเป็น User ใหม่ที่ไม่มีประวัติ Session ก่อนหน้า ทำให้รายงาน Attribution ผิดเพี้ยนได้ นี่คือความเสี่ยงเฉพาะของฝั่ง Server ที่ฝั่ง Client ไม่มี เพราะฝั่ง Client เบราว์เซอร์จัดการ Client ID ให้เองอัตโนมัติอยู่แล้ว

เทียบสองแบบให้เห็นชัด ๆ ในตารางเดียว

กรณีไหนใช้ฝั่ง Client พอแล้วไม่ต้องรีบลงทุนฝั่ง Server

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

ฝั่ง Client ยังเหมาะกับทีมที่ไม่มีนักพัฒนาประจำ หรือธุรกิจที่ใช้ระบบ Landing Page สำเร็จรูปที่ไม่สามารถแก้โค้ดฝั่งเซิร์ฟเวอร์ได้เอง ในกรณีนี้การตั้ง Key Event ผ่าน GTM ยังเป็นทางที่เร็วและคุ้มที่สุด แค่ต้องยอมรับว่าตัวเลขที่เห็นเป็น “ค่าประมาณที่ต่ำกว่าความจริง” ไม่ใช่ตัวเลขเป๊ะ

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

สัญญาณอะไรบอกว่าถึงเวลาต้องขยับไปฝั่ง Server

มีสัญญาณบางอย่างที่บอกว่าธุรกิจเริ่มเสียโอกาสจากการวัดผลไม่ครบ และควรพิจารณาขยับไปฝั่ง Server หรืออย่างน้อยทำควบคู่กันทั้งสองฝั่งเพื่อเทียบตัวเลข

• งบยิงแอดต่อเดือนสูงจนความคลาดเคลื่อนของข้อมูลแม้แค่ 15-20% ก็แปลว่าเงินหลักหมื่นถูกจัดสรรผิดทิศทาง
• ทราฟฟิกส่วนใหญ่มาจากมือถือและมีสัดส่วนสลับไปแอป LINE สูง ซึ่งเป็นจุดที่ฝั่ง Client มักยิงไม่ทัน
• ทีมกำลังใช้ระบบ Smart Bidding ของ Google Ads และต้องการให้ระบบเรียนรู้จากข้อมูลที่ครบและแม่นที่สุดเท่าที่ทำได้
• เคยเทียบยอดกดปุ่ม LINE จริงกับตัวเลขใน GA4 แล้วเจอว่าห่างกันเกินระดับที่ยอมรับได้ต่อเนื่องหลายสัปดาห์
• มีนักพัฒนาหรือระบบกลางอย่าง การส่ง Conversion แบบ Server-to-Server อยู่แล้วในสแตกของธุรกิจ ทำให้ต้นทุนเพิ่มเติมไม่สูงมาก

ข้อผิดพลาดที่เจอบ่อยตอนตั้ง Key Event จากปุ่ม LINE

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

• ทำเครื่องหมาย Event เป็น Key Event ผิดตัว เช่น เผลอเลือก Event การดูหน้าเว็บแทน Event การคลิกปุ่มจริง ทำให้ตัวเลขสูงเกินจริงแบบไม่มีความหมาย
• ตั้ง Trigger ใน GTM ให้ยิงซ้ำเมื่อคนคลิกปุ่มหลายครั้งติดกัน โดยไม่มีการกันซ้ำ ทำให้ 1 คนกลายเป็นหลาย Event
• ลืมทดสอบผ่าน GA4 DebugView ก่อนปล่อยใช้งานจริง ทำให้กว่าจะรู้ว่า Event ยิงไม่เข้าก็เสียโอกาสไปหลายวันหรือหลายสัปดาห์
• ตั้งฝั่ง Server แต่ไม่จับคู่ Client ID ให้ตรงกับ Session เดิม ทำให้ Event เข้าไปเป็นผู้ใช้ใหม่ที่ไม่มีที่มา รายงาน Attribution จึงผิดเพี้ยนโดยไม่มีใครสังเกตทัน

ถ้าจะย้ายจาก Client ไป Server ต้องทำตามลำดับไหน

1. เก็บ Baseline ของตัวเลขฝั่ง Client ไว้ก่อนอย่างน้อย 2-4 สัปดาห์ เพื่อใช้เทียบหลังเปลี่ยน
2. สร้าง API Secret ใน GA4 Admin แล้วส่งต่อให้ทีมเทคนิคที่จะยิง Measurement Protocol
3. ออกแบบวิธีจับคู่ Client ID ให้ตรงกับ Session เดิมของผู้ใช้แต่ละคน ไม่ใช่สุ่มค่าใหม่ทุกครั้ง
4. ทดสอบผ่าน GA4 DebugView ให้เห็น Event เข้าถูกต้องก่อน แล้วค่อยเปิดใช้งานจริงคู่ขนานกับฝั่ง Client
5. รันทั้งสองฝั่งพร้อมกันสักช่วงเพื่อดูว่าตัวเลขต่างกันเท่าไหร่ ก่อนตัดสินใจปิดฝั่งใดฝั่งหนึ่งถาวร

หลังตั้งเสร็จ ต้องเช็คอะไรก่อนเชื่อตัวเลข

การตั้งค่าเสร็จไม่ได้แปลว่าตัวเลขถูกต้องทันที ควรเข้าไปดูใน GA4 Exploration แล้วเทียบจำนวน Key Event ต่อวันกับยอดที่ทีมแอดมิน LINE นับได้จริงจากฝั่ง Audience คนกด LINE อย่างน้อยหนึ่งสัปดาห์ ถ้าตัวเลขทั้งสองฝั่งเริ่มใกล้เคียงกันมากขึ้นถึงจะเรียกว่าตั้งค่าสำเร็จจริง

อีกจุดที่ควรเช็คคือรายงานใน Google Ads หลังเชื่อม Conversion เข้าไปแล้ว ดูว่า Conversion ที่รับเข้ามาตรงกับ Key Event ใน GA4 ไหม เพราะบางครั้งปัญหาไม่ได้อยู่ที่การยิง Event แต่อยู่ที่การเชื่อมต่อระหว่าง GA4 กับ Google Ads เอง ซึ่งเป็นคนละขั้นตอนที่ต้องตรวจแยกกัน

สุดท้ายควรตั้งรอบตรวจสอบซ้ำทุกครั้งที่มีการเปลี่ยนโครงสร้างเว็บ เปลี่ยนปุ่ม LINE ตำแหน่งใหม่ หรือเปลี่ยนผู้ให้บริการ Landing Page เพราะการเปลี่ยนแปลงเหล่านี้มักทำให้ Trigger เดิมใน GTM หลุดโดยไม่มีใครรู้ตัวจนผ่านไปเป็นสัปดาห์

สรุป

การเลือกระหว่างฝั่ง Client กับฝั่ง Server ไม่ใช่คำถามว่าอันไหนถูกกว่าอันไหน แต่เป็นคำถามว่าธุรกิจอยู่ในสเกลไหนและงบแอดที่เสี่ยงต่อความคลาดเคลื่อนของข้อมูลมากแค่ไหน ธุรกิจเล็กที่เพิ่งเริ่มยิงแอดยังใช้ฝั่ง Client ได้สบาย ๆ ส่วนธุรกิจที่งบเยอะและพึ่งพา Smart Bidding ควรมองไปที่ฝั่ง Server อย่างจริงจัง

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

• ฝั่ง Client ตั้งเร็ว เหมาะกับธุรกิจเริ่มต้น แต่รั่วง่ายเมื่อโดน Ad Blocker หรือสลับแอปเร็ว
• ฝั่ง Server แม่นกว่าแต่ต้องมีคนดูแล Client ID และ API Secret ให้ถูกต้อง
• รันคู่ขนานสักช่วงก่อนตัดสินใจย้ายถาวร เพื่อเทียบตัวเลขจริง
• ทดสอบผ่าน GA4 DebugView ทุกครั้งก่อนปล่อยใช้งานจริง ไม่ว่าจะเลือกฝั่งไหน

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