Монетизация приложений и сайтов: стандарты и лучшие практики

Монетизация рекламы держится на трех вещах: покупатель должен доверять инвентарю, понимать, кому показывает рекламу, и видеть ее на экране. Отсюда чек-лист паблишера: опубликовать ads.txt или app-ads.txt, передавать в запросе максимум сигналов, разумно выставить флоры, продавать через биддинг, следить за видимостью, не злоупотреблять рефрешем и плотностью рекламы и мерить доход на пользователя, а не только eCPM.

#Чек-лист в одной таблице

Дальше — по каждому пункту коротко, со ссылками на подробные материалы.

#Прозрачность: ads.txt, sellers.json и schain

Покупатели закупают только тот инвентарь, право продавать который можно проверить. Для этого есть три связанных стандарта IAB Tech Lab:

• ads.txt (для приложений — app-ads.txt на сайте разработчика, указанном в магазине приложений) — список систем, которым владелец площадки разрешил продавать рекламу, с ID аккаунта и типом связи DIRECT или RESELLER. Версия 1.1 добавила переменные OWNERDOMAIN и MANAGERDOMAIN.
• sellers.json — обратная сторона: SSP или биржа публикует, кто ее продавцы и кто из них владелец инвентаря (PUBLISHER), а кто посредник (INTERMEDIARY).
• SupplyChain (schain) — цепочка узлов в самом запросе: каждый посредник дописывает себя, чтобы покупатель видел весь путь показа.

Типичная потеря дохода здесь не техническая, а организационная: подключили новую сеть, а строку в app-ads.txt не добавили. Запросы идут, но часть DSP их отбрасывает. Сверяйте файл при каждом изменении медиации.

#Полный bid request: за что покупатель готов платить больше

DSP оценивает показ по тому, что видит в запросе на ставку. Чем меньше она знает, тем осторожнее ставка: без рекламного ID не работают ретаргетинг и частотные ограничения, без гео — геотаргетинг, без точного размера — креатив может не подойти вовсе.

Правило простое: если сигнал есть у SDK и пользователь дал согласие, он должен дойти до покупателя без искажений. Типичные потери — рекламный ID, который SDK не запросил или передал из одних нулей, и неточный bundle: без них покупатель видит «анонимный» показ.

#Флоры: защищать цену, не душить спрос

Флор (bidfloor) — минимальная цена показа. Жесткий флор отсекает ставки ниже порога, мягкий — внутреннее правило некоторых бирж, а динамический меняется по слоту, стране, устройству и времени суток. Практика, которая работает чаще других:

1. Начинать с низких флоров и копить распределение ставок по каждому слоту.
2. Поднимать флор только там, где ставки плотно лежат выше текущего порога.
3. Судить по доходу на тысячу запросов, а не по eCPM: флор почти всегда поднимает eCPM, вопрос — какой ценой в заполнении.

Иллюстративный пример. Слот получает 100 000 запросов в день. При флоре 40 ₽ заполнение 70%, eCPM 90 ₽ — доход 6 300 ₽. При флоре 80 ₽ заполнение 45%, eCPM 120 ₽ — доход 5 400 ₽. eCPM вырос на треть, а денег стало меньше.

#Водопад, in-app bidding и header bidding

Водопад отдает показ первому источнику, согласившемуся заплатить порог, а биддинг — лучшей реальной ставке среди опрошенных одновременно. В вебе биддинг строят через header bidding, в приложениях — через in-app bidding в SDK-медиации; там же разобрано, чем гибрид лучше чистого водопада.

Что проверить в настройке:

• каждая строка водопада ниже лучшей ставки биддинга — лишняя задержка без шанса выиграть;
• таймаут аукциона согласован с tmax партнеров: короткий срезает поздние дорогие ставки, длинный тормозит показ;
• один и тот же спрос, пришедший через несколько путей, конкурирует сам с собой — это нормально, если цепочки прозрачны.

#Видимость и ленивая загрузка

