Session stitching ломается не в sGTM, а на границе client-side и server-side

Если Pixel и CAPI живут раздельно, у вас появляются дубли, дырки и «чужие» сессии. Базовая ошибка — передавать только event_name и timestamp. Для stitching нужен стабильный ключ, который доживает до сервера и обратно:
— event_id для дедупликации Pixel + CAPI
— client_id / ga_session_id для связки сессии
— fbp / fbc, если есть click_id и landing context
— user data: email_hash, phone_hash, external_id

На клиенте генерируйте event_id один раз на событие и прокидывайте его в dataLayer, чтобы и Pixel, и server tag получили одинаковое значение. Если событие собирается через SPA, не пересоздавайте идентификатор при каждом virtual pageview — иначе одна покупка превращается в три разных сессии.

На сервере не пытайтесь «угадать» сессию по IP и User-Agent. Эти поля полезны для enrichment, но не для склейки. Лучше хранить mapping: event_id → client_id → session_id. Тогда можно безопасно объединять Purchase, Lead и AddToCart даже при частичном потере client-side куки. 🔧

Итог простой: stitching строится на общих идентификаторах, а не на магии контейнера. Если у вас есть один event_id на обеих сторонах и понятная схема передачи fbp/fbc, процент дублей падает, а отчёты перестают расходиться между GA4, Meta и внутренней аналитикой.

Hashing PII для Meta CAPI: что нормализовать до SHA-256, а что ломает match

Hashing — это не просто «сделать sha256 и отправить». Если нормализация слабая, Meta получает мусор и EMQ падает, даже когда поля формально заполнены.

Минимум, который стоит привести в порядок перед хешированием:
— email: trim, lowercase, убрать пробелы
— phone: E.164, без знаков, скобок и пробелов
— first_name / last_name: lowercase, trim, без лишних символов
— city / state / zip / country: нормализовать формат, country — в ISO-2
— external_id: хешировать только если это стабильный first-party ID

Важно: хешировать нужно уже нормализованное значение. Если сначала отправить ` Ivan@Example.com `, а потом просто прогнать SHA-256, совпадение с источником будет хуже, чем у строки `ivan@example.com`.

Для CAPI не смешивайте два подхода: либо передаёте raw PII в server-side теге и хешируете на стороне шаблона, либо отправляете уже готовый hash. Двойное хеширование — частая причина пустых match_keys.

Отдельно проверьте:
— `fbp` и `fbc` не хешируются
— `client_ip_address` и `client_user_agent` отправляются как есть
— event_id должен совпадать у Pixel и CAPI для deduplication

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

Загон FB-трафика в WebView-аппу ломается не на крео, а на первом экране и прогреве

Чаще всего WebView-связка разваливается в трёх местах: • лендинг в app открывается с пустым экраном или долгой загрузкой; • оффер резко отличается от обещания в рекламе; • события не доходят в аналитику, и оптимизация идёт вслепую.

Что важно: app должна выглядеть как нормальный продукт, а не как контейнер для редиректа. На первом экране оставляют понятный хук, минимум интерфейса и один сценарий действия. Если нужен прогрев, лучше встроить его в онбординг, чем прятать за лишними кликами. Иначе FB быстро режет качество клика и уводит связку в мусор.

На практике сильнее всего работают 3 формата: • direct open на оффер, если крео уже максимально близко к ленду; • pre-lander внутри WebView, когда нужно снять холодный трафик; • hybrid-схема с коротким экраном доверия перед целевым действием. Для каждого варианта нужен свой темп: где-то важнее скорость, где-то — удержание.

Отдельно проверьте трекинг: инициализация app, первый view, клик по CTA, доход до целевого экрана. Если хотя бы один шаг теряется, вы не видите реальную проблему и начинаете чинить не ту часть связки.

Стабильная связка в FB строится не на хитром обходе, а на совпадении крео, первого экрана и событийной логики.

7 residential-провайдеров: кто закрывает какую задачу в арбитраже

Residential-прокси нужны, когда дата-центр блокирует ещё на стадии авторизации. Выбор провайдера определяется не ценой за гигабайт, а тем, чей IP-пул лучше переживает конкретный источник трафика.

