El 1 de mayo de 2026, Google anunció un cambio de política que rompe todos los reports year-over-year de Google Ads construidos sobre más de tres años de histórico. A partir del 1 de junio de 2026, los datos de performance horarios, diarios y semanales con más de 37 meses de antigüedad quedarán permanentemente bloqueados desde la UI de Google Ads, la Google Ads API, los Google Ads scripts, la Google Analytics Data API y el BigQuery Data Transfer Service. Si no archivas tus datos granulares históricos antes de esa fecha, se pierden.

Es la política inversa a la que Google anunció en octubre de 2024 cuando extendió la retención a 11 años. La data retention de 11 años se mantiene, pero solo para agregados mensuales, trimestrales y anuales. Todo lo más granular que mes se acoge al cap de 37 meses. Para la mayoría de equipos de marketing, esa es la data que importa de verdad: spend ad-level por día, performance horario de bidding, tests semanales de creatives a través de los años. Todo desaparece de los sistemas de Google el 1 de junio a menos que lo tengas almacenado en otro sitio.

Esta guía cubre exactamente qué se limita, dónde están los failure modes silenciosos (la Google Analytics Data API es el más peligroso), a quién afecta (la mayoría de advertisers con análisis granulares multi-año), y tres métodos para preservar tu histórico granular de Google Ads antes del deadline.

Qué se está limitando exactamente

El cambio distingue entre dos niveles de granularidad:

• Datos granulares (horarios, diarios, semanales). Capados a 37 meses rolling. Cualquier dato más antiguo queda permanentemente bloqueado.
• Datos agregados (mensuales, trimestrales, anuales). Retenidos hasta 11 años. Sin cambios.

Si solo miras gasto mensual por campaña para reports al board, no te afecta. Si alguna vez miras performance día a día de hace 3+ años, tests ad-level de creatives de tus campañas de 2022, análisis de pacing por hora del día a través de años, o tendencias semanales con baselines multi-año, te afecta.

Dónde se aplica el cap

Cinco interfaces aplican el límite. El comportamiento varía de forma desagradable:

• UI de Google Ads. Los rangos de fechas con más de 37 meses para reports granulares devuelven resultados vacíos o un mensaje "data unavailable". Los reports ya programados con rangos antiguos rompen silenciosamente.
• Google Ads API. Las queries con granularidad HOURLY / DAILY / WEEKLY para fechas de más de 37 meses devuelven un error explícito. El error es informativo; los scripts downstream que no lo manejen, crashean.
• Google Ads scripts. Mismo comportamiento que la API. Los scripts en cron que extraen histórico granular sin rangos de fecha acotados van a lanzar excepción y dejarán de refrescar dashboards.
• Google Analytics Data API (la más peligrosa). La API trunca silenciosamente las métricas de ads de más de 36 meses (un mes más estricto que el cap de Google Ads) en lugar de devolver error. Tus queries tienen éxito, devuelven datos, y simplemente faltan los valores más antiguos. Sin excepción, sin warning, sin señal obvia en la respuesta. El failure mode que tarda semanas en detectarse porque el dashboard "sigue funcionando."
• BigQuery Data Transfer Service. Las scheduled transfers dejarán de extraer datos de más de 37 meses a partir del 1 de junio. Se espera que los manual backfills apuntando a fechas de más de 37 meses fallen o no devuelvan data; las filas que ya están en tus tablas de BigQuery deberían permanecer intactas. El riesgo está en la capa de configuración: audita tus schedules de DTS y cualquier orquestación custom que re-dispare rangos históricos para evitar load errors o schema mismatches post-deadline. El comportamiento exacto de la API sobre backfills fuera de ventana no está documentado todavía. Google ha anunciado el cap pero no ha publicado el comportamiento post-enforcement en detalle, así que la respuesta precisa (error vs no-op) solo se conocerá completamente después del 1 de junio.

La truncación silenciosa de la GA Data API es el patrón que causará más daño post-deadline porque no produce error visible. Tus queries tienen éxito, faltan datos, y tus dashboards siguen refrescando como si nada hubiera cambiado.

