ROAS в programmatic ломается без раздельного учёта аукциона и конверсии

Стройте отчёт не от кампании, а от цепочки: bid request → bid response → win notice → impression → click/view → conversion. На каждом шаге фиксируйте ключи склейки: auction_id, impid, crid, dealid, placement, user_id/ppid, consent state.

Базовый слой:
— spend по win notice, не по DSP UI;
— revenue из postback/server-side event;
— match rate impression → conversion;
— lag до конверсии по окнам;
— ROAS отдельно для click-through и view-through.

Не смешивайте оптимизационный ROAS DSP и финансовый ROAS BI. Первый живёт в модели атрибуции и может включать modeled conversions. Второй считается из биллинга, дедупликации и CRM/order events.

Разрезы обязательны: source/ssp/schain, domain/app bundle, device, geo, deal type, creative id. Без них SPO превращается в средний ROAS: чистый supply маскирует дорогой путь.

Вывод: сначала зафиксируйте контракт событий и ключи join, потом спорьте об attribution window. Иначе ROAS будет артефактом логов, а не метрикой окупаемости.

MOAT считает viewability, но не видит весь риск: где у метрики слепые зоны

MOAT полезен как слой контроля качества инвентаря, но его нельзя читать как полный отчёт по кампании. Он хорошо ловит: viewable/non-viewable, время в фрейме, часть сигналов по brand safety и IVT-классам. Но он не отвечает на вопросы по аукциону: почему потерян bid, где режется supply path, какой bidder системно даёт late response.

Слепые зоны обычно сидят в интеграции: — MOAT-тег стоит не на том слое, и iframe/redirect ломает часть событий; — lazy load или sticky-форматы искажают viewability; — один и тот же placement даёт разные значения в web, app и AMP; — post-bid сигналы не совпадают с тем, что увидел bidder в bid request.

Ещё один риск — интерпретировать MOAT как truth source для всех метрик. Если в Prebid timeout агрессивный, bidder может не ответить, но MOAT покажет только итог по показу. Если у вас GAM с несколькими посредниками, отчёт по viewability может выглядеть чисто, а деньги теряются на пути к аукциону.

Проверка должна быть простой: сверяйте MOAT с логами ad server, bid stream и render-событием. Ищите расхождения по placement ID, creative ID, размеру слота и типу устройства. Если сигналы не сходятся, проблема чаще в цепочке доставки, чем в самом измерении.

Frequency capping cross-platform ломается не в DSP, а в идентификаторе и окне синхронизации

Если user виден в web, app и CTV, один и тот же cap нельзя считать по разным ключам. Нужен общий keyspace: uid, household_id, device_graph_id или связка через server-side profile. Иначе один человек получит 3–5 показов на каждом канале и вы увидите «нормальный» frequency report вместо дублей.

Технически cap делается на трёх слоях:
— pre-bid: отсекаем уже exhausted users до запроса в bidder;
— decisioning: храним счётчик в low-latency store с TTL по окну cap;
— post-impression: атомарно инкрементим счётчик после win notice / impression ping.

Критично выбрать семантику окна: rolling 24h, calendar day, campaign lifetime или session cap. Для cross-platform чаще нужен rolling window, иначе midnight reset даёт ложный refresh. TTL должен совпадать с логикой отчётности, а не с удобством backend-команды. ⏱️

Если нет стабильного ID, cap строят через probabilistic graph, но тогда обязательно вводят confidence threshold и fallback: лучше недокапить, чем перекапить premium inventory. Для publisher-side stack полезно держать отдельные caps на advertiser, campaign, creative и household.

Практика простая: сначала нормализуйте идентификатор, потом окно, потом атомарность записи. Пока эти три слоя не совпали, cross-platform frequency capping будет выглядеть как working setup и давать утечки в delivery.

Лонгрид о мемном кейсе Melbet vs Pepper Partners - реально ли оценить в аффилейтке репутационный ущерб в деньгах?

История на $2,000 вряд ли разрушит крупный бренд. Но она вполне может стоить ему сотен тысяч долларов и более, если публично остаётся без внятного решения.

Я в аффилейт-маркетинге более 25 лет, а последние пару лет одно из моих основных направлений - B2B matchmaking. Поэтому я регулярно вижу споры между компаниями о выплатах и претензии, и таких ситуаций в рынке явно становится больше.

