GA4 Data Redaction: как исключить email и чувствительные параметры из отправки

Настройка GA4 Data Redaction помогает убрать распознанные email и выбранные значения из аналитических событий до отправки. Начните с поиска источника данных: адрес страницы, параметры события, заголовок или серверная интеграция. Затем настройте обработку, проверьте фактический запрос и исправьте место, где ненужные сведения попадают в аналитику.

Один включённый переключатель не подтверждает очистку всей информации о пользователях. Ниже — практическая последовательность для владельца сайта и разработчика. Все адреса, значения и сценарии вымышлены: qa.user@example.com — учебный email, а DEMO_ONLY — тестовая строка, не действующий секрет.

1. Найдите, откуда сведения попадают в событие

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

Согласно справочнику конфигурации GA4, page_location по умолчанию содержит полный URL из document.location, а page_title — заголовок документа. Поэтому адрес почты может попасть в аналитику из URL без специально настроенного события «передать email».

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

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

Первую проверку проводите на вымышленных данных. Для обсуждения достаточно безопасного примера и описания пути значения. Не переносите реальные адреса клиентов в задачи, скриншоты и тестовые запросы: это создаёт дополнительные копии вместо устранения причины.

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

2. Разделите распознавание email и обработку query-параметров

В описании DataRedactionSettings предусмотрены отдельные настройки для email и ключей URL. Первая работает со значениями, похожими на адреса почты, в параметрах событий и свойствах пользователя. Вторая применяет правила к указанным именам query-параметров.

Это разные признаки. Значение qa.user@example.com похоже на email независимо от названия поля. Строка DEMO_ONLY на email не похожа, но может находиться в URL под ключом, который вы явно добавили в обработку. Нельзя рассчитывать, что распознавание почты автоматически найдёт телефоны, имена и произвольные токены.

По справке Data Redaction, механизм выполняется на клиенте после клиентского создания или изменения событий и перед отправкой. Он доступен для веб-потоков. Для URL перечислены поля page_location, page_referrer, page_path, link_url, video_url и form_destination.

Распознавание email выполняется по шаблонам с возможными пропусками и ложными срабатываниями. Поэтому результат нужно проверять на формах записи, встречающихся именно в вашем проекте. Не используйте слово «автоматически» как доказательство, что все нежелательные сведения исчезли.

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

Откройте Admin → Data streams → нужный веб-поток → Events → Redact data. Нужна роль Editor или выше. Включите выбранные опции; имена query-параметров добавляйте отдельно через Enter.

В новых свойствах GA4 обработка email включена по умолчанию; для свойств, созданных до появления функции, её требуется включить отдельно. Фактическое состояние всё равно проверьте. Настройка одного потока не заменяет проверку остальных потоков, куда ваш сайт отправляет события.

Для учебного сценария внесите два ключа: email и reset_token. В список нужны имена параметров, а не полный адрес, не email человека и не вся строка reset_token=DEMO_ONLY. Отдельно зафиксируйте, почему каждый ключ выбран и где он появляется.

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

Если доступен только просмотр, подготовьте точный перечень изменений для владельца настройки. Полезная заявка содержит поток, два переключателя, список ключей и тестовые ожидания. Формулировки «включить защиту персональных данных» недостаточно для однозначной реализации.

4. Не путайте обработку значения с удалением всего URL

Query-параметры находятся после знака вопроса и образуют пары имени и значения. Путь страницы, фрагмент адреса и произвольное поле события — другие части данных. Список query-ключей не является общей командой «удалить везде любую строку с таким названием».

В примере интерфейса Google адрес сохраняется, а выбранные значения заменяются на (redacted). Значит, нельзя обещать, что из отчёта исчезнет целый URL или даже имя параметра. Если само имя раскрывает нежелательные сведения, меняйте источник формирования адреса.

В Admin API указано сопоставление ключей без учёта регистра. Тем не менее включите в проверку реальное написание ключа, его кодирование и повторения, если они встречаются на сайте. Похожее название не обязательно означает тот же параметр: email и customer_email — разные имена.

Особенно важно различать URL-ключ и параметр события. Добавление reset_token в список URL не означает удаления одноимённого самостоятельного поля, которое разработчик отправляет с событием. Такой перенос значения нужно убрать в коде аналитики.

Документируйте ожидаемый результат по каждому источнику: маскирование почты, обработка конкретного ключа или полное исключение ненужного поля до сбора. Это предотвращает ситуацию, когда разработчик и аналитик считают одну настройку решением разных задач.

5. Проверьте настройку на безопасном примере

В Test data redaction вставьте вымышленный URL и нажмите Preview redacted data. Процентное кодирование query-параметров поддерживается. Исходная строка учебного сценария:

https://example.com/finish?email=qa.user%40example.com&reset_token=DEMO_ONLY&lang=ru

При включённой обработке и выбранных ключах ориентир для предпросмотра:

https://example.com/finish?email=(redacted)&reset_token=(redacted)&lang=ru

Параметр языка оставлен намеренно: он показывает, что проверяется избирательная обработка, а не потеря всей строки. Это учебное ожидаемое представление, а не результат проверки вашего сайта. Фактический сетевой запрос необходимо изучить отдельно.

Не отключайте обработку в рабочем потоке ради снимка «до». Исходное поведение можно воспроизвести в изолированной тестовой настройке с вымышленными значениями. Если старого безопасного примера нет, достаточно зафиксировать входную строку и ожидаемое содержимое после изменения.

Предпросмотр подтверждает работу выбранного правила на введённом образце. Он не доказывает, что нужный поток установлен на всех страницах, что отсутствует второй тег или что серверная интеграция отправляет такие же данные.

6. Посмотрите, что действительно уходит из браузера

