Facebook CAPI без потерь событий: схема, которая не ломается на дедупликации

Если Pixel и CAPI отправляют один и тот же event, потери чаще всего не в Meta, а в вашей схеме: разные event_id, несинхронный тайминг, пустые user_data и кривая нормализация. Сначала фиксируйте идентичность события, потом уже улучшайте матчинг.

Что должно уходить в CAPI:
— event_name, event_time, event_id
— fbp, fbc, client_ip_address, client_user_agent
— email_hash, phone_hash, external_id, если они реально есть и нормализованы
— action_source и page_url для контекста

Дедупликация держится на одном правиле: Pixel и server должны делить одинаковый event_id. Генерируйте его на стороне клиента до отправки и прокидывайте в оба канала. Если event_id создаётся отдельно в браузере и на сервере, дедуп почти всегда начинает «плыть».

Отдельно проверьте нормализацию PII: email в lowercase, phone в E.164, хеширование только после очистки пробелов и символов. На сервере не теряйте client_user_agent и IP — без них EMQ проседает даже при хорошем наборе user_data.

Если хотите стабильную CAPI-схему, сначала сделайте одинаковый event_id, потом доберите матчинг через fbp/fbc и нормализованные user_data.

Server-side трекинг для PWA: где ломается сессия и как не потерять атрибуцию

PWA часто ведёт себя не как обычный сайт: кеш, service worker, быстрые навигации без полного reload и отдельная логика офлайна. Из-за этого client-side события могут приходить рваными: PageView дублируется, Purchase теряется после закрытия вкладки, а `fbp/fbc` не всегда живут так, как ожидает CAPI.

Для sGTM здесь важны 3 вещи:
— передавать стабильный `event_id` для дедупликации Pixel + CAPI;
— сохранять first-party идентификаторы в cookie с корректным `SameSite` и `Secure`;
— не полагаться на `window.onload`: в PWA нужный триггер часто `route change` или кастомное событие приложения.

Если service worker отдаёт страницу из кеша, серверу нужен контекст: `client_id`, `event_time`, `page_location`, `referrer`, `user_agent`, `ip`. Без этого ухудшается матчинг и растёт доля событий без привязки к сессии.

Отдельно проверь офлайн-очередь. События, собранные в PWA без сети, должны уходить на сервер с исходным временем события, а не временем отправки. Иначе атрибуция съедет в сторону последнего касания.

Минимальный чек-лист:
— один источник генерации `event_id`;
— логика сохранения идентификаторов вне volatile storage;
— маршрутизация server-side на уровне маршрута, а не только page load;
— тест на back/forward navigation и кеш service worker.

В PWA выигрывает не тот, кто «отправил больше событий», а тот, кто сохранил их порядок и контекст.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

🧠 Ещё больше инсайтов → в канале AFF.top

TikTok Events API ломается не на отправке, а на валидации полей: вот где искать ошибку

Когда серверный event уходит, но не матчится — проблема обычно в схеме. Для TikTok Events API критичны три слоя: идентификаторы пользователя, данные события и технические поля запроса.

Проверь базовый набор:
— event, timestamp, event_id
— context.page.url, context.user_agent, context.ip
— user data: email/phone в хеше, ttclid, ttp если они доступны
— currency и value для ecommerce-событий

Типовая ошибка — отправлять пустые строки вместо null или не нормализовать PII перед SHA-256. Email нужно привести к lowercase и trim, телефон — к E.164-логике, иначе валидатор пропустит запрос, но матчинг просядет.

Ещё один частый сбой — дубль event_id. Если Pixel и Events API живут параллельно, идентификатор должен быть одинаковым на обеих сторонах, иначе дедупликация не сработает.

Для отладки удобно проверять запрос в таком порядке:
1. обязательные поля
2. формат timestamp
3. хеширование user data
4. наличие value/currency
5. консистентность event_id между client и server

