Нова політика retention у Google Ads: як адаптувати колтрекінг до змін

З червня 2026 року Google обмежив доступ до деталізованих історичних даних у Google Ads. Маркетологи по всьому світу зіткнулися з проблемою одразу після впровадження змін: при спробі вивантажити деталізовані звіти за минулі роки системи аналітики почали видавати критичні помилки. Обмеження доступу до історичних даних у Google Ads заблокувало звичний аналіз сезонності та ланцюжків конверсій, безпосередньо вдаривши по роботі систем відстеження дзвінків (колтрекінгу).

У цьому матеріалі команда агенції UAMASTER, яка спеціалізується на digital-маркетингу, детально розповідає, що саме змінилося в рекламному кабінеті, чим ці нововведення загрожують бізнесу та як оперативно переналаштувати свій колтрекінг, щоб захистити цінну статистику від втрат.

Що Google змінив у зберіганні даних

Google офіційно обмежив період зберігання та доступності деталізованих (granular) історичних даних. Нова політика Data Retention Policy вступила в силу 1 червня 2026 року і торкнулася не лише інтерфейсу Google Ads, а й запитів через Google Ads API. 

Обмеження стосується часових сегментів звітів: якщо ви намагаєтеся отримати деталізацію даних за днями чи годинами за період понад 37 місяців, то система блокує запит.

Тимчасові ліміти та технічні обмеження

• Період у 37 місяців (деталізовані дані): на рівні окремих днів, годин та тижнів дані тепер зберігаються рівно 37 місяців. При спробі зробити запит через Google Ads API із додаванням у вибірку (SELECT) сегментів, як-от segments.date, segments.hour або segments.week, для періоду після 37 місяців Google Ads API автоматично повертає помилку DateRangeError.INVALID_DATE_RANGE.
• Період у 11 років (агреговані дані): протягом цього терміну стало можливим отримати лише високорівневу статистику без деталізації. Система дозволила використовувати лише великі часові зрізи: segments.month, segments.quarter або segments.year.
• Метрики охоплення (Reach and frequency): дані щодо унікального охоплення та частоти показів отримали найсуворіший ліміт — відтепер вони повністю видаляються через 3 роки (36 місяців) і стають недоступними у будь-якому вигляді.
• Удар по BigQuery Data Transfer Service: для тих, хто використовує стандартний конектор від Google для копіювання даних в BigQuery, функція історичного перезапису або дозавантаження даних (backfill runs) для дат давністю понад 37 місяців з 1 червня була заблокована.

Конфіденційність і оптимізація: причини змін від Google

Крім офіційних заяв про оптимізацію інфраструктури для збереження петабайтів сирих даних, ключовим фактором стало посилення вимог до конфіденційності користувачів. Google планомірно обмежив доступ до деталізованих історичних даних, пов’язаних із ідентифікаторами кліків gclid і wbraid (зокрема щодо точного часу та дати взаємодій).

Цей крок був безпосередньо пов’язаний з адаптацією рекламної екосистеми до сучасних privacy-підходів та ініціатив на кшталт Privacy Sandbox.

Як зміни вплинули на колтрекінг

Колтрекінг працює за принципом наскрізної аналітики: він пов’язує конкретний телефонний дзвінок із кліком, ключовим словом, кампанією та часом візиту.

Якщо раніше можна було відкрити дані трирічної давнини і подивитися, яка саме кампанія принесла сплеск дзвінків у конкретний вівторок, то після оновлення політики:

• Старі конверсії (дзвінки), що передавалися в Google Ads як Google Ads API conversion uploads, втратили зв’язок із деталізованим часом.
• Звіти всередині кабінету Google Ads більше не показують погодинну або щоденну деталізацію за дзвінками для періодів давністю понад 37 місяців.
• Функції зворотного заповнення даних (backfill runs) у конекторах на кшталт BigQuery Data Transfer Service для Google Ads також перестали працювати для даних віком понад 37 місяців.

Як показує практика налаштування наскрізної аналітики спеціалістами агенції UAMASTER, бізнеси, які розгорнули власне сховище до 1 червня, не втратили безперервність щоденних зрізів — їхні дані залишилися недоторканими після оновлення політики.

За внутрішньою статистикою агенції, близько 40% клієнтів встигли повністю підготувати інфраструктуру завчасно. Для них перехід відбувся непомітно: уся рекламна статистика за 2022 та 2023 роки збереглася в BigQuery у повному обсязі, що дозволило пов’язати дані колтрекінгу з конкретними кампаніями (включаючи маркери gclid/wbraid) та продовжити аналізувати сезонність без жодних системних помилок. 

Натомість решта компаній втратили можливість зв’язати дзвінки з маркетинговими джерелами, історичні рекламні дані стали недоступними після завершення періоду їх зберігання в Google Ads. Зараз такі клієнти бачать у Looker Studio помилку джерела даних або порожні графіки при спробі побудувати звіт за днями за 2022-2023 роки. 

Запити до Google Ads API із параметром date_range, старшим за 37 місяців, повертають системну помилку DateRangeError.INVALID_DATE_RANGE.

Покроковий план адаптації колтрекінгу

Щоб уникнути втрати критично важливих даних під час річного планування або аналізу сезонності, компаніям доведеться переглянути підхід до архітектури зберігання даних. Ключовий принцип у сучасних умовах полягає в тому, що повний контроль над інформацією можливий лише за умови її зберігання у власній базі даних.

1. Перевірте та налаштуйте експорт у власне сховище (Data Warehouse)

Не покладайтеся на інтерфейс Google Ads чи кабінет системи колтрекінгу як на єдине джерело.