Знаю многие кейсы, которые были в итоге решены благополучно до выхода в публичное поле и всегда приятно видеть, когда так происходит, но все больше и больше кейсов, которые не просто выходят в паблик, а еще и очень странным и глупым образом в паблике продолжают долго оставаться и наносить ущерб в то время как имеют очень простые и адекватные для обеих сторон варианты решения.

Вот например про один из таких кейсов писал уже здесь весной.

Если неконструктивны обе стороны (а бывает и так), то можно к этому относиться просто как к развлекательному контенту.

Но когда одна сторона открыта к адекватной коммуникации и поиску оптимального решения, а вторая сторона просто игнорирует проблему, при этом не уходя с рынка в закат, а продолжая тратить огромные бюджеты на PR и маркетинг бренда - это любопытная аномалия.

Сейчас самый заметный в аффилейт рынке пример это кейс Melbet <> Pepper Partners, который уже более месяца развивается в публичном поле и о нем уже писали и многие аффилейт медиа, и отдельные блоги, я наверно один из последних, кто у себя в блоге еще об этом не писал)

Изначальное заявление кейса и описание претензии от Pepper Partners можно почитать здесь.

Очень приличный на мой взгляд разбор со стороны и указание пары простых и логичных вариантов решения ситуации написал Артем Кравченко, можно почитать у него.

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

Для мелкого и крупного бренда такие истории могут иметь очень разный эффект, поэтому здесь разберем на примере крупного бренда, так как Melbet в нашем рынке относится именно к таким.

Не знаю конечно их точные цифры затрат на PR в рамках афф рынка (участие в конфах, собственные ивенты, реклама в афф медиа и т.п.), но из того, что вижу как организатор ивентов с приличным опытом, этот бюджет явно измеряется в миллионах $ в год, если не выходит за $10млн+.

Это без PR затрат на прямое привлечение игроков (бренд-амбассадоры, спонсорства футбольных клубов и т.п.), без бюджетов непосредственно на закупку трафика. Только на аффилейтку.

И вот уже более месяца в паблике незакрытый и не откоммуницированный публично кейс на $2k (две тысячи долларов).

В публичной дискуссии сейчас преобладает позиция, что Melbet в этом споре неправы.

Может их развернутая публичная позиция поменяла бы мнение, но ее нет, соответственно на данный момент так.

Какие материальные потери может понести бренд в такой истории?

Многие люди, даже очень опытные и умные, почему-то к таким ситуациям относятся бинарно.

Рухнет бренд (закроется, обанкротится) - значит плохо на них повлиял кейс.

Останется бренд жить и работать как ни в чем не бывало внешне - значит никак не повлияло и может они правильно решили игнорировать, а кто-то вообще решит брать с них пример.

Но это же совсем не так, ситуация не бинарная.

Представим не фактические цифры Melbet, которых у нас нет, а консервативную модель крупного рекламодателя.

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

Я не знаю внутренний LTV партнёра у Melbet. Но если принять для активного опытного аффилейта условные $10,000 LTV, десять таких потерянных партнеров - это уже шестизначная сумма $ недополученного дохода. И это без учёта крупных команд, в случае которых эффект может быть кратно выше и оказаться семизначным.

Даже если в этой модели ошибиться и завысить в несколько раз, сам принцип никуда не исчезает - незакрытый публичный спор на $2,000 в любом случае обойдется бренду многократно дороже этих $2,000.

Цифры конечно я прикинул условные, но рассуждения не виртуальные - я знаю афф команды, которые перестали быть их активными партнерами из-за этого кейса.

Одна известная в рынке команда публично рассказала о своем таком решении в моем чатике про scam-кейсы.

А теперь вернемся к миллионам долларов в год, которые Melbet тратит на публичный PR среди аффов через конфы и прочие активности.

У этих трат же есть определенные ожидаемые и реальные результаты, верно?

На каждый затраченный миллион ожидается определенное количество привлеченных новых партнеров и укрепление лояльности и увеличение оборотов с определенным количеством действующих партнеров.

Вообще без понятия какая там ожидаемая сумма выхлопа на каждый потраченный миллион, поэтому обозначим ожидаемую сумму выхлопа с потраченного на PR миллиона в X.