— Bright Data. Самый глубокий пул и точная геотаргетинг до города и ASN. Работает там, где другие умирают через час, но переплата очевидна.
— Oxylabs и NetNut. Корпоративный сегмент, стабильные сессии и приоритетная поддержка. Хороши для долгих ферм и парсинга, но избыточны для коротких проливов.
— Smartproxy и SOAX. Баланс цены и качества. У SOAX — лучшая ротация по таймеру, у Smartproxy — проще API для быстрого старта.
— IPRoyal и PacketStream. Бюджетный сегмент через P2P-сети. Подходят для чекеров, фарминга аккаунтов и тестов, но готовность к банам выше.

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

Как уходят из арбитража трафика: интервью с бывшим медиабайером

Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…

➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom

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

Topics API — это не замена cookies, а способ отдать браузеру роль “контекстного посредника”

Вместо передачи интересов пользователя на каждый сайт, браузер сам строит короткий список тем по истории посещений и отдаёт только несколько категорий. Сайт видит не профиль, а набор high-level topics вроде “Fitness” или “Travel”. Для performance это важный сдвиг: сигнал слабее, но он приходит без прямой идентификации.

Что важно для настройки и оценки:
— Topics лучше читать как контекстный сигнал, а не как user-level таргетинг.
— Нельзя ожидать точности на уровне third-party cookies: сегмент грубый, шум есть.
— Для атрибуции Topics полезен в связке с first-party data, sGTM, Enhanced Conversions и чистой дедупликацией.

Типовая ошибка — пытаться строить на Topics отдельную “магическую” стратегию. Рабочий подход другой: используйте его как дополнительный вход в моделирование, а не как единственный источник оптимизации. Если у вас уже есть качественный first-party stack, Topics может закрыть часть loss’а там, где cookies и device IDs недоступны.

Практика простая: проверьте, какие события вы вообще можете собрать на своей стороне, и только потом решайте, нужен ли вам Topics в логике bidding или measurement. Чем меньше зависимость от одного идентификатора, тем устойчивее атрибуция.

BigQuery как хранилище server-side событий: что сломается, если не продумать схему заранее

Когда sGTM начинает собирать события из нескольких источников, BigQuery быстро превращается не в “лог”, а в основной слой разборов. Ошибка здесь одна: складывать всё в одну сырую таблицу без правил по ключам и типам.

Что нужно зафиксировать сразу:
— event_id для дедупликации Pixel + CAPI
— event_name, event_time, user_pseudo_id, client_id
— отдельные поля под fbp, fbc, click_id, IP, User-Agent
— raw payload в JSON или STRING, но не вместо нормализованных колонок

Если хранить только сырой body, вы быстро упрётесь в боль:
— тяжело считать deduplication rate
— сложно искать расхождения между client-side и server-side
— EMQ и матчинг по CAPI приходится разбирать вручную

Хорошая практика — разделить слой на два уровня:
— raw: всё, что пришло от клиента или из sGTM
— normalized: уже распарсенные поля для аналитики и QA

Для больших объёмов сразу закладывайте:
— партиционирование по event_date или event_timestamp
— кластеризацию по event_name, event_id, source
— единые правила нормализации email/phone до хеширования

Так BigQuery становится не “складом мусора”, а источником для сверки атрибуции, качества матчинг-данных и контроля потерь на каждом этапе. Чем раньше вы наведёте порядок в схеме, тем меньше будет ручного дебага через месяц.

ByteDance анонсировала новую версию SeeDance версии 2.5

ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…

➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5

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

Codex уничтожит твой SSD за год

Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…

➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god

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

Attribution Reporting API в Chrome: что уже можно использовать в реальной атрибуции

Attribution Reporting API — это не замена CAPI или sGTM, а способ получить более приватный сигнал об эффективности рекламы, когда user-level идентификаторы недоступны. Важная деталь: данные приходят не как сырые события, а как агрегированные отчёты, поэтому логика измерения меняется уже на этапе дизайна схемы.

Для внедрения обычно нужны 3 вещи: регистрация источника клика, регистрация триггера конверсии и выбор режима отчёта. На практике это значит, что нужно заранее определить, какие события вообще имеют право на атрибуцию, какие окна измерения вы используете и где будете склеивать отчёты с BI или ad server.

Типовые ошибки:
— отправляют слишком много конверсий в атрибуционный поток и ловят шум;
— не синхронизируют event schema между web и server-side;
— ждут user-level дедупликацию, хотя модель работает на агрегатах;
— не тестируют fallback-логику, когда отчёт не доехал или задержался.