A quién golpea más fuerte

Cuatro audiencias lo notan inmediatamente:

• Performance marketers haciendo análisis YoY. Si comparas este mayo con mayo de 2023, tienes ~36 meses de margen ahora mismo. En septiembre 2026 habrás perdido enero-agosto 2023 de los reports granulares.
• Agencias con histórico multi-año de clientes. Decks de onboarding que muestran "la trayectoria que hemos entregado en cuatro años" requieren datos de más de 37 meses. Una vez que se vayan de los sistemas de Google, esos decks no se pueden regenerar.
• Cualquiera que use el BigQuery Data Transfer Service para Google Ads o Search Ads 360. El DTS es la pipeline Google-native más común para llevar datos de Google Ads a un warehouse. Cada tabla de BigQuery que se nutre del DTS está a un manual backfill accidental de tener problemas.
• Equipos que construyeron dashboards asumiendo retención de 11 años. El anuncio previo de Google sobre los 11 años de retención (finales de 2024) dio confianza a los equipos para arquitecturar dashboards de ventana larga. Esos dashboards ahora tienen fecha de caducidad.

Nota cross-platform: 37 meses no es el suelo de la industria. Meta bajó Reach con breakdowns a 13 meses en enero de 2026, y la mayoría de otras métricas de la Meta Ads Insights API tienen un default de 2 años o menos. La retention se está apretando en varias plataformas de ads. La defensa es la misma en todos los casos: archiva hacia adelante en un destino que tú controles.

Qué se puede seguir consultando con seguridad después del 1 de junio

El cap es específicamente sobre granularidad, no sobre antigüedad. Después del 1 de junio:

• Spend, impressions, clicks, conversions mensuales por campaña hasta 2015 o así. OK.
• Tendencias trimestrales de performance a 11 años. OK.
• Agregados anuales para decks del board. OK.
• Performance a nivel diario desde enero 2023 en adelante (37 meses desde junio 2026). OK.
• Performance a nivel diario desde diciembre 2022 o antes. Se pierde a menos que esté archivado.
• Datos de bidding horarios de más de 37 meses. Se pierden a menos que estén archivados.

Si tu reporting solo usa granularidad mensual o más basta, este cambio es invisible para ti. Si usas cualquier cosa a nivel semanal o más fina, necesitas actuar antes del 1 de junio.

El plan de acción de 12 días

Tres métodos para preservar tu histórico granular de Google Ads. Elige uno y ejecútalo antes del 1 de junio.

Método 1: BigQuery Data Transfer Service one-time backfill (antes del 1 de junio)

Si todavía no tienes BigQuery Data Transfer Service configurado, puedes hacerlo ahora y ejecutar un backfill one-time para todos los datos granulares yendo hasta donde el histórico de tu cuenta llegue. Una vez en BigQuery, los datos son tuyos; el cap del 1 de junio solo afecta a lo que DTS puede extraer después de esa fecha.

Setup: en Google Cloud Console, BigQuery → Data Transfers → Create Transfer → Google Ads. Autentica, elige el dataset destino, configura la fecha de inicio tan atrás como el histórico de tu cuenta de Google Ads vaya. Ejecuta el backfill inicial manualmente. Verifica que los datos hayan aterrizado en tus tablas de BigQuery antes del 1 de junio.

Tip operacional: después del 1 de junio, los manual backfills para rangos de fecha de más de 37 meses fallarán o no devolverán data. Las filas históricas en BigQuery están seguras; el riesgo está en la capa de configuración. Restringe quién puede editar los settings de transfer o disparar re-loads orquestados para no introducir schema mismatches entre data fresca y archivada.

Cuándo encaja: equipos ya en Google Cloud, cómodos con BigQuery y dataset management, OK con pagar storage y query on-demand de BigQuery (consulta nuestra guía BigQuery hidden costs for marketing teams si eres nuevo en esos costes).

Método 2: Apps Script con export a Google Sheets

