Срок хранения данных GA4: почему пропала история в исследованиях и что настроить

В обычном отчёте GA4 видны прошлогодние показатели, а исследование за тот же период пустое или позволяет анализировать только последние месяцы. Это не обязательно означает, что счётчик перестал работать. Срок хранения данных GA4 ограничивает доступность определённых подробных данных, поэтому разные разделы одного ресурса могут показывать разную глубину истории.

Чтобы разобраться, сначала определите, чего именно не хватает: готовых итогов, событий конкретного периода, последовательностей действий или параметров, которые раньше не собирались. Затем проверьте настройку хранения и существующие выгрузки. Увеличение срока помогает сохранить ещё доступные данные, но не возвращает уже удалённую историю.

Какая история ограничена сроком хранения

Сводный показатель и возможность заново исследовать поведение — разные вещи. Допустим, отчёт показывает число покупок за прошлый сезон. Из одного этого итога нельзя восстановить, какие посетители сначала открыли доставку, потом вернулись к товару и только затем купили. Для такого вопроса нужны данные о событиях и связях между ними.

В правилах хранения Google Analytics указано: настройка не распространяется на стандартные агрегированные отчёты, но влияет на исследования и отчёты-воронки. Поэтому наличие старых итогов в разделе отчётов совместимо с отсутствием детализации в Explorations. Второй параметр или сравнение в стандартном отчёте сами по себе не превращают его в полный архив событий.

Сформулируйте запрос на восстановление конкретно. «Нужна история за год» слишком неопределённо. Полезнее написать: «Нужно сравнить последовательность поиска товара и покупки по устройствам за две недели прошлого ноября». Такая постановка сразу показывает, хватит ли сохранённой таблицы или потребуется подробная выгрузка с событиями.

Не подменяйте отсутствие данных нулём. Пустая историческая часть исследования не доказывает, что люди не посещали сайт или не совершали действия.

Что проверить до вывода об удалении

Начните с простого исследования за недавний завершённый период. Выберите один известный тип события, уберите сложные сегменты и дополнительные условия. Если свежие данные появились, расширяйте диапазон и добавляйте ограничения по одному. Зафиксируйте, при каком изменении результат становится пустым.

Google описывает различия отчётов и исследований: на результат влияют доступные поля, фильтры, сегменты, пороги конфиденциальности и время обработки. Например, условие в исследовании может учитывать регистр. Отсутствие небольшой группы или недавних данных нельзя автоматически объяснять retention.

Наблюдение	Первая проверка	Что сохранить
Старый период недоступен целиком	Ресурс, срок хранения, границы дат	Настройку и точный диапазон
Нет только отдельных строк	Фильтры и индикаторы качества данных	Условия отбора и предупреждения
Вчерашние данные отличаются	Завершённость обработки	Время выполнения проверки
Параметр пуст во всех старых датах	Когда начались его сбор и использование	Историю внедрения параметра

Проверьте идентификатор ресурса, а не только его похожее название. После смены подрядчика или создания нового ресурса команда иногда сравнивает разные наборы данных. В журнале проверки полезно сохранять ссылку на исследование, его условия и ожидаемый результат: это делает проблему воспроизводимой.

Какие сроки доступны и где есть исключения

Для стандартного GA4 доступны варианты хранения событий 2 и 14 месяцев. В Analytics 360 предусмотрены также 26, 38 и 50 месяцев; различия приведены в официальной таблице ограничений редакций. Возможность выбрать больший срок зависит от типа данных и ресурса, поэтому число 50 нельзя применять ко всему содержимому GA4.

Для данных уровня пользователя и ключевых событий справка указывает варианты 2 и 14 месяцев. Для возраста, пола и интересов действует двухмесячное ограничение независимо от выбранного срока. При переходе стандартного ресурса в категорию Large или ресурса 360 в XL хранение событий автоматически сокращается до двух месяцев; администраторам направляются уведомления.

Если задача — сравнивать сезоны, сначала выпишите необходимую глубину анализа. Для квартального разбора двух месяцев может не хватить; для нескольких прошлых лет не хватит и четырнадцати. Максимальный доступный переключатель не заменяет план хранения под конкретные вопросы.

