Что делать после первого события

Первое событие дошло — значит, транспорт работает. Дальше задача другая: сделать так, чтобы данным можно было доверять и чтобы из них получались решения. Ниже семь шагов в том порядке, в котором их стоит делать. У каждого шага есть признак «готово» — по нему видно, можно ли идти дальше.

Если первое событие ещё не пришло, вернитесь к быстрому старту и отправке первого события.

Шаг 1. Проверьте, что приём работает не только у вас

Зачем. Одно событие с вашего ноутбука не доказывает, что данные идут со всех страниц, со всех браузеров и с бэкенда. Самая дорогая ошибка на этом этапе — строить отчёты по неполным данным и не знать об этом.

Что сделать.

1. Откройте Данные и сбор → События. Включите живой поток и посмотрите, что приходит прямо сейчас — не только от вас.
2. Проверьте, что события есть с обоих контуров: браузерные — от посетителей, серверные — от вашего бэкенда. Достоверные факты (оплаты, заказы, возвраты) должен отправлять только бэкенд серверным ключом, см. ключи проекта.
3. Откройте Данные и сбор → Проверка интеграции — там видны нарушения, история проверок и живой поток кадров разбора.

Ссылки. Проверка интеграции · Проверка приёма после установки

Готово, когда в живом потоке видны события с ваших рабочих адресов, а не только с тестового; в ответах приёма нет отказов; каждое ключевое действие продукта хотя бы раз появилось в списке событий.

Шаг 2. Договоритесь о разметке до того, как её станет много

Зачем. Имена событий и свойств — это язык, на котором потом разговаривают продакт, аналитик и разработчик. Переименование не переписывает уже собранную историю: события с прежним именем останутся с прежним именем. Поэтому дешевле договориться заранее, чем чистить потом.

Что сделать.

1. Выпишите ключевые действия продукта — обычно их 10–20, а не сто.
2. Для каждого решите: как называется, какие свойства нужны, кто его отправляет — браузер или сервер.
3. Проверьте имена по правилу приёма ^[a-z0-9_.]{1,128}$: строчные латинские буквы, цифры, _ и .. У события до 64 свойств, имя свойства до 64 символов, значение до 8 КБ.
4. Проверьте каждое событие вопросом «какое решение мы примем, увидев это число». Если ответа нет — событие пока не нужно.

Ссылки. План разметки · События и пользователи · Словарь терминов

Готово, когда список событий и свойств согласован, лежит в одном месте, а имена соответствуют правилу приёма.

Шаг 3. Опишите схему в реестре событий

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

Что сделать.

1. Откройте Данные и сбор → Реестр событий и опишите ключевые события: свойства, их типы и обязательность. Правила версионируются — новая версия не ломает уже собранные данные. Примеры значений в реестре формируются автоматически и не берутся из содержимого ваших событий.
2. Включите режим проверки «Мониторинг». В нём ничего не отклоняется, нарушения только записываются.
3. Через сутки-двое посмотрите нарушения на экране Проверка интеграции и починьте разметку либо поправьте схему.
4. Когда новых нарушений нет — включите «Строгая проверка». В этом режиме отклоняются только нарушившие контракт элементы батча, а не весь запрос.

Схемы событий может править участник с ролью Аналитик и выше; переключить режим проверки — Админ или Владелец.

Ссылки. План разметки · Проверка интеграции

Готово, когда у ключевых событий есть описанная версия схемы, в режиме мониторинга за сутки не появляется новых нарушений, а режим переведён в строгую проверку.

Шаг 4. Соберите первую воронку

Зачем. Первый вопрос, на который отвечают данные: где люди уходят по пути к цели. Воронка сразу показывает шаг с наибольшей потерей — это и есть место для следующей задачи в продукте.

Что сделать.

1. Анализ → Воронки. Первый шаг уже добавлен — замените событие на нужное.
2. Добавьте остальные шаги в том порядке, в котором их проходит пользователь.
3. Задайте период и окно конверсии — за какое время шаги должны сложиться в один путь.
4. Сохраните отчёт, чтобы к нему возвращались коллеги, а не пересобирали заново.

Сохранять отчёты может Аналитик и выше. Состояние воронки попадает в адрес страницы: ссылку можно отправить в переписку, коллега увидит тот же разрез.

Ссылки. Воронки и разбор потерь

Готово, когда воронка сохранена, у неё есть понятный шаг с наибольшей потерей и вы можете назвать гипотезу, почему потеря там.

Шаг 5. Посмотрите удержание

Зачем. Воронка показывает путь до цели один раз. Удержание отвечает на другой вопрос: возвращаются ли люди после того, как этот путь прошли. Продукт с хорошей воронкой и плохим удержанием растёт только за счёт закупки трафика.

Что сделать.

1. Анализ → Удержание. Выберите стартовое событие — то, после которого начинается отсчёт.
2. Выберите возвратное событие. Вариант «Любое событие» подходит, когда важен сам факт возврата.
3. Выберите гранулярность — по дням или по неделям — и посмотрите тепловую карту когорт.

Ссылки. Удержание

Готово, когда видно, на каком периоде происходит основной отвал, и понятно, одинаково ли ведут себя разные когорты.

Шаг 6. Сохраните отчёт и сегмент, чтобы к ним возвращались

Зачем. Отчёт, который каждый раз собирают заново, не используют. Регулярная работа с данными начинается тогда, когда нужный разрез открывается одним кликом.

Что сделать.

1. Сохраните собранные отчёты. Список — в Мониторинг → Отчёты: там же поиск, фильтр по типу, избранное, переименование и удаление.
2. Соберите Сводную панель из сохранённых отчётов — экран, на который смотрят на регулярной встрече. Виджеты переставляются мышью, есть режим показа на большом экране.
3. Сохраните сегмент аудитории, если один и тот же фильтр нужен в нескольких отчётах: сегмент создаётся из построителя фильтров.

Ссылки. Сегменты, отчёты и пути

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

Шаг 7. Подключите уведомления, чтобы не смотреть в панель каждый день

Зачем. Данные полезны, когда о проблеме узнают в день, когда она случилась, а не в конце месяца. Отдельно важен случай «данные перестали приходить»: без уведомления это обычно замечают через неделю по странно ровному графику.

Что сделать.

1. Мониторинг → Оповещения → создайте правило. Типы правил: «Метрика» (порог по значению), «Нет событий», «Падение воронки», «Сезонная аномалия», «Качество данных».
2. Первым сделайте правило «Нет событий» на самом важном событии продукта — это страховка от сломанной интеграции.
3. Укажите каналы доставки: адреса почты, Telegram chat_id, webhook. Каналов у правила не больше восьми.
4. Нажмите «Отправить тест» и убедитесь, что уведомление дошло. Правила проверяются раз в минуту, у сработавшего правила есть период тишины, чтобы не получить сотню писем за час.
5. Включите еженедельный дайджест на том же экране: сводка уходит каждый понедельник в 09:00 по часовому поясу проекта и охватывает предыдущую полностью завершённую неделю.

Правила и дайджест настраивает Аналитик и выше. Оценочные величины — сезонные аномалии и корреляции — всегда помечены как оценка, а не как факт.

Ссылки. Методы API: Alerts · Доступ к данным и загрузка истории

Готово, когда есть работающее правило «Нет событий», хотя бы одно правило по метрике продукта и включённый дайджест, а тестовая доставка прошла.

Дальше стоит подгрузить историю из прежней системы, если она есть, и подключить выгрузки для собственных расчётов — оба пути описаны в доступе к данным. Если собираете в браузере, проверьте, что сбор согласован с вашим баннером согласия: согласие на сбор данных.