Procesa la solicitud

Una interacción de licitación en tiempo real comienza cuando Google envía una solicitud de oferta a tu aplicación. En esta guía, se explica cómo programar tu aplicación para procesar la solicitud de oferta.

Solicitud de análisis

Google envía una solicitud de oferta serializada en formato JSON de OpenRTB o Protobuf, adjunta como la carga útil de una solicitud POST de HTTP. El formato que se recibe depende de la configuración de tu endpoint. Consulta Ejemplo de solicitud de oferta para ver un ejemplo.

Debes analizar esta solicitud para recibir el objeto BidRequest serializado. Si usas el formato Protobuf, debes descargar openrtb.proto y openrtb-adx.proto de la página de datos de referencia y usarlos para generar una biblioteca que se pueda usar para analizar el mensaje BidRequest. Por ejemplo, el siguiente código de C++ analiza una solicitud con una carga útil de POST en una cadena: 

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

Una vez que tengas el BidRequest, puedes trabajar con él como un objeto, extraer e interpretar los campos que necesites. Por ejemplo, en C++, iterar a través de ofertas en un objeto `BidRequest` de OpenRTB podría verse de la siguiente manera:

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

IDs de facturación

Recibes una solicitud de oferta cuando una o más de tus configuraciones de segmentación previa segmentan el inventario de anuncios de un publicador. BidRequest.imp.ext.billing_id se completará con los IDs de facturación de los compradores aptos y las configuraciones de segmentación previa pertinentes. Además, para el inventario de acuerdos, puedes encontrar los IDs de facturación asociados con los compradores relevantes usando BidRequest.imp.pmp.deal.ext.billing_id. Solo se pueden especificar los IDs de facturación de los compradores incluidos en la solicitud de oferta cuando se realiza una oferta.

Si se incluyen varios IDs de facturación en la solicitud de oferta, debes especificar el ID de facturación del comprador al que deseas atribuir tu oferta con el campo BidResponse.seatbid.bid.ext.billing_id.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

Cómo determinar las categorías bloqueadas

Cuando estableces una oferta, la creatividad incluida no debe tener categorías detectadas que el publicador haya bloqueado. De lo contrario, la oferta se filtra de la subasta.

Para encontrar las categorías bloqueadas de una impresión, revisa el campo BidRequest.bcat, que se completa con las categorías de la taxonomía configurada para tu cuenta.

En el siguiente ejemplo, se muestran las categorías bloqueadas según una taxonomía de categorías de anuncios configurada:

Taxonomía de contenido de IAB 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

Determina las categorías contextuales

Las solicitudes de ofertas pueden incluir campos de categorías contextuales que describen el sitio web o la aplicación en los que se genera una impresión. Estos campos también usan taxonomías de categorías de anuncios, pero representan el contexto de la impresión, en lugar de las restricciones de la creatividad. Es posible que estos campos no usen la misma taxonomía que el campo BidRequest.bcat. Google o el publicador pueden proporcionar estas categorías contextuales. Usar categorías contextuales puede mejorar la evaluación de tus impresiones, la segmentación contextual y la seguridad de la marca.

Categorías contextuales detectadas por Google

Google completa los siguientes campos con las categorías de contenido de IAB detectadas para el sitio, la app o la página:

Campo Descripción
BidRequest.site.cat Es un array de IDs de categorías de contenido que describen el sitio.
BidRequest.site.pagecat Es un array de IDs de categorías de contenido que describen la página o vista actual del sitio.
BidRequest.app.cat Es un array de IDs de categorías de contenido que describen la app.
BidRequest.app.pagecat Es un array de IDs de categorías de contenido que describen la página o vista actual de la app.

Puedes encontrar la taxonomía exacta que se usa para estos campos en una solicitud de oferta determinada en los campos BidRequest.site.cattax o BidRequest.app.cattax. Es posible que los campos de categoría contextual no siempre se completen debido a las preferencias del publicador o a inquietudes regulatorias. Para obtener más información, consulta Categorías contextuales de OpenRTB en Google Ad Manager.

Indicadores proporcionados por el publicador

Además de las categorías contextuales detectadas por Google, las solicitudes de ofertas también pueden contener indicadores proporcionados por el publicador, que también describen el contexto de una impresión. A diferencia de las categorías contextuales detectadas por Google, estos indicadores solo se completan cuando los proporciona el publicador. Estos indicadores se envían en los objetos BidRequest.site.content y BidRequest.app.content, como content.data.segment y content.genre. La taxonomía que se usa para las entradas de content.data.segment se informa en content.data.ext.segtax. Para obtener más información, consulta Indicadores proporcionados por el publicador (PPS) para la Licitación en tiempo real (RTB).

