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

Analizar solicitud

Google envía una solicitud de oferta como un búfer de protocolo serializado adjunto como el carga útil binaria de una solicitud HTTP POST. La Content-Type se establece en application/octet-stream Consulta Ejemplo de solicitud de oferta para ver un ejemplo.

Debes analizar esta solicitud en una instancia de BidRequest. mensaje. BidRequest se define en realtime-bidding.proto, que se pueden obtener en la página de datos de referencia. Puedes analizar el mensaje usando el método ParseFromString() en la clase generada para el BidRequest Por ejemplo, el siguiente código 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 extraiga y, luego, interprete los campos que necesites. Por ejemplo, en C++:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

Parte de la información enviada en un BidRequest, como el Usuario de Google El ID, el idioma o la ubicación geográfica no siempre están disponibles. Si tienes grupos de anuncios de segmentación previa que usan información desconocida de una determinada impresión, esos grupos de anuncios no coincidirán. En los casos en los que la falta información no importa para las condiciones de segmentación previa, las solicitudes de oferta se enviados con la información omitida.

La información sobre el grupo de anuncios de segmentación previa se encuentra disponible en Grupo MatchingAdData para cada AdSlot. Contiene las primer ID de grupo de anuncios coincidente del grupo de anuncios de segmentación previa que solicitó a Google que envía la solicitud de oferta, es decir, el grupo de anuncios y la campaña a los que se les cobra si tu respuesta gana la subasta por la impresión. Bajo ciertas debes especificar de forma explícita el billing_id para la atribución en el BidResponse.AdSlot, por ejemplo, cuando la BidRequest.AdSlot tiene más de un matching_ad_data. Para obtener más información sobre las limitaciones de los contenidos de la oferta, consulte el objeto realtime-bidding.proto.

Archivos de diccionario

La solicitud de oferta utiliza identificadores definidos en archivos del diccionario, que se disponible en los datos de referencia .

Macros de URL de oferta

De manera opcional, se pueden insertar algunos campos de BidRequest en la URL utilizada en la solicitud HTTP POST. Esto es útil, por ejemplo, si usas un frontend ligero que balancea las cargas en múltiples backends usando un valor de la solicitud. Comunícate con tu administrador técnico de cuentas para solicitar asistencia las nuevas macros.

MacroDescripción
%%GOOGLE_USER_ID%%

Se reemplazó por google_user_id. del BidRequest. Por ejemplo, la URL del ofertante 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 será reemplazado por algo como 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 al momento de la solicitud.

Si no se conoce el ID de usuario de Google, se sustituye la cadena vacía por el resultado similar a

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

Se reemplaza por 1 o 0 cuando se realiza una llamada. has_mobile() de BidRequest
%%HAS_VIDEO%%

Se reemplazó por 1 (verdadero) o 0 (falso). cuando llames al elemento has_video() de BidRequest
%%HOSTED_MATCH_DATA%%

Se reemplazó por el valor del campo hosted_match_data. del BidRequest.
%%MOBILE_IS_APP%%

Se reemplazó por 1 (verdadero) o 0 (falso). del campo mobile.is_app de BidRequest.

Busque el ID de aplicación para dispositivos móviles a partir de la URL de la transacción

Las transacciones de aplicaciones para dispositivos móviles informarán URLs como las siguientes:

mbappgewtimrzgyytanjyg4888888.com

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

Puedes usar una en línea decodificador, pero deberás usar mayúsculas en las letras y reemplazar el texto 8 con valores =.

Entonces, se decodifica este valor: 

GEWTIMRZGYYTANJYG4======
 da como resultado: 
1-429610587
 La cadena 429610587 es el ID de la aplicación para iOS iFunny.

Les doy otro ejemplo. La URL denunciada es: 

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

Busque el nombre de la aplicación para dispositivos móviles en 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
 Decodifica este valor: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 da como resultado: 
air.com.hypah.io.slither
 El resultado equivale a la app para Android slither.io.

Campos de Open Bidding

Las solicitudes de oferta se envían a los ofertantes de intercambio y de red que participan en Open Bidding Las ofertas son similares a las de los compradores de Authorized Buyers que participan en el con las ofertas en tiempo real. Los clientes de Open Bidding recibirán una pequeña cantidad de campos adicionales, y algunos campos existentes pueden tener usos alternativos. Estos incluyen lo siguiente:

