Compatibilidad con subastas de varios vendedores con la mediación de Protected Audience

Por lo general, las plataformas de anuncios orientadas a la venta diversifican sus fuentes de demanda de anuncios a fin de optimizar los ingresos publicitarios. Con la mediación de anuncios, una red de publicidad o un servicio invocan varias redes de publicidad a fin de encontrar el mejor anuncio para un espacio publicitario específico. En esta propuesta, se presenta cómo extender la API de Protected Audience en Android para implementar la funcionalidad de la mediación en cascada de una manera que preserve la privacidad. En la actualidad, las redes de publicidad proporcionan varias formas para que los desarrolladores de apps actúen como intermediarios en las subastas de anuncios de varios vendedores:

1. Mediación en cascada: Los desarrolladores de apps definen una lista ordenada de redes de publicidad, a menudo clasificadas por los valores históricos de eCPM para la red determinada. Esta lista se conoce como cadena de mediación. La plataforma de mediación del desarrollador de apps usa esta lista para llamar a las redes de publicidad en el orden en el que se enumeran a fin de identificar las fuentes de demanda de anuncios relevantes.
2. Mediación programática: El desarrollador de apps configura varias redes de publicidad para participar en las ofertas de oportunidades de anuncios. Estas redes pueden ofertar en tiempo real en función del valor que asignen a la oportunidad.
3. Mediación híbrida: Es una combinación de técnicas de mediación programática y de cascada.

Mediación en cascada

En la mediación en cascada, cuando surge una oportunidad de anuncio, un SDK de anuncios envía una solicitud a su servidor de backend. En lugar de responder a la solicitud con una creatividad de anuncio ganadora, el servidor responde con una cadena de mediación que contiene una lista de redes de publicidad ordenadas por eCPM histórico.

Figura 1: Modelo de mediación en cascada

En el modelo de cascada tradicional, un SDK de anuncios llama a cada red de publicidad (o a su propio SDK de subasta) en el orden que especifica la cadena de mediación. Si una red de publicidad puede cumplir con la solicitud de anuncio, la red de publicidad renderiza el anuncio. De lo contrario, la solicitud se envía a la siguiente red de la cadena. Este proceso se repite hasta que se cumple la solicitud o se agota la cadena.

Para optimizar la mediación en cascada, es posible reordenar con regularidad la cadena de mediación en función de la reevaluación del eCPM de las fuentes de demanda de anuncios propias.

Mediación programática

La mediación programática (también conocida como "oferta de encabezado") es una alternativa al uso del eCPM histórico para determinar qué red de publicidad tiene la oportunidad de publicar una solicitud de anuncio. Con la mediación programática, los proveedores utilizan los valores de ofertas en tiempo real para encontrar el anuncio ganador.

Figura 2: Modelo de mediación programática

Mediación híbrida

Algunas soluciones de mediación programática combinan las redes de publicidad en un modo híbrido de cascada y oferta para proporcionar más control al anuncio y, al mismo tiempo, obtener el beneficio de usar eCPM en tiempo real para maximizar los ingresos de las redes de publicidad participantes.

En los modelos de mediación híbrida, las redes de publicidad y los proveedores de mediación pueden ofrecer mayor flexibilidad a los desarrolladores de apps, ya que combinan elementos de cascada y ofertas en tiempo real. Los modelos híbridos permiten a los desarrolladores de apps configurar redes de publicidad basadas en eCPM históricos, lo que les da la oportunidad de mostrar un anuncio antes de ejecutar ofertas en tiempo real con las redes participantes para cumplir las oportunidades de anuncios.

Mediación en cascada de Protected Audience

La API de Protected Audience para Android admite la mediación en cascada mediante varias subastas, una para cada nodo individual del gráfico de mediación. Si no hay un ganador para una subasta, se llama al siguiente nodo de subasta de la red hasta que se agote la cadena. El proceso de mediación en cascada es el siguiente:

1. El SDK de mediación obtiene la cadena de mediación desde el extremo del servidor de anuncios contextuales, que puede mostrar anuncios contextuales o cadenas de mediación.
2. Si el extremo del servidor de anuncios muestra una cadena de mediación, el SDK de mediación itera por cada elemento de la cadena en orden y, luego, invoca el SDK de la red de publicidad participante para ejecutar una selección de anuncios contextuales y de remarketing. Cada elemento de la cadena representa la solicitud de una red de publicidad para comprar espacio publicitario a un precio específico por una cantidad específica de impresiones, clics o tiempo del anuncio.
3. Si ninguna de las líneas de pedido de la cadena elige un anuncio ganador, el SDK de mediación puede mostrar un anuncio de su propia red de publicidad ejecutando una selección de anuncios de Protected Audience que tenga en cuenta los anuncios contextuales y de remarketing.

