Logs API Яндекс Метрики: сырые данные по хитам и визитам без агрегации

В отличие от Reports API, Logs API отдаёт необработанные данные по каждому хиту и визиту отдельно — разбираем, для каких задач это нужно, как устроен запрос и что важно учесть при загрузке в базу.

Коротко: Logs API возвращает построчные данные — каждая строка это отдельный хит (просмотр) или визит, без агрегации по метрикам и измерениям, как в Reports API. Это нужно для глубокого собственного анализа, который невозможно получить через готовые отчёты, но требует больше ресурсов для хранения и обработки.

← Каталог: Метрика · Введение · Системы аналитики · Счётчик и код · Безопасность данных · Основы HTML/JS · Карта настройки · Типы целей · Цели · Автоцели и ecommerce · ЯТМ на практике · Тег Менеджер · Фильтры и операции · Доступы и роли · Вебвизор и карты · Карты и формы · Семплирование · Отчёты · Стандартные отчёты · Атрибуция · Сегментация · Офлайн-конверсии · ClientID и идентификаторы · Measurement Protocol · CRM и интеграции · Битрикс24 и Albato · Мессенджеры · Воронки · AppMetrica · API: введение · API: возможности · API: архитектура · API: окружение · API: отчёты на практике · DataLens · Чек-лист · Справка Яндекс Метрики


Содержание

  1. Logs API и Reports API: в чём разница
  2. Типы запросов: Hits и Visits
  3. Жизненный цикл запроса: создание, проверка, скачивание
  4. Выбор полей выгрузки
  5. Подготовка и загрузка в базу

Logs API и Reports API: в чём разница

ПараметрReports APILogs API
Формат ответаАгрегированные метрики по измерениямПострочные данные по каждому хиту/визиту
Объём данныхКомпактный, готовый к использованиюБольшой, требует собственной агрегации
Типовая задачаГотовый отчёт (см. Reports API на практике)Нестандартный анализ, свои метрики, ML-модели
Риск семплированияВозможен на больших выборкахНе применяется — отдаются все строки

Типы запросов: Hits и Visits

Logs API поддерживает два основных типа выгрузки: hits — каждая строка это отдельный просмотр страницы, и visits — каждая строка это отдельный визит целиком (с итоговыми параметрами: источник, устройство, достигнутые цели за визит). Выбор зависит от того, нужен ли анализ на уровне отдельных просмотров или на уровне визита как единицы.

Жизненный цикл запроса: создание, проверка, скачивание

Запрос к Logs API работает не как мгновенный ответ, а как асинхронная задача: сначала запрос создаётся с указанием полей и периода, затем нужно периодически проверять его статус (готовится / готов / ошибка), и только после готовности скачивать результат — часто по частям, если данных много.

Коротко: Не пытайтесь скачивать результат сразу после создания запроса — формирование выгрузки за большой период может занимать заметное время; предусмотрите в скрипте цикл ожидания со статус-проверкой.

Выбор полей выгрузки

При создании запроса нужно явно указать список полей (например, дата визита, источник, устройство, ClientID, достигнутые цели) — чем шире список, тем больше объём выгрузки. Разумная практика — выгружать только те поля, которые реально нужны для конкретной задачи анализа, а не «все подряд на будущее», чтобы не раздувать объём хранения и время обработки.

Подготовка и загрузка в базу

Выгруженные построчные данные обычно требуют предобработки перед загрузкой в СУБД (см. Выбор окружения): преобразование форматов дат, разбор составных полей (например, списка целей за визит), удаление технических строк ботов, если фильтры в самой Метрике не покрывают весь необходимый период. Для действительно больших объёмов (миллионы хитов в день) на этапе хранения оправдан переход на колоночную СУБД типа ClickHouse вместо обычной реляционной базы.

Комментарий эксперта

Константин Горбунов

Константин Горбунов
Основатель Monster Context и AdPump, эксперт Яндекса по обучению. Работает с Яндекс Метрикой и Директом с 2011 года.

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 · Чек-лист