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

Оставьте отзыв

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

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

Посредничество водопада

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

Схема каскадной модели медиации
Рисунок 1. Водопадная модель посредничества.

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

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

Программное посредничество

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

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

Гибридное посредничество

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

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

Медиация каскада защищенной аудитории

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

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

Схема каскадного процесса медиации Защищенной аудитории
Рисунок 3. Посредничество каскада с API Protected Audience.

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

Результат AdSelection

Тип возвращаемого значения метода 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.
    2. Вызовите selectAds() с config из предыдущего шага.
    3. Если результат не пустой, верните объявление.
    4. Вызовите метод selectAds() текущего сетевого адаптера SDK. Если результат не пустой, верните объявление.
  3. Если в цепочке не найден победитель, верните собственное объявление.

Лучшие практики

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

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

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

Держите цепочки медиации на устройстве небольшими

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

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

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

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

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

{% дословно %} {% дословно %} {% дословно %} {% дословно %}