Важливо: дані, які вже завантажені до BigQuery, не підлягають видаленню з боку Google — це гарантує їх збереження та подальшу доступність для аналітичної обробки. 

Налаштуйте пряму передачу даних із вашого колтрекінгу (наприклад, Ringostat) у незалежне сховище — як-от Google BigQuery, PostgreSQL або ClickHouse.

Забезпечте потокове надходження сирих даних (Raw Data), включаючи ідентифікатор дзвінка, точний час здійснення, тривалість, статус, а також ключові параметри відстеження (gclid, wbraid, utm-мітки). 

2. Запустіть примусовий бекап (Backfill) історичних даних

Оскільки автоматичне вікно можливостей для дат, старших за 37 місяців, вже закрилося, терміново перевірте поточний стан бази.

Переконайтеся, що всі доступні на цей момент історичні деталізовані звіти (щоденні/погодинні) успішно імпортовані у ваші таблиці, і за потреби зробіть ручне копіювання залишків даних, які ще дозволяє вивантажити API.

3. Налаштуйте «зшивання» даних (Data Stitching) на своєму боці

Оскільки Google Analytics Data API також обрізатиме метрики витрат (Ad Cost, Clicks, Impressions) до 36-37 місяців, якщо в запиті є параметр “date”, вам доведеться самостійно зводити дані.

У своєму аналітичному сховищі створіть таблиці, де ID дзвінка з колтрекінгу з’єднується з витратами та кліками з Google Ads на основі вашої власної збереженої історичної бази.

4. Перегляньте логіку custom-дашбордів (Looker Studio / Power BI)

Якщо ваші клієнтські чи внутрішні звіти тягнуть дані напряму з Google Ads API за великі періоди, то:

• Перепишіть конектори. Змініть джерело даних із Google Ads UI на власну базу BigQuery.
• Якщо для раніших періодів (37+ місяців) власної бази немає, змініть деталізацію у графіках з Day / Week на Month. Інакше дашборди просто видаватимуть помилку відображення. 

5. Скорегуйте роботу з моделями атрибуції та сезонністю

Для бізнесів із довгим циклом укладання угод (нерухомість, автоіндустрія, B2B) важливо бачити повну історію взаємодій.

Зберігайте у своїй CRM-системі повний шлях клієнта (First Click і Last Click атрибуцію разом із даними колтрекінгу) безстроково. Це дозволить аналізувати відкладений ефект реклами, навіть коли Google Ads «забуде» про деталі цього кліку.

Що вже втрачено і як мінімізувати збитки

Оскільки оновлення політики Google Ads повністю набуло чинності 1 червня 2026 року, деталізацію за минулі роки вже втрачено, але головне зараз — зупинити витік даних у майбутньому. Якщо ваша компанія не підготувала інфраструктуру заздалегідь, ви вже могли зіткнутися з першими змінами та побачити у звітах такий результат:

Що вже втрачено:

• Спробувавши вивантажити дані за днями чи годинами для періодів, старших за 37 місяців (наприклад, для порівняння сезонності весни 2023 року з весною 2026), ви отримаєте системну помилку.
• Стандартний конектор BigQuery Data Transfer Service більше не зможе «підтягнути» цей історичний шматок у ваші таблиці в автоматичному режимі.
• Дані трирічної давнини за цими показниками стають недоступними для отримання через Google Ads.

Як зупинити подальшу втрату даних

Рекомендації для тих, хто запізнився з бекапом, але хоче зупинити втрату даних.

1. Якомога швидше вивантажте агреговані дані (за місяцями). Ви все ще маєте доступ до високорівневої статистики за останні 11 років. Налаштуйте експорт у BigQuery або навіть вручну вивантажте звіти на рівні місяців (segments.month), кварталів чи років. Це дозволить зберегти хоча б загальний тренд динаміки вашого колтрекінгу та витрат для загального планування.
2. Кожен день без власної бази — це один день, якого бракуватиме в ретроспективному аналізі через три роки. Що раніше ви налаштуєте власну базу, то швидше накопичиться незалежна історична статистика, яку Google більше не зможе забрати. 
3. Перейдіть на прямий збір логів (Raw Data) з колтрекінгу. Оскільки Google Ads обмежив зв’язок конверсій із часом кліку, побудуйте міст в іншому напрямку. Налаштуйте передачу сирих логів із вашої системи колтрекінгу напряму у ваше сховище, фіксуючи gclid та wbraid у момент дзвінка. Ваша внутрішня база даних стане головним «сейфом» для маркетингової інформації.
4. Упроваджуйте практику безстрокового збереження розширеного масиву маркетингових логів безпосередньо у вашій CRM-системі. Сюди належать первинні джерела лідогенерації, записи розмов, повна атрибуція першого та останнього взаємодії, а також асоційовані конверсії. Коли алгоритми Google Ads автоматично видалять деталізовані дані про кліки, саме локальна архітектура вашої CRM стане єдиним верифікованим джерелом істини для оцінки відкладеного ефекту реклами (LTV) та розрахунку окупності маркетингових інвестицій (ROMI). 

Висновки

Нова політика Google — це чіткий сигнал для ринку: ера безкоштовного та безстрокового зберігання сирих маркетингових даних у хмарі Google завершилася.

Підготовка системи колтрекінгу зводиться до одного головного завдання — побудови власної інфраструктури даних. Своєчасний експорт статистики дзвінків та витрат у BigQuery дозволить вам проводити глибокі ретроспективні аудити, аналізувати сезонність за 5 років та ухвалювати правильні рішення на основі цифр, які у вас ніхто не забере.