Una función principal de muchas aplicaciones de Google Ads es recuperar datos de la cuenta para su uso como análisis de datos, consultas de clientes y verificaciones de cumplimiento de políticas. Mientras recuperas los datos, debes optimizar el uso para no sobrecargar servidores de Google ni correr el riesgo de que se aplique un límite de frecuencia. Para obtener más detalles, consulta las guías sobre límite de frecuencia y mantener un dirección de correo electrónico de contacto actualizada.
Comprende la política de uso de recursos de Google para los informes
Para garantizar la estabilidad de sus servidores, la API de Google Ads limita
GoogleAdsService.Search y
GoogleAdsService.SearchStream patrones de consulta que consumen cantidades excesivas
cantidades de recursos de API. Si se limita un patrón de consulta particular,
servicios, métodos y patrones de consulta seguirán funcionando sin verse afectados. El
se arrojan los siguientes errores para las solicitudes limitadas:
| Versión de API | Código de error |
|---|---|
| <= v17 | QuotaError.RESOURCE_EXHAUSTED |
| >= v18 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
o QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION, dependiendo
durante el alto uso de los recursos. |
Para ayudarte a identificar y supervisar tus costosos informes, también mostraremos de costos en 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
- El tamaño de tus cuentas
- Las vistas y las columnas que recuperas en tus informes
- La carga en los servidores de la API de Google Ads.
Para ayudarte a realizar un seguimiento de las consultas costosas, publicamos datos agregados estadísticas sobre el consumo de recursos de diversos patrones de consulta que vemos nuestros servidores. Publicaremos números actualizados de forma periódica para ayudarte a perfeccionar tus consultas.
| Período | Promedio (p50). | P70 (medianamente alta) | P95 (muy alto) |
|---|---|---|---|
| Corto plazo (5 min) | 6000 | 30,000 | 1800000 |
| Largo plazo (24 horas) | 16000 | 90000 | 8400000 |
A modo de ejemplo, supongamos que estás ejecutando un patrón de consulta de la siguiente manera, que consume 600 unidades de recursos por informe
SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
segments.date = "YYYY-MM-DD"
Realiza esta consulta para varias cuentas de clientes en diferentes fechas individuales
Modifica la consulta para sustituir valores diferentes por segments.date.
filtro. En la siguiente tabla, se muestra la cantidad de informes que puedes ejecutar en un determinado
período de tiempo para que el uso de los recursos se adapte a diversos usos de recursos
buckets.
| Período | Promedio | Moderadamente alto | Muy alto |
|---|---|---|---|
| Corto plazo (5 min) | 10 | 50 | 3000 |
| Largo plazo (24 horas) | 26 | 150 | 14000 |
Ejecutar este patrón de consulta 10 veces en 5 minutos cuenta como un promedio de procesamiento, mientras que ejecutar 3,000 informes en 5 minutos sería un uso muy alto.
Existen varias estrategias para optimizar el consumo de recursos informes. En el resto de esta guía, se abarcan 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 ubicación en lugar de llamar al servidor cada vez que necesites los datos, especialmente para las entidades a las que se accede con frecuencia o que cambian con poca frecuencia. Usa change-event y change-status, donde posible detectar qué objetos cambiaron desde la última vez que sincronizaste los resultados.
Optimizar la frecuencia de la ejecución de informes
Google Ads publicó lineamientos sobre la actualidad de los datos y cómo hacerlo y con frecuencia los datos se actualizan. Deberías usar esta guía para determinar con frecuencia para recuperar informes.
Si necesita actualizar las cuentas en forma periódica, le recomendamos que limite las de este tipo de cuentas a un conjunto pequeño, por ejemplo, solo las veinte principales cuentas de servicio. El resto se puede actualizar con una frecuencia menor, por ejemplo, una vez 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 un gran la cantidad de informes pequeños. Un factor que influye en esta elección es la cuenta límites.
Por ejemplo, considera el siguiente código que extrae las estadísticas de un anuncio específico grupos y actualizar 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 Entonces, si este código se ejecuta en una cuenta grande de Google Ads, puede sobrecargar los servidores de la API de Google Ads lo que genera un límite de frecuencia y una regulación.
Un mejor enfoque sería ejecutar un solo informe y procesarlo a nivel local. Uno se muestra este enfoque con un mapa en la 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(customer_id, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
for each (GoogleAdsRow row in rows)
{
var adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (long adGroupId in memoryMap.Keys())
{
InsertRowsIntoStatsTable(adGroupId, rows);
}
Esto reduce la carga en los servidores de la API de Google Ads debido a la menor cantidad de informes. que se está ejecutando.
Si descubres que el informe es demasiado grande para retenerlo en la memoria, también puedes
reducir la consulta en grupos más pequeños agregando una cláusula LIMIT de la siguiente manera:
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 informes para tus consultas. Consulta la guía de etiquetas para obtener más información.
Optimiza los datos recuperados
Al ejecutar informes, debe tener en cuenta las columnas que incluye 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 probablemente cambien cada hora son metrics.clicks y
metrics.impressions Todas las otras columnas se actualizan con poca frecuencia o no se actualizan
por lo que es muy ineficiente
recuperarlas cada hora. Puedes almacenar estas
valores en una base de datos local y ejecutar un evento de cambio o
informe de estado de cambio para descargar los cambios una o dos veces al día.
En algunos casos, puedes reducir la cantidad de filas que descargas aplicando filtros adecuados.
Borra las cuentas que no uses
Si tu aplicación administra cuentas de anunciante de terceros, debes hacer lo siguiente: y desarrolles tu aplicación teniendo en cuenta la deserción de clientes. Deberías periódicamente limpiar tus procesos y almacenes de datos para quitar las cuentas de los clientes que no a utilizar tu aplicación. Cuando limpie las cuentas de Google Ads sin usar, conserve el la siguiente guía:
- Revocar la autorización que el cliente otorgó a tu aplicación para administrar a su cuenta.
- Dejar de realizar llamadas a la API a las cuentas de Google Ads del cliente Esto aplica especialmente a trabajos sin conexión, como cron y canalizaciones de datos diseñados para ejecutarse sin intervención del usuario.
- Si el cliente revocó su autorización, tu aplicación debe manejar correctamente la situación y evitar el envío de llamadas no válidas a la API a a los servidores de la API de Google.
- Si el cliente canceló su cuenta de Google Ads, deberías detectar y evita enviar llamadas no válidas a la API a los servidores de la API de Google.
- Borrar los datos que descargó de las cuentas de Google Ads del cliente desde su una base de datos local tras un período adecuado.