Увеличивать срок следует осознанно: определите, кому нужны подробные данные, какие события действительно полезны и как долго они должны оставаться доступными. Не включайте лишние события только ради будущего архива. Изменение количества собираемых действий влияет и на объём, и на понятность последующего анализа.

Когда новая настройка начнёт действовать

После изменения срока GA4 ждёт 24 часа перед применением; в этот интервал изменение можно отменить. Данные с истёкшим сроком удаляются ежемесячно. Увеличенный период распространяется на уже собранные данные, которые ещё не удалены. Уменьшение может привести к удалению затронутой истории во время следующей месячной обработки.

Представим условный ресурс, где часть прошлогодних событий уже удалена. Владелец выбирает более длительное хранение. Такая настройка меняет дальнейшую политику для сохранившегося массива; она не создаёт заново отсутствующие записи. Не обещайте руководителю, что история появится после ожидания суток: ожидание относится к применению изменения, а не к восстановлению.

Не рассчитывайте точную дату исчезновения каждой строки по приблизительной формуле «два месяца равно шестидесяти дням». Календарные месяцы и периодическая обработка — разные детали механизма. Для бизнес-процесса безопаснее заранее сохранять необходимые результаты и проверять фактическую доступность выбранных дат.

При сокращении срока сначала согласуйте последствия с владельцами отчётов. Сохраните нужные доступные выборки и задокументируйте решение. Это особенно важно, если другой сотрудник готовит сезонный анализ и ещё не знает, что его рабочий диапазон скоро изменится.

Что означает сброс срока при новой активности

Опция Reset user data on new activity относится к данным уровня пользователя: новая активность обновляет срок хранения пользовательского идентификатора. Она не продлевает срок хранения всех старых событий этого пользователя. Поэтому регулярные возвращения посетителя не превращают его давние действия в бессрочную историю для исследований.

Разделяйте два вопроса: «Можем ли мы продолжать работать с пользовательскими данными?» и «Сохранилась ли подробная последовательность действий за нужную дату?». Состояние одного переключателя не отвечает сразу на оба. В техническом задании фиксируйте значение опции отдельно от периода хранения событий.

Для проверки процесса не нужен эксперимент с настоящими клиентами на протяжении месяцев. Достаточно правильно описать ожидаемое поведение, зафиксировать параметры ресурса и проверить, какие данные доступны в выбранных диапазонах. Если подрядчик обещает сохранить весь путь пользователя благодаря одному переключателю сброса, попросите указать, где хранится архив событий и как из него получить прошлый период.

Такой вопрос быстро отделяет настройку GA4 от отдельной задачи хранения. Он также помогает избежать ситуации, когда команда считает возвращающихся клиентов доказательством сохранности старой детализации.

Как изменить настройку с проверяемым результатом

Откройте администрирование нужного ресурса и найдите Data retention в группе настроек сбора и изменения данных. Этот путь и двухмесячное значение по умолчанию приведены в руководстве по исследованиям. Для изменения настройки нужна роль редактора или выше. Название раздела зависит от языка интерфейса, поэтому ориентируйтесь на сам параметр хранения.

1. Запишите идентификатор ресурса, текущий период и состояние сброса пользовательских данных.
2. Согласуйте требуемую глубину анализа и выбранное значение.
3. Сохраните настройку, время изменения и имя ответственного.
4. После интервала применения повторно проверьте значение в том же ресурсе.
5. Проверьте исследование на диапазоне с заведомо сохранившимися данными.

Проверка последнего пункта не должна опираться только на старый период, который уже исчез. Иначе правильное изменение ошибочно признают неработающим. Подтверждением служат сохранённая настройка и корректная работа с доступными данными, а не появление любой запрошенной истории.

Если настроек несколько, меняйте их последовательно. Одновременная смена фильтров, периода хранения и определения событий затрудняет объяснение различий. Для передачи проекта другому подрядчику достаточно короткой записи: что изменено, зачем, какие данные доступны и где находится независимая выгрузка.

Почему сохранённое исследование не заменяет архив

Сохранённое исследование удобно как повторяемый способ анализа: в нём остаются выбранные поля, вкладки и условия. Но рассчитывать на него как на неизменяемую копию всех использованных событий нельзя. Когда исходная детализация становится недоступной, старое название исследования не обеспечивает возможность заново получить прежнюю выборку.

