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 codificar tu aplicación para procesar la solicitud de oferta.

Solicitud de análisis

Google envía una solicitud de oferta serializada en formato JSON o Protobuf de OpenRTB, adjunta como carga útil de una solicitud HTTP POST. 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 de 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 en C++ analiza una solicitud a partir de 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 el inventario de anuncios de un publicador se segmenta para una o más de tus configuraciones de segmentación previa. 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 pertinentes a través de 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 realices 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 revisar las categorías bloqueadas de una impresión, consulta 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": {
    ...
  }
}

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 información del 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 basado en 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 por una 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.
%%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 aplicaciones para dispositivos móviles o 0 en otros casos. Esto se basa en si BidRequest.app está completado.

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 registrarán URLs como las siguientes:

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 poner en mayúscula las letras y reemplazar los 8 finales por valores de =.

Por lo tanto, si decodificamos este valor, obtenemos lo siguiente: 

GEWTIMRZGYYTANJYG4======
 da como resultado lo siguiente: 
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 transacción

Este es un ejemplo para obtener el nombre de la app. La URL informada 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 pueden 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 del intercambio.

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 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 verificado 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 enumeran en Proveedores externos certificados de Ad Manager.
  2. Otros proveedores solo pueden participar si se declaran en 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 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 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 Authorized Buyers, así como los intercambios y las redes que utilizan Open Bidding, tienen acceso a comentarios en tiempo real.

Los comentarios en tiempo real se completan en BidRequest.ext.bid_feedback según el resultado de una o más ofertas que realizaste anteriormente, y se pueden usar para encontrar detalles como si la oferta ganó la subasta o la oferta mínima necesaria para haber ganado 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 a la oferta, también puedes enviar datos personalizados en la respuesta a la oferta con el campo BidResponse.seatbid.bid.ext.event_notification_token. El campo event_notification_token contiene datos arbitrarios que solo conoce el postor y que pueden ayudar con la depuración, por ejemplo, un nuevo ID de segmentación o de oferta que represente una nueva táctica, o bien metadatos asociados con la creatividad que solo conoce el postor. Para obtener más información, 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 objeto 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;

  // Deprecated. This field will be removed in February 2026.
  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM of the buyer account currency. The
  // minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidFeedback object.
  optional double sscminbidtowin = 14 [deprecated = true];

  // 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;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // Deprecated. This field will be removed in February 2026.
  // The type of the BidFeedback message. Google will send separate
  // BidFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedbacktype = 15 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyerorigin = 16 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 igbuyerstatus = 17 [deprecated = true];
}

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 oferta, puedes inhabilitar los comentarios sobre el precio. Para obtener más información, consulta Cómo inhabilitar la función.

Los comentarios en tiempo real incluyen el ID de la solicitud de oferta y uno de los siguientes elementos:

Resultado de la subasta Comentarios en tiempo real
El comprador no envió una oferta. Nada.
El comprador envió una oferta que se filtró antes de llegar a la subasta. Es 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. Es el precio de compensació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

Cómo compilar 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 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 establecido para ganar la subasta de ofertas en tiempo real. Si ganaste la subasta, esta será la oferta más baja que podrías haber establecido y aun así ganar. 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 fue más alta que la del ganador de la subasta, ponderada según el porcentaje de relleno esperado. Se establecerá en 0 si no se espera que ninguna de las redes de la cadena de mediación complete la solicitud 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 representan los CPMs en la cadena de mediación en orden descendente:
    \[C_1, C_2, …, C_n\]
  • A continuación, se muestran los porcentajes de relleno correspondientes a los CPM en la cadena de mediación:
    \[f_1, f_2, …, f_n\]
  • A continuación, se muestra 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 el porcentaje de relleno determinado:
    \(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 precio 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 ofertas en tiempo real y una cadena de mediación de SDK de la siguiente manera:

Cadena de mediación del 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 (G) $1.00
Subcampeón de la subasta (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 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 se 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\%\)

Separación de ofertas

El aplanamiento de ofertas describe el procesamiento de un solo BidRequest complejo en varias solicitudes de ofertas 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 reducción de la oferta 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 separarán en solicitudes de oferta distintas:

  • Banner
  • Video
  • Audio
  • Nativo

Ejemplo de compactación de formato de anuncio

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

Pre-flatten

Después del aplanamiento

Ofertas

Una oportunidad de anuncio para un ofertante determinado puede aplicarse a varios tipos de acuerdos, además de la subasta abierta. Con el aplanamiento 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 oferta 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, el aplanamiento aplicado a la oportunidad publicitaria te permite discernir con mayor facilidad las restricciones del anuncio para la subasta abierta y el acuerdo de precio fijo.

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. La implementación de Google usa el aplanamiento de ofertas para distinguir entre estos elementos con los campos BidRequest.video.maxduration y BidRequest.video.skip existentes.

A continuación, se muestra un ejemplo de cómo se aplana 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 aplanamiento 15 true
Solicitud nivelada núm. 1: No se puede omitir 15 false
Solicitud separada 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 tanto los videos que se pueden omitir como los que no, y las dos duraciones máximas respectivas difieren en valor.
  • Esta solicitud es apta para la subasta privada o la subasta abierta.

Para inhabilitar este tipo de aplanamiento, comunícate con tu administrador técnico de cuentas. Cuando está inhabilitado 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 capacidad de omitir, 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 múltiples oportunidades de anuncios se separan, de modo que cada solicitud de oferta sea para una oportunidad de anuncio individual de ese grupo. Esto te permite ofertar por varias oportunidades de anuncios 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 Open Measurement en la solicitud de oferta, verifica si la oportunidad de anuncio excluye el atributo OmsdkType: OMSDK 1.0 que se encuentra en Atributos de creatividad que puede excluir el publicador. Se encuentra 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 del SDK de Open Measurement.

Ejemplos de solicitudes de oferta

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

Anuncio intersticial de video en la aplicación

Protobuf de OpenRTB

JSON de OpenRTB

App nativa

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

Nativos y de video multiformato

Protobuf de OpenRTB

JSON de OpenRTB