การตรวจสอบทราฟฟิก: วิธีตรวจสอบให้แน่ใจว่าลิงก์นำไปยังโดเมนที่ถูกต้อง

อะไรถือเป็นการเข้าสู่โดเมนที่ถูกต้อง

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

ตรวจสอบไม่เพียงชื่อโดเมน แต่รวมถึงรูปแบบของมันด้วย: www และไม่ใช่ www, HTTP และ HTTPS, โดเมนหลักและซับโดเมน ที่อยู่ site.example, www.site.example และ promo.site.example อาจเป็นของโปรเจกต์เดียวกัน แต่สำหรับเบราว์เซอร์ การวิเคราะห์ และบันทึกแล้ว สิ่งเหล่านี้เป็นโฮสต์ที่แตกต่างกัน

เปิดลิงก์ในลักษณะที่ผู้ชมเปิด

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

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

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

ตรวจสอบห่วงโซ่การเปลี่ยนเส้นทางทั้งหมดในเบราว์เซอร์และผ่าน curl

สำหรับการตรวจสอบทางเทคนิค ให้ใช้ curl พร้อมพารามิเตอร์ -I และ -L: คำสั่งจะแสดงส่วนหัวการตอบสนองและผ่านการเปลี่ยนเส้นทาง มองหาสถานะ 301, 302, 307, 308 และส่วนหัว Location สิ่งเหล่านี้แสดงว่าเซิร์ฟเวอร์นำผู้ใช้ไปยังที่อยู่ใดในแต่ละขั้นตอน

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

1. เปิดใช้งาน Preserve log เพื่อให้รายการไม่ถูกล้างหลังการเปลี่ยนเส้นทาง
2. ปิดแคชเบราว์เซอร์หากจำเป็น
3. เปิดลิงก์เริ่มต้นจากโพสต์หรือวางลงในแท็บใหม่
4. ค้นหาการตอบสนองที่มีสถานะ 3xx
5. เทียบ Request URL ของแต่ละขั้นตอนกับค่า Location
6. ตรวจสอบโดเมนและ URL ของเอกสารสุดท้ายที่มีสถานะ 200

เมื่อใดที่โดเมนเก่าในห่วงโซ่เป็นเรื่องปกติ และเมื่อใดที่เป็นข้อผิดพลาด

โดเมนเก่าในห่วงโซ่ไม่ได้หมายถึงปัญหาเสมอไป หลังการย้าย เส้นทางเช่น old-site.example/stream → site.example/stream เป็นเรื่องปกติ: ที่อยู่เก่ารับคำขอและเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าที่เทียบเท่าของเว็บไซต์ใหม่อย่างถาวร โดเมนปลายทางถูกต้อง เส้นทางยังคงอยู่ และแท็ก UTM ไม่หายไป

บั๊กคือสถานการณ์ที่ old-site.example/stream นำไปยังหน้าหลักของเว็บไซต์ใหม่ ไปยังแลนดิ้งเพจอื่น หรือทำให้ผู้ใช้ยังคงอยู่ในโดเมนเก่า ปัญหาแยกต่างหากเกิดขึ้นเมื่อหลังการเปลี่ยนเส้นทาง สตริงหลังเครื่องหมายคำถามหายไป: ผู้ใช้ไปถึงหน้าที่ถูกต้อง แต่การวิเคราะห์สูญเสีย utm_source, utm_medium และ utm_campaign

ตรวจสอบไม่เพียงโดเมนสุดท้าย แต่รวมถึงเส้นทางและพารามิเตอร์ด้วย การเข้าสู่ site.example โดยไม่มีหน้าที่หรือแท็กที่ต้องการอาจบิดเบือนข้อมูลแคมเปญได้มากพอๆ กับการเข้าสู่โฮสต์ของผู้อื่น

คำนึงถึงการเปลี่ยนเส้นทางด้วย JavaScript และพารามิเตอร์ของลิงก์

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

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

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

ตรวจสอบเบราว์เซอร์ในแอป

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

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

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

เปรียบเทียบการเข้าชมจากภูมิภาคและเงื่อนไขที่แตกต่างกัน

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

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

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

ยืนยันโดเมนใน Yandex Metrica และ GA4

ใน Yandex Metrica ให้ดูรายงานตามหน้าเข้าชมและ URL ของหน้า กรองข้อมูลตามที่อยู่เต็มหรือโดเมนที่ต้องการ จากนั้นเพิ่มเซกเมนต์ตามแท็ก UTM แหล่งที่มา หรือแคมเปญ วิธีนี้จะช่วยให้เห็นว่าโฮสต์ใดที่การเข้าชมเริ่มต้นหลังการวางเฉพาะ

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

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

ตรวจสอบคำขอในบันทึกเซิร์ฟเวอร์

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

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

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

แยกโดเมนหลักและซับโดเมนในรายงาน

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

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

ข้อเสียของการกรองที่เข้มงวดเกินไป: การเปลี่ยนเส้นทางปกติระหว่างซับโดเมนอาจหายไปจากรายงาน และกรวยการขายจะดูเหมือนขาดตอน

เช็กลิสต์การตรวจสอบลิงก์ก่อนการวาง

• เปิดลิงก์จากตำแหน่งที่ผู้ชมจะเห็น
• ตรวจสอบโดเมนปลายทาง เส้นทาง และพารามิเตอร์ในแถบที่อยู่
• ดูห่วงโซ่ 3xx และส่วนหัว Location ผ่าน curl หรือ Network
• ตรวจสอบให้แน่ใจว่าโดเมนเก่ายังคงเส้นทางและแท็ก UTM เมื่อเปลี่ยนเส้นทาง
• ทำการเข้าชมซ้ำในเบราว์เซอร์ในแอป
• ตรวจสอบภูมิภาคอื่นหากใช้กฎทางภูมิศาสตร์
• เทียบ Hostname และแลนดิ้งเพจในการวิเคราะห์หลังการเปิดตัว
• ยืนยันคำขอไปยังโฮสต์ที่ต้องการผ่านบันทึกเซิร์ฟเวอร์

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