<b>Adblock не лечится одним тэгом: как не потерять события, когда client-side режется</b>

<b>Adblock не лечится одним тэгом: как не потерять события, когда client-side режется</b>

Adblock обычно бьёт не только по GA4, но и по Pixel, тегам ремаркетинга и части кастомных скриптов. Если считать конверсии только из браузера, вы увидите «дыры» там, где пользователь уже купил, а событие просто не дошло.

Рабочая схема: критичные события уводим в server-side GTM и шлём их на стороне сервера, а браузер оставляем для фоллбэка. Для CAPI и Events API важно собирать минимум контекста: event_name, event_id, timestamp, fbp/fbc, IP, User-Agent, hashed email/phone, если они есть легально и качественно нормализованы.

Что проверить в первую очередь:
— совпадает ли event_id у Pixel и server event для дедупликации;
— не режется ли endpoint `/collect` или `/events` самим списком блокировщика;
— не грузите ли вы критичный код с домена, похожего на рекламный;
— есть ли fallback на first-party endpoint, а не только на third-party запрос.

Если блокируется сам тег-лоадер, помогает не «обход», а архитектура: first-party domain, минимальный client bundle, серверная отправка, отдельный health-check на потерю событий. Полезно сравнивать не объём трафика, а долю событий по типам: page_view, view_content, add_to_cart, purchase.

Итог простой: adblock не победить, но можно сделать так, чтобы он бил по вспомогательным сигналам, а не по конверсии. Если событие критично для оптимизации, оно должно жить на сервере и иметь второй путь доставки.