Figura 3: Mediación en cascada con la API de Protected Audience

En el diagrama anterior, se representa un ejemplo de un algoritmo de mediación en cascada que puede implementar un SDK de mediación, pero sin la capacidad de optimización para la red de publicidad propia. La API de Protected Audience admite la optimización de redes de publicidad propias, ya que permite el encadenamiento de flujos de trabajo de selección de anuncios y la generación de informes sobre las impresiones ganadoras.

Resultado de AdSelection

El tipo de datos que muestra selectAds() es un objeto AdSelectionOutcome. AdSelectionOutcome contiene el URI de renderización del anuncio ganador y un AdSelectionId, que es un número entero opaco que identifica el ganador a la creatividad del anuncio de la línea de pedido.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId funciona como puntero a AdSelectionOutcome. Actualmente, AdSelectionId se pasa al método reportResult() como el parámetro ReportImpressionInput para ayudar a identificar los anuncios correctos según los que se invocan los métodos reportWin() y reportResult().

Propuesta de selección de anuncios de cadena

Proponemos sobrecargar selectAds() con AdSelectionFromOutcomesConfig.

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

Esto permite que el SDK de mediación compare la oferta de su anuncio ganador con la oferta mínima de la siguiente red intercalada.

Ejemplo 1:

Ejemplo 2:

Informes de impresiones ganadoras

Si hay un ganador de selectAds(AdSelectionFromOutcomes), ese anuncio ganará la mediación. Luego, se llama a reportImpression con el ID de selección de anuncios del anuncio ganador de selectAds(AdSelectionFromOutcomes) y el AdSelectionConfig correspondiente.

Si se muestra el ganador desde una selectAds(AdSelectionConfig) para cualquiera de las redes, se llama a reportImpression con el ID de selección de anuncios y la configuración de esa llamada.

Cómo ejecutar la mediación en cascada

A continuación, se muestra el orden de las operaciones para ejecutar a través del proceso de mediación en cascada.

1. Ejecuta la selección de anuncios propia.
2. Realiza la iteración en la cadena de mediación. Para cada red externa, haz lo siguiente:
   1. Compila AdSelectionFromOutcomeConfig, incluidos el outcomeId propio y la oferta externa y mínima del SDK.
   2. Llama a selectAds() con la config del paso anterior.
   3. Si el resultado no está vacío, muestra el anuncio.
   4. Llama al método selectAds() del adaptador de red del SDK actual. Si el resultado no está vacío, muestra el anuncio.
3. Si no se encuentra un ganador en la cadena, muestra el anuncio propio.

Prácticas recomendadas

Ejecuta subastas contextuales antes de la optimización propia

La demanda de remarketing puede generar ofertas altas que pueden dar lugar a resultados ganadores en una cadena de mediación. El truncamiento es un proceso que se suele usar para habilitar la optimización propia a través del perfeccionamiento de la lista de público de remarketing.

La demanda de remarketing de la API de Protected Audience solo está disponible del lado del cliente con las subastas de Protected Audience. Esto puede dificultar la habilitación de la optimización propia en el servidor. Para mitigar problemas con la optimización propia, se debe ejecutar primero la subasta contextual y, luego, la optimización propia en función del resultado del anuncio ganador, tal como se describió anteriormente en esta página.

Usa cadenas de mediación integradas en el dispositivo cortas

Para obtener un rendimiento óptimo, las cadenas de mediación integradas en el dispositivo deben ser cortas. El costo de procesamiento de la ejecución en el dispositivo puede ser lineal con la cantidad de subastas evaluadas como parte de la cadena de mediación. Es decir, más nodos generan más requisitos de ciclo de procesamiento y mayor latencia. Se debe tener en cuenta el impacto de la latencia en los ingresos al pasar nodos a la evaluación de mediación en el dispositivo.

Consideraciones adicionales

La API de Protected Audience no ofrece una solución integral para la mediación de varios espacios publicitarios. Cada espacio publicitario debe procesarse de forma independiente.

La API de mediación de Protected Audience admite la mediación en cascada y la mediación programática limitada. Se compartirán más detalles sobre casos de uso adicionales de mediación programática en el futuro.

Dado que la selección de anuncios de Protected Audience se ejecuta después de la recuperación de anuncios contextuales, invocar la API de Protected Audience puede afectar la latencia de extremo a extremo de las solicitudes de anuncios.