5 признаков, что проблема в SSP/DSP-интеграции, а не в трафике

Если ставки есть, а матчится мало, сначала смотрите не креативы и не таргетинг, а связку запросов: schema, required fields и правила аукциона. В programmatic чаще ломается не «модель», а контракт между сторонами.

— Несовпадение обязательных полей: bidrequest приходит, но DSP отбрасывает его из-за missing device, site/app или imp.
— Разные интерпретации price floor: SSP шлёт floor, DSP считает его невалидным или применяет другой currency/packing.
— Поле deal id есть, но условия deal не совпадают: seat, formats, inventory type, creative attrs.
— Частичные ответы: SSP ждёт bid в одном timeout, DSP отвечает позже и теряет выигрыш в аукционе.
— Тихие фильтры: blocklist, bundle/app-ads.txt, schain, sellers.json и UA-ограничения режут трафик без явной ошибки.

Самая частая ошибка — смотреть только на win rate. Низкий win rate может быть следствием слишком жёсткого floor, кривого timeout или несовместимости креатива с форматом. Высокий win rate тоже не гарантия качества: если post-auction отвал, проблема уже в валидации нативки, VAST или трекинга.

Для диагностики держите три лога рядом: raw bidrequest, bidresponse и post-auction events. Сверяйте не только коды ошибок, но и отсутствие полей — именно там чаще всего сидит поломка. Когда цепочка прозрачна, спор «SSP или DSP» быстро превращается в конкретный diff.

Сначала чинится контракт, потом оптимизируется bid strategy.

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

Postback от агентки в трекер ломается не из-за API, а из-за мелких косяков в логике

Чаще всего путают 3 вещи: event name, payout и статус конверсии. Агентка может шлать “approved”, а трекер ждёт “lead” или “sale”; в итоге конверсия есть, а в отчёте — пусто. Второй косяк — разные источники пишут в разные поля: postback уходит с одной валютой, трекер считает в другой.

На практике проблемы почти всегда в связке:
— не совпадает token / subid и конверсия не матчится;
— дублируется postback, потому что нет дедупликации;
— не проставлен макрос на click_id, и теряется связка клик → лид;
— передают тестовые лиды как боевые, а потом они портят статистику.

Что важно: сначала проверяй один путь данных от клика до конверсии. Ставь тестовый оффер, один поток, один postback, один статус. Если это работает, только потом подключай новые статусы, payout и дополнительные поля.

Ещё одна типовая ошибка — доверять “зелёным” цифрам в кабинете без сверки с трекером. Кабинет может считать по своему времени, округлять payout или вообще не отдавать часть статусов. Смотри не на красивый отчёт, а на совпадение id, статуса и суммы.

Если постбек не бьётся, ищи не “поломку системы”, а расхождение в одном из трёх мест: идентификатор, статус, дедупликация.

OpenRTB ломается не в протоколе, а в полях, которые вы заполнили «как-нибудь»

В интеграциях чаще всего путают три слоя: обязательные поля запроса, расширения `ext` и локальные договорённости между SSP и DSP. Если `imp`, `site/app`, `device`, `user`, `tmax` и `cur` заполнены непоследовательно, а `badv`, `bcat`, `regs`, `source` живут отдельной логикой, аукцион начинает вести себя «странно» уже на уровне матчей.

Проверяйте базовый набор:
— `imp.id` должен быть стабилен внутри запроса и совпадать в ответе.
— `banner`/`video`/`native` не должны конфликтовать с реальным форматом места.
— `schain` и `supplychain` должны описывать реальный путь инвентаря, иначе buyer-side фильтры режут трафик.
— `device.ifa`, `ip`, `ua`, `consent` и `regs` надо передавать консистентно, без дублирования и подмен.

Отдельная зона риска — приоритеты. Если DSP ждёт `floor`, а SSP отдаёт его в нестандартном `ext`, вы получаете не ошибку, а молча проигранные показы. То же самое с `wseat`, `dealid`, `at`, `mimes`, `protocols`: формально запрос валиден, но bidding logic уже не сходится с ожиданиями интеграции.