OpenRTB Authorized Buyers Detalles
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Contiene el código de red de Ad Manager del publicador seguido del anuncio. de unidades, separadas por barras diagonales.

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

Pares clave-valor repetidos que se envían del publicador al ofertante del intercambio.

Puedes determinar que los valores son pares clave-valor enviados por el publicador cuando BidRequest.user.data[].name está configurado como “Publisher Passed”

Declara los proveedores permitidos

Los proveedores de tecnología que prestan servicios, como investigación, remarketing y la publicación de anuncios puede influir en la interacción entre los compradores y los vendedores. Solo proveedores que Google aprobó para participar en Authorized Buyers se permiten interacciones.

Para comprender el BidRequest y crear BidResponse, debes tener en cuenta las dos opciones posibilidades para declarar proveedores de tecnología:

  1. No es necesario declarar algunos proveedores. estos proveedores se incluyen en la Ayuda de Authorized Buyers.
  2. Otros proveedores solo pueden participar si se declaran en el BidRequest y BidResponse:
    • En BidRequest, allowed_vendor_type que especifica los proveedores que permite el vendedor. Proveedores que se enviarán en el campo allowed_vendor_type de BidRequest se se incluye en la Vendors.txt de diccionario.
    • En BidResponse, el campo vendor_type especifica cuál de esos proveedores permitidos usará el comprador.

Ejemplo de solicitud de oferta

Los siguientes ejemplos representan muestras legibles de Protobuf y Solicitudes JSON.

Google

JSON de OpenRTB

Protocolo de OpenRTB

Para convertir la solicitud de oferta al formato binario, como lo obtendrías en POST en una solicitud real, puedes hacer lo siguiente (en C++). Nota: sin embargo, que esto no es aplicable al 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
  }
}

Remarketing

Authorized Buyers transfiere un ID de publicidad para dispositivos móviles en las solicitudes de oferta de un para dispositivos móviles. El ID de publicidad para móviles puede ser un IDFA de iOS o ID de publicidad de Android, que se envía a través del . Macro %%EXTRA_TAG_DATA%% en la etiqueta de JavaScript administrada por Authorized Buyers.

La macro %%ADVERTISING_IDENTIFIER%% permite que los compradores reciban IDFA de iOS o ID de publicidad de Android en la renderización de impresiones. Muestra un búfer de protocolo encriptado MobileAdvertisingId Me gusta %%EXTRA_TAG_DATA%%:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

El user_id_type es uno de los valores definidos en el enum AdxMobileIdType

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

Puedes crear listas de usuarios a partir de los ID de publicidad para dispositivos móviles mediante los ID de publicidad que recopilaste durante la renderización de impresiones. Estas listas de usuarios se pueden mantener en tu servidor o en el nuestro. Para crear listas de usuarios en los servidores de Google, puedes usar nuestro sitio de carga masiva.

Cuando el ID de publicidad para dispositivos móviles coincide con una lista de usuarios, puedes usarlo para publicar remarketing.

Comentarios en tiempo real

Los comentarios en tiempo real también están disponibles para Authorized Buyers como intercambios y redes con Open Bidding.

Los comentarios de la respuesta a la oferta se admiten en la solicitud de oferta posterior tanto para AdX Protocol y OpenRTB. Para OpenRTB, se envía en BidRequestExt

Además de los campos predeterminados enviados a través de los comentarios de la respuesta a la oferta, puedes También puede enviar datos personalizados en la respuesta a la oferta (en OpenRTB o AdX Proto). con un event_notification_token que se muestra en el BidResponse La event_notification_token es datos arbitrarios conocidos solo por el ofertante que podrían ayudar con la depuración, por Ejemplo: un ID de segmentación o un ID de oferta nuevos que representen una táctica nueva metadatos asociados con la creatividad que solo conoce el ofertante Para obtener más información, consulta OpenRTB Búfer de protocolo de extensiones para RTB y Proto de AdX para AdX.

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, Luego, en una solicitud de oferta posterior, Authorized Buyers envía comentarios sobre el en un mensaje BidResponseFeedback, como se muestra a continuación:

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

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

  // 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 int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // 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 did not 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 int64 minimum_bid_to_win = 7;

  // 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 micros 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 BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // 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 = 15 [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 micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // 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 BidResponseFeedback message. Google will send separate
  // BidResponseFeedback 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 feedback_type = 17;

  // 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 buyer_origin = 18;

  // 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 interest_group_buyer_status_code = 19;
}