Archivos de diccionario

La solicitud de oferta usa identificadores definidos en archivos de diccionario, que están disponibles en la página de datos de referencia.

Macros de URL del ofertante

De manera opcional, se puede insertar cierta información de la BidRequest en las URLs de los extremos de ofertas con macros. Si configuras una URL de extremo con una o más macros, estas se expandirán si esa información está presente en la solicitud de oferta. Esto puede ser útil, por ejemplo, si deseas realizar un balanceo de cargas según la información de BidRequest. Comunícate con tu administrador de cuentas para solicitar asistencia con las macros nuevas.

MacroDescripción
%%GOOGLE_USER_ID%%

Se reemplaza por el ID de usuario de Google que se encuentra en BidRequest.user.id. Por ejemplo, la URL del ofertante http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% se reemplazará por algo como http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl en el momento de la solicitud.

Si se desconoce el ID de usuario de Google, se sustituye la cadena vacía, con un resultado similar al siguiente:

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

Se reemplazó por 1 para indicar que la solicitud de oferta proviene de un dispositivo móvil o 0 en otros casos. Esto se basa en el valor de BidRequest.device.devicetype, en el que los dispositivos móviles se indican con HIGHEND_PHONE (4) o Tablet (5).
%%HAS_VIDEO%%

Se reemplazó por 1 para indicar que la solicitud de oferta contiene inventario de video o 0 en otros casos. Esto se basa en si BidRequest.imp.video se completó en la solicitud de oferta.
%%IS_CTV%%

Se reemplaza por 1 para indicar que la solicitud de oferta proviene de un dispositivo de CTV o, de lo contrario, por 0. Esto se basa en el valor de BidRequest.device.devicetype. Para Protobuf, los dispositivos de CTV son CONNECTED_TV, CONNECTED_DEVICE o SET_TOP_BOX, que corresponden a los valores enteros 3, 6 o 7 para JSON.
%%HOSTED_MATCH_DATA%%

Se reemplaza por un valor basado en BidRequest.user.buyeruid.

%%MOBILE_IS_APP%%

Se reemplazó por 1 para indicar que la solicitud de oferta es para el inventario de la app para dispositivos móviles o 0 en otros casos. Esto se basa en si se propaga BidRequest.app.

Cómo encontrar el ID de la app para dispositivos móviles en la URL de la transacción

Las transacciones de aplicaciones para dispositivos móviles informarán URLs que se verán de la siguiente manera:

mbappgewtimrzgyytanjyg4888888.com

Usa un decodificador base-32 para decodificar la parte de la cadena en negrita (gewtimrzgyytanjyg4888888).

Puedes usar un decodificador en línea, pero tendrás que escribir las letras en mayúscula y reemplazar los valores 8 finales por valores =.

Por lo tanto, decodifica este valor: 

GEWTIMRZGYYTANJYG4======
 genera el siguiente resultado: 
1-429610587
 La cadena 429610587 es el ID de la app para iOS iFunny.

Les doy otro ejemplo. La URL denunciada es la siguiente: 

mbappgewtgmjug4ytmmrtgm888888.com
 Decodificación de este valor: 
GEWTGMJUG4YTMMRTGM======
 da como resultado lo siguiente: 
1-314716233
 El resultado 314716233 es el ID de la app para iOS TextNow.

Cómo encontrar el nombre de la app para dispositivos móviles a partir de la URL de la transacción

Este es un ejemplo de cómo obtener el nombre de la app. La URL denunciada es la siguiente: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Decodificación de este valor: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 da como resultado lo siguiente: 
air.com.hypah.io.slither
 El resultado equivale a la app para Android slither.io.

Campos de Open Bidding

Las solicitudes de ofertas que se envían a los ofertantes de intercambios y redes que participan en Open Bidding son similares a las de Authorized Buyers que participan en la licitación en tiempo real estándar. Los clientes de Open Bidding recibirán una pequeña cantidad de campos adicionales, y algunos campos existentes podrían tener usos alternativos. Se incluyen los siguientes:

OpenRTB Detalles
BidRequest.imp.ext.dfp_ad_unit_code

Contiene el código de red de Ad Manager del publicador seguido de la jerarquía de la unidad de anuncios, separados por barras diagonales.

