Logs API Яндекс Метрики: выгрузка сырых данных для сквозной аналитики
Что такое Logs API?
Программный интерфейс для выгрузки из Яндекс Метрики неагрегированных логов о визитах и просмотрах в формате TSV. Инструмент используется для обхода лимитов веб-интерфейса, ручной настройки сложных моделей атрибуции и интеграции данных с внутренними CRM-системами и внешними СУБД (ClickHouse). Базовая квота на один счетчик составляет 10 ГБ, глубина одного запроса ограничена 1 годом.
Чем сырые данные отличаются от агрегированных
Стандартные отчеты в интерфейсе Яндекс Метрики или выгрузки через обычный API отчетов показывают нам агрегированные данные. Это значит, что система уже произвела математические вычисления для определенных групп визитов. Например, показатель «время на сайте» или «глубина просмотра» рассчитывается как среднее значение для всех переходов из конкретного источника трафика, мужчин определенного возраста или пользователей с мобильных устройств.
Работать с агрегированными метриками удобно, когда нужно быстро оценить общую эффективность каналов маркетинга и сделать верхнеуровневые выводы. Однако за этой простотой скрывается невозможность заглянуть внутрь каждого отдельного сеанса. Вы видите только итоговую сумму или среднее арифметическое.
Сырые данные (логи) — это фундамент, на котором строятся все эти расчеты. Они представляют собой массив строк, где каждая запись — это детальная хроника отдельного визита или просмотра. Таблица логов не содержит готовых выводов, но хранит колоссальный объем сопутствующей технической и коммерческой информации, переданной из Метрики.
Каждая строчка сырых данных дополняется полезными метаданными: подробными параметрами Директа, разметкой электронной коммерции (e-commerce), географией пользователя с точностью до города, а также техническими характеристиками (модель смартфона, версия браузера, разрешение экрана). Logs API позволяет забрать эти массивы данных в первозданном виде для их дальнейшего глубокого анализа на вашей стороне.
- Готовые средние показатели и суммы
- Рассчитаны алгоритмами на стороне Яндекса
- Жестко привязаны к стандартным моделям
- Построчные записи о каждом клике и визите
- Максимальная глубина технических параметров
- Основа для построения кастомных систем
Бизнес-сценарии: зачем компании сырые логи?
Переход на работу с Logs API оправдан, когда стандартных отчетов Метрики становится недостаточно для принятия управленческих решений. Обладая полным массивом неагрегированных логов, компания может реализовать три критически важных аналитических сценария, напрямую влияющих на окупаемость маркетинговых инвестиций (ROMI).
1. Построение кастомных моделей атрибуции. Коробочные решения Яндекса предлагают три классические модели: по первому, последнему и последнему значимому клику. Однако в B2B или сферах с длинным циклом сделки путь клиента состоит из десятков касаний. Сырые данные позволяют настроить любую сложную модель: линейную, с учетом давности взаимодействий (Time Decay) или на основе ассоциативных конверсий. Это помогает точно оценить промежуточный вклад медийной или таргетированной рекламы, даже если она находилась в самом начале воронки.
2. Сквозная аналитика и интеграция с CRM. Объединяя уникальные идентификаторы пользователей (ClientID) из Метрики с внутренними данными CRM-системы, бизнес получает прозрачный трекинг: от первого клика по рекламному объявлению до повторных продаж и LTV. Вы сможете склеивать онлайн-поведение на сайте с офлайн-отгрузками, возвратами и звонками из колл-трекинга на уровне единой базы данных.
3. Проектирование многошаговых воронок продаж. Анализ построчных логов дает возможность детально изучить микроконверсии и поведенческие паттерны. Вы сможете с точностью до секунды определить, сколько времени проходит между просмотром карточки товара и оплатой, какие цепочки категорий посещают самые лояльные клиенты и на каком именно этапе оформления заказа происходит наибольший отток пользователей.
Жесткие технические ограничения Logs API: о чем нужно знать инженеру
Переход на сырые данные требует четкого понимания лимитов инфраструктуры Яндекса. Игнорирование архитектурных правил Logs API приведет к систематическим блокировкам запросов и потере актуальной аналитики. Рассмотрим критические лимиты, зафиксированные в официальной документации разработчиков.
Лимит хранилища в 10 ГБ. На один счетчик Яндекс Метрики выделяется фиксированная квота — 10 Гигабайт. В этот объем суммарно входят все подготовленные к скачиванию файлы логов, а также архивы, которые пользователь еще не удалил из временного облачного хранилища Яндекса. Если вы превысите этот порог, Logs API заблокирует создание новых потоков выгрузки. Решение — строгая автоматизация: ваш ETL-скрипт должен отправить запрос, скачать файл в формате TSV, развернуть его в локальной БД и немедленно послать команду на удаление лог-файла с серверов Яндекса для освобождения квоты.
Временные рамки и глубина запросов. В одном POST-запросе к API невозможно указать временной интервал, превышающий 1 календарный год. Если вам необходима историческая ретроспектива за 3 года для анализа сезонных когорт, придется последовательно сформировать три отдельных запроса. Кроме того, статистика за текущие сутки недоступна: Метрика защищает точность выгрузки, блокируя экспорт незавершенных сессий. Согласно техническим регламентам, около 99% визитов окончательно закрываются и обогащаются данными в течение 3 дней с момента старта сеанса. Для построения стабильных витрин данных рекомендуется настраивать регулярное регламентное задание на выгрузку со смещением «минус 1 день» от текущей даты.
Ограничение полей ввода. Параметр fields, в котором перечисляются все необходимые идентификаторы визитов и просмотров, имеет жесткий лимит — не более 3000 символов в строке запроса. Избыточный выбор сотен системных полей «на всякий случай» вызовет синтаксическую ошибку API.
Проблема расхождения данных: почему логи не сходятся с веб-интерфейсом
Самый частый вопрос, который возникает у веб-аналитиков при первом сравнении сырых логов и готовых отчетов в браузере: «Почему итоговые цифры доходности не совпадают до копейки?». Это не баг трекинга Яндекса, а архитектурная особенность обработки дробных чисел в базах данных.
Для ускорения расчетов миллиардов строк в веб-интерфейсе Метрики применяются специализированные агрегационные алгоритмы. При этом все финансовые показатели с плавающей точкой (дробная часть) на аппаратном уровне обрабатываются по международному стандарту IEEE 754. Данный стандарт допускает микроскопические математические погрешности при выполнении базовых арифметических операций над округленными дробными числами.
Чтобы свести погрешность к абсолютному минимуму и сохранить исходную точность коммерческих метрик при передаче через Logs API, инженеры Яндекса используют метод принудительного масштабирования. Числа во многих финансовых полях базы данных предварительно умножаются на фиксированные коэффициенты, превращаясь в безопасные для вычислений целые числа (Integers). При извлечении логов аналитик обязан на своей стороне произвести обратную операцию деления на соответствующий коэффициент.
Если выгрузить данные и забыть восстановить исходный масштаб, аналитика e-commerce будет искажена в миллионы раз. Запомните базовые коэффициенты системных полей Метрики: для параметра суммарной стоимости заказа (ym:s:purchaseRevenue) коэффициент равен 1. Но для цены конкретной цели (ym:s:goalsPrice) множитель составляет 1 000, а для стоимости товаров (ym:s:productsPrice) и цен просмотров продуктов (ym:s:impressionsProductPrice) масштаб увеличен в 1 000 000 раз.
| Системное поле в API | Множитель | Обработка в ClickHouse |
|---|---|---|
| ym:s:purchaseRevenue | 1 | Без изменений |
| ym:s:goalsPrice | 1 000 | Разделить на 1 000 |
| ym:s:productsPrice | 1 000 000 | Разделить на 1 000 000 |
Технический стек: автоматизация выгрузки и связка с ClickHouse
Сырые логи выгружаются из Метрики в текстовом стандартном формате TSV (Tab-Separated Values). Пытаться открыть такие файлы в Excel бессмысленно — объемы данных измеряются миллионами строк. Промышленным стандартом для хранения и быстрой аналитической обработки логов является столбцовая СУБД ClickHouse.
ClickHouse — это бесплатное опенсорсное решение с высокой степенью сжатия данных, разработанное специально для обработки аналитических запросов в реальном времени. Оно идеально совместимо со структурой Logs API. Команда Яндекса предоставляет готовый официальный скрипт на Python, который можно развернуть на вашем сервере по cron-расписанию. Скрипт автоматически опрашивает API Метрики, проверяет статус готовности логов за прошедший день, скачивает файлы частями и без потерь импортирует их непосредственно в таблицы ClickHouse.
Что делать, если базового лимита хранилища в 10 ГБ критически не хватает для крупного e-commerce проекта? В этом случае компания может масштабировать инфраструктуру, подключив платный пакет расширения Яндекс Метрика Про. Это корпоративное решение снимает базовые квоты на объемы выгружаемых лог-файлов, предоставляет повышенные лимиты на суточное количество API-запросов и гарантирует приоритетную скорость генерации тяжелых неагрегированных выборок на стороне серверов Яндекса.
Итоги и чек-лист для быстрого старта
Выгрузка сырых данных через Logs API Яндекс Метрики — это необходимый шаг для любой компании, которая переросла базовые возможности веб-интерфейса и стремится к созданию прозрачной сквозной аналитики. Несмотря на строгие технические лимиты и нюансы с округлением чисел по стандарту IEEE 754, связка логов с СУБД ClickHouse дает полную независимость от встроенных моделей атрибуции и позволяет склеивать поведение пользователей на сайте с реальной выручкой из CRM.
Для успешного внедрения Logs API используйте следующий чек-лист:
fields — она строго ограничена 3000 символов.