Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Реклама — один из популярных способов монетизации развлекательных проектов и приложений. На примере iFunny я расскажу о механизмах получения рекламы и некоторых сложностях, с которыми можно столкнуться при интеграции рекламных SDK.
Инвентарь — это совокупность всех рекламных плейсментов сайта, приложения и т.д.
В инвентаре iFunny есть всего два плейсмента. Баннер располагается под контентом и практически всегда находится на экране. Нативная же реклама с некоторой периодичностью вставляется в ленту вместо контента.
Паблишер — это площадка, в инвентаре которой размещается реклама. Паблишер с рекламной сетью (далее — РС) может работать напрямую, но это не обязательно. В рекламной модели, используемой iFunny, есть третий участник — медиатор. То есть всегда в приложении стараются показывать рекламу, которая приносит наибольший доход, поэтому оно работает не с одной РС, а сразу с несколькими. Для каждого объекта инвентаря в системе медиатора существует специальный id, по которому паблишер запрашивает рекламу. В ответ медиатор предлагает варианты настроек, по которым тот будет обращаться к какой-то из РС в попытке получить самую дорогую рекламу.
Существует две принципиально разных модели выстраивания работы с получением рекламы: водопад и аукцион. Рассмотрим их подробнее.
Водопадная модель подразумевает перебор упорядоченных по CPM (cost-per-mille, т.е. цена за 1000 показов) настроек до тех пор, пока реклама не будет загружена. Приложение запрашивает настройки у медиатора и, получив их, идёт к конкретной РС. В случае положительного ответа происходит попытка загрузить предложенный креатив (со всеми сопроводительными ресурсами). В конце итерации отправляется сообщение о результате медиатору. В случае неудачи на любом из этапов всё повторяется. В результате для загрузки одного баннера могут быть выполнены сотни, а то и тысячи запросов. Такой механизм влияет на время загрузки баннера. Разумеется, всё это зависит ещё и от длины водопада.
В аукционной модели проблемы со временем и количеством запросов решены: приложение опрашивает каждую из сетей о том, по какой максимальной цене она готова купить инвентарь. Затем медиатор выбирает самый выгодный для паблишера вариант и возвращает настройки для попытки получения рекламы. С вероятностью в «почти наверное» РС отдаст нам рекламу по этим настройкам (ведь она её уже пообещала парой шагов ранее).
В iFunny постоянно ведутся эксперименты с подходами и в основном используется смешанный вариант:
В лучшем случае удастся обойтись одной итерацией: выбор будет стоять между самой высокой ставкой и первым уровня водопада. В худшем — придётся повторять попытки, планомерно спускаясь по водопаду.
Многие РС стремятся сделать свою рекламу уникальной, узнаваемой. Если вы хотите сотрудничать с определённой РС, скорее всего, вам придётся имплементировать ихдалеко не идеальный SDK в вашу кодовую базу, чтобы показывать их рекламу.
Помимо уникального дизайна, в SDK обычно реализуют собственную логику отправки событий аналитики.
В личных кабинетах рекламных сетей медиатора можно указывать категории, которые интересны целевой аудитории вашего продукта: спорт, путешествия, книги, образование, развлечения, игры и т.д.
Некоторые РС, например, не стесняются использовать информацию о положении девайса в пространстве. Так они в том числе понимают, какой креатив показывать: для книжной или альбомной ориентации девайса.
Аналитика очень важна при подсчёте денег — кто кому сколько должен.
Каждый рекламодатель хочет точно знать всю статистику по его креативам. Какой паблишер и сколько раз показал? А сколько было кликов? А если креатив содержит видео, то там вообще может быть миллион событий: показали на экране адаптер с креативом — событие; началось воспроизведение — ещё одно; пользователь включил или выключил звук — опять события; просмотрено 25% от длины видео — что-то давно события не отправляли…
У iFunny есть своя собственная система аналитики, и сейчас логируются 5 разных событий:
Все данные об успешных показах и кликах собираются непосредственно медиатором. Таким образом, в случае спорных ситуаций можно опираться на информацию, которую хранит медиатор.
Рекламные интеграции приносят не только деньги, но и проблемы, с которыми приходится справляться.
Для одной попытки получения рекламы нужно пройти 11 шагов, на каждом из которых может что-то пойти не так.
Тестирование, как правило, проводится на одних и тех же девайсах, и рекламщики могут воспринимать такие устройства как инструмент для накрутки просмотров. Отсюда возникают сложности с получением рекламы на этапе тестирования. Не у всех РС есть функционал тестового режима, в котором эта проблема решена. Есть и такие, у которых тестовый режим существует, но работает крайне нестабильно. Более того, если какой-то функционал работает на тестовом креативе, то совершенно не факт, что на реальном креативе этот функционал отработает так же.
Нередко проблемы можно найти и в отправке аналитики. Может, например, оказаться, что если реклама — видео-контент, то РС засчитает показ рекламы, только если пользователь посмотрел первые 5 секунд этого видео.
В конце концов, нужно понимать, что любой сторонний SDK в кодовой базе — это чёрный (или не очень) ящик, который не только выполняет полезную работу, но и генерирует проблемы. За качество написанного внутри SDK кода отвечаете не вы, а сторонний разработчик. Иногда этим качеством можно управлять, но, как правило, код обфусцирован и остаётся только догадываться, за что отвечает a.b.c.d.e.f, а за что k.l.m.n.p.
Время от времени выходят новые версии SDK. Нередко задача «обновить SDK X» подразумевает переподключение с нуля. Или наоборот, обновить нужно один файл, но вдруг обнаруживается, что не работает фактически всё. Обычно за этим следуют несколько часов исследований. Все эти проблемы, как правило, вызваны тем, что changelog обновлённой версии не отражает сути реальных изменений, а иногда его попросту нет. Но это и объяснимо: публичное признание проблем, хоть уже и решённых, может стоить рекламщикам больших денег.
Безусловно, реклама — сильный инструмент в монетизации продукта. Можно применять его по-разному: кому-то достаточно иметь в инвентаре один баннер, который заполняется лишь одной РС, а кто-то строит огромные системы, которые сочетают в себе сразу несколько механик и десятки РС. При выборе модели взаимодействия с РС стоит принимать во внимание и сложность последующей поддержки этой системы. Выбирайте такое решение, которое будет эффективно именно в вашем случае.
Глоссарий и общие механики
Инвентарь — это совокупность всех рекламных плейсментов сайта, приложения и т.д.
В инвентаре iFunny есть всего два плейсмента. Баннер располагается под контентом и практически всегда находится на экране. Нативная же реклама с некоторой периодичностью вставляется в ленту вместо контента.
Паблишер — это площадка, в инвентаре которой размещается реклама. Паблишер с рекламной сетью (далее — РС) может работать напрямую, но это не обязательно. В рекламной модели, используемой iFunny, есть третий участник — медиатор. То есть всегда в приложении стараются показывать рекламу, которая приносит наибольший доход, поэтому оно работает не с одной РС, а сразу с несколькими. Для каждого объекта инвентаря в системе медиатора существует специальный id, по которому паблишер запрашивает рекламу. В ответ медиатор предлагает варианты настроек, по которым тот будет обращаться к какой-то из РС в попытке получить самую дорогую рекламу.
Существует две принципиально разных модели выстраивания работы с получением рекламы: водопад и аукцион. Рассмотрим их подробнее.
Водопадная модель подразумевает перебор упорядоченных по CPM (cost-per-mille, т.е. цена за 1000 показов) настроек до тех пор, пока реклама не будет загружена. Приложение запрашивает настройки у медиатора и, получив их, идёт к конкретной РС. В случае положительного ответа происходит попытка загрузить предложенный креатив (со всеми сопроводительными ресурсами). В конце итерации отправляется сообщение о результате медиатору. В случае неудачи на любом из этапов всё повторяется. В результате для загрузки одного баннера могут быть выполнены сотни, а то и тысячи запросов. Такой механизм влияет на время загрузки баннера. Разумеется, всё это зависит ещё и от длины водопада.
В аукционной модели проблемы со временем и количеством запросов решены: приложение опрашивает каждую из сетей о том, по какой максимальной цене она готова купить инвентарь. Затем медиатор выбирает самый выгодный для паблишера вариант и возвращает настройки для попытки получения рекламы. С вероятностью в «почти наверное» РС отдаст нам рекламу по этим настройкам (ведь она её уже пообещала парой шагов ранее).
Как устроен процесс получения рекламы в iFunny
В iFunny постоянно ведутся эксперименты с подходами и в основном используется смешанный вариант:
- Cначала опрашиваются сети, с которыми работа ведётся по аукционной модели.
- Ожидается ответ от всех партнёров.
- Полученные ставки сохраняются на стороне клиента и отправляются в SDK медиатора.
- Медиатор, получив ставки, добавляет их к уже существующему водопаду.
- Медиатор идёт по водопаду сверху вниз и предлагает приложению вариант настроек для обращения в РС.
- Управление загрузкой передаётся в SDK партнёра, который обрабатывает присланные медиатором настройки.
- Приложение с полученными настройками обращается к партнёру в попытке получить рекламу.
- Партнёр возвращает приложению настройки для загрузки креатива (just in case you are lucky enough).
- Приложение делает попытку загрузить сам креатив.
- Креатив со всеми его ресурсами, загружается на девайс (if you are doubly lucky).
- Приложение отрисовывает рекламу.
В лучшем случае удастся обойтись одной итерацией: выбор будет стоять между самой высокой ставкой и первым уровня водопада. В худшем — придётся повторять попытки, планомерно спускаясь по водопаду.
SDK
Многие РС стремятся сделать свою рекламу уникальной, узнаваемой. Если вы хотите сотрудничать с определённой РС, скорее всего, вам придётся имплементировать их
Помимо уникального дизайна, в SDK обычно реализуют собственную логику отправки событий аналитики.
Таргетинг
В личных кабинетах рекламных сетей медиатора можно указывать категории, которые интересны целевой аудитории вашего продукта: спорт, путешествия, книги, образование, развлечения, игры и т.д.
Некоторые РС, например, не стесняются использовать информацию о положении девайса в пространстве. Так они в том числе понимают, какой креатив показывать: для книжной или альбомной ориентации девайса.
Аналитика
Аналитика очень важна при подсчёте денег — кто кому сколько должен.
Каждый рекламодатель хочет точно знать всю статистику по его креативам. Какой паблишер и сколько раз показал? А сколько было кликов? А если креатив содержит видео, то там вообще может быть миллион событий: показали на экране адаптер с креативом — событие; началось воспроизведение — ещё одно; пользователь включил или выключил звук — опять события; просмотрено 25% от длины видео — что-то давно события не отправляли…
У iFunny есть своя собственная система аналитики, и сейчас логируются 5 разных событий:
- Ad Requested. Статистика по каждой попытке запроса рекламы:
- тип рекламы (нативная или баннерная);
- РС;
- успешность загрузки (если не удалось загрузить, то почему).
- Ad Attempt. Показывает время от самого первого запроса рекламы до её успешного получения. Так можно экспериментировать с водопадом и его длиной, прогнозировать время, необходимое для получения рекламы.
- Ad Viewed. Если показали креатив, то необходимо запомнить информацию об этом — пригодится для определения выплат от рекламных сетей.
- Ad Tapped. Аналогично предыдущему, но если совершается переход по ссылке из креатива.
- Ad Revenue. С версии 5.7.0, MoPub присылает вместе с креативом и его CPM. Эта информация позволяет записывать доходы, ожидаемые от показов, и предоставляет широкие возможности для анализа. В iFunny этим активно пользуются.
Все данные об успешных показах и кликах собираются непосредственно медиатором. Таким образом, в случае спорных ситуаций можно опираться на информацию, которую хранит медиатор.
Проблемы
Рекламные интеграции приносят не только деньги, но и проблемы, с которыми приходится справляться.
Для одной попытки получения рекламы нужно пройти 11 шагов, на каждом из которых может что-то пойти не так.
Тестирование, как правило, проводится на одних и тех же девайсах, и рекламщики могут воспринимать такие устройства как инструмент для накрутки просмотров. Отсюда возникают сложности с получением рекламы на этапе тестирования. Не у всех РС есть функционал тестового режима, в котором эта проблема решена. Есть и такие, у которых тестовый режим существует, но работает крайне нестабильно. Более того, если какой-то функционал работает на тестовом креативе, то совершенно не факт, что на реальном креативе этот функционал отработает так же.
Нередко проблемы можно найти и в отправке аналитики. Может, например, оказаться, что если реклама — видео-контент, то РС засчитает показ рекламы, только если пользователь посмотрел первые 5 секунд этого видео.
В конце концов, нужно понимать, что любой сторонний SDK в кодовой базе — это чёрный (или не очень) ящик, который не только выполняет полезную работу, но и генерирует проблемы. За качество написанного внутри SDK кода отвечаете не вы, а сторонний разработчик. Иногда этим качеством можно управлять, но, как правило, код обфусцирован и остаётся только догадываться, за что отвечает a.b.c.d.e.f, а за что k.l.m.n.p.
Время от времени выходят новые версии SDK. Нередко задача «обновить SDK X» подразумевает переподключение с нуля. Или наоборот, обновить нужно один файл, но вдруг обнаруживается, что не работает фактически всё. Обычно за этим следуют несколько часов исследований. Все эти проблемы, как правило, вызваны тем, что changelog обновлённой версии не отражает сути реальных изменений, а иногда его попросту нет. Но это и объяснимо: публичное признание проблем, хоть уже и решённых, может стоить рекламщикам больших денег.
Безусловно, реклама — сильный инструмент в монетизации продукта. Можно применять его по-разному: кому-то достаточно иметь в инвентаре один баннер, который заполняется лишь одной РС, а кто-то строит огромные системы, которые сочетают в себе сразу несколько механик и десятки РС. При выборе модели взаимодействия с РС стоит принимать во внимание и сложность последующей поддержки этой системы. Выбирайте такое решение, которое будет эффективно именно в вашем случае.
