Становясь падаваном Logs API Яндекс.Метрики
API Яндекс.Метрики предоставляет мощный функционал для построения гибкой отчетности и автоматизации. Достаточно посмотреть список группировок и метрик в документации, чтобы придумать множество вариантов использования. Кто-то делает очень крутые дэшборды, кто-то строит системы аналитики контекстной рекламы, оптимизаторы ставок и прочие занятные вещи, например, коррелятор промежуточных целей.
Но Метрика не остановилась в своем развитии на обычной API, которая позволяет вытащить данные только по заданному списку группировок, ограниченному 10 группировками в запросе. Разработчики Яндекса предоставили возможность получать «сырые» данные из хранилища данных Яндекс.Метрики — Logs API.
Агрегированные, или обобщенные, данные, которые вы видите в интерфейсе Метрики или выгружаете через API отчетов, рассчитываются для определенной группы визитов. Например, метрика «Время на сайте» вычисляется для всех переходов из какого-либо источника трафика, всех визитов от посетителей мужского пола или всех визитов с планшетов.
А основой для этих расчетов служат сырые данные — записи об отдельных визитах или просмотрах. Таблица с этими записями и передается через Logs API, при этом каждая запись дополнена полезными сведениями из Метрики. Это подробные данные по Директу и по электронной коммерции, страна и город посетителя, а еще — различная техническая информация о визите: например, браузер и модель мобильного телефона.
Если вы новичок в работе с API Метрики, то я рекомендую сначала ознакомиться со статьей «Становясь гуру API Яндекс.Метрики». Она даст понимание того как работает API и как выгружать данные из Метрики с помощью API отчетов. Информация в ней нам еще будет полезна, чтобы получить авторизационный токен.
В этой статье я хочу поделиться своим рецептом получения данных из Logs API Яндекс.Метрики, а также о нескольких приемах обработки этих данных.
Приступим!
Первое: Получить авторизационный токен
Процедура получения токена подробно описывается в пункте 4 этой статьи. Для доступа к Logs API понадобится тот же токен, что и для доступа к API отчетов. Без авторизационного токена у нас не получится сделать запросы, это своего рода ключ доступа к данным вашего счетчика.
Внимание: в дальнейшем в примерах я буду использовать недействительный токен, поэтому, чтобы примеры работали, вам нужно использовать собственноручно полученный токен или можно попробовать токен, указанный в качестве тестового в документации: 05dd3dd84ff948fdae2bc4fb91f13e22bb1f289ceef0037
Второе: Запрос на создание лога
После того как мы получили авторизационный токен, например, AQAAAAAHrQEBAADn-FX3DPJUn04fkptrzvFv8nE, мы должны сформировать запрос к Logs API, который создает лог. Лог формируется на стороне Яндекс.Метрики в течение определенного времени, которое зависит от того, сколько параметров визита или просмотра вы хотите получить, а также от диапазона времени, за который нужен лог.
Метод «Создание лога запросов» создает запрос на подготовку отчета, в котором будут нужные нам данные.
Это POST-запрос следующей структуры:
POST
Параметры запроса на создание лога
Рассмотрим все параметры, которые нужно передать в запросе:
{counterId} — идентификатор счетчика Метрики.
date1 — дата начала отчетного периода в формате YYYY-MM-DD (например, 2015-08-31).
date2 — дата конца отчетного периода в формате YYYY-MM-DD (не может быть текущим днем).
fields — список полей, которые надо получить. Поля разделяются запятыми.
Давайте рассмотрим параметр fields подробнее.
Поля — это те параметры визитов или просмотров, которые Яндекс выгрузит из своей базы данных и предоставит нам в виде файла в формате CSV. Существует две категории полей, которые можно использовать в Logs API:
Предположим, мы хотим получить детально каждый визит с указанием:
- даты визита;
- идентификатора пользователя, совершившего визит;
- количеством просмотров страниц за визит;
- страницы входа, с которой начался этот визит.
Смотрим таблицу полей для визитов и определяем, что нам нужны следующие поля:
- ym:s:visitID — идентификатор визита;
- ym:s:date — дата визита;
- ym:s:clientID — идентификатор пользователя на сайте;
- ym:s:pageViews — глубина просмотра;
- ym:s:ym:s:startURL — страница входа.
Аналогично с просмотрами: все параметры просмотров находятся в табличке и нужно просто понимать, какие параметры взять для выполнения вашей задачи.
Следующий параметр source, который задает источник логов. Тут все просто: если вы хотите получить данные по визитам, то нужно указать visits; если нужны данные по просмотрам — указываем hits.
Последний параметр oauth_token — это авторизационный токен, который мы получили в предыдущем пункте.
Сформируем тестовый запрос:
https:\/\/api-metrika\.yandex\.ru\/management\/v1\/counter\/30177909\/logrequests?date1=2017-03-01&date2=2017-03-06&fields=ym:s:visitID,ym:s:date,ym:s:clientID,ym:s:pageViews,ym:s:startURL&source=visits&oauth_token=AQAAAAAHrQEBAADn-FX3DPJUn04fkptrzvFv8nE
Дальше нужно сделать POST-запрос. Один из самых простых способов сделать POST-запрос, не прибегая к программированию — воспользоваться расширением Postman для Chrome.
Как сделать POST-запрос к API Яндекс.Метрики?
1. Устанавливаем и запускаем расширение Postman:
2. Выбираем тип HTTP-запроса «POST», а в поле ввода запроса вставляем сформированный выше запрос:
3. Нажимаем синюю кнопку «Send».
4. Получаем ответ от API:
5. В ответе нас интересует идентификатор request_id. Это идентификатор, созданного запроса на получение данных из Logs API:
Этот идентификатор копируем, он понадобится нам на следующем шаге.
Третье: Получение информации о запросе логов
После того как мы отправили в АПИ заявку на формирование лога, нужно получить статус лога: узнать готов ли он для скачивания. Для этой цели существует метод «Информация о запросе логов».
Вызывается этот метод с помощью следующего GET-запроса:
GET https://api-metrika.yandex.ru/management/v1/counter/{counterId}/logrequest/{requestId}
Вместо counterId подставляем идентификатор счетчика, для которого мы делали запрос на создание, а вместо requestId ставим идентификатор request_id, полученный в ответе на предыдущий запрос. После этого через знак «?» указываем параметр oauth_token.
Таким образом, наша сформированная ссылка для получения информации о запросе лога выглядит так:
https:\/\/api-metrika\.yandex\.ru\/management\/v1\/counter\/30177909\/logrequest\/45264?oauth_token=AQAAAAAHrQEBAADn-FX3DPJUn04fkptrzvFv8nE
По сути, это обычный GET-запрос, поэтому выполнить его можно и в обычном браузере, но удобнее будет в Postman, потому что в него встроен pretty-вывод JSON и смотреть на результат будет приятнее.
Вставляем запрос в Postman, выбираем тип HTTP-запроса «GET» и нажимаем «Send»:
В ответе нас интересует параметр status. Этот параметр может принимать несколько значений, которые описаны тут. В нашем случае он принимает значение «processed», которое говорит о том, что запрос лога обработан и лог готов к скачиванию. Это то, что нужно!
Обратите внимание на параметр parts. Может так получиться, что полученный лог окажется слишком большим и будет разбит на несколько частей, которые придется скачивать по отдельности.
Перейдем к скачиванию лога.
Четвертое: Загрузка лога
Чтобы скачать подготовленный лог, нам понадобится метод «Загрузка части подготовленных логов обработанного запроса».
Этот метод, так же как и предыдущий, вызывается с помощью GET-запроса:
GET https://api-metrika.yandex.ru/management/v1/counter/{counterId}/logrequest/{requestId}/part/{partNumber}/download
Аналогично тому, как мы делали это в предыдущем запросе, вместо counterId подставляем идентификатор счетчика, вместо requestId указываем уже известный нам идентификатор request_id, а на место partNumber ставим порядковый номер той части лога, которую мы хотим скачать. В нашем примере всего одна часть, поэтому ставим 0. После этого через знак «?» указываем параметр oauth_token.
Сформированная ссылка для скачивания лога будет такой:
https:\/\/api-metrika\.yandex\.ru\/management\/v1\/counter\/30177909\/logrequest\/45264?oauth_token=AQAAAAAHrQEBAADn-FX3DPJUn04fkptrzvFv8nE
Этот GET-запрос можно выполнять как в браузере, так и через Postman, но в случае с Postman'ом вместо «Send» надо выбрать вариант «Send and Download»:
А затем сохранить полученный файл в формате CSV:
Все! Мы получили лог и сохранили его себе на диск, поэтому можно избавить Яндекс от хранения лишней информации и очистить лог с помощью метода «Очистка подготовленных для загрузки логов обработанного запроса». Делается это с помощью уже привычного нам POST-запроса.
Заключительное: Обработка лога
Честно говоря, обработка логов с помощью Excel — это то еще извращение, я бы рекомендовал использовать для таких задач что-то более подходящее, например, Pandas или R. Но Excel — базовый инструмент анализа данных, поэтому рассмотрю на его примере.
Открываем CSV-файл в Excel. Для этого создаем новую книгу, открываем вкладку «Данные» и выбираем «Из текста»:
Выбираем файл и указываем в мастере текстов, что наш файл содержит разделители и записан в кодировке UTF-8:
На следующем шаге выбираем в качестве символа-разделителя знак табуляции, а затем устанавливаем форматы колонок, лучше всего для идентификаторов задать текстовый формат колонок.
Итак, мы загрузили наши данные в таблицу:
Дальше давайте решим две простые задачи:
- Определим пользователя с наибольшим числом визитов, т. е. того, кто чаще всего посещал наш сайт;
- Определим пользователя с наибольшим суммарным числом просмотров страниц, т. е. того, кто больше всех лазил по нашему сайту.
Построим простейшую сводную таблицу:
В строки вынесем ID пользователей (ym:s:clientID), а в значения — ID визита (ym:s:visitID) и глубину просмотра (ym:s:pageViews). Из-за того, что для поля ym:s:visitID мы указали как текстовый столбец, сводная таблица автоматически посчитает не сумму айдишников, а их количество. Это и будет количеством визитов на пользователя.
Отсортировав сводную таблицу по второму столбцу, мы увидим, что больше всего визитов у пользователя 1487091524934294616, а отсортировав по третьему столбцу, обнаружим пользователя с наибольшим числом просмотров — это пользователь 1488553373564844012.
Теперь мы можем применить фильтр в таблице с данными, чтобы понять, с каких страниц эти пользователи чаще всего попадали на сайт и как часто заходили.
Видно, что первый пользователь заходил на протяжении 3 дней с одной и той же страницы, скорее всего, он добавил ее в закладки, и это были прямые переходы, чтобы подтвердить эту гипотезу, нужно бы сделать еще одну выгрузку из Logs API с указанием параметра ym:s:referer (реферер) или ym:s:lastTrafficSource (источник трафика):
Второй пользователь вел себя по-другому. Он совершил в ходе одного из визитов 16 просмотров, благодаря чему и стал рекордсменом по числу просмотров. Для этого пользователя было бы интересно посмотреть, какие страницы он просматривал. Это можно сделать, добавив в параметры выгрузки параметр ym:s:watchIDs (идентификаторы просмотров, которые были в визите):
Естественно, применение Logs API не ограничено этими простенькими ситуациями, можно делать намного более сложные вещи, вроде когортного анализа, сложных моделей атрибуции, анализа посещаемости страниц (например, определить на какую страницу чаще всего переходят после просмотра определенной страницы, или даже построить вероятностную модель переходов). Но все эти задачи в Excel не так просто решаются. Здесь на помощь приходят более мощные инструменты анализа данных: Python и Pandas, R, SQL. Об этом как-нибудь в другой раз :)
Да и получать данные из Logs API с помощью запросов в Postman'е — это не совсем удобный способ. Если вам захочется делать эти выгрузки постоянно, все складировать у себя и периодически анализировать — лучший вариант складывать данные в БД ClickHouse. Благо, что для интеграции Logs API с ClickHouse в Яндексе уже разработали простой в использовании Python-скрипт. Конечно, это сложнее, придется поднять ClickHouse, научиться запускать скрипты на Python'е, а еще лучше не ручками, а по расписанию, но, поверьте, все это намного интереснее и открывает кучу новых возможностей!
Источник: datalytics.ru
Есть о чем рассказать? Тогда присылайте свои материалы Марине Ибушевой
-
Алексей, Спасибо за вашу статью. Получил логи, распарсил, все сделал как вы написали. Но потом при Получение информации о запросе логов, статус мне возвращается "created" и нет частей. Подскажите, это идет обработка моего запроса, как долго она может продолжаться? Проверяю статус запроса, он все еще created.