Инструменты разработчика · Кодер и декодер URL
Почему противоречивая кодировка URL разбивает одну страницу на множество строк в аналитике
· Почему это важно
аналитика URL-кодировка нормализация
%20 и +, %2F и /, %c3 и %C3 могут описывать один и тот же URL, но в отчетах они рассматриваются как разные страницы. В этом посте объясняется, откуда берутся варианты и как их нормализовать перед подсчетом.
Лендинг с шестью URL-адресами в отчете — варианты рядом и трафик, который они разделяют
Аналитики данных заметили, что одна целевая страница отображается в виде шести разных 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. Шестнадцатеричные прописные и строчные буквы кодируют одинаковые байты. Строгое сравнение обрабатывает %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 резервирует ген-разделители (:, /, ?, #, [, ], @) и подразделители (!, $, &, ', (, ), *, +, ,, ;, =). Они имеют структурное значение. Косая черта в путях действует как разделитель и не должна кодироваться. Когда один и тот же символ появляется в качестве данных в значениях запроса, он должен кодироваться как %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 (канонический), 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, настраиваемые фильтры позволяют группировать регулярные выражения или отправлять заголовки отдельно от URL-адресов. Наиболее надежные подходы нормализуются в источниках: когда код отслеживания отправляет URL-адреса в аналитику, убедитесь, что формы канонизированы.
Делаем это в конвейере — нормализуем при приеме и сохраняем необработанное значение, описанное как шаблон.
Сюда не входит удаление параметров отслеживания и канонические теги для SEO, которые связаны, но различны. Параметры отслеживания, такие как utm_source и utm_campaign, могут быть удалены из аналитики и сгруппированы по органическому контенту. Это отдельная бизнес-логика. Канонические теги HTML объединяют просмотры страниц по вариантам для SEO, но не влияют на внутреннюю аналитику. Комплексные стратегии используют несколько уровней дедупликации, сочетая оба подхода.
Поддержка нормализации аналитического пространства сильно различается. Google Analytics автоматически выполняет некоторую нормализацию, но может пропускать варианты. Другие инструменты требуют ручной настройки. Платформы платного поиска применяют различную нормализацию к URL-адресам кампаний. Журналы сервера записывают URL-адреса как полученные без нормализации. Комплексные стратегии документируют нормализацию, применяемую на каждом уровне, и сохраняют необработанные данные для аудита. Кодер и декодер URL помогают проверять варианты.
Что здесь не распространяется — политики удаления параметров отслеживания и канонические теги для SEO.
Вывод: нормализуйте перед подсчетом — кодировщик и декодер URL помогают проверить любой вариант, показывая, что он кодирует и соответствует ли он каноническим формам. Если есть подозрительные варианты аналитики, вставьте их в декодеры, проверяющие декодированные выходные данные. Если два URL-адреса декодируются в идентичные формы, они представляют собой идентичные страницы и должны быть объединены. Инструмент показывает, какие именно символы кодируются, их шестнадцатеричные значения и результаты. Эта проверка является первым шагом по устранению неполадок.
При устранении расхождений в аналитике создайте списки всех наблюдаемых вариантов URL и декодируйте каждый из них с помощью кодера и декодера URL. Сравните расшифрованные формы. Если формы различаются по содержанию данных (например, разные значения utm_source), это действительно разные страницы. Если они отличаются только кодировкой (например, %65mail и электронная почта), это дубликаты, требующие нормализации. Документируйте канонические формы и реализуйте нормализацию. URL кодер и декодер обеспечивают диагностику; конвейер аналитики предоставляет решение.
Вывод: нормализуйте, прежде чем считать — как кодировщик и декодер URL помогают вам проверить любой вариант, чтобы увидеть, что он на самом деле кодирует.
Вывод: нормализуйте перед подсчетом — кодировщик и декодер URL помогают проверить любой вариант, показывая, что он кодирует и соответствует ли он каноническим формам. Если есть подозрительные варианты аналитики, вставьте их в декодеры, проверяющие декодированные выходные данные. Если два URL-адреса декодируются в идентичные формы, они представляют собой идентичные страницы и должны быть объединены. Инструмент показывает, какие именно символы кодируются, их шестнадцатеричные значения и результаты.
При устранении расхождений в аналитике создайте списки всех наблюдаемых вариантов URL и декодируйте каждый из них с помощью кодера и декодера URL. Сравните расшифрованные формы. Если формы различаются по содержанию данных (например, разные значения utm_source), это действительно разные страницы. Если они отличаются только кодировкой (например, %65mail и электронная почта), это дубликаты, требующие нормализации. Документируйте канонические формы и реализуйте нормализацию.