เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส

เหตุใดการเข้ารหัส URL ที่ไม่สอดคล้องกันจึงแยกหนึ่งหน้าออกเป็นหลายแถวในการวิเคราะห์

3 กันยายน 2569 · เหตุใดจึงสำคัญ

การวิเคราะห์ การเข้ารหัส URL การทำให้เป็นมาตรฐาน

รูปแบบ URL หกรูปแบบปรากฏเป็นหน้าต่างๆ ในการวิเคราะห์ — ภาพประกอบเวกเตอร์ต้นฉบับ ToolAcre

%20 และ +, %2F และ /, %c3 และ %C3 ทั้งหมดสามารถอธิบาย URL ที่เหมือนกันได้ แต่รายงานจะถือว่าทั้งสองหน้าต่างกัน โพสต์นี้จะอธิบายว่าตัวแปรต่างๆ มาจากไหน และวิธีทำให้ตัวแปรเหล่านั้นเป็นมาตรฐานก่อนนับ

หน้า Landing Page ที่มี URL 6 รายการในรายงาน ได้แก่ รูปแบบต่างๆ เคียงข้างกันและการเข้าชมที่แยกออกจากกัน

นักวิเคราะห์ข้อมูลสังเกตเห็นหน้า Landing Page หนึ่งหน้าปรากฏเป็น URL ที่แตกต่างกันหกรายการในแดชบอร์ดการวิเคราะห์ หน้าเดียวกันอาจเป็น: /landing?utm_source=email, /landing?utm_source=%65mail, /landing?utm_source=email%20campaign, /landing?utm_source=email+campaign, /landing?utm_source=email%20แคมเปญ, /landing?utm_source=email%2bแคมเปญ แต่ละรูปแบบจะนับเป็นการดูหน้าเว็บแยกกัน ทำให้การเข้าชมกระจัดกระจาย ข้อมูลจากสเปรดชีต อีเมล และแบบฟอร์มทำให้เกิดการเข้ารหัสที่หลากหลาย

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

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

ตัวพิมพ์ที่เป็นเลขฐานสิบหกแสดงถึงปัญหาการทำให้เป็นมาตรฐานครั้งแรก RFC 3986 ระบุเลขฐานสิบหกควรเป็นตัวพิมพ์ใหญ่: %2F ไม่ใช่ %2f ตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก hex เข้ารหัสไบต์ที่เหมือนกัน การเปรียบเทียบที่เข้มงวดถือว่า %2F และ %2f แตกต่างกัน อักขระ "e" เป็น %65 ควรทำให้เป็นมาตรฐานเป็น "e" ที่ไม่ได้เข้ารหัส เนื่องจาก RFC 3986 จัดประเภทตัวอักษรเป็นแบบไม่สงวนไว้ การเข้ารหัส URL ทั้งหมดมากเกินไปทำให้เกิดบันทึกการวิเคราะห์ที่แตกต่างกัน

ชุดที่ไม่ได้สงวนไว้ใน RFC 3986 ประกอบด้วย: A-Z, a-z, 0-9 ยัติภังค์ จุด ขีดล่าง และตัวหนอน สิ่งเหล่านี้ไม่ควรเข้ารหัสเป็นเปอร์เซ็นต์ใน URL ที่ทำให้เป็นมาตรฐาน การทำให้เป็นมาตรฐาน RFC ระบุว่า %41 ถอดรหัสเป็น "A" ควรทำให้เป็นมาตรฐานเป็น "A" ที่ไม่ได้เข้ารหัส การใช้สิ่งนี้กับ URL จะลบการเข้ารหัสที่ซ้ำซ้อน URL เช่น %2f%6c%61%6e%64%69%6e%67 จะกลายเป็น /landing หลังจากถอดรหัส

ตัวพิมพ์เป็นเลขฐานสิบหกและชุดที่ไม่ได้สงวนไว้ — สิ่งที่ RFC 3986 บอกว่าเทียบเท่ากับสิ่งใดที่ไม่ใช่