Покупатели платят больше за показы, которые человек мог увидеть. Стандарт MRC для медийной рекламы — не меньше 50% площади объявления на экране не меньше секунды подряд (подробно — в статье про viewability). Что поднимает видимость:

• ленивая загрузка: запрашивать рекламу, когда место приближается к зоне просмотра, а не при открытии страницы;
• места в контенте, а не в подвале, куда мало кто долистывает;
• быстрые креативы и статика с правильным кешированием — медленный баннер успевают пролистать.

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

#Рефреш, кеширование и таймауты

Три технические темы, на которых паблишеры теряют деньги незаметно, разобраны отдельно:

• Рефреш рекламы — обновлять объявление только по таймеру видимого времени, не чаще порога рекламных систем и с объявлением рефреша покупателю в imp.refresh.
• Кеширование рекламы — предзагружать полноэкранные форматы, но следить за сроком годности ставки и не кешировать трекеры.
• Ретраи и коды nbr — переспрашивать только при технических сбоях и в остатке бюджета времени, а отказы с причиной «бот» или «невалидный запрос» не повторять.

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

#Плотность рекламы и опыт пользователя

Coalition for Better Ads по результатам опросов пользователей выделила форматы, которые раздражают сильнее всего. Для мобильного веба среди них всплывающие окна, престишиалы до контента, плотность рекламы больше 30%, мигающая анимация, автозапуск видео со звуком, постишиалы с отсчетом, полноэкранные перекрытия при прокрутке, крупные липкие баннеры и липкое всплывающее видео. Для десктопа — всплывающие окна, автовидео со звуком, престишиалы с отсчетом, крупные липкие баннеры, плотность выше 50% (или выше 30% вместе с липким видео). Для приложений — прерывающие межстраничные объявления, в том числе непропускаемое видео и видео при открытии приложения.

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

#Маркировка интернет-рекламы

В России реклама в интернете должна нести токен ERID, а сведения о ней — попадать в ЕРИР через операторов рекламных данных. Для паблишера это значит: креативы, которые приходят через программатик, должны содержать пометку «Реклама» и токен, а условия с продавцами — определять, кто и что сдает в отчетность. Кто за что отвечает в цепочке SSP — DSP — рекламодатель, разобрано в статье про маркировку в программатике. Это не юридическая консультация: требования меняются, сверяйтесь с действующей редакцией 38-ФЗ «О рекламе» и разъяснениями Роскомнадзора.

#Метрики: что считать и как связаны

Иллюстративный пример за один день: 200 000 запросов, 150 000 показов, доход 9 000 ₽, DAU 20 000.

fill rate                = 150 000 / 200 000          = 75%
eCPM                     = 9 000 / 150 000 × 1000     = 60 ₽
доход на тысячу запросов = 9 000 / 200 000 × 1000     = 45 ₽  (0,75 × 60)
ARPDAU                   = 9 000 / 20 000             = 0,45 ₽

Любое изменение — флор, рефреш, новая сеть — проверяйте по доходу на тысячу запросов и ARPDAU. Рост одного eCPM ничего не доказывает: его легко получить, срезав дешевые показы вместе с доходом.

#Что из этого уже есть в Ibiza

Биржа Ibiza публикует sellers.json: каждая активная площадка входит в него как PUBLISHER со своим seller_id, а внешний источник трафика — как INTERMEDIARY. Перепродавая трафик источника, биржа дописывает свой узел в schain запроса — в source.schain или source.ext.schain, смотря где цепочка пришла. Для веб-площадок админка по расписанию проверяет ads.txt на домене площадки и ищет строку с доменом биржи и seller_id. Для площадок, подключенных через SDK, флор задается на площадке и слоте и уточняется правилами по стране, производителю устройства, наличию рекламного ID и расписанию; для слотов с автофлором он поднимается до уровня, рассчитанного по наблюдаемым ценам клиринга. Порядок продажи показа: сделки PMP, затем водопад слота, затем общий аукцион среди разрешенных партнеров. Требования к запросу источника — в документации «Подключение SSP».