Откройте DevTools до выполнения контрольного действия. В документации панели Network описаны сохранение журнала через Preserve log и просмотр содержимого запроса во вкладке Payload. Для параметров доступны исходное и декодированное представления.

1. Очистите журнал и откройте тестовый сценарий с вымышленными значениями.
2. Найдите запрос аналитической интеграции по известному получателю и контрольному действию.
3. Убедитесь, что проверяете нужный поток и нужное событие.
4. В Payload сопоставьте передаваемый URL и остальные значения с ожидаемыми.
5. Проверьте отсутствие исходных контрольных строк и сохранение безопасного параметра.

Ищите значение во всём содержимом запроса, а не только в одном ожидаемом поле. Транспортное представление может отличаться от названий в интерфейсе GA4. Символ @ в исходной строке может выглядеть как %40; переключение на декодированный вид помогает не пропустить совпадение.

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

Не публикуйте полный сетевой журнал без проверки содержимого. Для отчёта достаточно обезличенного фрагмента с тестовой строкой, именем события и итогом. В соседних запросах могут находиться сведения, которые не относятся к диагностике.

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

7. Добавьте проверки границ, а не только удобного примера

Учебный набор ниже состоит из шести проверок. Первые четыре проверяют обработку или сохранение нужного значения. Последние две показывают, где одного списка query-ключей недостаточно. Все строки остаются вымышленными.

Проверка	Контрольный ввод	Что оценить
Email в URL	email=qa.user%40example.com	Исходный адрес не уходит
Другой регистр ключа	RESET_TOKEN=DEMO_ONLY	Правило для выбранного ключа применяется
Email в значении события	sample_note: qa.user@example.com	Распознавание почты проверено
Безопасный параметр	lang=ru	Полезное значение сохранилось
Отдельное поле события	reset_token: DEMO_ONLY	Нужна правка источника события
Значение в пути URL	/finish/DEMO_ONLY	Query-правило не является очисткой пути

Успех первых проверок не компенсирует оставшееся ненужное поле. После исправления источника повторите весь набор: отсутствие контрольной строки должно сопровождаться сохранением самого события и нужных измерений.

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

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

8. Отдельно проверьте заголовки и серверные отправки

Data Redaction не проверяет HTTP-заголовки, включая Referer. Параметр события page_referrer и заголовок запроса с похожим названием — разные объекты. Нельзя переносить положительный результат проверки одного на другой.

Measurement Protocol позволяет отправлять события HTTP-запросами непосредственно на серверы Analytics. Клиентская настройка Data Redaction не предотвращает передачу PII этим путём. Для серверного отправителя нужна собственная проверка состава данных до запроса.

Аналогично проверяйте импорт событий через Data Import. Подготовка CSV и его загрузка образуют отдельный маршрут. Настройка веб-потока не является фильтром содержимого импортируемого файла.

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

Этот механизм также не меняет адрес в браузере, уже созданные серверные журналы и запросы других систем. Для каждого назначения данных нужен собственный контроль. Переключатель GA4 не следует считать общей очисткой трафика сайта.

9. Исправьте источник, сохранив полезную аналитику

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

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

Если разработчик переопределяет page_location или page_title, проверьте порядок выполнения. Безопасное значение должно использоваться уже при первом соответствующем событии. Правка, сработавшая после отправки, не отменяет предыдущий запрос. Для приложения с переходами без перезагрузки проверьте также последующие маршруты.

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

Переименование параметра, кодирование или хеширование значения сами по себе не подтверждают устранение проблемы. Решение должно описывать, какие сведения нужны, откуда они берутся и почему их передают. Изменение внешнего вида строки не заменяет этот разбор.

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

10. Дополните Network проверкой DebugView

В DebugView можно смотреть события и параметры, которые получает Analytics. Google рекомендует для диагностики включать отладку на собственном устройстве; один из способов — Tag Assistant. Это помогает отделить контрольный сценарий от остального потока.

Найдите своё событие и сопоставьте его с сетевой записью. Имя, момент действия и безопасные контрольные признаки должны соответствовать тесту. Отсутствие исходного email в одном отчёте не объясняет, почему его не видно: значение могло быть очищено, не отправлено или попасть в другой поток.

Результат оформляйте конкретно: «В проверенном событии после изменения исходная строка отсутствует, параметр языка сохранён». Не расширяйте его до утверждения «вся аналитика больше не получает персональные данные». Для такого вывода потребуется гораздо более широкий охват источников.

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

11. Разберите уже собранные данные отдельно

Предотвращение новых отправок не является ретроактивной очисткой истории. Если нежелательные значения уже попали в Analytics, сначала остановите их дальнейшее поступление и определите охват: период, события, параметры и связанные выгрузки.

Для исторических данных существует отдельная процедура Data-deletion requests. Она позволяет запросить удаление определённого текстового содержимого; область и последствия нужно проверить до запуска. Не выбирайте максимально широкое удаление, не понимая, какие полезные данные оно затронет.

Само скрытие измерения в отчёте не равно удалению собранного содержимого. Для импорта также важно различать удаление источника загрузки и удаление уже импортированных событий: документация Google прямо разделяет эти действия.

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

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

12. Сделайте проверку частью выпуска изменений

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

Критерий приёмки должен быть наблюдаемым: событие отправляется в нужный поток, исходные контрольные значения отсутствуют, разрешённые признаки сохранены, серверные пути проверены отдельно. Если часть маршрутов не исследована, явно отметьте это вместо формального завершения задачи.

Так Data Redaction остаётся дополнительным уровнем защиты, а команда контролирует причины появления данных. Владелец получает понятный результат: какие сведения исключены, где это проверено и какие изменения потребуют повторной проверки.

Подключите SiteGuard для внешнего HTTP-контроля доступности важных страниц. Содержимое запросов аналитики проверяйте отдельным процессом.