Если event проходит по HTTP, это ещё не значит, что он пригоден для атрибуции. Сначала валидируй схему, потом уже смотри EMQ и deduplication.

Кросс-девайс атрибуция ломается там, где client-side видит только один экран

Когда пользователь начал путь на телефоне, а купил с ноутбука, Pixel и GA4 часто собирают два отдельных фрагмента. Server-side ID нужен не для «магии», а чтобы связать события в один контур: login_id, hashed email, customer_id, CRM user_id — если они реально стабильны между сессиями.

Базовый паттерн такой:
— на сайте генерируете first-party identifier и кладёте в cookie;
— при логине маппите его на внутренний user_id;
— в sGTM прокидываете этот ID в CAPI / Enhanced Conversions / аналитику;
— при всех дальнейших событиях используете один и тот же ключ.

Важно не путать ID для атрибуции и PII. Email и phone хешируются, а сам server-side ID должен быть бессмысленным токеном без прямой расшифровки. Иначе вы строите не трекинг, а лишний риск. Ещё один частый провал — разные ID в разных поддоменах, из-за чего кросс-девайс склейка разваливается на уровне источника.

Проверка простая: один и тот же пользователь должен получать одинаковый server-side ID после авторизации, а события Purchase / Lead должны уходить с тем же идентификатором и в вебе, и в сервере. Если ID меняется при каждом визите, у вас нет атрибуции, есть набор несвязанных хитов.

Практика одна: сначала стабилизируйте identity layer, потом уже оптимизируйте EMQ и deduplication.

BigQuery как хранилище server-side событий: когда это лучше логов и CSV

Если sGTM уже шлёт события на несколько endpoint’ов, BigQuery удобно использовать как слой сырого факта. Не как отчётный BI-слой, а как место, где лежит полный event stream: входящие payload’ы, debug-флаги, ошибки валидации, повторные отправки.

Главное правило: в таблицу надо писать не только “успешные” события. Иначе вы теряете возможность искать, почему рассыпались дедупликация, match_keys или routing. Полезно хранить:
— event_name, event_id, timestamp
— user_data в хэшированном виде
— fbp/fbc, ip, user_agent
— source, client_id, request_id, status_code
— raw_payload в отдельном поле или отдельной таблице

Структурируйте хранение сразу. Для аналитики по времени — партиционирование по дате события. Для быстрых разборов — кластеризация по event_name, event_id, request_id. Если кладёте всё в одну широкую таблицу, следите, чтобы raw JSON не ломал стоимость запросов.

Практика, которая спасает дебаг:
— одна таблица для “чистых” событий
— одна таблица для ошибок и невалидных запросов
— одно поле для correlation id между sGTM, CAPI и downstream-системами

Такой слой позволяет быстро сравнить: что пришло на вход, что ушло в Meta/Google/TikTok, и где именно событие потерялось. Для server-side атрибуции это часто важнее, чем сама витрина в Looker.

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

Topics API: как Google отдаёт интересы пользователя без third-party cookies

Topics — это не «интересы из браузера» в привычном смысле, а попытка заменить часть поведенческого таргетинга на уровне Chrome. Браузер сам выбирает несколько тем, которые соответствуют недавнему контенту, и периодически обновляет их.

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

Для performance это не аналог аудиторий из пикселя. Topics полезен как сигнал контекста: понять, в каком общем интересе находится пользователь, и использовать это в медиамиксе, а не как точный триггер на конверсию. Для high-intent сценариев он слабее, чем first-party data, события сайта и server-side сигналы.

Что важно проверить до интеграции:
— есть ли у вас запрос темы на стороне рекламной логики, а не только на лендинге;
— не смешиваете ли Topics с consentless tracking — это разные механики;
— не строите ли отчётность только на Topics, игнорируя CAPI / Enhanced Conversions / sGTM.

Если коротко: Topics — это дополнительный контекстный сигнал, а не замена нормальной атрибуции. Сначала чините first-party сбор событий, потом подключайте Privacy Sandbox как слой поверх.