Por ejemplo, aparecería con un formato similar al siguiente: /1234/cruises/mars.
BidRequest.user.data.segment

Son los pares clave-valor repetidos que se envían del publicador al ofertante de Ofertas de Ad Exchange.

Puedes determinar que los valores son pares clave-valor que envía el publicador cuando BidRequest.user.data.name se establece en “Publisher Passed”.

Cómo declarar los proveedores permitidos

Los proveedores de tecnología que brindan servicios como investigación, remarketing y publicación de anuncios pueden desempeñar un papel en la interacción entre compradores y vendedores. Solo se permiten los proveedores que Google haya investigado para participar en las interacciones de Authorized Buyers.

Para comprender el BidRequest y crear tu BidResponse, debes conocer las dos posibilidades diferentes para declarar proveedores de tecnología:

  1. No es necesario declarar algunos proveedores, que se incluyen en la lista de proveedores externos certificados de Ad Manager.
  2. Otros proveedores solo pueden participar si se declaran en el archivo BidRequest:
    • En BidRequest, el campo BidRequest.imp.ext.allowed_vendor_type especifica qué proveedores permite el vendedor. Los proveedores que se enviarán en allowed_vendor_type se enumeran en el archivo de diccionario vendors.txt.

Ejemplo de solicitud de oferta

En los siguientes ejemplos, se muestran muestras legibles por humanos de las solicitudes de Protobuf y JSON.

Protobuf de OpenRTB

JSON de OpenRTB

Para convertir la solicitud de oferta en un formato binario, como el que obtendrías de la carga útil de POST en una solicitud real, puedes hacer lo siguiente (en C++). Sin embargo, ten en cuenta que esto no se aplica a OpenRTB JSON.

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

Comentarios en tiempo real

Los comentarios en tiempo real están disponibles para Authorized Buyers, así como para los intercambios y las redes que usan Open Bidding.

Los comentarios en tiempo real propagan BidRequest.ext.bid_feedback según el resultado de una o más ofertas que realizaste antes y se pueden usar para encontrar detalles, como si la oferta ganó la subasta o la oferta mínima necesaria para ganar la subasta. Comunícate con tu administrador de cuentas para habilitar los comentarios en tiempo real.

Además de los campos predeterminados que se envían en los comentarios sobre la respuesta de oferta, también puedes enviar datos personalizados en la respuesta de oferta con el campo BidResponse.seatbid.bid.ext.event_notification_token. El parámetro event_notification_token son datos arbitrarios que solo conoce el ofertante y que podrían ayudar con la depuración, por ejemplo: un ID de segmentación o de ofertas nuevo que represente una táctica nueva, o metadatos asociados con la creatividad que solo conoce el ofertante. Para obtener más detalles, consulta el archivo de búfer de protocolo de extensiones de OpenRTB.

Cuando Authorized Buyers envía una solicitud de oferta a un ofertante, este responde con un BidResponse. Si el ofertante tiene habilitados los comentarios en tiempo real, en una solicitud de oferta posterior, Authorized Buyers envía comentarios sobre la respuesta en un mensaje BidFeedback:

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;
}

En este mensaje, el primer campo que debes verificar es bid_feedback.creative_status_code. Puedes encontrar el significado del código en creative-status-codes.txt. Ten en cuenta que, si ganas la licitación, puedes inhabilitar los comentarios sobre el precio. Para obtener más información, consulta Cómo inhabilitar la función.

El feedback en tiempo real incluye el ID de la solicitud de oferta y uno de los siguientes elementos:

Resultado de la subasta Feedback en tiempo real
El comprador no envió una oferta. Nada.
El comprador envió una oferta que se filtró antes de llegar a la subasta. El código de estado de la creatividad (creative-status-codes.txt).
El comprador envió una oferta, pero perdió la subasta. Es el código de estado de la creatividad 79 (se superó la oferta en la subasta).
El comprador envió una oferta que ganó la subasta. El precio de liquidación y el código de estado de la creatividad 1.

En el caso de una impresión de aplicación y un código de estado de la creatividad de 83, es posible que el publicador de la aplicación haya estado usando una cascada de mediación y, por lo tanto, la oferta ganadora haya competido con otra demanda en la cadena de cascada de devolución del publicador. Obtén más información para usar sampled_mediation_cpm_ahead_of_auction_winner cuando establezcas ofertas.

Muestra

A continuación, se muestra un ejemplo de comentarios en tiempo real tal como se ven en los protocolos compatibles:

Protobuf de OpenRTB

