Migración

La nueva infraestructura de secuencias de comandos de Google Ads se basa en la API de Google Ads. Debido a la arquitectura diferente de esa API, es posible que debas actualizar las secuencias de comandos existentes. Hicimos todo lo posible para garantizar la mayor retrocompatibilidad posible, por lo que estos cambios deberían ser menores.

Informes

Muchos informes de AWQL seguirán funcionando. En segundo plano, cuando uses la infraestructura nueva, las secuencias de comandos convertirán tu consulta de AWQL a GAQL (el nuevo lenguaje de consulta para la API de Google Ads), la ejecutarán en el nuevo backend y, luego, volverán a convertir los resultados al formato que usaban originalmente los informes de AWQL. Las consultas con GAQL se pasarán tal como están.

Debido a esta sobrecarga, te recomendamos que revises tus secuencias de comandos y actualices las consultas de AWQL a GAQL siempre que sea posible. Puedes usar la herramienta de migración de consultas, que usa la misma lógica que las secuencias de comandos para determinar la consulta de GAQL para una consulta de AWQL determinada, o el compilador de consultas interactivo para crear consultas.

Estas son algunas limitaciones de la traducción automática de AWQL a GAQL:

  • No todas las consultas de AWQL se traducen de forma clara a consultas de GAQL. En estos casos, se registrará un mensaje de error con algunos detalles sobre lo que salió mal para ayudarte a corregirlo de forma manual.
  • No todos los tipos de informes de AWQL son compatibles con GAQL.
  • GAQL no admite "filas de impresiones cero". Especificar que un informe debe incluir cero impresiones generará un error.
  • Algunos campos ambiguos no se pueden usar en los filtros. Por ejemplo, "Título" puede hacer referencia a cualquier cantidad de campos del anuncio diferentes.
  • Algunos campos pueden mostrar resultados en un formato diferente, por ejemplo, dividir un resultado en varias columnas.

Organizar selectores

Cuando se recuperan recursos con secuencias de comandos, es bastante común usar llamadas withCondition y orderBy para restringir o ordenar los resultados en el iterador. Los campos de estas llamadas ahora usan los nuevos nombres de la API de Google Ads. Por ejemplo, para filtrar por nombre de campaña, antes habrías usado lo siguiente:

.withCondition('CampaignName = "SOME_CAMPAIGN_NAME"')

Ahora, debes usar los nombres de campo nuevos para estas condiciones siempre que sea posible:

.withCondition('campaign.name = "SOME_CAMPAIGN_NAME"')

Dicho esto, nos esforzamos por incluir una asignación de nombres antiguos a nombres nuevos, por lo que, si tu secuencia de comandos aún usa CampaignName, se reemplazará automáticamente por campaign.name durante el tiempo de ejecución para garantizar que siga funcionando. Si tienes algún problema con los nombres de los estilos anteriores, actualiza tus secuencias de comandos para usar los nombres de los estilos nuevos como primer paso para solucionar problemas.

Límites

Muchos límites son los mismos que en la infraestructura anterior y, por lo general, los cambios realizados aquí ayudarán a mejorar el rendimiento.

  • Los límites de tiempo son los mismos. Una secuencia de comandos puede ejecutarse durante 30 minutos.
  • Un solo iterador muestra 50,000 entidades de forma predeterminada, pero esto se puede anular. Anteriormente, este límite de 50,000 no era personalizable.
  • Un solo selector puede controlar como máximo 10,000 IDs (sin cambios).
  • La nueva infraestructura no tiene límite para la cantidad de entidades que se pueden procesar en una sola secuencia de comandos. Anteriormente, el límite era de 250,000.
  • La nueva infraestructura no tiene límite en la cantidad de palabras clave o anuncios que se pueden crear por ejecución. Anteriormente, el límite era de 250,000.
  • El resultado del registro se trunca a los 100 KB (sin cambios).
  • Las cuotas de los servicios de Apps Script (SpreadsheetApp, MailApp, etcétera) no se modifican.
  • Las cuotas de Google Ads se aplicarán como si estuvieras usando la API. Es decir, tu secuencia de comandos estará sujeta a los límites de frecuencia de la API, pero esto permite una mayor flexibilidad para acceder a más informes o realizar más cambios por ejecución.

Otros cambios

ExecutionInfo ya no expone getRemainingCreateQuota() ni getRemainingGetQuota(), ya que esas cuotas ya no se aplican en la nueva experiencia.