Для важных разовых выводов экспортируйте результат. GA4 предлагает для исследований, в частности, CSV, TSV, Google Sheets и PDF. Табличный экспорт содержит данные выбранной визуализации, а PDF имеет ограничения отображения. Ни один такой файл не следует автоматически считать полной событийной выгрузкой ресурса.

Рядом с файлом сохраните период, часовой пояс, определения показателей, сегменты и дату формирования. Запишите, были ли предупреждения о выборке или порогах. Без этого даже хорошо оформленная таблица через полгода может стать непонятной: сотрудники не смогут определить, почему её итог отличается от нового запроса.

Практичный минимум для отчёта по релизу — отдельный файл результата и короткое описание расчёта. Если впоследствии потребуется другой разрез, сохранённой сводки может не хватить. Такие будущие вопросы нужно учитывать при выборе подробного экспорта заранее.

Полезно сохранять и версию определения события. Например, раньше событие покупки отправлялось после подтверждения заказа, а после доработки — только после оплаты. Даже полностью сохранённые данные этих периодов нельзя сравнивать как одну неизменную метрику без поправки на новый смысл. В архивном описании отметьте дату изменения и правило подсчёта. Это занимает несколько строк, но предотвращает ситуацию, когда технически сохранённая история приводит к неверному бизнес-выводу. Сам факт наличия файла ещё не подтверждает сопоставимость периодов.

Как экспорт помогает сохранить историю и где заканчивается backfill

BigQuery Export передаёт данные событий в отдельное хранилище, где команда может строить собственные запросы. Это другой уровень контроля: вы отвечаете за доступ, срок хранения, обработку и стоимость. Данные экспорта также могут отличаться от интерфейса GA4, поэтому совпадение всех цифр без согласования методики не гарантируется.

Обычный экспорт событий необходимо подключать заранее. В документации Google Cloud об интеграции GA4 прямо отмечено: BigQuery Export начинается с момента настройки и не выполняет исторический backfill. Подключение после утраты детализации не создаёт таблицы со всеми старыми событиями.

При этом существует отдельный коннектор GA4 в BigQuery Data Transfer Service. Он получает отчётные данные через Data API и поддерживает backfill в пределах доступности источника. Это полезно для переноса доступных исторических отчётов, но не равнозначно восстановлению исходного потока событий.

Для этого коннектора действует отдельное ограничение: согласно журналу изменений BigQuery Data Transfer Service, с 1 июня 2026 года backfill ограничен последними 37 месяцами. Более старый запрос может вернуть неполные либо пустые данные и перезаписать ими существующий раздел таблицы. Перед повторной выгрузкой проверьте даты и сохраните независимую копию нужных разделов; не направляйте backfill на период старше этой границы. Это ограничение повторной загрузки не задаёт срок жизни уже сохранённого архива.

Когда вам предлагают «вернуть историю через API», уточните состав результата: агрегаты или отдельные события, доступные параметры, период, ограничения и источник. Попросите показать контрольную выборку. Таблица с прошлогодним числом покупок может решить отчётную задачу, но не восстановит неизвестный порядок действий посетителей.

Как убедиться, что отдельная выгрузка действительно сохраняется

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

Составьте перечень обязательных событий и сверяйте его с экспортируемым набором. Если команда исключила нужное действие, ежедневные таблицы могут исправно создаваться, но ответить на будущий вопрос будет невозможно. Для стандартного ресурса также учитывайте лимит ежедневного экспорта: до миллиона событий в день.

У BigQuery есть собственное управление сроком жизни таблиц. Истечение этого срока удаляет таблицу вместе с данными. Проверьте настройки набора данных и отдельных таблиц, чтобы архив не исчезал раньше согласованного горизонта. Настройка хранения в GA4 не заменяет эту проверку.

В рабочий контроль включите наличие ожидаемых дат, количество событий по типам, задержку поступления и доступность старых контрольных периодов. Сравнивайте результаты с обычным диапазоном проекта, учитывая выходные и изменения трафика. Один универсальный порог «должно быть больше тысячи строк» не подходит сайтам разного размера.

