Optimización de cuotas

La optimización de la cuota es fundamental para cualquier aplicación que use la API de Display & Video 360. La optimización del uso de la cuota mejora el rendimiento, ya que optimiza las solicitudes a la API y te ayuda a evitar los errores que se muestran cuando se superan los límites de frecuencia establecidos.

En esta página, se detallan las prácticas recomendadas generales y se destacan las funciones complementarias de la API de Display & Video 360 que pueden ayudarte a reducir el uso de tu cuota.

Realiza solicitudes simultáneas a varios anunciantes

La mayoría de los métodos de la API de Display & Video 360 especifican un anunciante en la URL. Además de la cuota de todo el proyecto, se aplican límites de frecuencia más restrictivos"por anunciante por proyecto" para estos métodos cuando se realizan llamadas que especifican el mismo anunciante.

Para optimizar esta cuota, limita las solicitudes simultáneas a aquellas que especifiquen anunciantes diferentes.

Usa los parámetros pageSize, filter y orderBy

Usa métodos list en lugar de métodos get cuando recuperes varios recursos. Debido a los límites de tamaño de página, las llamadas a list aún pueden consumir mucha cuota.

Para optimizar todas tus solicitudes de list, configura el parámetro pageSize en el valor máximo permitido. El tamaño de página predeterminado de un método, que se usa cuando no se configura el parámetro, puede ser inferior a su valor máximo permitido y requerir más solicitudes para recuperar una lista exhaustiva de recursos.

Si solo necesitas recuperar un subconjunto de la respuesta de la lista completa, puedes optimizar el uso de la cuota aprovechando los parámetros opcionales filter y orderBy.

El parámetro filter te permite restringir los recursos que recupera la llamada a list a aquellos cuyas propiedades cumplen con expresiones determinadas. Este parámetro es útil cuando se intenta recuperar lo siguiente:

  • Un recurso específico con un ID desconocido, pero con propiedades conocidas. Si buscas un recurso específico, puedes filtrar la lista que se muestra por propiedades conocidas del recurso deseado. Algunos ejemplos son filtrar las líneas de pedido por un displayName conocido, las creatividades por el creativeType esperado y las fuentes de inventario por el exchange relevante.
  • Recursos asociados. Los recursos de Display & Video 360 suelen estar asociados entre sí. Puedes usar filtros para restringir los recursos que se muestran a aquellos que tienen una relación específica con otro. Entre los ejemplos, se incluyen la recuperación de todos los pedidos de inserción debajo de un campaignId específico y todas las creatividades asignadas a una línea de pedido.
  • Solo los recursos que tienen propiedades prácticas. La funcionalidad de la API te permite verificar fácilmente el estado de los recursos y reaccionar de manera programática. Con los filtros, puedes usar llamadas list para obtener solo los recursos en los que se necesita una acción. Por ejemplo, puedes recuperar todas las líneas de pedido que muestran un lineItemWarningMessage práctico, todos los pedidos de inserción que se actualizaron desde una fecha y hora determinadas, o todas las creatividades que tienen un approvalStatus que falló.

El parámetro orderBy te permite ordenar los recursos recuperados por propiedades específicas, de forma ascendente o descendente. orderBy, en especial cuando se usa junto con filter, se puede usar para limitar la cantidad de páginas que se deben recorrer antes de encontrar un recurso específico. También te permite obtener fácilmente los límites superior e inferior de una lista de recursos. Por ejemplo, ordenar por updateTime te permitiría encontrar rápidamente las líneas de pedido o los pedidos de inserción de un anunciante que se hayan actualizado más recientemente.

Usa funciones masivas y de todo el recurso

