Режимы приватности и GDPR: что записывает клик по короткой ссылке

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

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

Что записывает клик

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

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

Двух вещей нет намеренно. Почтовый индекс гео-база определяет, но он не записывается: в плотной застройке почтовый индекс — это почти адрес. И сам сетевой адрес не записывается никогда — об этом отдельный раздел ниже.

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

Два разных способа ограничить данные

Путать эти два способа — самая дорогая ошибка в теме, а поставщики их разделяют редко.

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

| | Хранение по тарифу | Режим приватности | | --- | --- | --- | | Чем управляет | Насколько далеко назад можно смотреть | Что вообще записывается | | Где применяется | На чтении | На записи | | Обратимо | Да, переходом на тариф выше | Нет, для уже записанных строк | | Кто меняет | Тот, кто управляет оплатой | Владелец рабочего пространства или администратор |

Действуют оба сразу — именно это чаще всего упускают. Рабочее пространство на тарифе с глубиной просмотра в два года, задавшее собственный срок хранения в 30 дней, хранит 30 дней.

Детализация выбирается в момент записи

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

| Уровень | Что несёт событие | | --- | --- | | Полностью | Страна, континент, регион, город, идентификаторы GeoNames, координаты, радиус точности, часовой пояс, местный час | | Город без координат | Всё вышеперечисленное, кроме координат и радиуса точности | | Только страна | Страна и континент |

На уровне только страна гео-база для события вообще не опрашивается — страна и континент и так приходят от CDN бесплатно. Настройка убирает не только данные, но и работу, поэтому самый приватный выбор оказывается и самым дешёвым в эксплуатации.

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

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

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

Адрес: усечь или не хранить вовсе

Расхожий отраслевой подход — усечение: обнулить последний октет адреса IPv4 или более широкий префикс у IPv6. Это лучше, чем хранить адрес целиком, и слабее, чем звучит: усечённый адрес по-прежнему указывает на сеть ограниченного размера, по-прежнему заметно сужает круг для посетителя из небольшого города и складывается с остальными полями той же строки. Усечение снижает разрешение, но не убирает поле из системы.

Альтернатива — не хранить его вовсе. Здесь адрес живёт внутри одной функции ровно столько, сколько нужно на две вещи, и после этого отбрасывается. Хеш односторонний и считается от адреса, строки user agent, домена ссылки и секретной соли, обновляемой каждую ночь в полночь UTC; предыдущая соль выбрасывается.

address + user agent + link domain + daily salt  ->  one-way hash  ->  stored
address                                          ->  range lookup  ->  country, city, network
address                                          ->  discarded

Отсюда два честных следствия, и обоим место в разговоре с клиентом, а не в сноске.

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

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

Тот же принцип продолжается на границе выдачи. Публичная страница статистики ссылки получает из гео-слоя только страну и город: ни сетей, ни типа трафика, ни оценки качества, ни координат — и держит эту границу тест на форму ответа, а не оставленная на честное слово договорённость. Что показывает каждая разбивка, описано в гео-аналитике и на странице географии и качества трафика.

Срок хранения — настройка рабочего пространства

Оставьте поле срока хранения пустым, чтобы получить платформенный максимум в 730 дней, либо задайте число дней.

Механизм важнее числа. Значение едет внутри каждого события, и срок жизни строк в хранилище выражен через это значение. Строка, записанная при настройке в 30 дней, удаляется через 30 дней, даже если рабочее пространство позже переключится на 730: действует та настройка, что была в момент записи строки.

Именно это делает срок хранения пригодным ответом, а не туманным утешением. «Мы храним 90 дней» защитимо, если эти 90 проставлены в каждой строке в момент её записи, и незащитимо, если так описан фильтр в отчёте поверх строк, которые на самом деле лежат два года. Сравнивая платформы, спрашивайте не какой срок хранения, а где он применяется, — и отдельно какова глубина просмотра по тарифу, потому что это ограничение действует тоже. Оба механизма описаны в данных посетителей и режимах приватности.

Согласие касается данных, а не редиректа

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

У такой рамки есть практические следствия. Межсайтовой измерительной cookie нет вовсе: дневной хеш заменяет ровно тот механизм, ради которого писалось большинство режимов согласия. В пути редиректа есть ровно одна cookie — отметка первого визита на вашем собственном домене редиректа, — и ставится она лишь тогда, когда одно из ваших правил действительно спрашивает, первый это визит или повторный. Поэтому ответ на вопрос «ставят ли ваши ссылки cookie» опирается на конфигурацию, которую можно показать пальцем, а не на общую политику.

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

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

Документы, которые попросит проверяющий

Основную работу делают два документа, и ни один из них не стоит сочинять на ходу.

Соглашение об обработке данных (DPA) регулирует обработку, выполняемую по вашему поручению. Проверяющий читает в нём вполне определённый набор вещей: кто контролёр данных и кто обработчик по каждой категории данных, категории субъектов данных и персональных данных, меры безопасности, срок уведомления об утечке, механизм передачи данных за пределы Европейской экономической зоны или Великобритании, права на аудит и что происходит с данными при прекращении договора. Наш DPA задаёт эти условия, включая срок уведомления об утечке в 72 часа, Стандартные договорные условия с британским дополнением там, где оно применимо, ежегодное право на аудит по уведомлению и удаление в течение 30 дней после окончания окна выгрузки.

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

Если поставщик не может предъявить оба документа или предъявляет список субобработчиков без механизма уведомления, вот это и есть находка, а вовсе не отсутствие логотипа сертификата.

Чек-лист для разговора с клиентом

1. Предъявите список полей для режима, который включён на самом деле — не платформенный максимум, а то, что это рабочее пространство пишет сегодня.
2. Назовите срок хранения в днях и место, где он применяется, отделив его от глубины просмотра по тарифу, и скажите, какое из двух ограничений сейчас связывает.
3. Ответьте на вопрос об адресе одной фразой: хранится целиком, усечённым или не хранится вовсе, — а если не хранится, объясните дневной хеш и суточную природу уникальных посетителей.
4. Перечислите cookie в пути редиректа и то, из-за чего ставится каждая. «Ни одной, пока не настроено правило про первый визит» лучше, чем «только необходимые cookie».
5. Отделяйте то, что прикрепляете вы, от того, что делает платформа. Пиксели, сторонние теги и аналитика на стороне назначения — это ваша обработка, а не редиректора.
6. Отдавайте DPA и список субобработчиков целиком, а не в пересказе, и отдельно называйте срок уведомления об изменениях.
7. Поставьте режим приватности на самый строгий уровень, с которым живёт ваша отчётность, а потом проверьте, какие разбивки опустели, — так и выясняется, была настройка выбрана или досталась по умолчанию.

Неудобная часть этой темы в том, что решения, принятые на записи, необратимы в обе стороны. Данные, которые вы решили не собирать, потом не восстановить, когда кто-нибудь попросит разбивку по городам; а собранные данные потом не отменить, когда кто-нибудь спросит, зачем они у вас. Это довод за то, чтобы решать осознанно в начале работы с клиентом, а не наследовать значение по умолчанию. Всё, что есть в аналитике, продолжает работать и на строгом краю диапазона; меняется то, сколько вы видите посетителя, а не то, сколько вы видите кампании.