Учебный пример: что можно восстановить, а что остаётся неизвестным

Представим магазин, который хочет разобрать прошлогоднюю акцию. В сохранённой согласованной таблице есть 1000 сеансов и 40 сеансов с покупкой. Подробные события того периода уже удалены, а экспорт тогда не работал. За новую сопоставимую акцию таблица содержит 1200 сеансов и 60 сеансов с покупкой.

По этим данным доля сеансов с покупкой выросла с 40 / 1000 = 4% до 60 / 1200 = 5%. Разница составляет один процентный пункт; относительное увеличение доли — 25%. Этот расчёт возможен, потому что сохранены одинаково определённые числитель и знаменатель.

Но определить, на каком шаге оформления произошло улучшение, из этих двух итогов нельзя. Неизвестные переходы нельзя заменить придуманными значениями. Даже сам рост доли не доказывает, что его вызвал новый дизайн: состав аудитории, ассортимент и условия акции могли отличаться.

После подключения экспорта команда проверяет семь ожидаемых завершённых дат и находит таблицы только за шесть. Покрытие дат равно 6 / 7, примерно 85,7%. Это показатель наличия дневных таблиц, а не процент сохранённых событий: объём пропущенного дня может быть другим. Даже семь найденных таблиц требуют проверки содержимого.

Результат разбора оформляют честно: какие итоги подтверждены, каких подробностей нет, с какой даты начался новый архив и какие действия предотвращают повторение пробела.

Какие доказательства запросить после исправления

Попросите подрядчика передать результат в форме, которую другой специалист сможет повторить. Нужны идентификатор ресурса, выбранная настройка, дата её изменения и контрольный запрос с понятными условиями. Скриншот переключателя подтверждает только конфигурацию; наличие выгрузки и глубину истории проверяют отдельно.

Для архива задайте три контрольных диапазона: недавний завершённый день, период после начала экспорта и старый период около согласованной границы хранения. Исполнитель должен показать, какие таблицы доступны, какие события в них присутствуют и где зафиксированы исключения. Проверку доступа проводите под обычной рабочей ролью аналитика: результат, видимый только владельцу проекта, может оказаться недоступным команде в нужный момент.

Для уже утраченного периода составьте перечень независимых источников. Сохранённый отчёт может подтвердить агрегаты, CRM — зарегистрированные заказы, журнал приложения — отдельные технические действия. Эти источники полезны для собственного анализа, но не являются точной копией удалённых событий GA4. Не загружайте реконструированные записи как будто они были первоначально собраны счётчиком: происхождение и ограничения восстановленных итогов должны оставаться видимыми.

Завершайте задачу после демонстрации контрольного результата и назначения дальнейшего владельца процесса. Формулировка «включили более длительное хранение» описывает только одно действие. Для бизнеса важнее понимать, на какие вопросы теперь можно ответить, какие остаются без данных и когда следующая проверка обнаружит пропуск экспорта.

Как закрепить политику хранения в работе команды

Полезная политика умещается в небольшую таблицу. Она связывает настройку с бизнес-вопросом и назначает владельца проверки, чтобы история не зависела от памяти одного аналитика.

Что фиксировать	Практический пример записи
Назначение истории	Сравнение сезонных воронок и результатов релизов
Срок и область действия	Отдельно настройки GA4 и отдельного хранилища
Обязательные события	Утверждённый список с определениями и владельцем
Проверка выгрузки	Даты, состав, задержка, старый контрольный период
Изменения	Кто согласует сокращение срока и исключение событий

После обнаружения пропажи сначала сохраните доступные результаты, затем установите границы утраты и проверьте независимые копии. В отчёте различайте «данные удалены», «данные ещё доступны в другом представлении» и «сбор этого параметра не был настроен». Эти ситуации требуют разных решений.

При смене подрядчика передавайте этот документ вместе с доступами. Новый специалист должен знать владельца архива, обязательные события, согласованный срок и расположение контрольных отчётов, чтобы продолжить проверку без повторного расследования всей истории проекта.

Для внешнего контроля HTTP-доступности сайта подключите SiteGuard, а сохранность истории GA4 и регулярность экспорта проверяйте отдельным регламентом аналитики.