GA4 หรือ Matomo: ตัวเลขต่าง 5–10% ยังไม่แปลว่าติดตั้งผิด

GA4 กับ Matomo อาจรายงานยอดการเข้าชมและการดูหน้าต่างกัน 5–10% แม้ตั้งค่าถูกต้อง โดย คำอธิบายของ Matomo ระบุว่าตัวเลขควรมีแนวโน้มใกล้กันเมื่อเปรียบเทียบตัวชี้วัดเดียวกัน ความต่างระดับนี้จึงยังไม่ใช่หลักฐานว่าแท็กตัวใดติดตั้งผิด แต่ก็ไม่ใช่เกณฑ์รับรองการติดตั้งทุกเว็บไซต์: ต้องดูว่าทั้งสองระบบได้รับเหตุการณ์ชุดเดียวกันหรือไม่ และนำเหตุการณ์นั้นไปนับอย่างไร

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

ตัวเลขเดียวกันต้องเริ่มจากหน่วยที่นับตรงกัน

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

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

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

แยกสาเหตุของผลต่างก่อนแก้แท็ก

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

• ความยินยอม: ตรวจว่าระบบจัดการความยินยอมอนุญาตให้แท็กทั้งคู่ทำงานในสถานะเดียวกันหรือไม่ หากแท็กหนึ่งรอการยอมรับ แต่อีกแท็กเริ่มส่งข้อมูลทันที ฐานเหตุการณ์ย่อมต่างกันตั้งแต่ต้น ควรดูทั้งก่อนตัดสินใจ หลังยอมรับ หลังปฏิเสธ และเมื่อผู้เข้าชมเปลี่ยนตัวเลือก เพราะการตั้งค่าที่ถูกต้องต้องสอดคล้องกับวิธีเก็บข้อมูลที่องค์กรกำหนดไว้ด้วย
• คุกกี้และการจดจำผู้เข้าชม: เมื่อคุกกี้ถูกจำกัดหรือลบ ระบบอาจจำการกลับมาเยือนไม่ได้เหมือนเดิม จำนวนผู้ใช้ที่ไม่ซ้ำจึงเปลี่ยนได้แม้จำนวนการดูหน้าใกล้กัน Matomo สามารถใช้วิธีจดจำผู้เข้าชมจากข้อมูลคำขอเมื่อใช้คุกกี้ไม่ได้ภายใต้การตั้งค่าที่เกี่ยวข้อง จึงต้องดูวิธีระบุตัวตนที่เปิดใช้จริง ไม่ควรเหมารวมว่าการนับแบบไม่มีคุกกี้เท่ากับการนับด้วยคุกกี้
• เขตเวลาและช่วงวัน: ตรวจเขตเวลาของพร็อพเพอร์ตี GA4 และเว็บไซต์ใน Matomo พร้อมเวลาเริ่มและสิ้นสุดของรายงาน ความต่างที่กระจุกอยู่ต้นหรือท้ายวันอาจเกิดจากการจัดเหตุการณ์ลงวันคนละวัน การเปรียบเทียบวันซึ่งยังไม่สิ้นสุดยังปนผลจากข้อมูลที่เข้ามาหรือประมวลผลภายหลัง จึงควรใช้ช่วงเวลาที่ปิดแล้วเมื่อหาสาเหตุ
• บอตและตัวกรอง: เทียบกฎยกเว้นทราฟฟิกภายใน IP ที่ถูกตัดออก และการจัดการคำขออัตโนมัติ หากระบบหนึ่งกรองกิจกรรมของทีมงานหรือบอต แต่อีกระบบเก็บไว้ ยอดการเข้าชมจะไม่เท่ากัน บอตบางชนิดรัน JavaScript ได้ จึงไม่ควรถือว่าการใช้แท็กบนหน้าเว็บจะตัดบอตทั้งหมดโดยอัตโนมัติ
• User ID: ตรวจว่าส่งรหัสผู้ใช้หลังล็อกอินไปยังทั้งสองระบบหรือไม่ ส่งตั้งแต่จุดใด และหยุดส่งเมื่อใด การรวมกิจกรรมจากหลายอุปกรณ์อาจต่างกันหากระบบหนึ่งได้รับรหัส แต่อีกระบบเห็นเพียงตัวระบุจากเบราว์เซอร์ ประเด็นนี้มักปรากฏในจำนวนผู้ใช้มากกว่าจำนวนเหตุการณ์ดิบ
• Cardinality หรือจำนวนค่าที่แตกต่างของมิติ: หากมิติอย่างที่อยู่หน้าเว็บมีค่าหลากหลายมาก รายงาน GA4 อาจรวบแถวที่เกินขีดจำกัดเป็น “(other)” ตาม คำอธิบายรูปแบบรายงานของ Google แถวของหน้าบางหน้าอาจไม่ปรากฏแยกกันทั้งที่ข้อมูลยังถูกรวมในรายงาน ควรเทียบยอดรวมก่อน แล้วจึงตรวจมิติและตัวกรองที่ทำให้จำนวนแถวเพิ่ม
• การสุ่มข้อมูล: ตรวจสัญลักษณ์คุณภาพข้อมูลของรายงาน GA4 ที่ใช้จริง โดยเฉพาะคำขอซึ่งประมวลผลเหตุการณ์จำนวนมากหรือใช้มิติละเอียด Matomo ระบุว่าไม่สุ่มข้อมูลที่ติดตามได้ แต่ข้อเท็จจริงนี้ไม่ได้หมายความว่า Matomo จะได้รับทุกเหตุการณ์ที่เกิดบนเว็บไซต์ หากแท็กถูกระงับ บล็อก หรือส่งคำขอไม่สำเร็จ ข้อมูลนั้นก็ไม่เข้าสู่การประมวลผล

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