Самый полезный чек-лист перед запуском: сверить JSON-схему, прогнать один и тот же запрос через логи SSP и DSP, сравнить нулевые ответы, 204 и bid responses. Если поле влияет на таргетинг, биллинг или privacy, оно должно быть задокументировано и одинаково трактоваться на обеих сторонах.

Privacy Sandbox для programmatic: 6 вещей, которые надо проверить в интеграции

Если у вас в цепочке есть browser-based inventory, Privacy Sandbox ломает не «таргетинг вообще», а привычные допущения: меньше кросс-сайтовых идентификаторов, больше контекста и on-device сигналов. Для SSP/DSP это значит: часть логики уезжает из bid request в браузерные API, а часть — в server-side матчинг и моделирование.

Проверьте сбор сигналов: • есть ли fallback без third-party cookies; • не завязан ли frequency capping только на cookie; • умеет ли ваш bidder жить без user-level path между доменами; • не теряются ли consent и privacy flags при проксировании запросов. Если у вас Prebid или собственный wrapper, важно отдельно смотреть, где именно режутся параметры до аукциона.

Дальше — сегменты и измерение. Topics, Protected Audience и Attribution Reporting не заменяют старый user sync один-в-один: аудитории становятся менее переносимыми, а атрибуция — более агрегированной. Поэтому заранее отделяйте: 1) идентификацию; 2) таргетинг; 3) measurement. Если всё смешано в одном модуле, отладка превращается в угадайку.

Для DSP практичный чек-лист простой: логируйте, какие запросы пришли с browser API, какие — без них, и где вы реально получаете bid uplift. Для SSP — не маскируйте отсутствие идентификатора «пустым» user object: лучше честный контекст, чем сломанный матчинг.

Главная идея: интеграция должна деградировать по ступеням, а не падать целиком. Если у вас есть отдельные ветки для contextual, on-device signals и legacy cookie path, вы переживёте пост-cookie стек без переписывания всего аукциона.

Programmatic ломается не в аукционе, а в плохом описании инвентаря

Почти все проблемы в programmatic начинаются с трёх мест: неправильный placement, пустые device-поля и разъехавшийся floor. Если SSP не может корректно описать слот, DSP уходит в conservative bidding или режет спрос.

Проверь базу:
— placement_id стабилен и не переиспользуется между разными форматами;
— size и placement type совпадают с фактическим рендером;
— app/web не путаются в source.ext и bundle/domain;
— floor передаётся одним способом, без дублей в разных слоях.

Дальше смотрите, не ломаете ли вы сигнал на уровне OpenRTB: content, site/app, schain, user, regs, device. Один пустой или конфликтующий объект часто сильнее влияет на fill rate, чем кажется. Для байера это выглядит как «плохой инвентарь», хотя корень — в кривой интеграции.

Отдельно держите в порядке deal-логику: priority, targeting, adomain-ограничения, currency и creative validation. Если в логах нельзя восстановить цепочку решения, отладка превращается в гадание.

Чем чище описание инвентаря и логика передачи сигналов, тем меньше магии в аукционе и тем стабильнее eCPM.

7 сигналов, что SSP/DSP интеграция сломана ещё до первой сделки

Если цепочка bid request → bid response → win notice собрана криво, деньги теряются не в закупке, а в протоколе. Ищите не «плохой трафик», а разрывы в данных.

— В запросе есть impression, но нет нужных dimensions, placement, floor или auction type; DSP отвечает пусто или с default bidder logic.
— SSP режет user-объекты, а DSP ждёт device, geo, regs, schain, ext; в логах появляется много no-bid без явной причины.
— В ответе есть bid, но нет price, crid, adm или nurl в ожидаемом формате; выигрыш проходит, креатив не может загрузиться.
— Счётчик win rate растёт, а render rate падает: это обычно значит, что win notice, cache, timeout или macro-подстановки разъехались.

Проверяйте интеграцию по трём слоям: валидность OpenRTB-полей, совпадение таймингов на стороне SSP/DSP и корректность макросов в креативе. Отдельно смотрите schain, dealid, adomain и cat — именно там чаще всего всплывают расхождения между логикой площадки и логикой покупателя.

Если нет единого лога по request, response, win и render, вы видите только симптомы, а не причину. Лучший дебаг в programmatic — это не спор с баером, а поиск первого поля, которое перестало совпадать.