A partir de este mensaje, el primer campo que debes verificar es bid_response_feedback.creative_status_code; pueden encontrar el código significado en Creative-status-codes.txt. Ten en cuenta que si ganas la oferta, puedes inhabilitar a partir de los comentarios sobre el precio. Para obtener más información, consulta Cómo el rechazo de las comunicaciones.

Los comentarios en tiempo real incluyen el ID de solicitud de oferta y una de las lo siguiente:

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 durante la subasta. Es 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 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 creatividad de 83, la el publicador de aplicaciones podría haber usado una cascada de mediación y, por lo tanto, ganadora habría compitido contra otra demanda en la de una cadena de cascada de devoluciones. Aprende a utilizar sampled_mediation_cpm_ahead_of_auction_winner cuando con las ofertas.

Muestra

El siguiente es un ejemplo de comentarios en tiempo real, tal como se ve en protocolos:

Google

JSON de OpenRTB

Protocolo de OpenRTB

Crea un modelo de ofertas para las subastas de primer precio

Después de realizar una oferta en una subasta de primer precio, comentarios, como 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 podría haber sido más alta o más baja su oferta para ganar la impresión.

  • minimum_bid_to_win: la oferta mínima que se podría haber para ganar la subasta de ofertas en tiempo real. Si ganaste la subasta, esto sería la oferta más baja que podrías haber hecho y, al mismo tiempo, seguir ganando. Si perdiste el subasta, esta será la oferta ganadora.
  • sampled_mediation_cpm_ahead_of_auction_winner: Si hay otras redes de la cadena de mediación, de este campo es un precio que representa una oferta de muestra de uno de los redes de mediación aptas que superaron el ganador de la subasta, ponderado según la tasa de relleno esperada. Este valor se establecerá en 0 si ninguna de las redes de la se espera que llene la cadena de mediación, o si el publicador no usa un SDK mediación.

Cómo funciona

Para describir los cálculos usados para determinar los valores posibles para minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner, primero necesitamos definen 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 a los CPM de la cadena de mediación:
    \[f_1, f_2, …, f_n\]
  • La siguiente es una función utilizada para determinar el CPM esperado y su probabilidad del elemento de la cadena de mediación \(i\), según el relleno especificado tarifa:
    \(X_i = \{C_i\) con probabilidad \(f_i\); \(0\) con probabilidad \(1 - f_i\}\)
  • La última cadena de mediación ganadora 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 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 perdedor en 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 licitación en tiempo real y una cadena de mediación de SDK sigue:

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\%\)

Como resultado de la subasta de RTB, suponga lo siguiente:

Subasta de RTB CPM
Ganador de la subasta (W) USD 1.00
Segundo puesto de la subasta (D) $0.05
Precio mínimo de reserva (F) USD 0
Oferta que ganó la subasta

El siguiente es un ejemplo de cómo los valores y las probabilidades para minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner se calculan para un la 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 los valores y las probabilidades para minimum_bid_to_win y sampled_mediation_cpm_ahead_of_auction_winner se calculan para un 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\%\)

Disminución de ofertas

La separación de ofertas describe el procesamiento de una única estrategia BidRequest en varias solicitudes de oferta que se envían a su y mantener la integridad de su aplicación. Debido a que conservan IDs idénticos (BidRequest.google_query_id en el protocolo de RTB de Authorized Buyers) o BidRequestExt.google_query_id en el protocolo OpenRTB), puedes determinar qué solicitudes de oferta se correlacionan después de la compactación.

Formatos de anuncios

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

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

  • Banner
  • Video
  • Audio
  • Nativo

Ejemplo de compactación del formato del anuncio

A continuación, se incluye un ejemplo de una solicitud de oferta JSON de OpenRTB simplificada sin anuncio. acoplamiento de formato en comparación con un conjunto equivalente de solicitudes acopladas:

