Logs API Яндекс Метрики: сырые данные по хитам и визитам без агрегации
Коротко: Logs API возвращает построчные данные — каждая строка это отдельный хит (просмотр) или визит, без агрегации по метрикам и измерениям, как в Reports API. Это нужно для глубокого собственного анализа, который невозможно получить через готовые отчёты, но требует больше ресурсов для хранения и обработки.
← Каталог: Метрика · Введение · Системы аналитики · Счётчик и код · Безопасность данных · Основы HTML/JS · Карта настройки · Типы целей · Цели · Автоцели и ecommerce · ЯТМ на практике · Тег Менеджер · Фильтры и операции · Доступы и роли · Вебвизор и карты · Карты и формы · Семплирование · Отчёты · Стандартные отчёты · Атрибуция · Сегментация · Офлайн-конверсии · ClientID и идентификаторы · Measurement Protocol · CRM и интеграции · Битрикс24 и Albato · Мессенджеры · Воронки · AppMetrica · API: введение · API: возможности · API: архитектура · API: окружение · API: отчёты на практике · DataLens · Чек-лист · Справка Яндекс Метрики
Содержание
- Logs API и Reports API: в чём разница
- Типы запросов: Hits и Visits
- Жизненный цикл запроса: создание, проверка, скачивание
- Выбор полей выгрузки
- Подготовка и загрузка в базу
Logs API и Reports API: в чём разница
| Параметр | Reports API | Logs API |
| Формат ответа | Агрегированные метрики по измерениям | Построчные данные по каждому хиту/визиту |
| Объём данных | Компактный, готовый к использованию | Большой, требует собственной агрегации |
| Типовая задача | Готовый отчёт (см. Reports API на практике) | Нестандартный анализ, свои метрики, ML-модели |
| Риск семплирования | Возможен на больших выборках | Не применяется — отдаются все строки |
Типы запросов: Hits и Visits
Logs API поддерживает два основных типа выгрузки: hits — каждая строка это отдельный просмотр страницы, и visits — каждая строка это отдельный визит целиком (с итоговыми параметрами: источник, устройство, достигнутые цели за визит). Выбор зависит от того, нужен ли анализ на уровне отдельных просмотров или на уровне визита как единицы.
Жизненный цикл запроса: создание, проверка, скачивание
Запрос к Logs API работает не как мгновенный ответ, а как асинхронная задача: сначала запрос создаётся с указанием полей и периода, затем нужно периодически проверять его статус (готовится / готов / ошибка), и только после готовности скачивать результат — часто по частям, если данных много.
Коротко: Не пытайтесь скачивать результат сразу после создания запроса — формирование выгрузки за большой период может занимать заметное время; предусмотрите в скрипте цикл ожидания со статус-проверкой.
Выбор полей выгрузки
При создании запроса нужно явно указать список полей (например, дата визита, источник, устройство, ClientID, достигнутые цели) — чем шире список, тем больше объём выгрузки. Разумная практика — выгружать только те поля, которые реально нужны для конкретной задачи анализа, а не «все подряд на будущее», чтобы не раздувать объём хранения и время обработки.
Подготовка и загрузка в базу
Выгруженные построчные данные обычно требуют предобработки перед загрузкой в СУБД (см. Выбор окружения): преобразование форматов дат, разбор составных полей (например, списка целей за визит), удаление технических строк ботов, если фильтры в самой Метрике не покрывают весь необходимый период. Для действительно больших объёмов (миллионы хитов в день) на этапе хранения оправдан переход на колоночную СУБД типа ClickHouse вместо обычной реляционной базы.
Комментарий эксперта
|
Константин Горбунов Logs API беру в проект только тогда, когда готовых отчётов и Reports API объективно не хватает — например, для собственной модели атрибуции. Для 90% регулярных задач построчные данные — избыточная сложность. |
Частые вопросы
Logs API можно использовать вместо Reports API для типовых отчётов?
Технически можно посчитать любую агрегацию самостоятельно из построчных данных, но для типовых отчётов это избыточно по ресурсам — Reports API уже отдаёт готовую агрегацию быстрее и дешевле.
Есть ли ограничение на глубину истории данных для Logs API?
Да, доступный период ограничен политикой хранения данных Метрики; для длительного хранения истории данные нужно регулярно выгружать в свою базу, а не рассчитывать на бесконечный доступ через API к старым периодам.
Нужно ли фильтровать ботов дополнительно при работе с Logs API?
Стоит проверить, покрывают ли уже настроенные в счётчике фильтры (см. Фильтры и операции) весь нужный период; для ретроспективного анализа старых данных может потребоваться дополнительная фильтрация вручную на уровне выгруженных строк.
См. также: Reports API на практике, DataLens.
Материал подготовлен редакцией AdPump совместно со специалистами Monster Context (m-context.ru) на основе практики ведения аккаунтов Яндекс Директа и обновлений Яндекс Метрики 2026 года.
← Каталог: Метрика · Введение · Системы аналитики · Счётчик и код · Безопасность данных · Основы HTML/JS · Карта настройки · Типы целей · Цели · Автоцели и ecommerce · ЯТМ на практике · Тег Менеджер · Фильтры и операции · Доступы и роли · Вебвизор и карты · Карты и формы · Семплирование · Отчёты · Стандартные отчёты · Атрибуция · Сегментация · Офлайн-конверсии · ClientID и идентификаторы · Measurement Protocol · CRM и интеграции · Битрикс24 и Albato · Мессенджеры · Воронки · AppMetrica · API: введение · API: возможности · API: архитектура · API: окружение · API: отчёты на практике · DataLens · Чек-лист