yandex-metrika

yandex-metrika

Работа с API Яндекс Метрики: детализация трафика по источникам и UTM-меткам, отчёты по конверсиям и поисковым системам, API-сегменты и прямые доступы к счётчикам.

Config

Требуется YANDEX_METRIKA_TOKEN в config/.env. Для чтения нужен доступ metrika:read, для создания сегментов и управления доступами — metrika:write. Инструкция: config/README.md.

Philosophy

1. Cache-first — конфигурационные данные (счётчики, цели, инфо) кешируются надолго. Отчёты кешируются по ключу counter+dates+params. Перед API-запросом всегда проверяем кеш.
2. Context window hygiene — stdout ограничен 30 строками. Полные данные в CSV/файл. Кеш доступен через grep/rg для поиска без загрузки в контекст.
3. Точные данные — accuracy=1 (без сэмплирования), фильтр isRobot по умолчанию.
4. Атрибуция — дефолт lastsign (последний значимый источник). Спрашиваем пользователя при первом запуске.

Workflow

STOP! Перед любым анализом:

1. Получи список счётчиков:

   bash scripts/counters.sh
   

2. Спроси пользователя (если счётчик не очевиден из контекста):

   "О каком счётчике/сайте идёт речь?
   Укажите ID, название или домен."
   

   Если пользователь назвал сайт/домен — ищи через --search:

   bash scripts/counters.sh --search "metallik"
   

   Это grep по TSV (id + name + site), поэтому находит и по домену.

3. Получи инфо о счётчике и его цели:

   bash scripts/counter_info.sh --counter <ID>
   bash scripts/goals.sh --counter <ID>
   

4. Спроси про конверсионные цели:

   "Какие из этих целей являются конверсионными для вашего бизнеса?
   [список целей из goals.sh]
   Сохраню выбранные для будущих отчётов."
   

5. Сохрани конфигурацию в cache/counter_<id>/config.json:

   {
     "attribution": "lastsign",
     "conversion_goals": [
       {"id": 12345, "name": "Заказ оформлен"},
       {"id": 67890, "name": "Заявка отправлена"}
     ]
   }
   

6. Запускай отчёты по задаче пользователя.

Сегменты и доступы

Для API-сегмента сначала зафиксируй понятное название и выражение filters. Создание и удаление без --apply показывают план и ничего не меняют. Перед записью сценарий читает свежую роль на счётчике; сервер API остаётся окончательным источником прав.

bash scripts/segments.sh --counter <ID> --action create \
  --name "Посетители карточек" \
  --expression "EXISTS(ym:pv:URL=@'/catalog/')"
# после проверки плана повторить с --apply

Получи точный логин от вызывающей задачи, затем проверь прямой доступ к счётчику и при необходимости подготовь минимальную роль:

bash scripts/grants.sh --counter <ID> --action get --login <LOGIN>
bash scripts/grants.sh --counter <ID> --action add \
  --login <LOGIN> --permission view
# после проверки плана повторить с --apply

Для использования сегмента обычно достаточно view. Не выдавай edit, если задача не требует менять счётчик. Если пользователь выбрал analyst или edit, передай эту роль через --permission; существующую роль меняй через update. Список /grants содержит прямые разрешения; владелец выводится отдельно, а представители аккаунта в этот список не входят. После записи верни вызывающей задаче номер счётчика, ID сегмента, логин и подтверждённую роль. Подробности: API-сегменты и прямые доступы к счётчику.

Scripts

Общий паттерн вызова:

bash scripts/<script>.sh --counter <ID> --date1 YYYY-MM-DD [--date2 ...] [--group month] [--csv path]

Script	Description	Special params
counters.sh	Список счётчиков	--search "query"
goals.sh	Цели счётчика	—
counter_info.sh	Метаданные счётчика	—
traffic_summary.sh	Трафик по источникам	—
conversions.sh	Достижение целей	--goals "ID,ID" / --all-goals; по умолчанию из config.json
utm_report.sh	UTM-разбивка	—
search_engines.sh	Поисковые системы (organic)	—
ecommerce.sh	Покупки, выручка, средний чек	--currency RUB|USD|EUR; авто из counter_info
direct_clients.sh	Логины Директа	—
direct_costs.sh	Расходы Директа (ym:ad:*)	--direct-client-logins "login"; нет --group/--device/--source
comparison.sh	Сравнение двух периодов	--date1a/--date2a/--date1b/--date2b; --dimension, --metrics
segments.sh	Список, просмотр, создание и удаление API-сегментов	--action; запись только с --apply
grants.sh	Владелец и прямые доступы по логинам; роли view, analyst, edit	--action; запись только с --apply

Не все скрипты поддерживают все общие параметры — см. Special params. Сценариям управления segments.sh и grants.sh для надёжного разбора JSON нужен Python 3.10+ либо uv; обычные отчёты по-прежнему работают без них.

目标报告

conversions.sh 会自动分批请求目标，每批 6 个，并将结果合并为一个 CSV。这适用于 --all-goals、--goals 和 config.json 中的目标。 使用 --all-goals 时，会先通过 Management API 更新目标列表。 合并使用普通的 awk；运行报告不需要 Python 和 uv。 每个目标会保存三项指标：达成目标的访问量、目标达成次数和转化率。 列中的目标顺序与所选列表一致。

请求中会添加总访问量指标，避免达成次数为零的来源从单独的分批结果中消失。最终 CSV 中不包含辅助指标，但会保留没有转化的来源；最终转化率会计入这些来源的访问量。 来源按第一个所选目标的达成访问量排序；若相同，则按来源排序。

--limit 限制来源数量：不带 --group 时可设为 1–100000（默认值为 100）；带 --group 时可设为 1–30（默认值为 30，API 参数为 top_keys）。 日期范围不会因此缩短。只有在所有分批结果均成功获取并合并后，报告才会写入缓存和 --csv。

报告脚本通用参数

参数	必填	默认值	可选值
--counter	是	-	计数器 ID
--date1	是	-	YYYY-MM-DD
--date2	否	今天	YYYY-MM-DD
--group	否	-	day、week、month
--device	否	all	desktop、mobile、tablet
--source	否	all	organic、ad、referral、direct、social
--attribution	否	lastsign	lastsign、last、first
--filters	否	不含机器人	报告 API 的细分表达式
--limit	否	API 默认值	行数
--csv	否	-	导出路径
--no-cache	否	-	跳过缓存

缓存策略

缓存存储在 cache/ 中：

• counters.json + counters.tsv — 所有计数器
• counter_<id>/info.json — 元数据（永久）
• counter_<id>/goals.json + goals.tsv — 目标
• counter_<id>/config.json — 归因、转化目标
• counter_<id>/direct_clients.json — Direct 登录名
• counter_<id>/reports/*.csv — 报告结果

细分和访问权限始终重新读取，不会保存到缓存中：这些数据的变化独立于报告，而且访问权限列表包含用户登录名。

在缓存中搜索：grep "text" cache/counters.tsv 或 rg "text" cache/。

高级用例

• 热门搜索查询
• 自定义报告和 JSON 请求（drilldown、metrika_get 等）
• dimensions/metrics 参考手册
• 同比期间比较
• Direct 费用和损益
• 用于在 Direct 中筛选受众的 API 细分
• 检查并授予广告账户访问权限
• API 限制（bytime、scope mixing、drilldown CSV）

API 限额

• Reporting API：约 200 次请求 / 5 分钟（超出时请等待约 5 分钟）
• 脚本会自动处理 429（Retry-After ≤ 60s 时重试，否则失败并显示提示）