Нужен доступ к счётчику и хранилище, куда складывать данные. Мы настраиваем регулярную выгрузку визитов, просмотров и событий в ClickHouse — ваш или развёрнутый нами — и дальше следим, чтобы она не прерывалась.
Резервирование данных
Резервная копия данных Яндекс.Метрики
Настраиваем регулярный бэкап сырых данных Метрики — визитов, просмотров и событий — в ClickHouse за пределами инфраструктуры Яндекса. Сервис недоступен, а история остаётся у вас.
Что попадает в бэкап Метрики
Копируем построчные данные, а не готовые отчёты. Разница принципиальна: из сырых данных собирается любой разрез, из готового отчёта — только он сам.
Сырые визиты и просмотры
Не агрегаты из интерфейса, а построчные данные: визиты, хиты, параметры. По ним можно пересобрать любой отчёт задним числом, в том числе тот, который не догадались настроить вовремя.
Цели и события
Достижения целей и пользовательские события — вместе с идентификаторами, по которым они связываются с визитами и заказами из CRM.
История на вашу глубину
Сервис хранит данные по своим правилам и может их менять. В копии глубина истории определяется вами, а не настройками источника.
Регулярное обновление
Копия пополняется автоматически по расписанию. Мы следим за выгрузками: когда меняется API — наблюдаем и катим исправление на своей стороне.
Как это делается
Как сделать бэкап Яндекс.Метрики
Коротко: сырые данные Метрика отдаёт через Logs API — выгрузка заказывается на период, сервис её готовит, дальше её забирают частями. На этом простая часть заканчивается.
За один запрос можно взять ограниченный объём, поэтому историю режут на куски и выкачивают последовательно. На больших счётчиках первая заливка идёт не часы, а дни — и всё это время процесс нужно вести, а не запустить и забыть.
Дальше начинается то, из-за чего разовый скрипт не работает: выгрузку надо повторять по расписанию, помнить, что уже забрано, переживать ошибки и повторять попытки. Когда меняется API — всё ломается молча, и заметить это можно сильно позже, чем хотелось бы.
- Доступ к данным
- Logs API Сырые визиты и хиты, не агрегаты
- Объём
- Кратно больше Построчные данные против сводок в интерфейсе
- Первая заливка
- Частями Историю режут на куски и качают последовательно
- Регулярность
- Коннектор, не скрипт Расписание, состояние, повторные попытки
- Главный риск
- Тихая поломка Выгрузка встала — узнали через месяц
Это можно собрать самостоятельно — вопрос в том, кто будет вести процесс первые недели и следить за ним потом. Мы делали такие выгрузки многократно и держим их живыми на своей стороне: если API меняется, чинить будем мы, а не ваша команда.
Обсудить бэкап с нами Хранение
Копия лежит в другом контуре
Смысл резервной копии теряется, если она лежит там же, где оригинал. Поэтому хранилище под копии не связано с инфраструктурой Яндекса — а для критичных данных разносится между разными провайдерами и дата-центрами.
Наша инфраструктура распределена по трём зонам доступности: во время крупного сбоя у облачного провайдера сбор данных по клиентам не прерывался.
- Хранилище
- ClickHouse Ваш или развёрнутый нами
- Контур
- Вне инфраструктуры Яндекса Источник и копия не падают вместе
- Распределение
- По запросу Несколько провайдеров и дата-центров
- Доступ
- SQL по своим данным Без интерфейса источника
- Отчёты
- Строятся поверх копии Витрины и дашборды на тех же данных
Как начать
Со стороны вашей команды нужен только доступ к счётчику. Остальное — наша работа, включая присмотр за выгрузками.
- 01
Доступ к счётчику
Гостевой доступ или сервисный аккаунт
1 день - 02
Согласуем состав выгрузки
Таблицы, поля, глубина истории
1–3 дня - 03
Первая заливка истории
Переносим накопленное
по объёму - 04
Регулярная копия
Расписание и контроль полноты
постоянно
Частые вопросы
Если вашего вопроса здесь нет — обсудим на звонке.
Выгруженный отчёт — это готовый срез, из него нельзя собрать другой разрез. Резервная копия хранит построчные данные, поэтому любой отчёт пересобирается задним числом, включая тот, о котором вы тогда не думали.
В ClickHouse: либо в вашем, если он уже есть, либо в хранилище, которое мы разворачиваем. Наша инфраструктура не связана с инфраструктурой Яндекса, поэтому недоступность Метрики не мешает работать с копией. По запросу разносим копии между разными провайдерами.
Копия остаётся доступной: она лежит в отдельном контуре и не зависит от работоспособности источника. Новые данные за время недоступности догружаются, когда сервис возвращается.
Да, это обычное аналитическое хранилище. Поверх копии собираются витрины и дашборды — те же, что в Performance-отчёте DataGo. Так копия работает каждый день, а не лежит мёртвым грузом.
Технически близко, но задача другая. Экспорт мы продаём как способ получить данные для сквозной аналитики. Здесь цель — сохранность: копия вне контура источника, со своей глубиной истории и контролем полноты.
Сделаем копию данных вашей Метрики
Расскажите, какая глубина истории нужна и есть ли своё хранилище — предложим схему и посчитаем смету под объём данных.