Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Administra los datos de manera eficiente

Una función principal de muchas aplicaciones de Google Ads es recuperar datos de la cuenta para casos de uso, como el análisis de datos, las consultas de los clientes y las verificaciones de cumplimiento de políticas. Mientras recuperas los datos, debes optimizar el uso para no sobrecargar los servidores de Google ni correr el riesgo de que se limite la frecuencia. Para obtener más detalles, consulta las guías sobre límite de frecuencia y cómo mantener una dirección de correo electrónico de contacto actualizada.

Comprende la política de uso de recursos para los informes

Para garantizar la estabilidad de sus servidores, la API de Google Ads limita los patrones de consulta GoogleAdsService.Search y GoogleAdsService.SearchStream que consumen cantidades excesivas de recursos de la API. Si se limita un patrón de consulta en particular, otros servicios, métodos y patrones de consulta seguirán funcionando sin verse afectados. Se arrojan los siguientes errores para las solicitudes limitadas:

Código de error
`QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION` o `QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION`, según la duración del uso elevado de recursos.

Si encuentras estos errores, espera 5 minutos antes de volver a intentar las solicitudes que fallaron con QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION y 30 minutos para las solicitudes que fallaron con QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Para ayudarte a identificar y supervisar tus informes costosos, también devolvemos una métrica de costo para los informes individuales:

Método	Campo de costo
`GoogleAdsService.Search`	`SearchGoogleAdsResponse.query_resource_consumption`
`GoogleAdsService.SearchStream`	`SearchGoogleAdsStreamResponse.query_resource_consumption`

La métrica de costo que devuelven estos campos depende de varios factores, como los siguientes:

La cantidad de cuentas que tienes
Las vistas y columnas que recuperas en tus informes
La carga en los servidores de la API de Google Ads

En la siguiente tabla, se enumeran las estadísticas agregadas sobre el consumo de recursos de varios patrones de consulta en los servidores de la API de Google Ads para ayudarte a hacer un seguimiento de las consultas costosas y ajustarlas:

Período	Promedio (p50)	P70 (moderadamente alta)	P95 (muy alta)
Corto plazo (5 min)	6000	30,000	1800000
Largo plazo (24 h)	16,000	90000	8400000

Por ejemplo, supongamos que ejecutas un patrón de consulta como el siguiente, que consume 600 unidades de recursos por informe:

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = 'YYYY-MM-DD'

Ejecutas esta consulta para varias cuentas de clientes en varias fechas individuales modificando la consulta para sustituir diferentes valores para el filtro segments.date. En la siguiente tabla, se muestra la cantidad de informes que puedes ejecutar en un período determinado, de modo que el uso de recursos se ajuste a varios buckets de uso de recursos.

Período	Promedio	Moderadamente alta	Muy alto
Corto plazo (5 min)	10	50	3000
Largo plazo (24 h)	26	150	14000

Ejecutar este patrón de consulta 10 veces en 5 minutos se consideraría un uso promedio, mientras que ejecutar 3,000 informes en 5 minutos se consideraría un uso muy alto.

Existen varias estrategias para optimizar el consumo de recursos de tus informes. En el resto de esta guía, se abordan algunas de estas estrategias.

Almacena tus datos en caché

Debes almacenar en caché los detalles de la entidad que recuperas de los servidores de la API en una base de datos local, en lugar de llamar al servidor cada vez que necesites los datos, en especial para las entidades a las que se accede con frecuencia o que cambian con poca frecuencia. Usa change-event y change-status siempre que sea posible para detectar qué objetos cambiaron desde la última vez que sincronizaste los resultados.

Optimiza la frecuencia de ejecución de los informes

Google Ads tiene lineamientos publicados sobre la actualidad de los datos y la frecuencia con la que se actualizan. Debes usar esta guía para determinar con qué frecuencia recuperar los informes.

Si necesitas actualizar cuentas con regularidad, te recomendamos que limites la cantidad de esas cuentas a un conjunto pequeño, por ejemplo, solo las veinte cuentas de Google Ads principales. El resto se puede actualizar con menos frecuencia, por ejemplo, una o dos veces al día.

Optimiza el tamaño de tus informes

Tu aplicación debería recuperar grandes lotes de datos en lugar de ejecutar una gran cantidad de informes pequeños. Un factor que influye en esta elección son los límites de la cuenta.