El path gratis para equipos sin warehouse. Extrae el histórico granular de Google Ads a un Google Sheet vía Apps Script + la Google Ads API, y conserva el sheet (o expórtalo a Drive) para siempre.

Setup outline: genera un developer token de la Google Ads API, escribe un Apps Script que pagine por GoogleAdsService.searchStream con segmentos HOURLY o DAILY para rangos de fechas tan atrás como necesites, y append rows a un Sheet. La documentación de la Google Ads API cubre syntax de reporting queries y paginación.

Dónde se complica:

• Volumen. Data a nivel diario a través de múltiples campañas y cuentas llega rápido al límite de 10 millones de celdas de Google Sheets. Vas a necesitar partir exports en varios sheets o trocear por trimestre.
• Timeout de Apps Script. Workspace Free: 6 minutos de ejecución. Paid: 30 minutos. Extraer 4+ años de data granular a través de 10 cuentas pasará de ambos. Solución: trocea por mes y ejecuta repetidamente.
• Setup de Auth. El developer token requiere una Google Ads MCC y una review de aprobación por parte de Google. Google no publica un turnaround time garantizado; los reportes de comunidad típicamente describen una ventana de aproximadamente una semana, pero el wait real varía y no está oficialmente comprometido. No empieces este método el 28 de mayo esperando terminar el 1 de junio.

Cuándo encaja: advertisers pequeños con una o dos cuentas, histórico bajo 2 años, sin presupuesto para warehouse, y un marketer cómodo con código.

Método 3: Conector programado (Dataslayer)

El path para equipos que quieren la data preservada sin gestionar quotas de API, aprobación de MCC, o troceo de Apps Script. Setup en minutos para equipos de cuenta única; agencias con histórico multi-año a través de múltiples cuentas de clientes deberían planificar unas horas de backfill ejecutándose en background.

Dataslayer conecta a Google Ads vía OAuth, consulta la misma Google Ads API que haría el script manual, y aterriza la data en el destino de tu elección: Google Sheets, Looker Studio, BigQuery, Snowflake, Redshift, o el próximo Dataslayer Data Warehouse. Para el deadline del 1 de junio, el workflow relevante es un backfill histórico one-time: conecta Google Ads, elige los campos granulares que quieras preservar (diario, semanal, mensual, ad-level si lo necesitas), configura el rango de fechas tan atrás como tu cuenta de Google Ads vaya, ejecuta la query, escribe al destino. Después, configura un refresh diario para que lo que se traiga hacia adelante se mantenga al día (el refresh programado requiere el plan Starter o superior; el plan Free soporta refresh manual solo).

Por qué un conector programado es la respuesta correcta para la mayoría de equipos contra el deadline del 1 de junio:

• Sin bottleneck de MCC / dev token. El conector de Google Ads de Dataslayer gestiona la capa de autenticación API por ti. OAuth del lado del usuario, las queries corren en el backend.
• El volumen no es un límite. El conector batchea llamadas API y respeta los rate limits a través de setups multi-cuenta de agencia.
• Flexibilidad de destino. Aterriza el histórico en Sheets para equipos pequeños, BigQuery para equipos que ya usan warehouse, o ambos. La data es tuya independientemente de dónde viva.
• El refresh continuo es el mismo flow. El backfill one-time y el refresh diario continuo usan el mismo conector. No reconstruyes nada después del 1 de junio.

Costes: Free cubre 1 conector y 1 usuario con refresh manual, suficiente para ejecutar el backfill histórico one-time antes del 1 de junio. Starter ($35/mes anual) añade refresh diario programado a 3 conectores; Advanced ($115/mes) cubre refresh horario y AI Insights; Pro ($345/mes) gestiona 100+ cuentas por conector para agencias. Precios actualizados aquí.

Comparando los tres métodos

Estrategia continua después del 1 de junio

