Как перестроить атрибуцию под новые правила конфиденциальности

Браузеры и мобильные платформы ограничивают сбор пользовательских данных, пользователи чаще отказываются от cookies, а закон № 152-ФЗ требует понятного согласия и локального хранения. Это отражается на всей аналитике. В этой статье разбираем именно атрибуцию: как перестроить её так, чтобы она оставалась законной, прозрачной и прикладной для управления бюджетом — в рамках общей системы работы с данными.

1. Собирайте события на своей стороне

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

Как настроить сбор событий

Чтобы данные о действиях пользователей не терялись и собирались законно, события лучше принимать на своей стороне — не через сторонние пиксели, а напрямую в ваш сервер. Так вы контролируете, что именно собирается, где хранится и что отправляется наружу.

1. Создайте точку приёма данных

• На сайте или сервере должен быть адрес, куда поступают события — например, переходы, заявки, покупки.
• Для каждого события стоит сохранять время, тип действия, источник трафика и код клиента.
• Технически это реализуется через HTTP-эндпойнт (например, POST /collect), который принимает эти поля:
  время, тип события, параметры кампании (UTM), идентификатор клиента и, при необходимости, стоимость или выручку.

2. Используйте собственный идентификатор клиента

• У каждого посетителя должен быть уникальный код, который хранится в cookie на вашем домене.
• Если код отсутствует — создайте новый, если уже есть — продлевайте срок его действия, чтобы сохранить связь между сессиями.
• Это позволит связать действия одного человека без передачи персональных данных наружу.
• На техническом уровне это first-party cookie с вашим идентификатором (cid), не зависящий от сторонних систем.

3. Передавайте данные в аналитику

• Когда события накоплены, их нужно загрузить в систему аналитики через официальный интерфейс — например, офлайн-конверсии в Яндекс Метрике.
  Так вы не нарушаете требования 152-ФЗ и сохраняете точность отчётов.
• Если отправлять данные с вашего сервера, а не напрямую из браузера, они меньше подвержены блокировкам и фильтрации.

4. Проверяйте дубли и ошибки

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

2. Встраивайте согласие пользователя в аналитику

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

Как организовать процесс

• Система управления согласием
  Используйте платформу управления согласием (CMP) или простой собственный модуль. Пользователь видит понятный выбор «разрешить/отклонить», а решение фиксируется в журнале согласий.

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

• Практические требования

  • Не запускайте рекламные и аналитические скрипты без согласия.
    Сначала человек должен увидеть баннер и выбрать, разрешает ли он сбор данных. Баннер должен появляться до установки любых cookies, кроме технических. Только после этого можно включать пиксели и счётчики.

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

  • Дайте возможность отказаться в любой момент.
    Пользователь должен иметь простой способ отозвать своё согласие — например, кнопку «изменить настройки cookies» внизу сайта.
    После отказа сбор данных должен прекратиться автоматически.

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

3. Храните персональные данные в России и взвешенно подходите к трансграничной передаче

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

Практика соблюдения

• Локализация. Размещайте первичные базы с персональными данными в российских дата-центрах. Если используете облако, убедитесь, что площадка физически находится в России.

• Передача за рубеж. Трансграничную передачу персональных данных можно осуществлять только после первичного размещения в России, с согласия пользователя* и при наличии договора, который гарантирует сопоставимый уровень защиты у иностранного партнёра. Перечень стран, обеспечивающих адекватную защиту персональных данных, утверждён Роскомнадзором. Уровень защиты у принимающей стороны оценивает оператор: наличие правовых гарантий в договоре, технические и организационные меры защиты, контроль доступа, аудит. Если есть сомнения — не передавайте.
  
  *Согласие пользователя на обработку данных в России не означает согласие на передачу их за рубеж. Если компания использует иностранные сервисы, нужно дополнительно уведомить об этом пользователя — в политике конфиденциальности или через баннер согласия.

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

4. Контролируйте качество данных в отчётах

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

Какие показатели качества включать в отчёты

• Доля событий, собранных с согласия. Позволяет понять правовой статус данных и уровень полноты.

• Доля смоделированных конверсий. Если часть пути пользователя недоступна и восстановлена алгоритмами, указывайте долю таких событий.

• Покрытие внутреннего идентификатора. Доля сессий и событий, где установлен ваш идентификатор клиента.

• Расхождения между клиентским и серверным сбором. Сравнивайте объёмы событий: если с клиента приходит больше, чем попадает на сервер, ищите технические потери.

• Ошибки импорта и экспорта. Сколько событий отклонено при загрузке в аналитику и почему.

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

Как интерпретировать показатели качества

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

• Если покрытие внутреннего идентификатора низкое, сначала решайте вопрос с установкой first-party cookie и стабильностью маршрута сбора, а уже потом меняйте бюджет.

5. Зафиксируйте внутренние правила работы с данными

• Единые правила разметки кампаний. Утвердите шаблон UTM-меток и названий: источник, канал, кампания, креатив. Настройте автоматическую проверку на входе, чтобы исключить ошибки и дубли.

• Соглашение о составе событий. Зафиксируйте перечень полей в каждом типе события (что обязательно, что опционально), форматы, допустимые значения и примеры. Это «контракт» между маркетингом, разработкой и аналитиками, чтобы все писали одно и то же.

• Приоритет источников и дедупликация. Определите, чьи записи считаются главными при совпадении (обычно — серверные), и как устраняются дубли.

• Хранение и удаление. Опишите, где лежат сырые данные и агрегированные отчёты, какие сроки хранения у каждого слоя и по какому графику выполняется удаление.

• Доступ и аудит. Назначьте роли (маркетолог, аналитик, разработчик, внешний подрядчик), ограничьте доступ к сырым данным, ведите журнал выгрузок и изменений.

• Передача вовне. Разрешайте выгружать партнёрам только агрегированные и обезличенные данные. Персональные данные не передавайте.

Что сделать прямо сейчасy

1. Проверить, где физически хранятся данные о пользователях. При необходимости перенести персональные данные в российский дата-центр, наладить резервное копирование.

2. Развернуть собственную точку приёма событий. Настроить /collect (точку приёма данных), внутренний идентификатор клиента и запись событий в базу данных.

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

4. Настроить официальную загрузку конверсий в систему аналитики. Автоматизировать экспорт из базы данных, контролировать отчёты об ошибках.

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

Вывод

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