JSON de OpenRTB

Crea un modelo de ofertas para subastas de primer precio

Después de realizar una oferta en una subasta de primer precio, recibirás comentarios en tiempo real, incluidos los campos minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner, si la oferta no se filtró de la subasta. Estos indicadores se pueden usar para informar a tu lógica de ofertas sobre cuánto más alta o más baja podría haber sido tu oferta para ganar la impresión.

  • minimum_bid_to_win: Es la oferta mínima que se podría haber realizado para ganar la subasta de licitación en tiempo real. Si ganaste la subasta, esta será la oferta más baja que podrías haber realizado y seguir ganando. Si perdiste la subasta, esta será la oferta ganadora.
  • sampled_mediation_cpm_ahead_of_auction_winner: Si hay otras redes en la cadena de mediación, el valor de este campo es un precio que representa una oferta de muestra de una de las redes de mediación aptas que fueron más altas que el ganador de la subasta, ponderada por la tasa de relleno esperada. Se establecerá en 0 si no se espera que se complete ninguna de las redes de la cadena de mediación o si el publicador no usa la mediación del SDK.

Cómo funciona

Para describir los cálculos que se usan para determinar los valores posibles de minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner, primero debemos definir lo siguiente:

  • A continuación, se muestran los CPM de la cadena de mediación en orden descendente:
    \[C_1, C_2, …, C_n\]
  • A continuación, se muestran las tasas de relleno correspondientes para los CPM de la cadena de mediación:
    \[f_1, f_2, …, f_n\]
  • La siguiente es una función que se usa para determinar el CPM esperado y su probabilidad a partir del elemento de la cadena de mediación \(i\), según la tasa de relleno determinada:
    \(X_i = \{C_i\) con probabilidad \(f_i\); \(0\) con probabilidad \(1 - f_i\}\)
  • La cadena de mediación ganadora final será la siguiente:
    \[\{C_1, C_2, …, C_K, W\}\]
    donde \(W\) es la oferta ganadora y \(C_K > W >= C_{K+1}\)
  • El precio de reserva, o mínimo, se indica como \(F\).
  • La segunda mejor oferta se indica como \(R\).
Cálculos para el ganador de la subasta
Campo Cálculo
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) con probabilidad \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Para \(1 <= i <= K\).
Cálculos para el perdedor de la subasta
Campo Cálculo
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Ejemplo con una cadena de mediación simple

Supongamos que un publicador usa la licitación en tiempo real y una cadena de mediación de SDK de la siguiente manera:

Cadena de mediación de SDK CPM esperado Tasa de relleno
Red 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Red 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Red 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Red 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Supongamos que el resultado de la subasta de RTB es el siguiente:

Subasta de RTB CPM
Ganador de la subasta (W) $1.00
Subasta, segundo lugar (R) $0.05
Precio de reserva / mínimo (F) USD 0
Oferta que ganó la subasta

A continuación, se muestra un ejemplo de cómo se calculan los valores y las probabilidades de minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner para una oferta ganadora.

minimum_bid_to_win Probabilidad
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probabilidad
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
Ofertas que perdieron en la subasta

A continuación, se muestra un ejemplo de cómo se calculan los valores y las probabilidades de minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner para las ofertas que perdieron.