Если у вас уже есть sGTM, полезно разделить контуры: для точной операционной аналитики оставить first-party события, а Attribution Reporting использовать как дополнительный слой для браузерных сценариев. Это особенно важно там, где нужно сохранить хотя бы часть измерения без опоры на cookies.

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

UID 2.0 полезен не везде: где он реально усиливает арбитражный стек

UID 2.0 — это не «замена всем идентификаторам», а слой для контролируемого first-party matching. В арбитражном стеке он работает только там, где у вас есть согласие, нормальная регистрация/логин и стабильный поток user data.

Где применять:
— login walls и подписки: email/phone можно трансформировать в UID 2.0 и использовать для матчинга;
— SaaS / e-commerce с кабинетом: лучше всего работает на повторных сессиях и LTV-аудитории;
— серверная передача: UID 2.0 логичнее отправлять из sGTM вместе с event data, а не пытаться «додумать» его в браузере.

Где он слаб:
— анонимный трафик без логина;
— короткие лендинги с одной конверсией;
— связки, где нет стабильного first-party identity слоя.

Критичный момент — не путать UID 2.0 с волшебным user_id. Он не решает deduplication, не чинит плохой event_id и не заменяет нормальную схему согласий. Если у вас уже кривой CAPI payload, UID только добавит ещё один плохой идентификатор.

Практика: храните источник идентификатора, используйте один формат нормализации, и не смешивайте UID 2.0 с сырыми PII в одном поле. Для performance он полезен как дополнительный match key, а не как основа всей атрибуции.

Вывод простой: если у вас есть логин и server-side стек — UID 2.0 имеет смысл. Если identity слоя нет, сначала чините сбор данных, потом уже добавляйте UID.

Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

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

Хеширование PII для Meta CAPI: где ломают матчинг даже при правильной схеме полей

Hashing сам по себе не спасает, если данные нормализованы по-разному на клиенте и на сервере. Для Meta CAPI критичны одинаковые правила до SHA-256: email в lowercase, без пробелов; phone — в E.164; имена — без лишних символов и двойных пробелов.

Базовый набор для match_keys:
— email_hash
— phone_hash
— external_id
— fbp / fbc
— IP и User-Agent как server data

Типовая ошибка: хешируют уже «грязные» строки, а потом сравнивают это с данными из Pixel или CRM. В итоге событие уходит, но EMQ проседает, потому что совпадение ищется по разным представлениям одного и того же значения.

Что делать:
— нормализовать до хеша, а не после
— использовать один и тот же пайплайн для CRM, sGTM и backend
— не смешивать raw и hashed значения в одном поле
— отдельно проверять event_id для deduplication Pixel + CAPI

Если у вас один email приходит как `John.Doe@Mail.com`, а другой как `john doe@mail.com`, это не “почти одно и то же” — для CAPI это разные строки до нормализации.

Практика простая: сначала приводите PII к канону, потом хешируете, потом тестируете матчинг на реальном payload. Именно так ловятся проблемы до того, как они превращаются в потерянные конверсии.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

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

BigQuery как хранилище server-side событий: не склад, а слой контроля качества

Если sGTM шлёт события в BigQuery «на всякий случай», через месяц вы получаете не аналитику, а дорогой мусорный ящик. Рабочая схема другая: сырые события кладём отдельно от нормализованных, а в витрину — только то, что прошло проверку на schema, dedup и обязательные поля.

Что важно хранить:
— raw payload целиком: чтобы пересобрать логику маппинга без повторной отправки
— event_id, client_id, user_id, fbp/fbc: для склейки и поиска дублей
— timestamp received / timestamp event: чтобы видеть лаги между браузером, сервером и DWH
— routing metadata: какой client, tag template, source domain, trigger

Дальше строится простой контроль:
— `COUNT(*)` vs `COUNT(DISTINCT event_id)` — ловит дубляж
— `NULL` по email_hash/phone_hash — показывает, где ломается enrichment
— доля событий без `user_agent` или `ip` — сигнал, что server context теряется
— сравнение inbound и outbound объёма по каждому event_name — помогает найти обрыв в маршрутизации

Главная ошибка — использовать BigQuery как единственный источник истины для CAPI. Истина там только после нормализации: один и тот же `Purchase` может прийти три раза с разным quality, а в хранилище это будут три строки. Поэтому raw и curated должны жить отдельно.

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

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