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.

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

Если cap задан отдельно для web, app и CTV, пользователь легко получает 3× показов вместо одного лимита. Нужен единый ключ: user_id, household_id или связка через identity graph. Без него вы капите не человека, а девайс.

Техническая схема простая:
— на входе нормализуете identity в общий namespace;
— храните счётчик в Redis/KeyDB с TTL на окно cap;
— инкремент делаете атомарно, до отправки bid response или render;
— отдельно считаете soft cap для частоты в аукционе и hard cap для фактического показа.

Ошибки обычно три: лаг репликации между регионами, расхождение timezone в окне cap и двойной учёт при late win notice. Для мультиплатформы нужен один источник истины, иначе DSP видит clean path, а паблишер — перегретую частоту. 🧩

Если нет стабильного identity, cap строят по иерархии: user > device > household > cookie. Тогда деградация контролируемая, а не хаотичная. Главное — логировать, по какому ключу сработало ограничение, иначе разбирать утечки частоты будете вслепую.

Bid shading в DSP: где именно DSP режет цену и как не сломать аукцион

Bid shading — это не «магия снижения CPM», а корректировка bid price относительно вероятности победы и уровня конкуренции в конкретном auction. DSP берёт сырые сигналы из bid stream, оценивает clearing price и подаёт не максимальную готовность платить, а цену с запасом, чтобы не переплатить за тот же инвентарь.

Технически шейдинг обычно упирается в 3 слоя:
— входные фичи: geo, device, publisher, placement, time bucket, floor, deal/open auction;
— модель вероятности win: где цена победы зависит от спроса, floor и density конкурентов;
— policy-ограничения: нельзя шейдить так, чтобы просадить win rate на узких supply-path или в PMPs.

Ошибки появляются там, где DSP считает шейдинг по усреднённому рынку, а не по конкретному path. Тогда одна и та же ставка в двух SSP ведёт себя по-разному: в одном случае вы выигрываете почти всегда, в другом теряете объём из-за агрессивного floor или более дорогой конкуренции. Поэтому production-логика почти всегда должна учитывать seller, deal id, traffic quality и historical clearance curve.

Проверять шейдинг надо не только по win rate. Смотрите на revenue per mille для паблишера, post-shading conversion efficiency для рекламодателя, долю missed wins на high-value сегментах и расхождение между predicted clearing price и фактическим win notice. Если эти кривые расходятся, модель уже не описывает auction.

Итог простой: bid shading работает только тогда, когда DSP шейдит цену на уровне path + сегмент, а не «средней температуры по инвентарю».