Відкриваєш дослідження (Explorations) у GA4, ставиш діапазон на цей вересень і вересень рік тому, а старіший період порожній — хоча сайт тоді вже працював. Зазвичай винне одне налаштування: у Google Analytics 4 термін зберігання даних на рівні користувача стоїть або 2, або 14 місяців, і після цього терміну дані зникають з досліджень і звітів воронки назавжди.
З цього тексту дізнаєшся, що саме регулює це одне налаштування в розділі Data Settings, чого воно взагалі не стосується, як безпечно змінити термін без втрати даних і як порахувати на своїх датах, з якого моменту твоє дослідження почне показувати пропуски. Наприкінці — як вести власну історію чисел незалежно від цього обмеження GA4.
Коли раптом зникають дані за минулий рік
Сезонність у роздрібній торгівлі, клініці чи сервісі зазвичай повторюється з року в рік, тож природне бажання — порівняти «цей вересень з минулим». У стандартних звітах GA4 таке порівняння працює без обмежень. Проблема виникає в дослідженнях (Explorations) і звітах воронки — там GA4 заглядає назад рівно настільки, наскільки дозволяє термін зберігання даних на рівні користувача: 2 або 14 місяців. Якщо колись хтось залишив налаштування на 2 місяцях, будь-яке дослідження старше цього терміну просто порожнє — не через збій вимірювання, а тому що дані вже видалено із серверів Analytics.
Це налаштування легко пропустити: його немає в щоденних звітах, воно лежить у технічній частині розділу «Адміністрування», яку відкривають один раз при впровадженні і потім рідко туди повертаються. Перш ніж підозрювати код вимірювання чи втрату даних, перевір саме це налаштування.
Що саме регулює налаштування зберігання даних
Налаштування розташоване в Адмініструванні: колонка «Ресурс» › Data Settings › Data Retention. Воно стосується даних, прив'язаних до ідентифікаторів користувача — файлів cookie, User-ID, рекламних ідентифікаторів.
Зберігання даних на рівні користувача та ключових подій
Для даних на рівні користувача (а разом з ними — даних ключових подій) доступні два значення: 2 місяці або 14 місяців. Для решти даних подій додаються варіанти, доступні лише в Google Analytics 360: 26, 38 і 50 місяців, як описано в документації Google про зберігання даних. Джерело не каже, яке значення стоїть за замовчуванням на новому ресурсі — замість того, щоб гадати, перевір безпосередньо, що стоїть саме в твоєму акаунті.
Винятки: вік, стать, інтереси, а також ресурси Large і XL
Дані про вік, стать та інтереси завжди обмежені жорстким терміном у 2 місяці, незалежно від того, що встановлено для решти даних. Той самий ліміт у 2 місяці автоматично застосовується до ресурсів, позначених як Large (стандартний) або XL (360) — тобто тих, що перевищили ліміти збору подій. Коли ресурс потрапляє в такий стан, GA4 спершу надсилає адміністраторам попереджувальний лист, а потім другий — про те, що термін зберігання скорочено і старі дані подій уже видалено безповоротно.
Чого це налаштування взагалі не стосується
Найчастіша помилка — вважати, що короткий термін зберігання стирає всю історію компанії. Насправді він зачіпає лише два типи звітів.
| Звіт / дані | Скорочується разом із налаштуванням зберігання | Завжди зберігає повну, незмінну історію |
|---|---|---|
| Дослідження (Explorations) | Так | Ні |
| Звіти воронки (funnel reports) | Так | Ні |
| Стандартні зведені звіти (включно з порівнянням періодів) | Ні | Так |
| Основні та додаткові параметри у стандартних звітах | Ні | Так |
Іншими словами, кількість сеансів, користувачів чи подій у стандартному місячному звіті лишається видимою безкінечно, навіть якщо на тому самому акаунті термін зберігання на рівні користувача стоїть на 2 місяцях. Втрачається лише можливість будувати власні, нестандартні зрізи та воронки за періодом, старшим за межу зберігання — і саме там перевіряють, чому клієнти не залишають запитів, або де саме люди виходять із процесу бронювання.
Порахуй це на своїх датах
Правило з документації Google просте: якщо діапазон дат у дослідженні довший за встановлений термін зберігання, дані за зайвий період просто недоступні. Сам постачальник наводить приклад: за терміну зберігання 14 місяців і діапазону дослідження 14 місяців плюс 1 день дані за цей зайвий день у звіті не показуються.
Твій приклад: сьогодні і межа зберігання
Підстав свою дату в те саме правило. Сьогодні 14.09.2026, термін зберігання стоїть на 14 місяцях. Межа: 14.09.2026 − 14 місяців = 14.07.2025. Якщо відкрити дослідження з діапазоном від 01.07.2025, дні з 1 по 13 липня 2025 року — це 13 днів — старші за межу і будуть порожніми; дані з'являються лише з 14.07.2025. Той самий розрахунок зроби для своєї дати відкриття звіту, перш ніж вирішити, що щось зламано.
Як безпечно змінити налаштування — крок за кроком
Для зміни терміну зберігання потрібна роль «Редактор» (Editor) на рівні ресурсу — ролі лише на читання недостатньо. Шлях в інтерфейсі: Адміністрування, колонка «Ресурс», Data Settings, Data Retention — спершу переконайся, що перебуваєш у потрібному акаунті й ресурсі. Там обери термін зберігання даних подій, увімкни чи вимкни скидання при новій активності і натисни «Зберегти».
- 01Зміна налаштування зберігання
- →0224 години на скасування
- →03завершення встановленого терміну
- →04щомісячне видалення даних
- →05коротша історія в дослідженнях
Після збереження зміна набирає чинності не одразу — Analytics чекає 24 години перед тим, як застосувати її, і за цей час зміну можна скасувати без жодних наслідків для даних. При скороченні терміну дані, старші за нову межу, видаляються під час найближчого щомісячного процесу очищення, а не того самого дня. При збільшенні терміну зміна стосується вже зібраних і ще не видалених даних — повернути те, що видалено раніше, неможливо.
Скидання при новій активності: що це означає для постійних клієнтів
Окремий перемикач, «Reset user data on new activity», вирішує, чи відлічується термін зберігання для конкретного ідентифікатора користувача від першого візиту, чи оновлюється з кожним новим. Скидання увімкнено: кожна нова сесія того самого користувача зсуває термін закінчення на повний період зберігання вперед, тож поки він повертається регулярно, його дані на рівні користувача не зникають. Скидання вимкнено: дані цього ідентифікатора видаляються після закінчення терміну зберігання незалежно від того, чи повертався користувач у цей час. Ця опція стосується лише даних на рівні користувача — на стандартні зведені звіти вона не впливає.
Для сервісної компанії з постійними клієнтами це відчутна різниця: GA4 завжди залишається джерелом поведінки на сайті в заданому часовому вікні, а не заміною картки клієнта. Якщо потрібна історія конкретної людини — що замовляла, коли була, про що розмовляли, — для цього потрібні Дані клієнтів, які об'єднують бронювання, розмови та замовлення в один профіль, незалежний від налаштувань зберігання GA4.
Довше — не завжди краще: RODO і мінімізація даних
Спокуса проста: виставити 14 місяців усюди і не думати про це. Але варто пам'ятати принцип зі ст. 5 RODO (GDPR — регламент ЄС про захист персональних даних), який наводить у своєму посібнику польське Управління із захисту персональних даних (UODO): дані мають бути адекватними, доречними та обмеженими тим, що необхідно для цілей їх обробки (мінімізація даних), і зберігатися не довше, ніж це необхідно (обмеження зберігання). Посібник UODO з RODO написаний для шкіл, але сам принцип ст. 5 загальний і поширюється на будь-якого оператора даних, включно з фірмою, що використовує GA4.
На практиці це одне рішення, яке варто записати, а не тримати в пам'яті: який термін зберігання реально потрібен для твоїх аналізів і чому саме такий. Якщо ти здебільшого працюєш зі стандартними звітами рік до року, довгий термін зберігання на рівні користувача може бути зайвим — ці звіти й так зберігають повну історію незалежно від налаштування.
Ролі, доступи і ліміт ключових подій
Змінити термін зберігання може людина з роллю «Редактор» на рівні ресурсу. Це інша роль, ніж та, що потрібна для керування самими користувачами: щоб додати чи змінити когось у списку доступу до акаунта чи ресурсу, потрібна роль «Адміністратор» на рівні акаунта або ресурсу; видалити обліковий запис користувача може лише адміністратор на рівні акаунта — так описано в довідці Google про керування користувачами. Ці дві ролі варто розділити всередині команди — інакше відпустка однієї людини блокує одразу обидва завдання.
Заразом варто перевірити ліміт ключових подій: у стандартному ресурсі ключовими можна позначити до 30 подій, у Google Analytics 360 — до 50, згідно з правилами ключових подій GA4. Подія purchase — ключова за замовчуванням; за увімкненої персоналізації реклами і підключеного Google Ads ключовими стають також, наприклад, add_to_cart і begin_checkout. Це окрема від зберігання даних тема — який саме ліміт діє для твого акаунта, варто перевірити окремо в панелі подій.
Зроби сьогодні — перевір і запиши рішення
- Зайди в Адміністрування › Data Settings › Data Retention і подивись, який термін стоїть зараз — не вважай заздалегідь, що це саме 14 місяців.
- Перевір, чи увімкнено скидання при новій активності, якщо важливо відстежувати користувачів, що повертаються, у дослідженнях.
- Запиши рішення і дату зміни у внутрішній нотатці — це доказ на випадок питання про відповідність принципу мінімізації.
- Раз на місяць вивантажуй із GA4 ті числа з досліджень і звітів воронки, які справді важливі, у свою таблицю — поки до них ще є доступ.
- Плануючи платні кампанії, перевір, чи вимірювання конверсій у Google Ads рахує заявки й бронювання, а не лише кліки — це залежить від якості вихідних даних, а не від терміну зберігання, але перевірити обидві речі разом варто.
Як це виглядає, коли цим керує система
Оскільки стандартні звіти GA4 і так зберігають повну історію, а межа є лише в досліджень, розумно переносити важливі числа за межі GA4, поки до них ще є доступ у нестандартному вигляді. Система Aura раз на місяць зберігає ключові числа з аналітики і CRM у власну історію компанії, тож порівняння рік до року більше не залежить від того, який термін зберігання стоїть зараз у GA4.
Виглядає це так: Аналітика та BI збирає дані з кількох каналів в одному місці і перетворює їх на цифри, які можна зіставити з виторгом, а Дашборди показують ліди, продажі, маркетинг і фінанси на одному екрані — для того, хто на їх основі справді ухвалює рішення. Кому зручніше отримувати зведення просто в пошту, а не відкривати панель, у яку ніхто не заглядає, — та сама інформація доступна як щотижневе зведення в послузі AI-звіти. Про те, як рахувати окупність маркетингу на власних даних, коли історія вже накопичена, варто прочитати окремо: окупність реклами ресторану за маржею, чи спрацювала акція — контрольна група або вартість одного бронювання за каналами — ці методи мають сенс лише за достатньо довгої власної історії чисел. Про те, які числа взагалі варто зводити щомісяця, ми писали окремо про автоматизацію звітності.
Часті питання
Якщо змінити термін зберігання з 2 на 14 місяців, чи повернуться старі, вже видалені дані?
Ні. Збільшення терміну стосується лише вже зібраних і ще не видалених даних. Дані, видалені раніше за коротшого терміну зберігання, не відновлюються — нове налаштування діє вперед, а не назад.
Чому в стандартному звіті видно дані старші за 14 місяців, а в дослідженні — вже ні?
Тому що це два різні механізми. Налаштування зберігання даних стосується лише досліджень і звітів воронки. Стандартні зведені звіти, включно з порівнянням періодів, зберігають повну історію незалежно від цього налаштування.
Хто може змінювати термін зберігання даних у GA4?
Людина з роллю «Редактор» на рівні ресурсу. Це інша роль, ніж право керувати списком користувачів, — для додавання чи видалення людей із доступом потрібна роль «Адміністратор» на рівні акаунта або ресурсу.
Чи можна зберігати дані про вік та інтереси теж 14 місяців?
Ні. Демографічні дані — вік, стать, інтереси — завжди обмежені жорстким терміном у 2 місяці, незалежно від того, яке значення встановлено для решти даних користувача.
Що станеться, якщо мій ресурс GA4 стане Large?
Термін зберігання даних на рівні подій автоматично скорочується до 2 місяців, а старі дані подій видаляються безповоротно. Перед цим GA4 надсилає адміністраторам попереджувальний лист, а після перевищення ліміту — другий, про саме скорочення.
Як перевірити, який саме термін зберігання встановлено зараз?
Зайди в Адміністрування, переконайся, що перебуваєш у потрібному ресурсі, і відкрий колонку «Ресурс» › Data Settings › Data Retention. Там видно поточне значення для даних подій і стан перемикача скидання при новій активності.