Аудит утечек данных в Google Analytics: 8 рисков за 2 дня
Коротко: Утечки данных в Google Analytics — это не про взлом, а про дыры в настройке: персональные данные в URL, незамаскированные IP, лишние доступы и сторонние скрипты, тянущие сырьё наружу. За пару дней реально проверить 8 ключевых рисков: PII в параметрах, права пользователей, передачу данных третьим сторонам, настройки хранения, фильтры и измерения. Аудит экономит от штрафов и не даёт сливать конверсии и KPI наружу.
Содержание
- Почему данные в Google Analytics вообще утекают?
- Что такое PII и почему это главная боль аналитики?
- Как за 2 дня проверить 8 рисков: план аудита
- Какие риски связаны с доступами и интеграциями?
- Чем Яндекс.Метрика отличается по части безопасности данных?
- Как закрыть дыры и держать дашборд в чистоте?
- Частые вопросы
Почему данные в Google Analytics вообще утекают?
Когда говорят «утечка данных в аналитике», большинство представляет хакера в капюшоне, который ломает аккаунт. На практике всё скучнее и обиднее: данные утекают сами, потому что их туда отправили руками. Чаще всего — случайно.
Мы в DS495 разбирали чужие настройки Google Analytics, и в значительной части из них находили что-то, что отправлять туда категорически нельзя. Email в URL, номер заказа вместе с телефоном, иногда даже фрагменты паспортных данных в параметрах страницы. Никто не делал этого специально — просто разработчик добавил параметр в адрес, а аналитика его честно проглотила.
Логика простая: Google Analytics собирает всё, что ему дают. Он не фильтрует за вас личные данные. Если ваш сайт после оформления заказа делает редирект на /thanks?email=ivan@mail.ru, эта строка уедет в отчёты и будет там жить.
Аналитика — как кладовка без двери. Что положили, то и хранится. И если вы туда зачем-то засунули чужие персональные данные, отвечать за это будете вы, а не Google.
Откуда чаще всего лезут проблемы
- URL с параметрами. Поиск по сайту, формы через GET, реферальные ссылки с зашитым ID клиента.
- Слишком щедрая настройка событий. Когда в свойствах события зачем-то прокидывают весь объект пользователя.
- Сторонние теги в контейнере. Десяток скриптов в Tag Manager, половину из которых никто не помнит зачем поставил.
- Открытые доступы. Бывший подрядчик, у которого до сих пор есть права администратора.
И вот тут начинается интересное. Потому что данные, которые вы собрали неправильно, нельзя просто «развидеть». Их нужно вычистить, а исторические — иногда и удалить полностью. А это уже про репутацию, про закон и про доверие пользователей.
Что такое PII и почему это главная боль аналитики?
PII — это Personally Identifiable Information, персонально идентифицирующая информация. Простыми словами: всё, по чему конкретного человека можно вычислить. Имя, email, телефон, точный адрес, номер карты, иногда даже связка «город + дата рождения + пол».
Правила Google Analytics прямо запрещают отправлять туда PII. Не «не рекомендуют», а запрещают. И если они это обнаружат, аккаунт могут просто заблокировать — вместе со всей вашей накопленной аналитикой за годы. Представьте: вы строили дашборды, считали KPI, гоняли A/B тесты, а потом в один день всё это превращается в тыкву.
Что считается PII, а что нет
| Можно отправлять | Нельзя отправлять (PII) |
|---|---|
| ID пользователя (хешированный, обезличенный) | Email в любом виде |
| Сегмент аудитории («новые клиенты») | Номер телефона |
| Тип устройства, браузер | ФИО |
| Город (без точного адреса) | Точный адрес доставки |
| Сумма заказа | Номер банковской карты |
| Категория товара | Паспортные данные, СНИЛС |
Хитрость в том, что PII любит прятаться. Вы можете быть уверены, что ничего лишнего не отправляете, а на деле email сидит в параметре utm_content, потому что маркетолог собрал письмо с персонализированными ссылками. И теперь у вас в отчётах десятки адресов подписчиков.
По нашему опыту, самое частое место утечки PII — это страница «спасибо за заказ». Туда любят пихать всё подряд, считая её технической. А она индексируется аналитикой как обычная.
Чем это грозит на практике
- Блокировкой аккаунта. Без предупреждения и без права на восстановление данных.
- Штрафами по закону о персональных данных. В России это 152-ФЗ, и ответственность за нарушения ужесточается.
- Репутационными потерями. Если выяснится, что вы сливали данные клиентов в чужие системы.
- Кривой аналитикой. Email вместо ID ломает подсчёт уникальных пользователей и портит конверсию в отчётах.
Последний пункт многие недооценивают. А зря: когда один человек оставил три разных email в трёх формах, аналитика посчитает его как трёх разных людей. И ваш KPI по конверсии превратится в фантазию.
Как за 2 дня проверить 8 рисков: план аудита
Теперь к делу. Полный аудит утечек данных реально провести за два рабочих дня, если действовать по структуре, а не метаться по настройкам. Мы обычно разбиваем процесс на два этапа: первый день — поиск, второй — закрытие дыр.
День первый: ищем, где течёт
Вот восемь рисков, которые нужно прогнать. Идём по порядку, ничего не пропускаем. Время в таблице — ориентировочное.
| № | Риск | Где смотреть | Время |
|---|---|---|---|
| 1 | PII в URL и параметрах | Отчёт «Страницы», поиск по @ | ~40 мин |
| 2 | PII в событиях и параметрах | Конструктор событий, DebugView | ~60 мин |
| 3 | Лишние доступы пользователей | Администрирование → Доступ | ~20 мин |
| 4 | Незамаскированный IP | Настройки сбора данных | ~15 мин |
| 5 | Передача данных третьим сторонам | Связи и интеграции | ~30 мин |
| 6 | Сторонние теги в Tag Manager | Контейнер GTM | ~40 мин |
| 7 | Срок хранения данных | Настройки хранения | ~10 мин |
| 8 | Открытый доступ к дашбордам и BI | Looker Studio / BI-система | ~30 мин |
Пошаговая инструкция: проверка PII в URL
Это самый частый и самый опасный риск, поэтому покажем на нём весь принцип.
- Откройте отчёт по страницам (путь страницы и экрана).
- В поиске по таблице введите символ
@— так вы вытащите все URL с email. - Повторите поиск по словам
email,phone,tel,name,token. - Если что-то нашлось — фиксируйте каждый URL в таблицу аудита.
- Проверьте параметры запроса:
?в адресах часто прячет персональные данные. - Загляните в отчёт по внутреннему поиску — там пользователи иногда вбивают свои же данные.
На этом этапе многие выдыхают: «у нас чисто». Не спешите. Проверьте исторические данные хотя бы за полгода — утечка могла случиться разово, когда выкатывали новую форму, а потом её поправили. Но данные-то остались.
Нужна помощь с этой задачей? Команда DS495 решит её под ключ. Обсудить проект →
День второй: закрываем дыры
Второй день — это правки. По каждому найденному риску заводим задачу и закрываем. Тут уже не про поиск, а про настройку фильтров, удаление лишних доступов и переписывание событий. Подробно — в шестом разделе.
Какие риски связаны с доступами и интеграциями?
Значительная часть утечек — это не про сами данные, а про то, кто к ним имеет доступ. Можно идеально настроить сбор, но если права администратора есть у пяти человек, двое из которых уже не работают в компании, — у вас проблема.
Доступы: кто и зачем
Зайдите в раздел управления доступом и честно посмотрите на список. По нашему опыту, типичная картина выглядит так:
- Один-два реальных администратора, которым доступ нужен.
- Бывший подрядчик с правами «администратор» — забыли отозвать.
- Маркетолог, которому хватило бы прав «аналитик», но дали полный доступ «на всякий случай».
- Личный gmail-аккаунт сотрудника вместо корпоративного — классика.
Каждый лишний доступ — это потенциальная точка утечки. Уволился человек обиженным, выгрузил всю базу конверсий конкуренту — и вот ваши данные про A/B тесты и эффективные связки уже у соседей.
Интеграции и передача данных третьим сторонам
Google Analytics редко живёт в одиночестве. Он связан с рекламными кабинетами, с BI-системами, с CRM. Каждая связь — это канал, по которому данные текут наружу. И не всегда туда, куда вы думаете.
| Интеграция | Что утекает | Уровень риска |
|---|---|---|
| Рекламные кабинеты | Аудитории, конверсии | Средний |
| BI-системы (Looker, Power BI) | Сырые выгрузки, KPI | Высокий |
| Сторонние трекеры в GTM | Всё, что видит страница | Очень высокий |
| CRM через коннекторы | Связка ID и контактов | Высокий |
Особенно внимательно смотрите на сторонние теги в Tag Manager. Иногда там сидят скрипты, про которые никто не помнит. Каждый такой тег имеет доступ ко всему содержимому страницы — а значит, может читать формы, заполненные поля и куки. Это самый опасный канал, потому что вы его не контролируете.
Правило простое: если вы не можете объяснить, зачем в контейнере конкретный тег и что он отправляет — удаляйте. Тег, назначение которого никто не помнит, — это не аналитика, а дыра.
Чем Яндекс.Метрика отличается по части безопасности данных?
Раз уж мы в России, нельзя обойти Яндекс.Метрику. Многие используют её параллельно с Google Analytics, и логика рисков там похожая, но есть нюансы.
Главное отличие — данные Метрики хранятся на серверах в России, что упрощает соответствие 152-ФЗ. Это не значит, что Метрика автоматически безопаснее. PII в URL утечёт туда точно так же, просто отвечать вы будете перед российским регулятором, который ближе и реальнее.
Где Метрика рискованнее
У Метрики есть Вебвизор — запись действий пользователя на странице. Штука полезная для UX-анализа, но опасная: если не настроить маскирование полей, Вебвизор запишет, как человек вводит свой телефон, email и данные карты прямо в форму. И вы получите видео с чужими персональными данными.
- Маскируйте поля ввода. Все формы с персональными данными должны быть закрыты атрибутом маскирования.
- Отключайте запись чувствительных страниц. Страницы оплаты и личного кабинета — не место для Вебвизора.
- Проверяйте доступ к записям. Видео сессий — это PII в чистом виде.
По части дашбордов и BI логика одинаковая: и Google Analytics, и Яндекс.Метрику можно выгружать во внешние системы, и там данные часто оказываются менее защищёнными, чем в самих сервисах аналитики. Выгрузили сырьё в гугл-таблицу, расшарили по ссылке «всем, у кого есть ссылка» — и вот ваши конверсии уже гуляют по интернету.
Сравнение по ключевым параметрам
| Параметр | Google Analytics | Яндекс.Метрика |
|---|---|---|
| Где хранятся данные | Серверы Google | Серверы в России |
| Запрет на PII | Жёсткий, блокировка аккаунта | Есть, но мягче |
| Запись сессий | Через сторонние сервисы | Встроенный Вебвизор |
| Маскирование IP | По умолчанию в GA4 | Настраивается |
| Соответствие 152-ФЗ | Спорно | Проще обосновать |
Мы обычно советуем не выбирать между ними по принципу «что безопаснее», а правильно настроить обе системы. Потому что риск создаёт не сервис, а то, как вы с ним обращаетесь.
Как закрыть дыры и держать дашборд в чистоте?
Нашли проблемы — теперь чиним. Разберём по основным рискам, что конкретно делать.
Чистим PII
Самое срочное. Алгоритм такой:
- Настройте фильтры или правила, которые вырезают параметры с PII до того, как данные попадут в отчёты.
- Перепишите URL на сайте: персональные данные не должны попадать в адресную строку. Используйте POST-формы вместо GET.
- Если в исторических данных уже есть PII — оформите запрос на удаление через инструменты сервиса. Да, это может стоить части аналитики, но альтернатива хуже.
- Замените email и телефоны на обезличенные ID везде, где это технически нужно для связки данных.
Наводим порядок в доступах
Это делается довольно быстро, а защищает надолго:
- Отзовите все доступы, которые не можете объяснить.
- Понизьте права тем, кому не нужен полный доступ. Маркетологу обычно хватает уровня «чтение и анализ».
- Переведите всех на корпоративные аккаунты. Личные gmail — это риск.
- Заведите регламент: при увольнении сотрудника доступ отзывается в тот же день.
Защищаем дашборды и BI
Дашборд — это место, где сырые данные превращаются в красивые KPI. И именно поэтому он часто оказывается самым уязвимым: его расшаривают коллегам, клиентам, подрядчикам.
Дашборд с реальными цифрами по конверсии и выручке — это коммерческая тайна. Относитесь к ссылке на него как к ключам от сейфа. Не раздавайте «всем, у кого есть ссылка».
- Используйте доступ по конкретным email, а не публичные ссылки.
- Разделяйте дашборды: клиенту — урезанная версия без чувствительных метрик.
- Регулярно пересматривайте, у кого есть доступ к BI-отчётам.
- Не выгружайте сырьё с PII в гугл-таблицы и публичные хранилища.
Как поддерживать чистоту дальше
Аудит — это не разовая акция. Утечки появляются снова: добавили новую форму, подключили новый трекер, запустили новый A/B тест с персонализацией. Поэтому мы рекомендуем проводить мини-аудит раз в квартал. Это несколько часов работы, которые экономят месяцы разгребания последствий.
Заведите простой чек-лист и проходите по нему после каждого крупного релиза. Восемь пунктов из третьего раздела — отличная основа. Добавьте проверку новых событий и тегов, и этого хватит, чтобы спать спокойно.
И помните: чистая аналитика — это не только про безопасность. Это ещё и про точность. Когда в данных нет мусора и дублей, ваши KPI отражают реальность, A/B тесты дают честные результаты, а конверсия считается так, как есть на самом деле. Безопасность и качество данных здесь идут рука об руку.
Частые вопросы
В: Заблокируют ли аккаунт Google Analytics, если найдут один email в URL?
О: Риск реальный, хотя за единичный случай блокируют редко. Проблема в том, что предупреждения может не быть вовсе — аккаунт отключают сразу и без восстановления данных. Поэтому даже один найденный email стоит вычистить немедленно, а не ждать, заметят или нет.
В: Сколько реально занимает аудит утечек данных?
О: Базовый аудит по восьми рискам — ориентировочно два рабочих дня: первый на поиск, второй на исправление. Для крупного проекта с десятками интеграций и большой историей данных может уйти заметно больше. Но первичную проверку PII в URL можно сделать буквально за час.
В: Можно ли удалить персональные данные, которые уже попали в отчёты?
О: Да, в сервисах аналитики есть инструменты запроса на удаление данных. Минус в том, что иногда приходится удалять целые срезы, теряя часть исторической аналитики. Поэтому дешевле не допускать утечку, чем потом вырезать данные кусками.
В: Яндекс.Метрика безопаснее Google Analytics с точки зрения 152-ФЗ?
О: Метрику проще обосновать перед российским регулятором, потому что данные хранятся на серверах в России. Но сама по себе она не защищает от утечек: PII утечёт туда так же легко, а Вебвизор без маскирования полей способен записать чужие персональные данные.
В: Что опаснее — PII в URL или лишние доступы к дашборду?
О: Оба критичны, но по-разному. PII в URL грозит блокировкой и штрафом, это про закон. Лишние доступы и публичные дашборды — это про утечку коммерческих данных конкурентам. По нашему опыту, второе чаще приводит к реальным финансовым потерям.
В: Как часто нужно повторять аудит?
О: Раз в квартал и обязательно после каждого крупного релиза или подключения новой интеграции. Большинство новых утечек появляется именно при изменениях: новая форма, новый тег в Tag Manager, новый A/B тест с персонализацией.
В: Влияет ли мусор в данных на точность KPI и A/B тестов?
О: Напрямую. Когда email или телефон используются как идентификатор, один человек считается несколькими пользователями, и конверсия завышается или занижается. A/B тесты на таких данных дают ложные выводы, и вы принимаете решения вслепую. Чистые данные — основа честной аналитики.
Это часть серии материалов по теме «Кибербезопасность». Основная статья серии: Квантовое шифрование vs SSL в 2026: 7 критериев защиты.
Читайте также
- Квантовое шифрование vs SSL в 2026: 7 критериев защиты — основная статья кластера
- Сколько стоит обслуживание домена и SSL-сертификата в 2026 году: реальные цены и что входит
- Сколько стоит мобильное приложение для малого бизнеса в 2026 году: цены, типы и что реально нужно
- Как выбрать между SQL и NoSQL базой данных в 2026 году: сравнение, цены и когда что использовать
Нужна помощь с этим? Обсудить проект с DS495 →