Блокировщики рекламы и трекинг: что теряет ваш магазин

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

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

Как блокировщики рекламы останавливают пиксели трекинга?

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

Самые известные списки — EasyList для рекламы и EasyPrivacy для трекинга. Они работают с такими расширениями, как Adblock Plus, AdBlock, uBlock Origin и AdGuard. Пиксель крупной рекламной платформы — лёгкая цель для таких списков, потому что он загружает один и тот же скрипт с одного и того же домена на множестве разных сайтов.

Браузеры со встроенной защитой

Некоторые браузеры блокируют трекеры без расширений. Brave по умолчанию включает свою защиту Shields на каждом сайте, и Shields блокируют сторонние объявления, трекеры и кросс-сайтовые cookie. Firefox блокирует контент с известных кросс-сайтовых трекинговых доменов в приватных окнах, а пользователи могут выбрать более строгие настройки, которые действуют во всех окнах. Intelligent Tracking Prevention в Safari блокирует все сторонние cookie и сокращает срок жизни cookie, которые устанавливают скрипты. Эти ограничения объясняет наше руководство Safari ITP и рекламный трекинг.

Блокировщики на уровне всей сети

Некоторые пользователи блокируют трекеры для всего устройства или домашней сети с помощью DNS-блокировщика или VPN с фильтром трекеров. Такие средства останавливают запросы к трекинговым доменам в любом браузере и приложении в этой сети. Смена браузера результат не меняет.

Какие события теряет ваш магазин?

Когда пиксель заблокирован, теряется каждое событие, которое он отправил бы из этого браузера. Но ущерб от разных событий неодинаков.

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

Почему серверные события из данных заказов не блокируются

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

Затем платформа сопоставляет покупку с человеком по данным в событии: хешированным email и телефону из заказа, IP-адресу и user agent, а также по click id, если он был сохранён. Ничто из этого не проходит через блокировщик. Весь путь данных описан в материале что такое серверный трекинг.

Что серверный трекинг не может восстановить?

Для click id нужен браузер

Сам заказ в безопасности, но связь с кликом по рекламе устанавливается в браузере. Скрипт должен прочитать click id из URL лендинга и сохранить его. Если блокировщик рекламы блокирует и этот скрипт, заказ приходит без click id. Платформа всё равно может сопоставить покупку по хешированным данным клиента, но уверенность в совпадении ниже.

Две вещи уменьшают эту потерю. Во-первых, собирайте события как first-party: отдавайте скрипт трекинга и его запросы со своего домена, например через app proxy Shopify или поддомен вашего сайта. Списки фильтров нацелены на известные сторонние трекинговые адреса, поэтому first-party путь заблокировать намного сложнее, хотя и не невозможно. Во-вторых, используйте страницу входа, которую некоторые интернет-магазины, например Shopify, сохраняют вместе с каждым заказом. Если в этом URL всё ещё есть click id или UTM, заказ можно атрибутировать без какого-либо события из браузера.

События просмотров всё равно теряются

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

Отказ от согласия — это не блокировка

Посетитель, который отклонил маркетинговые cookie в вашем cookie-баннере, — это не то же самое, что посетитель с блокировщиком рекламы. Первый сделал выбор, которому ваш трекинг обязан следовать. Когда включён Respect visitor consent, ROASaurus не присваивает такому посетителю visitor id, поэтому его клики по рекламе и визиты не связываются с ним. Его события в браузере сохраняются без visitor id, IP-адреса и данных браузера и не отправляются на рекламные платформы. Оплаченный заказ всё равно отправляется с сервера — с хешированными данными клиента из заказа, а также IP-адресом и user agent заказа. Разделяйте эти две группы, когда измеряете потери, а подробности смотрите в разделе согласие и конфиденциальность.

Как оценить собственные потери

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

1. Выберите период и одну платформу

   Возьмите 14 или 30 дней и одну платформу, например Meta. В обеих системах используйте один и тот же часовой пояс.

2. Посчитайте веб-заказы в магазине

   Начните со всех заказов. Исключите заказы, которые не проходят через ваш онлайн-чекаут: заказы с точек продаж (POS), ручные и черновые заказы, продления подписок и тестовые заказы.

3. Посчитайте события Purchase из браузера

   В инструменте событий платформы посчитайте события Purchase, которые отправил браузерный пиксель. Проще всего это сделать до подключения серверных событий. Если серверные события уже работают, используйте представление платформы по способу подключения, если оно есть. Meta Events Manager показывает способ подключения каждого события и считает события там до дедупликации. Не берите атрибутированные покупки из рекламного отчёта.

4. Разделите

   Покупки из браузера ÷ веб-заказы — это доля, которую увидел пиксель. Остальное — ваш разрыв.

5. Отделите отказ от согласия от блокировки

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

Разрыв влияет и на ROAS. Допустим, Meta показывает для этого магазина ROAS 2.0, а его ROAS безубыточности — 2.3. По данным пикселя кампании убыточны. Если заказы от рекламы терялись с той же долей 24%, что и все веб-заказы, пиксель увидел только 76% рекламной выручки. Тогда реальный ROAS был бы около 2.0 ÷ 0.76 = 2.6, выше безубыточности. Это верхняя оценка, потому что не каждый потерянный заказ пришёл от рекламы. Как задать этот порог, объясняет наше руководство по ROAS безубыточности.

Как сократить потери

Эти исправления одинаковы для любой платформы интернет-магазина. Лучше всего они работают вместе.

1. Отправляйте покупки из данных заказов. Это закрывает разрыв по покупкам для каждой подключённой платформы, что бы ни блокировал браузер посетителя.
2. Оставьте пиксель с общим event id. Посетители без блокировщика по-прежнему отправляют события из браузера с cookie и контекстом страницы. Один и тот же event id в обеих копиях позволяет платформе оставить одну. См. как избежать двойного учёта.
3. Собирайте данные как first-party. Отдавайте скрипт трекинга и его события со своего домена, чтобы click id сохранялись для большего числа посетителей.
4. Отправляйте хешированные данные клиента. Email и телефон из заказа позволяют платформе сопоставить покупки, у которых нет click id.
5. Измерьте снова. Повторите сравнение через месяц. События Purchase, которые получает платформа, теперь должны совпадать с вашими веб-заказами.

Как ROASaurus работает с блокировщиками рекламы

ROASaurus отправляет каждый оплаченный заказ с сервера на рекламные платформы, которые вы добавили в разделе Tracking & platforms, поэтому блокировщик рекламы в браузере покупателя не мешает покупке дойти. В Shopify события витрины идут через app proxy Shopify на домене вашего магазина. Скрипт и его события можно также отдавать с CNAME-поддомена вашего сайта. Если у посетителя нет касания в браузере, атрибуция ROASaurus опирается на click id и UTM из URL лендинга в заказе, если магазин его записывает, как это делает Shopify.

Каждая отправка и ответ платформы перечислены в Event log, так что вы можете убедиться, что каждый заказ дошёл до каждой платформы. Настройку смотрите в разделах серверный трекинг и интеграция с Shopify.

Источники

1. EasyList: Overview
2. Brave: Brave Shields
3. MDN Web Docs: Firefox tracking protection
4. WebKit: Tracking Prevention in WebKit
5. Meta for Developers: Verifying Your Setup

В ROASaurus

• Серверный трекинг в ROASaurus
• Как избежать двойного учёта
• Согласие и конфиденциальность

Читайте дальше