Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
Tại sao mã hóa URL không nhất quán lại chia một trang thành nhiều hàng trong Analytics
· Tại sao nó quan trọng
phân tích url-encoding bình thường hóa
%20 và +, %2F và /, %c3 và %C3 đều có thể mô tả cùng một URL nhưng báo cáo coi chúng là các trang khác nhau. Bài đăng này giải thích các biến thể đến từ đâu và cách bình thường hóa chúng trước khi đếm.
Trang đích có sáu URL trong báo cáo — các biến thể cạnh nhau và lưu lượng truy cập mà chúng phân chia
Các nhà phân tích dữ liệu nhận thấy một trang đích xuất hiện dưới dạng sáu URL khác nhau trong bảng điều khiển phân tích. Các trang giống nhau có thể là: /landing?utm_source=email, /landing?utm_source=%65mail, /landing?utm_source=email%20campaign, /landing?utm_source=email+chiến dịch, /landing?utm_source=email%20Chiến dịch, /landing?utm_source=email%2bchiến dịch. Mỗi biến thể được tính là lượt xem trang riêng biệt, lưu lượng truy cập bị phân mảnh. Dữ liệu từ bảng tính, email và biểu mẫu đưa ra các biến thể mã hóa.
Mã hóa không nhất quán bắt nguồn từ nhiều nguồn dữ liệu và chuyển đổi. Liên kết viết tay sử dụng khoảng trống thô hoặc không có mã hóa. Xuất bảng tính tạo ra các URL được mã hóa phần trăm. Ứng dụng khách email xáo trộn hoặc mã hóa lại URL. Chuỗi chuyển hướng bình thường hóa không nhất quán. Tích hợp API, khung JavaScript và mã phân tích áp dụng các quy tắc khác nhau. Khái niệm URL tương tự đi qua các lớp, được mã hóa và mã hóa lại theo cách khác nhau.
Các nguồn biến thể - liên kết viết tay, xuất bảng tính, ứng dụng thư khách và chuỗi chuyển hướng
Trường hợp bằng chữ số hex trình bày vấn đề chuẩn hóa đầu tiên. RFC 3986 chỉ định các chữ số thập lục phân phải viết hoa: %2F chứ không phải %2f. Chữ hoa và chữ thường hex mã hóa các byte giống hệt nhau. So sánh nghiêm ngặt xử lý %2F và %2f một cách khác nhau. Ký tự "e" là %65 sẽ chuẩn hóa thành "e" chưa được mã hóa vì RFC 3986 phân loại các chữ cái là không được bảo vệ. Mã hóa quá mức toàn bộ URL sẽ tạo ra các bản ghi phân tích khác nhau.
Tập hợp không được đặt trước trong RFC 3986 bao gồm: A-Z, a-z, 0-9, dấu gạch ngang, dấu chấm, dấu gạch dưới và dấu ngã. Chúng không bao giờ được mã hóa phần trăm trong các URL được chuẩn hóa. RFC chuẩn hóa chỉ định rằng việc giải mã %41 thành "A" sẽ chuẩn hóa thành "A" chưa được mã hóa. Việc áp dụng điều này trên các URL sẽ loại bỏ mã hóa dư thừa. Các URL như %2f%6c%61%6e%64%69%6e%67 trở thành /landing sau khi giải mã.
Viết hoa chữ số thập lục phân và tập hợp không đặt trước — những gì RFC 3986 nói là tương đương và những gì không
Các ký tự dành riêng không thể thay thế cho nhau và phải duy trì sự khác biệt trong quá trình chuẩn hóa. RFC 3986 dự trữ các phân cách gen (:, /, ?, #, [, ], @) và các phân cách phụ (!, $, &, ', (, ), *, +, ,, ;, =). Chúng có ý nghĩa cấu trúc. Dấu gạch chéo chuyển tiếp trong đường dẫn có chức năng như dấu phân cách và không được mã hóa. Khi cùng một ký tự xuất hiện dưới dạng dữ liệu trong các giá trị truy vấn, ký tự đó sẽ mã hóa thành %2F. Giải mã mù quáng phá vỡ cấu trúc URL.
Các sắc thái bình thường hóa tạo ra những thách thức đòi hỏi sự hiểu biết theo ngữ cảnh. Chỉ giải mã các ký tự không được đặt trước, để lại các ký tự được mã hóa. Các URL như /landing?data=%2F%20%2f vẫn không rõ ràng. Chuỗi truy vấn bắt đầu bằng ? (dành riêng, cấu trúc). Bên trong các giá trị truy vấn, mọi thứ đều có thể xuất hiện—dấu hỏi yêu cầu mã hóa %3F. URL được mã hóa dưới dạng %2f%6c%61%6e%64%69%6e%67%3fkey%3dgiá trị chuẩn hóa thành /landing?key=value.
Các ký tự dành riêng không thể hoán đổi cho nhau - tại sao %2F và / có thể có nghĩa hợp pháp là những thứ khác nhau
Ví dụ đã hoạt động: việc chuẩn hóa sáu biến thể URL thể hiện quá trình chuẩn hóa hoàn toàn. Cơ sở URL đại diện cho /page?utm_source=email&campaign=test. Sáu biến thể: 1) /page?utm_source=email&campaign=test (chuẩn), 2) /page?utm_source=%65%6d%61%69%6c&campaign=test (hex chữ thường), 3) /page?utm_source=email%20&campaign=test (dấu cách trong giá trị), 4) /page?utm_source=email+&campaign=test (dấu cách trong giá trị), 5) /page?utm_source=EMAIL&campaign=test (trường hợp khác), 6) /page?utm_source=email&%63ampaign=test (có tên hex).
Biến thể bình thường hóa 2 yêu cầu sửa các chữ cái hex và giải mã các chữ cái không được đặt trước: %65%6d%61%69%6c trở thành email. Biến thể 4 có dấu cộng yêu cầu nhận biết ngữ cảnh—nếu nguồn là biểu mẫu HTML, dấu cộng có nghĩa là khoảng trắng; nếu không thì dấu cộng là theo nghĩa đen. Biến thể 5 có chữ hoa "EMAIL"; "email" chữ thường là chuẩn vì email không phân biệt chữ hoa chữ thường. Biến thể 6 có %63 (hex cho "c"); giải mã không hạn chế tạo ra "chiến dịch" phù hợp với chuẩn.
Ví dụ hoạt động: chuẩn hóa sáu biến thể của một URL — giải mã các ký tự an toàn, sửa chữ hoa chữ thường và những gì vẫn khác biệt
Triển khai chuẩn hóa trong quy trình—chuẩn hóa khi nhập và giữ giá trị thô—là kiến trúc được đề xuất cho phân tích. Tại các điểm nhập nơi URL nhập cơ sở dữ liệu (điểm cuối ghi nhật ký), hãy áp dụng chuẩn hóa trước khi lưu trữ hoặc lấy khóa xem trang. Chuẩn hóa: 1) Phân tích cú pháp URL thành các thành phần, 2) Giải mã các chuỗi không được đặt trước (sửa chữ hoa chữ thường hex), 3) Chuẩn hóa thứ tự tham số, 4) Tạo biểu mẫu chuẩn để nhóm, 5) Lưu trữ các biểu mẫu chuẩn hóa và giá trị thô. Điều này đảm bảo tất cả sáu biến thể đều được băm vào cùng một khóa nhóm.
Hàm băm dựa trên các URL được chuẩn hóa đảm bảo tất cả các biến thể ánh xạ tới các trang giống hệt nhau trong báo cáo. Nếu hệ thống phân tích thiếu tính năng chuẩn hóa tích hợp thì các lớp kỹ thuật dữ liệu (ETL đường ống) sẽ chuẩn hóa trước khi ghi cơ sở dữ liệu. Đối với các công cụ như Google Analytics, các bộ lọc có thể định cấu hình cho phép nhóm biểu thức chính quy hoặc gửi tiêu đề tách biệt khỏi URL. Hầu hết các phương pháp mạnh mẽ đều bình thường hóa tại các nguồn: khi mã theo dõi gửi URL tới phân tích, hãy đảm bảo các biểu mẫu được chuẩn hóa.
Thực hiện theo quy trình - chuẩn hóa quá trình nhập và giữ giá trị thô, được mô tả dưới dạng mẫu
Nội dung này không bao gồm việc loại bỏ tham số theo dõi và thẻ chuẩn cho SEO, có liên quan nhưng khác nhau. Các thông số theo dõi như utm_source và utm_campaign có thể bị loại khỏi phân tích thành nhóm theo nội dung không phải trả tiền. Đây là logic kinh doanh riêng biệt. HTML thẻ chuẩn hợp nhất lượt xem trang trên các biến thể cho SEO nhưng không ảnh hưởng đến phân tích nội bộ. Các chiến lược toàn diện sử dụng nhiều lớp chống trùng lặp kết hợp cả hai phương pháp.
Hỗ trợ chuẩn hóa không gian phân tích rất khác nhau. Google Analytics tự động xử lý một số hoạt động chuẩn hóa nhưng có thể bỏ sót các biến thể. Các công cụ khác yêu cầu cấu hình thủ công. Nền tảng tìm kiếm phải trả tiền áp dụng cách chuẩn hóa khác nhau cho URL chiến dịch. Nhật ký máy chủ ghi lại các URL khi nhận được mà không cần chuẩn hóa. Chiến lược toàn diện chuẩn hóa tài liệu được áp dụng ở mỗi lớp và dữ liệu thô được bảo tồn để kiểm tra. Bộ mã hóa và giải mã URL giúp kiểm tra các biến thể.
Điều này không bao gồm những gì — chính sách loại bỏ tham số theo dõi và thẻ chuẩn cho SEO
Bài học rút ra: chuẩn hóa trước khi đếm—bộ mã hóa và giải mã URL giúp kiểm tra bất kỳ biến thể nào cho thấy nội dung nó mã hóa và liệu nó có khớp với các dạng chuẩn hay không. Đối với các biến thể phân tích đáng ngờ, hãy dán vào bộ giải mã để kiểm tra kết quả đầu ra được giải mã. Nếu hai URL giải mã thành các dạng giống hệt nhau thì chúng đại diện cho các trang giống hệt nhau và sẽ hợp nhất. Công cụ này hiển thị chính xác những ký tự nào được mã hóa, giá trị hex và kết quả của chúng. Việc kiểm tra này là bước khắc phục sự cố đầu tiên.
Khi khắc phục sự khác biệt trong phân tích, hãy tạo danh sách tất cả các biến thể URL được quan sát và giải mã từng biến thể bằng bộ mã hóa & giải mã URL. So sánh các hình thức được giải mã. Nếu các biểu mẫu khác nhau về nội dung dữ liệu (chẳng hạn như các giá trị utm_source khác nhau), thì chúng là các trang khác nhau về mặt pháp lý. Nếu chúng chỉ khác nhau về mã hóa (như %65mail so với email), thì chúng là những bản sao cần chuẩn hóa. Tài liệu các hình thức kinh điển và thực hiện chuẩn hóa. Bộ mã hóa & giải mã URL cung cấp chẩn đoán; đường ống phân tích cung cấp giải pháp.
Bài học rút ra: chuẩn hóa trước khi đếm — cách bộ mã hóa và giải mã URL giúp bạn kiểm tra bất kỳ biến thể nào để xem nó thực sự mã hóa những gì
Bài học rút ra: chuẩn hóa trước khi đếm—bộ mã hóa và giải mã URL giúp kiểm tra bất kỳ biến thể nào cho thấy nội dung nó mã hóa và liệu nó có khớp với các dạng chuẩn hay không. Đối với các biến thể phân tích đáng ngờ, hãy dán vào bộ giải mã để kiểm tra kết quả đầu ra được giải mã. Nếu hai URL giải mã thành các dạng giống hệt nhau thì chúng đại diện cho các trang giống hệt nhau và sẽ hợp nhất. Công cụ này hiển thị chính xác những ký tự nào được mã hóa, giá trị hex và kết quả của chúng.
Khi khắc phục sự khác biệt trong phân tích, hãy tạo danh sách tất cả các biến thể URL được quan sát và giải mã từng biến thể bằng bộ mã hóa & giải mã URL. So sánh các hình thức được giải mã. Nếu các biểu mẫu khác nhau về nội dung dữ liệu (chẳng hạn như các giá trị utm_source khác nhau), thì chúng là các trang khác nhau về mặt pháp lý. Nếu chúng chỉ khác nhau về mã hóa (như %65mail so với email), thì chúng là những bản sao cần chuẩn hóa. Tài liệu các hình thức kinh điển và thực hiện chuẩn hóa.