Блокировать нельзя разрешить

Блокировать нельзя разрешить

Глобальная проблема трекеров, локальное решение одной компании и пять шагов принятия

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

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

Отрицание

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

Казалось бы, что может пойти не так?

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

Конечно, столкновение с таким явлением как полное отсутствие анонимности в интернете рождает закономерное решение пользователей: «Мы не хотим, чтобы за нами следили».

Гнев

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

На самом деле, составить портрет пользователя не так сложно — достаточно проследить, что он ищет в поисковиках, какие сайты посещает, что покупает. Для этого нужно построить цепочку посещений интернет-ресурсов. Переходя от сайта к сайту, браузер пользователя тянет за собой след из cookie-файлов (для простоты будем называть их просто «куки»), которые сохраняются в нём и несут информацию о посещении каждого сайта. При этом навешиваться могут не только куки посещённого сайта (first party cookies), но и куки сторонних ресурсов (third party cookies), которые прогружаются на том же сайте в фоновом режиме. Если зайти на любой сайт и посмотреть, какие же куки ваш браузер собрал с одной страницы, вы увидите, что там будет с десяток (а то и больше) файлов различных метрик, трекеров, рекламных систем. Эти сторонние куки могут просматривать все сайты и трекеры, на которые в дальнейшем попадает пользователь (в отличие от first party cookies, которые видны только тем сайтам, которые их ставили).

Естественно, в какой-то момент это вызвало гнев пользователей, которые стали требовать анонимности и говорить: «Мы не хотим, чтобы интернет знал, какие сайты мы посещаем».

Торг

Кажется, что решение проблемы лежит на поверхности, то есть на уровне браузера. «Если без first party cookie обойтись сложно, то без third party (сторонних) — вполне реально», — подумали браузеры и решили ограничить сбор сторонник куки, то есть блокировать их.

По умолчанию это уже делают Apple Safari и Mozilla Firefox, на очереди (предположительно к 2022 году) — Google Chrome. Задержка понятна — около ⅔ пользователей мира предпочитают браузер от Google, а львиная доля дохода корпорации зависит от рекламы (в том числе таргетированной), запустить которую возможно только с помощью тех самых third party cookies. Но уже сейчас можно считать, что сторонние куки вышли из игры, и опираться на них в построении трекинга бессмысленно.

Остаются first party cookies (их называют по-разному — основные, главные, первого лица) — собственные куки сайта, которые присуждаются вам, пока вы на нём находитесь. Обычно их не удаляют и не блокируют, так как на них завязана большая часть пользовательского опыта и правильное отображение сайта. И так как сторонними куками мы уже пользоваться не можем, для передачи информации о переходе приходится использовать основные куки.

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

...но это только кажется. В августе 2020 в борьбу вступает Enhanced Tracking Protection (ETP) от Mozilla Firefox — улучшенная защита, которая противостоит трекинговым редиректам. Каждые 24 часа алгоритм браузера удаляет куки, используемые партнерскими сетями и другими трекерами. Данная настройка включена по умолчанию для всех пользователей браузера. Таким образом Mozilla хочет уберечь пользователей от сбора данных без их согласия и ограничить возможности трекингового редиректа.

И здесь мы подходим к самому главному и интересному.

Депрессия

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

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

Но мотивы для браузеров не так важны: назвался трекером — будь добр следовать правилам.

Встаёт вопрос: как же будут работать партнёрские сети, если сам принцип CPA-маркетинга основан на том, чтобы сопоставить источник трафика и конечную цель перехода? Что будет, если передача информации через куки станет невозможной, а трекинговые редиректы перестанут быть эффективными?

Говорить за всех, конечно, не приходится, но вот как мы в Admitad оцениваем сложившуюся ситуацию:

  • С одной стороны, не всё так плохо. Многие рекламодатели используют такие виды интеграции, при которых куки либо вообще не используются, либо не создаются через браузер: в интеграциях через postback-запросы, XML, свой API, Google Analytics. Это значит, что политика браузеров не коснётся ни их лидов, ни веб-мастеров, которые их привели.
  • С другой стороны, есть чего опасаться. Использование cookie-файлов — один из самых простых инструментов трекинга с точки зрения интеграции, поэтому его часто выбирают рекламодатели. Через него проходит большой объём трафика, и велик риск потерять его через год-два. У некоторых рекламодателей нет технических ресурсов на переинтеграцию, у других есть причины этого не делать, веб-мастера же повлиять на процесс никак не могут.
  • Велика вероятность того, что в скором времени браузеры перейдут от упреждающих мер к более категоричным, а именно к блокировке самих трекинговых редиректов. Это значит, что после клика по партнёрской ссылке пользователь просто не попадёт на сайт рекламодателя, отчего недовольными останутся и он сам, и веб-мастер, и магазин, и партнёрская сеть. Очевидно, это приводит нас к смерти трекинговых редиректов — finita la comedia.

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