minimum_bid_to_win Probabilidad
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probabilidad
\(C_1 = $3.00\) \(f_1 = 5\%\)
\(C_2 = $2.00\) \((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\) \((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

Aplanamiento de ofertas

La separación de ofertas describe el procesamiento de un solo BidRequest complejo en varias solicitudes de oferta que se envían a tu aplicación. Cuando se aplana una solicitud de oferta, puedes saber qué solicitudes de oferta formaban parte de la original porque tendrán un valor idéntico en el campo BidRequest.ext.google_query_id.

La separación de ofertas está habilitada de forma predeterminada, pero puedes comunicarte con tu administrador de cuentas si prefieres inhabilitarla.

Formatos de anuncios

Algunas oportunidades de anuncios pueden aceptar varios formatos. Con la separación de ofertas, cada formato se envía en una solicitud de oferta distinta en la que los atributos, como los IDs de facturación aptos, son relevantes para el formato especificado en la solicitud.

Las solicitudes de oferta que contengan los siguientes formatos se simplificarán en solicitudes de oferta distintas:

  • Banner
  • Video
  • Audio
  • Nativo

Ejemplo de compactación de formatos de anuncios

A continuación, se muestra un ejemplo de una solicitud de oferta JSON de OpenRTB simplificada sin formato de anuncio plano en comparación con un conjunto equivalente de solicitudes planas:

Aplanar previamente

Post-flatten

Ofertas

Una oportunidad de anuncio para un ofertante determinado puede aplicarse a varios tipos de acuerdos, además de la subasta abierta. Con la separación de ofertas para acuerdos, se enviará una solicitud de oferta para la subasta abierta y una para cada tipo de acuerdo de precio fijo. En la práctica, las restricciones de anuncios pueden diferir entre las subastas y los tipos de acuerdos de precio fijo. Por ejemplo, para una oportunidad de anuncio de video determinada que está disponible tanto para la subasta abierta como para un acuerdo de precio fijo, un ofertante recibirá solicitudes de ofertas distintas para cada una, en las que pueden diferir restricciones como la duración máxima del anuncio y si se permiten anuncios que se pueden omitir. Como resultado, la reducción aplicada a la oportunidad de anuncio te permite discernir con mayor facilidad las restricciones de anuncios para la subasta abierta y el acuerdo de precio fijo.

Posibilidad de omisión y duración del video

La especificación de OpenRTB no tiene campos separados para especificar las duraciones máximas de los videos de los anuncios que se pueden omitir y los que no se pueden omitir. La implementación de Google usa la separación de ofertas para distinguir entre estos con los campos BidRequest.video.maxduration y BidRequest.video.skip existentes.

A continuación, se muestra un ejemplo de cómo se simplifica el inventario de video cuando la duración máxima de un anuncio que no se puede omitir es de 15 y la duración máxima de un anuncio que se puede omitir es de 60.

Ejemplo max_ad_duration skip (verdadero O falso)
Solicitud original sin aplanar 15 true
Solicitud aplanada núm. 1: No se puede omitir 15 false
Solicitud aplanada nº 2: Se puede omitir 60 true

La separación de solicitudes de ofertas de duración de video que se puede omitir solo se realizará cuando se cumplan las siguientes condiciones:

  • La solicitud permite el video.
  • Se permiten los videos que se pueden omitir y los que no se pueden omitir, y las dos duraciones máximas respectivas difieren en valor.
  • Esta solicitud es apta para la subasta privada o la subasta abierta.

Si quieres inhabilitar este tipo de aplanamiento, comunícate con tu administrador técnico de cuentas. Cuando se inhabilita y el publicador permite anuncios de video que se pueden omitir y que no se pueden omitir con diferentes duraciones máximas según la posibilidad de omisión, skip se establecería en true y maxduration se establecería en la duración más corta entre las restricciones de anuncios que se pueden omitir y que no se pueden omitir.

Grupos de anuncios de video

Las solicitudes de ofertas para un grupo de anuncios de video con varias oportunidades de anuncios se unifican, de modo que cada solicitud de oferta corresponde a una oportunidad de anuncio individual de ese grupo. Esto te permite ofertar por varias oportunidades publicitarias para un grupo determinado.

Open Measurement

Open Measurement te permite especificar proveedores externos que brindan servicios independientes de medición y verificación para los anuncios publicados en entornos de aplicaciones para dispositivos móviles.

Para determinar si un publicador admite la medición abierta en la solicitud de oferta, comprueba si la oportunidad de anuncio excluye el atributo OmsdkType: OMSDK 1.0 que se encuentra en Atributos de creatividades excluidos por el publicador. Esto se encontraría en el atributo battr para Banner o Video, según el formato.

Para obtener más información sobre cómo interpretar las solicitudes de ofertas que contienen indicadores de Open Measurement, consulta el artículo del Centro de ayuda sobre el SDK de Open Measurement.

Solicitudes de oferta de muestra

En las siguientes secciones, se muestran ejemplos de solicitudes de ofertas para diferentes tipos de anuncios.

Banner de la app

Protobuf de OpenRTB

JSON de OpenRTB

Anuncio intersticial para aplicaciones

Protobuf de OpenRTB

JSON de OpenRTB

Video de anuncio intersticial para aplicaciones

Protobuf de OpenRTB

JSON de OpenRTB

Nativo de la app

Protobuf de OpenRTB

JSON de OpenRTB

Video web

Protobuf de OpenRTB

JSON de OpenRTB

Banner web para dispositivos móviles para el ofertante de intercambio

Protobuf de OpenRTB

JSON de OpenRTB

Anuncios nativos y de video multiformato

Protobuf de OpenRTB

JSON de OpenRTB