Procesa la solicitud

Una interacción de ofertas 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.

Cómo analizar una solicitud

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

Debes analizar esta solicitud para recibir el BidRequest serializado. Si usas el formato Protobuf, debes descargar openrtb.proto y openrtb-adx.proto de la página 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 dada una carga útil 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, podrás trabajar con él como un objeto, extraer e interpretar los campos que necesites. Por ejemplo, en C++, iterar por las ofertas en una "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

Recibirás una solicitud de oferta cuando una o más de tus configuraciones de orientación previa se segmenten para el inventario de anuncios de un publicador. BidRequest.imp.ext.billing_id se propagará con los IDs de facturación de los compradores aptos y las configuraciones de segmentación previa relevantes. Además, para el inventario de ofertas, puedes encontrar los IDs de facturación asociados con el comprador relevante con BidRequest.imp.pmp.deal.ext.billing_id. Cuando se realiza una oferta, solo se pueden especificar los IDs de facturación de los compradores incluidos en la solicitud de 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.

Archivos de diccionario

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

Macros de URL del ofertante

De manera opcional, se puede insertar información de 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 el balanceo de cargas según la información de BidRequest. Comunícate con tu administrador de cuentas para solicitar asistencia con macros nuevas.

MacroDescripción
%%GOOGLE_USER_ID%%

Se reemplazó 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 el ID de usuario de Google es desconocido, se reemplaza 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 de lo contrario. 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 un inventario de video, o 0 de lo contrario. Esto se basa en si BidRequest.imp.video se propaga en la solicitud de oferta.
%%HOSTED_MATCH_DATA%%

Se reemplazó 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 de lo contrario. Esto se basa en si se propaga BidRequest.app.

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

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

mbappgewtimrzgyytanjyg4888888.com

Usa un decodificador de 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úsculas y reemplazar los 8 finales por valores =.

Por lo tanto, la decodificación de este valor es la siguiente: 

GEWTIMRZGYYTANJYG4======
 genera 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
 Decodifica este valor: 
GEWTGMJUG4YTMMRTGM======
 genera 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 para obtener el nombre de la app. La URL informada es la siguiente: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Decodifica este valor: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 genera lo siguiente: 
air.com.hypah.io.slither
 El resultado equivale a la app para Android slither.io.

Campos de Open Bidding

Las solicitudes de oferta 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 las ofertas 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. Entre estos, 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, separada por barras diagonales.

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

Pares clave-valor repetidos que se envían del publicador al ofertante de 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 proporcionan 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 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, ya que aparecen en la sección 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 indican en el archivo de diccionario vendors.txt.

Ejemplo de solicitud de oferta

En los siguientes ejemplos, se representan 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 lo harías con 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 JSON de OpenRTB.

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 que se necesitaba para ganarla. 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 de la respuesta de la oferta, también puedes enviar datos personalizados en la respuesta de la oferta con el campo BidResponse.seatbid.bid.ext.event_notification_token. event_notification_token son datos arbitrarios que solo conoce el ofertante y que pueden ayudar con la depuración, por ejemplo, un nuevo ID de segmentación o de oferta que representa una táctica nueva, o metadatos asociados con la creatividad que solo conoce el ofertante. 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 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;

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

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

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

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

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

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 una de las siguientes opciones:

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. El código de estado de la creatividad (creative-status-codes.txt).
El comprador envió una oferta, pero perdió la subasta. 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, el publicador de la aplicación podría haber estado usando una cascada de mediación y, por lo tanto, la oferta ganadora habría competido con otra demanda en la cadena de cascada de notificaciones de conversión del publicador. Obtén información para usar sampled_mediation_cpm_ahead_of_auction_winner cuando realices ofertas.

Muestra

El siguiente es un ejemplo de comentarios en tiempo real, como se ve 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 fundamentar tu lógica de ofertas sobre qué tan alta o 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 ofertas en tiempo real. Si ganaste la subasta, esta será la oferta más baja que podrías haber realizado y, aún 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 superior a la oferta ganadora de la subasta, ponderada por el porcentaje de anuncios publicados esperado. Se establecerá en 0 si se espera que ninguna de las redes de la cadena de mediación se complete 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 para 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 en 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 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\}\]
    en el que \(W\) es la oferta ganadora y \(C_K > W >= C_{K+1}\)
  • El precio de reserva, o mínimo, se indica como \(F\).
  • La oferta en segundo lugar 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 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 lo siguiente como resultado de la subasta de RTB:

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

El siguiente es 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 que ganó.

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

El siguiente es 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 que perdió.

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

La aplanación 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 cuáles solicitudes de oferta formaron parte de la original, ya que tendrán un valor idéntico en el campo BidRequest.ext.google_query_id.

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

Formatos de anuncios

Algunas oportunidades publicitarias pueden aceptar varios formatos. Con la aplanació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 aplanamiento de formatos de anuncios

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

Preaplanar

Después de la aplanación

Ofertas

Una oportunidad de anuncio para un ofertante determinado se puede aplicar a varios tipos de acuerdos, además de la subasta abierta. Con la aplanación de ofertas para los 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 para la subasta abierta y un acuerdo de precio fijo, un ofertante recibirá solicitudes de oferta distintas para cada una, en las que las restricciones, como la duración máxima del anuncio y si se permiten los anuncios que se pueden omitir, pueden diferir. Como resultado, la aplanación aplicada a la oportunidad de anuncios te permite discernir con mayor facilidad las restricciones de anuncios 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 video de los anuncios que se pueden omitir y los que no. La implementación de Google usa la aplanación de ofertas para distinguir entre estas con los campos BidRequest.video.maxduration y BidRequest.video.skip existentes.

El siguiente es 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 15 y la duración máxima de un anuncio que se puede omitir es 60.

Ejemplo max_ad_duration skip (verdadero O falso)
Solicitud original sin aplanar 15 true
Solicitud nivelada n.° 1: No se puede omitir 15 false
Solicitud nivelada 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 estas condiciones:

  • La solicitud permite videos.
  • Se permiten videos que se pueden omitir y que no se pueden omitir, y las dos duraciones máximas respectivas difieren en valor.
  • Esta solicitud es apta para subastas privadas o subastas abiertas.

Para 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á en true y maxduration se establecerá 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 oferta para un grupo de anuncios de video con varias oportunidades de anuncios se aplanan, 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 proporcionan servicios de medición y verificación independientes 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, 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 oferta que contienen indicadores de Open Measurement, consulta el artículo del Centro de ayuda del SDK de Open Measurement.

Solicitudes de oferta de muestra

En las siguientes secciones, se muestran solicitudes de oferta de muestra para diferentes tipos de anuncios.

Banner de la app

Protobuf de OpenRTB

JSON de OpenRTB

Anuncio intersticial de aplicación

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 móvil para ofertantes de intercambio

Protobuf de OpenRTB

JSON de OpenRTB

Video y nativo multiformato

Protobuf de OpenRTB

JSON de OpenRTB