อักขระที่สงวนไว้ไม่สามารถใช้แทนกันได้และต้องคงความแตกต่างระหว่างการทำให้เป็นมาตรฐาน RFC 3986 สงวน gen-delims (:, /, ?, #, [, ], @) และ sub-delims ( !, $, &, ', (, ), *, +, ,, ;, =) สิ่งเหล่านี้มีความหมายเชิงโครงสร้าง เครื่องหมายทับในเส้นทางทำหน้าที่เป็นตัวคั่นและไม่ควรเข้ารหัส เมื่ออักขระเดียวกันปรากฏเป็นข้อมูลในค่าการสืบค้น ควรเข้ารหัสเป็น %2F การถอดรหัสแบบสุ่มสี่สุ่มห้าทำให้โครงสร้าง URL เสียหาย

ความแตกต่างระหว่างการทำให้เป็นมาตรฐานจะสร้างความท้าทายที่ต้องใช้ความเข้าใจในบริบท ถอดรหัสเฉพาะอักขระที่ไม่ได้สงวนไว้ โดยปล่อยให้อักขระที่สงวนไว้ถูกเข้ารหัส URL เช่น /landing?data=%2F%20%2f ยังคงไม่ชัดเจน สตริงการสืบค้นขึ้นต้นด้วย ? (สงวนไว้โครงสร้าง) ภายในค่าข้อความค้นหา ทุกสิ่งสามารถปรากฏขึ้นได้ เครื่องหมายคำถามจำเป็นต้องมีการเข้ารหัส %3F URL ที่เข้ารหัสเป็น %2f%6c%61%6e%64%69%6e%67%3fkey%3dvalue ทำให้เป็น /landing?key=value

อักขระที่สงวนไว้ไม่สามารถใช้แทนกันได้ — เหตุใด %2F และ / จึงอาจหมายถึงสิ่งที่แตกต่างกันอย่างถูกต้องตามกฎหมาย

ตัวอย่างการทำงาน: การทำให้ตัวแปร URL หกตัวเป็นมาตรฐานแสดงให้เห็นถึงการทำให้เป็นมาตรฐานโดยสมบูรณ์ ฐาน URL แสดงถึง /page?utm_source=email&campaign=test หกรูปแบบ: 1) /page?utm_source=email&campaign=test (canonical), 2) /page?utm_source=%65%6d%61%69%6c&campaign=test (ฐานสิบหกตัวพิมพ์เล็ก) 3) /page?utm_source=email%20&campaign=test (เว้นวรรคเป็นค่า), 4) /page?utm_source=email+&campaign=test (บวกเป็นเว้นวรรค), 5) /page?utm_source=EMAIL&campaign=test (กรณีต่างกัน), 6) /page?utm_source=email&%63ampaign=test (เลขฐานสิบหกในชื่อ)

การทำให้ตัวแปรมาตรฐาน 2 ต้องแก้ไขตัวพิมพ์ฐานสิบหกและการถอดรหัสตัวอักษรที่ไม่ได้สงวนไว้: %65%6d%61%69%6c กลายเป็นอีเมล รูปแบบ 4 ที่มีเครื่องหมายบวกจำเป็นต้องมีการรับรู้บริบท หากแหล่งที่มาเป็นรูปแบบ HTML เครื่องหมายบวกหมายถึงช่องว่าง มิฉะนั้น บวกก็คือตัวอักษร ตัวแปร 5 มีตัวพิมพ์ใหญ่ "EMAIL"; "อีเมล" ตัวพิมพ์เล็กเป็นแบบบัญญัติเนื่องจากอีเมลไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่ ตัวแปร 6 มี %63 (ฐานสิบหกสำหรับ "c"); การถอดรหัสแบบไม่สงวนไว้จะสร้าง "แคมเปญ" ที่ตรงกับรูปแบบบัญญัติ

