--- name: yandex-metrika description: | Яндекс Метрика: детализация трафика по источникам и UTM-меткам, отчёты по конверсиям и поисковым системам, API-сегменты и доступы к счётчикам. Cache-first подход для гигиены контекстного окна. Triggers: яндекс метрика, yandex metrika, metrika analytics, метрика трафик, метрика конверсии, метрика отчёт, создать сегмент, доступ к счётчику, выдать доступ рекламному кабинету. --- # 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 bash scripts/counters.sh ``` 2. **Спроси пользователя** (если счётчик не очевиден из контекста): ``` "О каком счётчике/сайте идёт речь? Укажите ID, название или домен." ``` Если пользователь назвал сайт/домен — ищи через `--search`: ```bash bash scripts/counters.sh --search "metallik" ``` Это grep по TSV (id + name + site), поэтому находит и по домену. 3. **Получи инфо о счётчике и его цели:** ```bash bash scripts/counter_info.sh --counter bash scripts/goals.sh --counter ``` 4. **Спроси про конверсионные цели:** ``` "Какие из этих целей являются конверсионными для вашего бизнеса? [список целей из goals.sh] Сохраню выбранные для будущих отчётов." ``` 5. **Сохрани конфигурацию** в `cache/counter_/config.json`: ```json { "attribution": "lastsign", "conversion_goals": [ {"id": 12345, "name": "Заказ оформлен"}, {"id": 67890, "name": "Заявка отправлена"} ] } ``` 6. **Запускай отчёты** по задаче пользователя. ## Сегменты и доступы Для API-сегмента сначала зафиксируй понятное название и выражение `filters`. Создание и удаление без `--apply` показывают план и ничего не меняют. Перед записью сценарий читает свежую роль на счётчике; сервер API остаётся окончательным источником прав. ```bash bash scripts/segments.sh --counter --action create \ --name "Посетители карточек" \ --expression "EXISTS(ym:pv:URL=@'/catalog/')" # после проверки плана повторить с --apply ``` Получи точный логин от вызывающей задачи, затем проверь прямой доступ к счётчику и при необходимости подготовь минимальную роль: ```bash bash scripts/grants.sh --counter --action get --login bash scripts/grants.sh --counter --action add \ --login --permission view # после проверки плана повторить с --apply ``` Для использования сегмента обычно достаточно `view`. Не выдавай `edit`, если задача не требует менять счётчик. Если пользователь выбрал `analyst` или `edit`, передай эту роль через `--permission`; существующую роль меняй через `update`. Список `/grants` содержит прямые разрешения; владелец выводится отдельно, а представители аккаунта в этот список не входят. После записи верни вызывающей задаче номер счётчика, ID сегмента, логин и подтверждённую роль. Подробности: [API-сегменты](references/SEGMENTS.md) и [прямые доступы к счётчику](references/ACCESS.md). ## Scripts Общий паттерн вызова: ```bash bash scripts/