ทำไม Yandex Metrica ไม่แสดงทราฟฟิกบนเว็บไซต์

การไม่มีข้อมูลไม่ได้หมายความว่าไม่มีทราฟฟิกเสมอไป

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

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

วิธีแยกแยะการไม่มีทราฟฟิกออกจากการไม่มีข้อมูล

โดยปกติระบบโฆษณาจะแสดงคลิกบนโฆษณา ส่วนล็อกเซิร์ฟเวอร์จะแสดงการเรียกไปยังเว็บไซต์ ในการตรวจสอบ ให้เปิดบันทึกการเข้าถึงของเซิร์ฟเวอร์และค้นหาหน้าเป้าหมายในช่วงเวลาที่ต้องการ ในล็อก Nginx อาจเป็นคำขอในรูปแบบ: grep "GET /promo" /var/log/nginx/access.log หากพาธเปลี่ยนไปเนื่องจากแท็ก UTM ให้ค้นหา URL โดยไม่มีพารามิเตอร์หรือใช้บางส่วนของที่อยู่แลนดิ้ง

คลิกในระบบโฆษณาไม่เท่ากับการโหลดหน้าเว็บ: ผู้ใช้อาจปิดแท็บ การเชื่อมต่ออาจขาดหาย และลิงก์อาจนำไปยัง URL ที่ไม่สามารถเข้าถึงได้ ล็อกเซิร์ฟเวอร์ก็ไม่เท่ากับการเข้าชมจริง เพราะมีบอท การแสดงตัวอย่างลิงก์ และการตรวจสอบทางเทคนิคปะปนอยู่ แต่หากมี переходыในล็อกแต่ไม่มีใน Metrica ปัญหาน่าจะอยู่ที่เคาน์เตอร์หรือการตั้งค่าของมัน

ความคลาดเคลื่อนระหว่างโฆษณา ล็อก และ Metrica หมายความว่าอย่างไร

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

สำหรับการตรวจสอบที่แม่นยำ ให้เลือกช่วงเวลาสั้น ๆ และแหล่งที่มาเดียว เปรียบเทียบเวลา พาธของหน้า สถานะการตอบกลับ ที่อยู่ IP และ User-Agent ภายในกรอบของกฎการประมวลผลข้อมูลที่ใช้ในโปรเจกต์เท่านั้น การตรวจสอบด้วยมือไม่สะดวกเมื่อมีปริมาณมาก: ช่วยค้นหาความเสียหายได้ แต่ไม่สามารถทดแทนการตรวจสอบอย่างต่อเนื่องได้

โค้ดเคาน์เตอร์หายไปจากบางหน้า

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

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

เว็บไซต์ติดตั้งหมายเลขเคาน์เตอร์อื่น

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

ค้นหาตัวระบุในโค้ดของหน้าและเปรียบเทียบกับหมายเลขในแดชบอร์ด Metrica ในคอนโซลเบราว์เซอร์สามารถรันคำสั่ง: document.documentElement.innerHTML.includes("mc.yandex.ru") คำสั่งนี้จะแสดงว่าที่อยู่ Metrica ปรากฏใน HTML หรือไม่ แต่ไม่ยืนยันว่าสคริปต์ทำงานแล้ว สำหรับสิ่งนั้นต้องตรวจสอบคำขอเครือข่าย

วิธีตรวจสอบการโหลด Metrica ในเบราว์เซอร์

เปิดหน้าในเบราว์เซอร์ที่ไม่มีตัวบล็อก กด F12 ไปที่แท็บ Network และรีเฟรชหน้า ในช่องฟิลเตอร์ให้พิมพ์ mc.yandex.ru เมื่อทำงานปกติควรมีคำขอไปยังที่อยู่สำหรับโหลดสคริปต์และคำขอเก็บข้อมูล ซึ่งโดยปกติมีพาธ metrika/tag.js หรือ watch พร้อมหมายเลขเคาน์เตอร์

จากนั้นเปิดแท็บ Console และตรวจสอบข้อผิดพลาด สัญญาณที่มีประโยชน์ของปัญหา: ข้อความ «Refused to load the script», «blocked by client», «Content Security Policy» หรือข้อผิดพลาด JavaScript ที่เกิดขึ้นก่อนเคาน์เตอร์เริ่มทำงาน การตรวจสอบในเบราว์เซอร์เดียวมีข้อเสีย: ส่วนขยาย เวอร์ชันเบราว์เซอร์ หรือการตั้งค่าเครือข่ายของผู้ใช้แต่ละคนอาจให้ผลลัพธ์ที่แตกต่างกัน

ตัวบล็อกโฆษณาซ่อนการเข้าชมบางส่วน

ส่วนขยายสำหรับบล็อกโฆษณา บริการ DNS ส่วนตัว การป้องกันในตัวของเบราว์เซอร์ และโปรแกรมแอนตี้ไวรัสสามารถหยุดคำขอไปยังระบบวิเคราะห์ ใน Network มักเห็นเป็น blocked by client หน้าเว็บยังเปิดได้ปกติ เซิร์ฟเวอร์บันทึกการเรียก แต่ Metrica ไม่ได้รับข้อมูลเกี่ยวกับการเข้าชม

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