Preservar tu histórico de Google Ads es la tarea urgente antes de que el cap de data retention entre en efecto. La tarea continua es asegurar que no vuelves a enfrentarte a esta pérdida, porque Google ha demostrado dos veces en 18 meses que las políticas de retención pueden cambiar en cualquier dirección. El principio: cualquier capa de reporting que no controles puede ser deprecada. Tu defensa es un destino que tú controles donde la data aterriza y se queda.

Para la mayoría de equipos de marketing, ese destino es un warehouse: BigQuery, Snowflake, Redshift, o una opción gestionada marketing-native como el Dataslayer Data Warehouse. Para equipos que aún no están en volumen de warehouse, un Google Sheet mantenido al día vía un conector programado cumple la misma función a menor escala. La forma que importa es: la data aterriza en almacenamiento que tú controlas en un schedule, separada de la plataforma cuya política de retención puede cambiar.

Para el framework de decisión completo sobre si necesitas un warehouse y cuál, consulta nuestra Guía de Marketing Data Warehouse 2026.

FAQ

¿Este cambio afecta a los date pickers de la UI de Google Ads inmediatamente, o solo a la API?
Ambos. La UI devuelve resultados vacíos o "data unavailable" para reports granulares de más de 37 meses desde el 1 de junio. La API lanza error. La Google Analytics Data API trunca silenciosamente a 36 meses sin warning. El failure mode más difícil de detectar porque tus queries simplemente devuelven menos data que antes. No hay carve-out solo para UI o solo para API.

¿La data agregada mensual está realmente a salvo?
Sí. Los agregados mensuales, trimestrales y anuales se mantienen disponibles hasta 11 años según el anuncio de Google. El cap de 37 meses es específicamente sobre granularidad horaria, diaria y semanal.

¿Qué pasa con mis tablas de BigQuery existentes alimentadas por el Data Transfer Service?
La data existente en tus tablas de BigQuery se queda donde está. Post-1 de junio, las scheduled transfers dejarán de poblar nueva data de más de 37 meses, y los manual backfills para esos rangos de fecha fallarán o harán no-op. El riesgo operacional está en la capa de configuración. Audita tus schedules de transfer y cualquier orquestación custom que re-dispare rangos históricos para evitar load errors o schema mismatches entre data fresca y el histórico granular que preservaste antes del deadline.

¿Puedo apelar el cambio o conseguir una excepción?
No se ha anunciado proceso de excepción. La política es uniforme a través de todas las cuentas de Google Ads y todos los advertisers.

¿El Search Ads 360 también está capado?
Sí. El mismo límite de 37 meses se aplica al conector de Search Ads 360 en el BigQuery Data Transfer Service. El comportamiento en manual backfills también es el mismo: fallan o hacen no-op para rangos de fecha de más de 37 meses.

¿Y si solo necesito comparaciones year-over-year, no histórico diario?
Si tus comparaciones YoY son a granularidad mensual o más basta, no te afecta. El cap solo golpea reports granulares. Si tu YoY usa granularidad diaria o semanal para comparar semanas específicas o lanzamientos de campañas a través de años, necesitas archivar antes del 1 de junio.

Conclusión

El cap de 37 meses es un deadline duro sin proceso de excepción. La fecha de enforcement del 1 de junio separa equipos que conservarán todo su histórico granular para siempre de equipos que se quedarán bloqueados en ventanas rolling de 37 meses para el resto de su vida de reporting. La truncación silenciosa de la Google Analytics Data API es el failure mode más probable de pasar desapercibido; los equipos que no archiven antes del 1 de junio solo descubrirán el hueco semanas después cuando una query YoY devuelva silenciosamente menos data que antes.

La acción es directa: elige un destino que tú controles, ejecuta un backfill histórico one-time de toda la data granular de Google Ads, verifica que aterrizó antes del 1 de junio, y luego configura refreshes diarios continuos para no enfrentarte a esta pérdida de nuevo. El método importa menos que la velocidad de ejecución. Los equipos que no actúan pierden data; los que actúan la conservan.

Empieza tu trial gratis de Dataslayer para preservar tu histórico de Google Ads antes del deadline. Setup en minutos; el backfill histórico corre en background.