การสุ่ม การประมาณค่า และแถว “(other)” ไม่ใช่เรื่องเดียวกัน

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

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

ส่วน “(other)” เกี่ยวกับวิธีแสดงมิติที่มีค่าจำนวนมาก ไม่ใช่สัญลักษณ์แทนการสุ่มโดยอัตโนมัติ ตัวอย่างเช่น ร้านค้าที่สร้างที่อยู่หน้าเว็บต่างกันตามตัวเลือกสินค้าและพารามิเตอร์ อาจเห็นชื่อหน้ารายละเอียดบางรายการถูกรวมไว้ในแถวเดียว การอ่านยอดของหน้าที่มองเห็นเพียงบางแถวแล้วเทียบกับรายงาน Matomo ทั้งหมดจะทำให้ดูเหมือนหน้าหาย ทั้งที่กำลังเทียบคนละระดับของรายละเอียด

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

ลำดับตรวจเมื่อสองระบบให้ยอดไม่ตรงกัน

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

1. กำหนดชื่อเมตริก ชื่อเหตุการณ์ ช่วงวัน เขตเวลา มิติ และตัวกรองของรายงานทั้งสองชุดให้ชัด เลือกเว็บไซต์และสภาพแวดล้อมเดียวกัน อย่านำทราฟฟิกจากเว็บทดสอบมาปนกับเว็บใช้งานจริง หากมีหลายโดเมน ให้ระบุว่ารายงานครอบคลุมโดเมนใดบ้าง
2. เลือกเส้นทางที่ทราบแน่ชัด เช่น การเปิดหน้าสินค้า เพิ่มสินค้าในตะกร้า และไปยังหน้ายืนยันคำสั่งซื้อ ดูว่าแท็กทั้งคู่โหลดบนหน้าที่เกี่ยวข้อง และมีคำขอออกเมื่อเกิดการกระทำเดียวกันหรือไม่ ตรวจแท็กเก่าที่อาจยังทำงานอยู่ โดยเฉพาะหลังย้ายไปใช้ระบบจัดการแท็ก
3. ทดสอบสถานะความยินยอมตามที่เว็บไซต์เปิดให้เลือกจริง ตรวจว่าการรับหรือระงับคำขอสอดคล้องกับนโยบายขององค์กร ไม่ควรแก้ให้ยอดสองระบบเท่ากันด้วยการเปิดการติดตามที่เดิมตั้งใจระงับไว้ เพราะยอดที่ใกล้กันไม่มีความหมายหากเงื่อนไขการเก็บข้อมูลเปลี่ยน
4. เทียบกฎจดจำผู้เข้าชม การส่ง User ID และตัวกรองทราฟฟิกภายในหรือบอต ถ้าเหตุการณ์ดิบใกล้กันแต่ผู้ใช้ต่างมาก ให้เริ่มจากการระบุตัวตน ถ้ายอดทุกเมตริกลดลงในหน้าเดียว ให้กลับไปดูการโหลดแท็กและคำขอจากหน้านั้น
5. ตรวจสัญลักษณ์คุณภาพข้อมูลและแถว “(other)” ในรายงาน GA4 ที่นำมาเทียบ หากมีการสุ่ม ให้ลดช่วงวันหรือความละเอียดของคำขอแล้วดูผลใหม่ หากมีแถวรวม ให้หลีกเลี่ยงการสรุปจากรายชื่อหน้าที่แสดงเพียงบางส่วน
6. แยกผลตามหน้า ช่องทาง อุปกรณ์ และช่วงก่อนกับหลังการเปลี่ยนเว็บไซต์ ผลต่างที่เกิดทันทีในส่วนเดียวชี้ไปยังการเปลี่ยนแท็ก ตัวกรอง หรือเส้นทางการใช้งาน ส่วนผลต่างที่ค่อนข้างคงที่ในหลายส่วนควรตรวจนิยามเมตริกและวิธีระบุตัวผู้เข้าชมต่อ

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

เลือกตามการใช้ข้อมูลและงานที่องค์กรรับไหว

หน้า Google Analytics ระบุว่ามีเครื่องมือวิเคราะห์พื้นฐานให้ใช้ฟรี และเชื่อมกับผลิตภัณฑ์อย่าง Google Ads และ Search Console ได้ ทีมที่ใช้ข้อมูลจากเครื่องมือเหล่านี้เพื่อดูผลแคมเปญจึงมีเหตุผลเชิงงานที่จะเลือก GA4 แต่ยังต้องกำหนดเหตุการณ์ สิทธิ์เข้าถึง ระยะเก็บข้อมูล และเงื่อนไขความยินยอมให้เหมาะกับข้อมูลที่เก็บจริง

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

สำหรับองค์กรในไทย การกำกับข้อมูลลูกค้าเป็นคำถามเรื่องการดำเนินงานจริง: เก็บข้อมูลชนิดใด ส่งให้ใคร ผู้ใดเปิดดูได้ เก็บไว้นานเท่าไร และการตั้งค่าความยินยอมทำให้แท็กแต่ละตัวทำงานเมื่อใด การใช้ Matomo แบบติดตั้งเองเพิ่มอำนาจควบคุม แต่ก็เพิ่มหน้าที่ดูแลข้อมูลและระบบ ส่วนการใช้ GA4 ลดงานโครงสร้างพื้นฐาน แต่ต้องจัดการการเข้าถึงและการใช้ข้อมูลผ่านบริการของ Google ให้ตรงกับนโยบายองค์กร

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

อ่านเพิ่มเติม:

• ChatGPT Search หรือ Perplexity: ลิงก์เยอะไม่ได้แปลว่าอ้างอิงแม่น