Content Security Policy บล็อกคำขอไปยัง Metrica

ส่วนหัว Content Security Policy จำกัดแหล่งที่มาที่หน้าเว็บสามารถโหลดสคริปต์ รูปภาพ และดำเนินการคำขอเครือข่ายได้ หลังจากเชื่อมต่อ CDN พร็อกซี หรือเสริมความปลอดภัยของเว็บไซต์ เว็บไซต์อาจเริ่มบล็อกการเรียกไปยัง Metrica ในคอนโซลเบราว์เซอร์จะปรากฏข้อความเกี่ยวกับการละเมิด CSP พร้อมระบุที่อยู่ที่ถูกบล็อก mc.yandex.ru

ควรเพิ่มกฎอย่างเจาะจง ไม่ใช่ปิด CSP ทั้งหมด ตัวอย่างไดเรกทีฟในบรรทัดเดียว: script-src 'self' https://mc.yandex.ru; connect-src 'self' https://mc.yandex.ru; img-src 'self' data: https://mc.yandex.ru;

ไม่ควรแทนที่บรรทัดนี้ในส่วนหัวที่มีอยู่โดยไม่คิด เพราะต้องรวมกับแหล่งที่มาที่เว็บไซต์ต้องการอยู่แล้ว หากโค้ดเคาน์เตอร์ถูกแทรกโดยตรงใน HTML สคริปต์แบบ inline อาจต้องมีการอนุญาตแยกผ่าน nonce หรือ hash การเพิ่ม unsafe-inline ง่ายกว่า แต่ข้อเสียคือการป้องกันที่อ่อนแอกว่าต่อการแทรก JavaScript จากภายนอก

การยินยอมคุกกี้ไม่ทำให้เคาน์เตอร์เริ่มทำงาน

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

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

ฟิลเตอร์ของเคาน์เตอร์ตัดการเข้าชมที่ต้องการออก

ในการตั้งค่า Metrica อาจมีฟิลเตอร์ตามที่อยู่ IP โดเมน URL พารามิเตอร์ หรือทราฟฟิกทางเทคนิคทำงานอยู่ โดยปกติจะเพิ่มเพื่อลบการเข้าชมของทีมและการเข้าชมทดสอบ หลังจากเปลี่ยนออฟฟิศ VPN เครือข่ายองค์กร หรือโครงสร้าง URL ฟิลเตอร์ดังกล่าวอาจตัดการเข้าชมที่ไม่ใช่แค่ภายในออกไปแล้ว

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

เปิดช่วงเวลา รายงาน หรือเขตเวลาที่ไม่ถูกต้อง

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

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

การเปลี่ยนเส้นทางและโดเมนเปลี่ยนพาธของผู้เข้าชม

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

ตรวจสอบลำดับด้วยคำสั่ง curl -I -L "https://example.com/promo" และดูสถานะพร้อมที่อยู่ของการเปลี่ยนเส้นทาง คำสั่งจะแสดงการเปลี่ยนเส้นทางฝั่งเซิร์ฟเวอร์ แต่ไม่สามารถทดแทนการทดสอบในเบราว์เซอร์ได้: curl จะไม่เห็นการเปลี่ยนเส้นทางด้วย JavaScript และการบล็อกจากส่วนขยาย ลิงก์ย่อสะดวกในการเผยแพร่ แต่การเปลี่ยนเส้นทางเพิ่มเติมทำให้การวินิจฉัยซับซ้อนขึ้น

SPA ไม่ส่งการดูหน้าเมื่อมีการนำทางภายใน

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

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

เป้าหมายไม่ทำงานแม้มีการเข้าชม

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

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

เช็กลิสต์การวินิจฉัยในห้านาที

1. เปิดลิงก์ที่ทราฟฟิกควรไปถึงในเบราว์เซอร์ปกติที่ไม่มีตัวบล็อก
2. ใน DevTools เปิด Network รีเฟรชหน้า และฟิลเตอร์คำขอตาม mc.yandex.ru
3. ในแท็บ Console ตรวจสอบข้อผิดพลาด JavaScript, CSP และข้อความ blocked by client
4. เปรียบเทียบหมายเลขเคาน์เตอร์ในโค้ดของหน้ากับหมายเลขรายงานในแดชบอร์ด Metrica
5. ตรวจสอบใน access.log การเรียกไปยัง URL ที่ต้องการในช่วงเวลาทดสอบ เช่น grep "GET /promo" /var/log/nginx/access.log
6. เปรียบเทียบล็อกเซิร์ฟเวอร์กับคลิกในระบบโฆษณาโดยใช้ลิงก์เดียวและช่วงเวลาเดียว
7. ตรวจสอบฟิลเตอร์ วันที่ที่เลือก เขตเวลา ซับโดเมน และสถานการณ์การยินยอมคุกกี้
8. สำหรับ SPA ให้ทำการนำทางภายในและยืนยันว่ามีคำขอใหม่ถูกส่งหลังการเปลี่ยนเส้นทาง