При таком незакрытом публичном кейсе, вызывающем большой отклик и возмущение в рынке - останется эта сумма выхлопа с PR X без учета прочих факторов или она станет меньше X?

Очевидно станет меньше, доверие к бренду ниже, а значит и вложения в PR дают меньшую отдачу.

Я понимаю, что не все читатели, в том числе заинтересованные, могут дружить с математикой, и особенно понятием математического ожидания на дистанции, но вопрос здесь не только в этике и не только в справедливости конкретной претензии. Это вопрос качества управленческого решения.

Когда бренд инвестирует миллионы в доверие рынка - через конференции, медиа, партнёрские активности и PR, игнорирование аргументированного публичного конфликта снижает отдачу от всех этих вложений. Репутация не выглядит отдельной строкой в P&L, но её потеря вполне превращается в недополученный доход, более дорогой PR и менее лояльных партнёров.

Я искренне надеюсь, что все больше компаний в нашем рынке будут становиться более сознательными и не терять огромные деньги на ровном месте, и если бизнес-этика не зашита в культурный код, то хотя бы из сугубо материальных корыстных соображений начнут вести себя адекватнее)

Всем отличной недели и благоразумия)

First-price auction в RTB: где ломается логика ставок и почему second-price был проще

В first-price победитель платит свою же bid price. В second-price — почти всегда чуть выше следующей ставки, поэтому старый стек мог жить с более агрессивным bidding без постоянной ручной коррекции.

Для паблишера first-price обычно даёт более прозрачный revenue per win, но ломает привычные ожидания по CPM: одинаковый bid stream начинает приносить меньше, если bidders не умеют shading. Для buyer-side это означает одно: модель должна учитывать win-rate, floor, конкуренцию в supply path и вероятность переторга, иначе переплата становится системной.

Проверять first-price интеграцию стоит по трём точкам:
— bid response: нет ли завышенных бидов «на удачу»;
— auction dynamics: как меняется clearing price после floor adjustments;
— supply path: не уходит ли часть инвентаря в более дорогой маршрут из-за слабой конкуренции.

В Prebid и на стороне SSP критичны timeout, floor logic и consistency между bidder и exchange: если один слой считает аукцион first-price, а другой продолжает оптимизироваться как под second-price, вы увидите либо просадку win rate, либо лишний spend. Особенно заметно это в PMPs и в сегментах с узким supply.

Практика простая: сначала меряйте delta между bid и paid price, потом сегментируйте по geo, device и placement, и только после этого меняйте стратегию shading. Иначе вы оптимизируете не аукцион, а шум.

$80 за FTD на СНГ — казино-оффер от ПОКЕРОК Partners

Ищете новый оффер для теста? Рассказываем, что предлагаем партнёрам:
• CPA $80 за FTD на все гео СНГ
• $100 к первой выплате для новых аффилиатов
• 5% по саб-реферальной программе
• прозрачная статистика в партнёрском кабинете
• поддержка личного менеджера

Принимаем различные источники: social, мессенджеры, YouTube / Twitch / Kick, SEO, PPC, in-app и медийный трафик.

В казино ПОКЕРОК также доступна GG99 — линейка из 20+ игр с RTP 99%, включая слоты, настольные игры, видеопокер и аркады. Это весомое преимущество для новых игроков в дополнение к приветственным бонусам.

И ещё один повод подключиться уже сейчас: 27 августа состоится Friendly Tournament для партнёров ПОКЕРОК Partners. Успейте подключиться до 25 августа, чтобы принять участие!

Присоединяйтесь к ПОКЕРОК Partners и начинайте зарабатывать на своём трафике уже сейчас!

OpenRTB 3.0 для арбитража: где в bid request теряется маржа

Для арбитражной команды OpenRTB 3.0 важен не как «ещё одна спецификация», а как карта цепочки: кто сформировал запрос, кто его перепродал, какие ограничения и сигналы качества дошли до DSP.

Смотрите не только на imp, site/app и device. Полезный минимум для аудита:
— source: происхождение инвентаря и hops в цепочке;
— sellers.json + ads.txt: совпадает ли продавец с заявленным;
— regs / user: есть ли consent и usable ID;
— metric: viewability, IVT, completion rate, если SSP передаёт.