Preaplanado

Posaplanado

Ofertas

Una oportunidad de anuncio para un ofertante determinado puede aplicarse a varios acuerdos. nuevos, además de la subasta abierta. Con la separación de ofertas para los acuerdos, una oferta una solicitud para la subasta abierta y una para cada tipo de precio fijo de un acuerdo de precios. En la práctica, las restricciones de anuncios pueden diferir entre las subastas y las de precio fijo tipos de acuerdos, por ejemplo, para una determinada oportunidad de anuncio de video que esté disponible para en la subasta abierta y en el acuerdo de precio fijo, el ofertante recibirá solicitudes de oferta para cada una en las que haya restricciones, como la duración máxima del anuncio y si que se permiten los anuncios que se pueden omitir pueden variar. Como resultado, la compactación se aplicó al anuncio le permite distinguir más fácilmente las limitaciones de los anuncios de la y el acuerdo de precio fijo.

Duración máxima de video que se puede omitir

El protocolo de Google y la implementación de OpenRTB admiten los siguientes campos para la duración y omisión del video:

Duración Duración que se puede omitir Posibilidad de omitir
Protocolo de Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration N/A skip

Esto significa que, si bien el protocolo de Google puede tener una capa y de duración que no se puede omitir, la implementación de OpenRTB solo tiene un de duración máxima.

Antes de la compactación de ofertas, el valor maxduration de OpenRTB se configuraba como el valor inferior de la max_ad_duration del protocolo de Google y skippable_max_ad_duration. Este comportamiento ha cambiado a enviar dos solicitudes de oferta separadas cuando estos valores difieren: una que represente la maxduration para anuncios que se pueden omitir y la otra para los que no se pueden omitir oportunidades.

En los siguientes ejemplos, se muestra cómo se traduce una solicitud de protocolo de Google con OpenRTB antes y después de la separación de ofertas. El protocolo equivalente de Google tiene un max_ad_duration de 15 y una skippable_max_ad_duration de 60.

Ejemplo max_ad_duration skip (verdadero O falso)
Solicitud original sin compactar 15 true
Solicitud plana n° 1: No se puede omitir 15 false
Solicitud separada n° 2: Se puede omitir 60 true

La compactación de solicitudes de oferta de duración de videos que se pueden omitir solo ocurrirá cuando se cumplan estas condiciones:

  • La solicitud permite el video.
  • Se permiten tanto los videos que se pueden omitir como los que no se pueden omitir, y los dos valores máximos respectivos las duraciones difieren en el valor.
  • Esta solicitud es apta para subasta privada o subasta abierta.
  • La cuenta de ofertante tiene extremos de OpenRTB activos.

Para inhabilitar este tipo de compactación, comunícate con tu administrador de cuentas.

Grupos de anuncios de video

Las solicitudes de oferta para un grupo de anuncios de video con varias oportunidades de anuncios se aplanan de manera que cada solicitud de oferta sea para una oportunidad de anuncio individual de ese grupo. Esto te permite realizar ofertas para varias oportunidades de anuncios para un grupo de anuncios determinado.

Open Measurement

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

Puede determinar si un publicador admite Open Measurement en la oferta. solicitud comprobando si la oportunidad de anuncio excluye el atributo OmsdkType: OMSDK 1.0 que se encuentra en Exclusivo por el publicador atributos de creatividades. Para el protocolo Authorized Buyers, que se encuentran en BidRequest.adslot[].excluded_attribute. Para el protocolo OpenRTB, que 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 Open Indicadores de medición, consulta Open Measurement SDK.

Ejemplos de solicitudes de oferta

Las siguientes secciones muestran ejemplos de solicitudes de oferta para diferentes tipos de anuncios.

Banner de la app

Google

JSON de OpenRTB

Protocolo de OpenRTB

Intersticial para aplicaciones

Google

JSON de OpenRTB

Protocolo de OpenRTB

Video intersticial para aplicaciones

Google

Protocolo de OpenRTB

Aplicación nativa

Google

JSON de OpenRTB

Protocolo de OpenRTB

Video web

Google

Banner de Web móvil para ofertante de intercambio

Protocolo de OpenRTB