Принятие

Руководствуясь принципом «Не можешь предотвратить — возглавь», мы решили переосмыслить привычные многим принципы трекинга. Во-первых, отказались от использования сторонних куки (ещё много лет назад). Во-вторых, помимо first party cookies используются альтернативные методы хранения данных (например, Cookieless-трекинг или запись click id на сервер рекламодателя). В-третьих, было решено отказаться от трекинга через редиректы и передать возможность настройки передачи информации о переходах в руки веб-мастера. Так на свет появился Admitad Teleport.

Admitad Teleport — инструмент, благодаря которому веб-мастер исключает Admitad из цепочки «сайт веб-мастера — сайт рекламодателя». Рассмотрим принцип работы подробнее, и начнём с визуализации того, как это было раньше:

Блокировать нельзя разрешить

Этап «Admitad» и являлся тем самым «слабым звеном», при блокировке которого просто не произойдёт редиректа на сайт рекламодателя, и с потерями столкнутся и веб-мастер, и рекламодатель, и партнёрская сеть.

Перейдём к решению, которое воплотилось в Admitad Teleport:

Блокировать нельзя разрешить

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

Помимо потенциальных блокировок от браузеров, которые будут учащаться в ближайшие годы, инструмент борется с текущими потерями из-за блокировщиков рекламы и антивирусов, которые также занижают количество учитываемых кликов и действий. Первые испытания показали, что на контентном сайте про игры с переходом на такое решение CR вырос с 3,5% до 6,5% (а в октябре и до 9,5%), а тест на купонном сервисе принёс ему дополнительные 270 заказов на 100 000 кликов.

Конечно, результаты сильно зависят от аудитории веб-мастера — чем более она молодая и продвинутая, тем чаще использует блокировщики рекламы и обновляет антивирусы, что приводит к потерям. Поэтому эффект от использования Admitad Teleport будет более ярко выраженным на сайте «Собери игровой комп своими руками», чем на «Рассада & удобрения» (по крайней мере пока).

Первый релиз Admitad Teleport вышел в API формате, который подойдёт:

  • Кэшбэкам, браузерам и браузерные расширения, дропшиппинг-платформам, некоторым витринам, купонным сервисам и программам лояльности
  • Тем, кто работает через API Admitad
  • Веб-мастерам, которые ведут пользователя на внутреннюю страницу, с которой происходит редирект на партнёрский адрес

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

В дальнейшем мы попытаемся расширить действие инструмента на остальные виды трафика в Admitad, тем самым сможем полностью уйти от редиректов.

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

___

Будь вы веб-мастером или рекламодателем, не забывайте про соответствие требованиям о защите данных пользователей — следите за тем, какую информацию вы собираете, куда передаёте и как используете. Ну и конечно, пользуйтесь только инструментами проверенных партнёров — например, Admitad Teleport.

2 комментария

 А как рекламодатель соотносит конкретный клик с сайта веб-мастера с покупками? Сделал юзер клик в 00:01 минуту по прямой ссылке с сайта веба, сделал покупку. Как рекламодатель поймет, что именно этот "клик" совершил покупку? А если юзер еще недельку подумал и только потом купил?
Хочется больше подробностей, чтобы понимать всю механику и предотвратить возможные слабые места.

Спасибо за интересный вопрос! Информация об источнике перехода и об идентификаторе веб-мастера (click_id, или admitad_uid) сохраняется из GET-параметров в финально сформированной ссылке на стороне рекламодателя. Это происходит либо через 1st part cookie (которые, как мы описали в статье, пока не блокируются браузерами), либо запись в базу данных рекламодателя (эта запись вообще не может быть удалена браузером или другими расширениями). При заказе рекламодатель извлекает клик из куки или из базы данных и отправляет нам вместе с информацией о заказе.

Клик и источник живут на стороне рекламодателя в течение заранее оговоренного срока. Как правило, это 30 дней, но у некоторых рекламодателей может быть больше или меньше. Если заказ был совершён в течение срока жизни куки, то мы получим запрос на его создание от рекламодателя.
Если в конверсии участвовало несколько платных источников, выбирается последний платный - метод атрибуции Last Paid Click. Для его настройки рекламодатель настраивает специальный код дедупликации - чтобы, когда приходит клик из нового источника, он перезаписывал старый.