Типовая утечка: покупаете «паблишера», а в цепочке сидят реселлеры без прозрачного sid. CPM выглядит дешевле, но win-rate ниже, post-click шумнее, а DSP режет bids по trust-сигналам.

Для CPA-связок полезно логировать bid request до трекера: domain/app bundle, schain, placement, floor, geo, device, consent. Без этого SPO превращается в ручное отключение площадок по конверсиям, а не в чистку supply path.

Вывод: OpenRTB 3.0 нужен арбитражнику не для чтения RFC, а для диагностики закупки. Если не видите цепочку продавцов и quality-сигналы, вы оптимизируете оффер вслепую.

Google Ad Manager выбирают по умолчанию. Но не всем нужен именно он

Если у вас mixed inventory, header bidding и несколько demand-источников, сравнивать GAM с альтернативами надо по трём осям: контроль правил аукциона, прозрачность отчётности и цена операционного слоя. У GAM сильная сторона — связка с экосистемой и привычный ad ops workflow. Слабая — жёсткая логика, где часть решений спрятана за интерфейсом и ограничениями policy.

Альтернативы обычно делятся на два класса: managed SSP-platforms и open / self-hosted ad server stack. Magnite, PubMatic, Index Exchange, Sovrn дают удобный монетизационный слой, но вы зависите от их логики маршрутизации и уровня доступа к данным. Open-source и self-hosted варианты выигрывают там, где важны кастомные decision rules, собственный pricing logic и контроль над auction waterfall.

Смотрите не на бренд, а на чек-лист интеграции:
— есть ли granular line-item control и targeting без костылей;
— как устроены key-values, passback, frequency caps и roadblocking;
— можно ли нормально связать ads.txt / sellers.json / app-ads.txt;
— отдаёт ли стек сырой bid stream для SPO и антифрода;
— сколько ручной работы в GAM replacement понадобится ad ops команде.

Если вам нужен быстрый time-to-market и стандартный publisher stack — GAM обычно достаточно. Если нужен контроль над economics, кастомная логика и меньше black box в цепочке, смотрите в сторону альтернатив и сразу проверяйте не UI, а доступ к данным и правилам аукциона.

↩️ Пост из @NutraCabinPro:

Я люблю, когда терминал выглядит как «просто железка», а внутри — маленький цирк. Kozen P10F как раз из таких: его ставят в киосках самообслуживания и на кассах, он новее и заметно бодрее старых квадратных коробок.

Почему мне это интересно? Потому что в affiliate-cpa всё держится на том же принципе: снаружи — один и тот же оффер, а внутри может быть совсем другая логика. Платформа, ограничения, прошивка, сценарии — и вот уже один терминал живёт, а другой умирает от любой лишней нагрузки.

Можно ли накатить свою прошивку? Теоретически — вопрос не в «можно», а в том, сколько у тебя контроля над железом и насколько хорошо ты понимаешь риски. В продукте, как и в арбитраже, самая дорогая ошибка — это попытка «доработать» систему, не разобравшись, где у неё болит.

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

OpenRTB 3.0 для арбитража: где ломается bid request и как это ловить

В 3.0 главный сдвиг — структура запроса становится объектной, а не плоской. Для арбитражной команды это означает одно: нельзя смотреть только на bid.price и device.ua, нужно валидировать связки source / seat / source.ext, user, regs и content как единый контракт.

— source: проверяйте цепочку supply chain, иначе SPO-отчёты будут врать.
— user: идентификаторы и сегменты могут жить в разных ветках; потеря одного поля не всегда видна в логах bidder’а.
— regs: consent и privacy-флаги нельзя просто прокинуть «как есть» из старого payload.
— imp: placement, format и ext должны совпадать с тем, что реально уходит в wrapper или SDK.

Практика простая: делайте mapping-слой между legacy 2.x и 3.0, а не «прямой прокид». Иначе часть трафика тихо уедет в no-bid из-за пустых обязательных объектов, а часть — в неверный floor, когда ext не распарсился на стороне bidder’а.

Если вы держите свои Prebid / SSP / DSP-интеграции на object-based модели, проверяйте не только наличие полей, но и их вложенность, типы и согласованность между source, user и imp. Тогда OpenRTB 3.0 перестаёт быть проблемой схемы и становится нормальным инструментом для чистого bid stream.