Adblock не лечится одним трюком: как не потерять события и не сломать атрибуцию
Если пиксель режется расширением, проблема обычно не в одном теге, а в цепочке: запрос до браузера не дошёл, JS не выполнился, или событие не попало в серверный дубль. Поэтому считать надо не «пиксель работает/не работает», а долю событий, которые пережили блокировку.
Рабочая схема такая:
— client-side шлёт минимум: page_view, consent, event_id;
— sGTM принимает то, что прошло, и дублирует в CAPI / Events API;
— server-side добавляет IP, User-Agent, fbp/fbc, click_id;
— event_id одинаковый на браузере и сервере, иначе deduplication не сработает.
Если нужен контроль потерь, смотрите не только на общий объём, а на разницу между browser events и server accepted events. Отдельно полезно логировать 4 класса отказов: не загрузился контейнер, заблокирован запрос к collector, невалидный payload, нет consent. Тогда видно, где именно съедаются события, а не просто «упала конверсия» 🧩
Анти-кейс: пытаться обойти блокировки через скрытый fingerprinting. Это плохая идея и для качества данных, и для комплаенса. Нормальная архитектура — first-party endpoint, аккуратный consent, server enrichment и честный мониторинг потерь.
Итог простой: adblock не исчезнет, поэтому ваша задача — не «победить блок», а сделать так, чтобы каждое дошедшее событие было дедуплицировано, обогащено и измеримо.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
Adblock не лечится одним трюком: как не потерять события и не сломать атрибуцию
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.