Data redaction в GA4 помогает удалять распознанные email и выбранные параметры URL из событий веб-потока до отправки. Настройку нужно проверять на тестовых примерах: это не универсальная очистка всех каналов передачи данных. Официальная справка проверена 27 октября 2026 года. Материал предназначен для команды собственного магазина, управляющей сайтом и аналитикой.

Найдите, какие поля вообще попадают в адреса

Просмотрите маршруты поиска, регистрации, восстановления доступа и оформления заказа. Составьте перечень имён параметров и их назначения, используя вымышленные значения. Не копируйте в рабочий документ настоящие персональные данные покупателей. Проблему лучше устранять в месте формирования ненужного адреса, а настройку аналитики рассматривать как дополнительную границу для конкретного потока событий.

Разделите параметры, необходимые для различения товара, и поля с контактной информацией или служебными значениями. Сокращение числа URL в отчёте решает другую задачу; пример такой нормализации рассмотрен в материале о параметрах карточек. Здесь критерий успеха — отсутствие нежелательных данных в передаваемом событии, а не просто уменьшение числа строк.

Настройте и испытайте правила веб-потока

В нужном Data stream откройте Redact data, включите соответствующие опции и перечислите имена query-параметров. Для email используется распознавание по шаблонам, поэтому возможны как пропуски, так и ошибочное распознавание обычного текста. Для новых ресурсов email-редакция включена по умолчанию; состояние старого ресурса нужно проверить, а не предполагать.

Встроенный тест позволяет увидеть результат обработки введённого текста или URL. Возьмите вымышленный адрес с одним исключаемым параметром и одним обычным товарным параметром. Проверьте, что удаляется именно ожидаемое значение. Затем испытайте вариант с кодированием символов. Не используйте реальные контакты в тестовой строке, даже если цель настройки состоит в их последующем удалении.

Проверьте результат после правил событий

Обработка происходит на стороне клиента после создания или изменения событий и до отправки в Analytics. Поэтому проверяйте конечное событие, а не только исходную ссылку в браузере. Сопоставьте ожидаемые параметры с результатом диагностики DebugView. В приёмке полезно сохранить названия проверенных полей и обезличенные результаты, не дублируя нежелательные значения в отчёте.

Для URL-редакции справка перечисляет определённые поля, включая page_location, page_referrer, page_path, link_url, video_url и form_destination. Это не доказательство обработки любого произвольного текста во всех компонентах сайта. Если разработчик помещает контакт в новое пользовательское поле, нужно отдельно изучить его передачу и устранить причину, а не рассчитывать только на название включённой опции.

Отдельно проверьте серверные и импортируемые данные

Механизм не проверяет HTTP-заголовки и не предотвращает такую передачу через Measurement Protocol или Data Import. Для этих маршрутов нужен самостоятельный контроль источника и состава данных. Настройка веб-потока также не очищает журналы вашего сервера. Зафиксируйте перечень каналов, которые реально проверены, и не распространяйте положительный результат одного браузерного теста на всю инфраструктуру магазина.

Не объявляйте включение Data redaction достаточным выполнением всех требований к данным. Практический итог здесь уже и проверяемее: известные тестовые значения удаляются из ожидаемых событий, нужные товарные признаки сохраняются, ограничения документированы. После добавления формы, виджета или нового способа отправки повторите соответствующие сценарии. Такая проверка поддерживает качество измерения и помогает обнаружить новый канал передачи до массового накопления данных.