La API de Display & Video 360 ofrece varias funciones masivas y de recursos que ejecutan varias acciones con una sola solicitud. Estos son algunos ejemplos de este tipo de funciones:

  • Editar de forma masiva los sitios que pertenecen a un solo canal Los canales pueden tener miles de sitios asignados. En lugar de administrar la lista de sitios de un canal con solicitudes individuales de create o delete, puedes usar una sola solicitud de bulkEdit o replace para agregar y quitar varios sitios, o reemplazar todo el contenido de un canal, respectivamente.
  • Administrar todo el paquete de segmentación de un anunciante El paquete de segmentación de un recurso se asigna a varios tipos de segmentación. Las funciones de segmentación a nivel del recurso, como listAssignedTargetingOptions y editAssignedTargetingOptions en el servicio advertisers, te permiten recuperar, crear y quitar la segmentación en varios tipos de segmentación en una sola solicitud. De esta manera, se reduce el costo de cuota de configurar el paquete de segmentación de un anunciante en una sola solicitud.
  • Establecer la misma restricción de segmentación en varias líneas de pedido Si necesitas realizar los mismos cambios de segmentación en varias líneas de pedido a la vez, puedes hacerlo con una sola solicitud advertisers.lineItems.bulkEditAssignedTargetingOptions.
  • Activa o detiene varias líneas de pedido. Las líneas de pedido se deben activar después de crearlas para que comiencen a publicarse. Si creas varias líneas de pedido de forma consecutiva, puedes activarlas todas con una sola solicitud advertisers.lineItems.bulkUpdate. Se puede usar el mismo método para pausar varias líneas de pedido y evitar que se publiquen.

Almacena en caché y revisa los IDs que se usan con frecuencia

Muchas operaciones de la API de Display & Video 360 requieren el uso de IDs de recursos que se recuperan a través de la propia API, incluidos los IDs de opciones de segmentación, los IDs de público de Google y mucho más. Para evitar recuperar los ID de la API en cada uso, te recomendamos que los almacenes de forma local.

Sin embargo, algunos recursos pueden quedar obsoletos, borrarse o dejar de estar disponibles para su uso. Si intentas usar los IDs de estos recursos, es posible que se muestre un error. Por lo tanto, te recomendamos que revises todos los IDs almacenados en caché semanalmente con el método get o list filtrado adecuado para confirmar que aún se puedan recuperar y que tengan el estado esperado.

Implementa la retirada exponencial para operaciones de larga duración

Mientras sondeas para ver si se terminó una operación de larga duración, como una tarea de descarga de SDF, usa una estrategia de retirada exponencial para reducir la frecuencia y la cantidad total de solicitudes enviadas.

La retirada exponencial es una estrategia estándar de manejo de errores para aplicaciones de red en la que el cliente reintenta periódicamente las solicitudes durante un período creciente. Si se la utiliza de forma correcta, la retirada exponencial aumenta la eficiencia del uso del ancho de banda, reduce la cantidad de solicitudes que se requieren para obtener una respuesta correcta y maximiza la capacidad de procesamiento de las solicitudes en entornos simultáneos.

Puedes encontrar la estrategia de retirada exponencial implementada con bibliotecas cliente en nuestros ejemplos de código de descarga de SDF. El flujo paso a paso para implementar una retirada exponencial simple es el siguiente:

  • Realiza una solicitud sdfdownloadtasks.operations.get a la API.
  • Recupera el objeto de operación.
    • Si el campo done no es verdadero, significa que debes reintentar la solicitud.
    • Esperar 5 segundos + una cantidad aleatoria de milisegundos y reintentar la solicitud
  • Recupera el objeto de operación.
    • Si el campo done no es verdadero, significa que debes reintentar la solicitud.
    • Esperar 10 segundos + una cantidad aleatoria de milisegundos y reintentar la solicitud
  • Recupera el objeto de operación.
    • Si el campo done no es verdadero, significa que debes reintentar la solicitud.
    • Esperar 20 segundos + una cantidad aleatoria de milisegundos y reintentar la solicitud
  • Recupera el objeto de operación.
    • Si el campo done no es verdadero, significa que debes reintentar la solicitud.
    • Esperar 40 segundos + una cantidad aleatoria de milisegundos y reintentar la solicitud
  • Recupera el objeto de operación.
    • Si el campo done no es verdadero, significa que debes reintentar la solicitud.
    • Esperar 80 segundos + una cantidad aleatoria de milisegundos y reintentar la solicitud
  • Continúa con este patrón hasta que se actualice el objeto de consulta o se alcance un tiempo máximo transcurrido.