ตัวอย่างการทำงาน: การทำให้ตัวแปรหกตัวเป็นมาตรฐานของ URL หนึ่งตัว — การถอดรหัสอักขระที่ปลอดภัย การแก้ไขตัวพิมพ์ฐานสิบหก และสิ่งที่ยังคงแตกต่าง

การใช้การทำให้เป็นมาตรฐานในไปป์ไลน์—การทำให้เป็นมาตรฐานในการนำเข้าและรักษาค่าดิบ—เป็นสถาปัตยกรรมที่แนะนำสำหรับการวิเคราะห์ ที่จุดนำเข้าที่ URL เข้าสู่ฐานข้อมูล (จุดสิ้นสุดการบันทึก) ให้ใช้การทำให้เป็นมาตรฐานก่อนที่จะจัดเก็บหรือรับคีย์การดูหน้าเว็บ การทำให้เป็นมาตรฐาน: 1) แยกวิเคราะห์ URL ออกเป็นส่วนประกอบ 2) ถอดรหัสลำดับที่ไม่ได้สงวนไว้ (แก้ไขตัวพิมพ์ฐานสิบหก) 3) ทำให้ลำดับพารามิเตอร์เป็นปกติ 4) สร้างรูปแบบมาตรฐานสำหรับการจัดกลุ่ม 5) จัดเก็บรูปแบบมาตรฐานและค่าดิบ สิ่งนี้ทำให้มั่นใจได้ว่าตัวแปรทั้งหกจะแฮชไปยังคีย์กลุ่มเดียวกัน

ฟังก์ชันแฮชตาม URL ที่ทำให้เป็นมาตรฐานช่วยให้มั่นใจได้ว่ารูปแบบทั้งหมดจะแมปกับหน้าที่เหมือนกันในรายงาน หากระบบการวิเคราะห์ขาดการทำให้เป็นมาตรฐานในตัว ชั้นวิศวกรรมข้อมูล (ไปป์ไลน์ ETL) จะทำให้เป็นมาตรฐานก่อนที่จะเขียนฐานข้อมูล สำหรับเครื่องมือเช่น Google Analytics ตัวกรองที่กำหนดค่าได้ช่วยให้จัดกลุ่ม regex หรือส่งชื่อแยกจาก URL ได้ วิธีการที่มีประสิทธิภาพส่วนใหญ่จะทำให้แหล่งที่มาเป็นมาตรฐาน: เมื่อโค้ดติดตามส่ง URL ไปยังการวิเคราะห์ ให้ตรวจสอบให้แน่ใจว่าได้กำหนดรูปแบบมาตรฐานแล้ว

การทำไปป์ไลน์ — ทำให้การนำเข้าเป็นมาตรฐานและรักษาค่าดิบไว้ โดยอธิบายว่าเป็นรูปแบบ

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

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

สิ่งนี้ไม่ครอบคลุม — นโยบายการแยกพารามิเตอร์การติดตามและแท็ก Canonical สำหรับ SEO

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

เมื่อแก้ไขปัญหาความคลาดเคลื่อนของการวิเคราะห์ ให้สร้างรายการตัวแปร URL ที่สังเกตทั้งหมด และถอดรหัสแต่ละรายการด้วยตัวเข้ารหัสและตัวถอดรหัส URL เปรียบเทียบแบบฟอร์มที่ถอดรหัส หากเนื้อหาข้อมูลในรูปแบบแตกต่างกัน (เช่น ค่า utm_source ที่แตกต่างกัน) เนื้อหาเหล่านั้นก็จะเป็นหน้าที่แตกต่างกันอย่างถูกต้องตามกฎหมาย หากต่างกันเพียงการเข้ารหัส (เช่น %65 เมลเทียบกับอีเมล) แสดงว่าซ้ำกันซึ่งจำเป็นต้องทำให้เป็นมาตรฐาน จัดทำเอกสารแบบฟอร์ม Canonical และใช้การทำให้เป็นมาตรฐาน URL ตัวเข้ารหัสและตัวถอดรหัสให้การวินิจฉัย ไปป์ไลน์การวิเคราะห์มอบโซลูชัน