Поддержка аукционов с несколькими продавцами с помощью посредничества защищенной аудитории

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

1. Посредничество по принципу «водопада» : разработчики приложений определяют упорядоченный список рекламных сетей, часто ранжированных по историческим показателям eCPM для данной сети. Этот список известен как цепочка посредничества . Платформа посредничества разработчика приложения использует этот список для вызова рекламных сетей в порядке их перечисления, чтобы определить релевантные источники рекламного спроса.
2. Программная медиация : Разработчик приложения настраивает несколько рекламных сетей для участия в торгах за рекламные возможности. Эти сети могут делать ставки в режиме реального времени, исходя из своей оценки возможностей.
3. Гибридная медиация : сочетание каскадной и программной методов медиации.

Водопадная медиация

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

Рисунок 1. Модель опосредования «водопад».

В серверной каскадной модели SDK для рекламных кампаний вызывает каждую рекламную сеть (или свой собственный SDK для аукционов) в порядке, указанном цепочкой посредничества. Если рекламная сеть может выполнить запрос на показ рекламы, она отображает объявление. В противном случае запрос отправляется следующей сети в цепочке. Этот процесс повторяется до тех пор, пока запрос не будет выполнен или цепочка не будет исчерпана.

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

Программная медиация

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

Рисунок 2: Модель программного посредничества

Гибридная медиация

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

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

Медиация по принципу «водопада» с участием защищенной аудитории

API Protected Audience на Android поддерживает каскадную медиацию, используя несколько аукционов, каждый из которых предназначен для отдельного узла в графе медиации. Если в аукционе нет победителя, вызывается следующий узел сетевого аукциона, пока цепочка не будет исчерпана. Процесс каскадной медиации выглядит следующим образом:

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

Рисунок 3. Каскадная модель медиации с использованием API защищенной аудитории.

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

Результат выбора рекламы

Возвращаемым типом функции selectAds() является объект AdSelectionOutcome . AdSelectionOutcome содержит URI рендеринга выигрышного объявления и AdSelectionId , представляющий собой непрозрачное целое число, идентифицирующее креатив выигрышного объявления.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId выступает в роли указателя на AdSelectionOutcome . Сегодня AdSelectionId передается в метод reportResult() в качестве параметра ReportImpressionInput , чтобы помочь определить правильные объявления, для которых вызываются методы reportWin() и reportResult() .

Предложение по выбору цепочек рекламных объявлений

Мы предлагаем перегрузить selectAds() с помощью AdSelectionFromOutcomesConfig .

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

Это позволяет SDK для медиации сравнивать ставку победившего объявления с минимальной ставкой следующей по порядку рекламной сети.

Пример 1:

Пример 2:

Отчет о привлечении успешных показов

Если в результате выбора объявления из selectAds(AdSelectionFromOutcomes) определяется победитель, то это объявление выигрывает в процессе медиации. Затем вызывается reportImpression с идентификатором выбранного объявления победителя из selectAds(AdSelectionFromOutcomes) и соответствующим параметром AdSelectionConfig .

Если в результате вызова selectAds(AdSelectionConfig) для любой из сетей возвращается победитель, то вызывается reportImpression с идентификатором выбранного объявления и конфигурацией из этого вызова.

Проведение каскадной медиации

Вот порядок действий при прохождении каскадной модели медиации.

1. Запустить подборку рекламы от первого лица.
2. Пройдите по цепочке посредничества. Для каждой сети третьих сторон выполните следующие действия:
   1. Создайте объект AdSelectionFromOutcomeConfig , включая идентификатор outcomeId исходного SDK и минимальную ставку (bid floor) из стороннего SDK.
   2. Вызовите функцию selectAds() с config полученными на предыдущем шаге.
   3. Если результат не пустой, верните объявление.
   4. Вызовите метод selectAds() текущего сетевого адаптера SDK. Если результат не пустой, верните объявление.
3. Если победитель в цепочке не найден, верните объявление от первого лица.

Передовые методы

Перед оптимизацией на основе собственных данных запустите контекстные аукционы.

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

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

Не урезайте цепочки обмена данными внутри устройства.

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

Дополнительные соображения

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

API для защищенной аудитории поддерживает каскадную медиацию и ограниченную программную медиацию. Более подробная информация о поддержке дополнительных вариантов использования программной медиации будет предоставлена ​​в будущем.

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