Por ejemplo, considera el siguiente código que extrae las estadísticas de grupos de anuncios específicos y actualiza una tabla de base de datos de estadísticas:

  List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  foreach (long adGroupId in adGroupIds)
  {
    string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
        "metrics.cost_micros, metrics.impressions, segments.date FROM " +
        "ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
        $"ad_group.id = {adGroupId}";
    List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

Este código funciona bien en una cuenta de prueba pequeña. Sin embargo, Google Ads admite hasta 20,000 grupos de anuncios por campaña y 10,000 campañas por cuenta. Por lo tanto, si este código se ejecuta en una cuenta de Google Ads grande, puede sobrecargar los servidores de la API de Google Ads, lo que genera una limitación de frecuencia y una limitación de ancho de banda.

Un mejor enfoque sería ejecutar un solo informe y procesarlo de forma local. A continuación, se muestra un enfoque de este tipo con un mapa en memoria:

  HashSet<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
      "metrics.cost_micros, metrics.impressions, segments.date FROM " +
      "ad_group WHERE segments.date DURING LAST_7_DAYS";
  List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

Esto reduce la carga en los servidores de la API de Google Ads debido a la menor cantidad de informes que se ejecutan.

Si descubres que el informe es demasiado grande para guardarlo en la memoria, también puedes dividir la consulta en grupos más pequeños agregando una cláusula LIMIT como esta:

SELECT
  ad_group.id,
  ad_group.name,
  metrics.clicks,
  metrics.cost_micros,
  metrics.impressions,
  segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
  AND ad_group.id IN (id1, id2, ...)
LIMIT 100000

Las etiquetas son otra forma de agrupar entidades y reducir la cantidad de consultas de informes. Consulta la guía de etiquetas para obtener más información.

Optimiza lo que recuperas

Cuando ejecutes informes, debes tener en cuenta las columnas que incluyes en tus consultas. Considera el siguiente ejemplo, que está programado para ejecutarse cada hora:

SELECT
  customer.id,
  customer.currency_code,
  campaign.id,
  campaign.name,
  ad_group.id,
  ad_group.name,
  ad_group_criterion.keyword.match_type,
  ad_group_criterion.keyword.text,
  ad_group_criterion.criterion_id,
  ad_group_criterion.quality_info.creative_quality_score,
  ad_group_criterion.system_serving_status,
  ad_group_criterion.negative,
  ad_group_criterion.quality_info.quality_score,
  ad_group_criterion.quality_info.search_predicted_ctr,
  ad_group_criterion.quality_info.post_click_quality_score,
  metrics.historical_landing_page_quality_score,
  metrics.search_click_share,
  metrics.historical_creative_quality_score,
  metrics.clicks,
  metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS

Las únicas columnas que pueden cambiar cada hora son metrics.clicks y metrics.impressions. Todas las demás columnas se actualizan con poca frecuencia o no se actualizan, por lo que es muy ineficiente recuperarlas cada hora. Puedes almacenar estos valores en una base de datos local y ejecutar un informe de evento de cambio o estado de cambio para descargar los cambios una o dos veces al día.

En algunos casos, puedes aplicar filtros adecuados para reducir la cantidad de filas que descargas.

Borra las cuentas que no uses

Si tu aplicación administra cuentas de clientes de terceros, debes desarrollarla teniendo en cuenta la deserción de clientes. Debes limpiar periódicamente tus procesos y almacenes de datos para quitar las cuentas de los clientes que ya no usan tu aplicación. Cuando limpies las cuentas de Google Ads que no se usan, ten en cuenta la siguiente guía:

Revoca la autorización que tu cliente le otorgó a tu aplicación para administrar su cuenta.
Deja de realizar llamadas a la API para las cuentas de Google Ads del cliente. Esto se aplica, en especial, a los trabajos sin conexión, como los trabajos cron y las canalizaciones de datos que están diseñados para ejecutarse sin la intervención del usuario.
Si el cliente revocó su autorización, tu aplicación debería controlar la situación de forma correcta y evitar enviar llamadas a la API no válidas a los servidores de la API de Google.
Si el cliente canceló su cuenta de Google Ads, debes detectar las cuentas canceladas y evitar enviar llamadas a la API no válidas a los servidores de la API de Google.
Borra de tu base de datos local los datos que descargaste de las cuentas de Google Ads del cliente después de un período adecuado.

Supervisión

Límites de tarifas