События трекинга: что мы видим и зачем

Одна страница: какие события мы собираем, что они говорят, и какие из них критичны для оптимизации рекламы. Это карта данных, на которой строится отчёт по воронке.

⚙️ Технический as-built (May 2026) и runbook для добавления новых воронок — 24-tracking-runbook.md. Этот документ описывает что мы трекаем (карта данных); runbook — как оно собрано в коде, Make сценарии и Meta-стеке, плюс чек-лист для запуска ещё одной воронки.

Что изменилось недавно (май 2026)

• form_id теперь содержит CTA-источник для модальной формы. PR #572. Было modal, стало modal:hero / modal:pricing-offer / modal:countdown-reserve / modal:cta-band-final и т.д. Это говорит, какая кнопка на странице открыла форму, которая в итоге конвертировала. Полная таблица CTA — в разделе «CTA → cta_location» ниже.
• Новое поле в lead-блоке: exclusive_interest (boolean). PR #573. Срабатывает, когда пользователь поставил чекбокс «Мне интересен Exclusive · 1:1 с Юсупом» в форме регистрации. Используется CRM для приоритизации на квалифицирующем звонке.
• lead_upsell событие больше не срабатывает на текущем флоу. PR #573. Раньше клик «Да, рассмотреть Exclusive» на /thank-you создавал второй submission + второй conversion event. Теперь интерес ловим в исходной регистрации через exclusive_interest. Скрипт src/scripts/upsell.ts остался в репо (dormant) — если в будущем понадобится отдельный upsell на другом флоу, его можно переподключить.

Принцип

Каждое событие отвечает на один из трёх вопросов:

1. Сколько людей дошли до X?
2. Где они отвалились?
3. Какой вариант работает лучше?

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

Карта воронки → события

   Показ рекламы                Meta показывает (статистика в кабинете)
        │
        ▼
   Клик по рекламе              utm_*, fbclid, gclid, yclid → летят на сайт
        │
        ▼
   Открыли лендинг              page_view  +  scroll_depth (глубина)
        │
        ▼
   Видео / контент              video_*  |  section_view (что посмотрели)
        │
        ▼
   Клик по CTA                  cta_click  +  whatsapp_click
        │
        ▼
   Открыли форму                form_view
        │
        ▼
   Заполнили                    form_start → form_step → form_submit
        │
        ▼
   Лид зафиксирован             form_success + Lead (Meta Pixel)
        │
        ▼
   /thank-you                   generate_lead (ключевая конверсия)
        │
        ▼
   Менеджер → оплата            [вне сайта: amoCRM + Продамус]
        │
        ▼
   Покупка                      Purchase (CAPI с шлюза) ← главное для рекламы

Три события, без которых нет рекламной оптимизации

Без Purchase реклама оптимизируется только на дешёвые лиды. С Purchase — на людей, которые реально платят. Разница для нас в ROAS — в разы. Это главная причина, почему серверная сторона (шлюз → Meta CAPI) не опциональна.

Полный список событий

Сгруппированы по этапу воронки. Колонка Статус: ✅ работает · 🟡 ставим в плане · 🔲 пока не нужно.

Этап 1 — Заход на сайт

Этап 2 — Вовлечение

Этап 3 — VSL (видео на /vsl)

Этап 4 — Форма

Почему form_view / form_start / form_step несут БАЗОВЫЙ form_id, а form_submit / form_success / form_error — ОБОГАЩЁННЫЙ: форма монтируется (client:idle) до того, как пользователь кликнул кнопку, которая её открыла, — на этом этапе CTA-источник ещё неизвестен. Как только пользователь дошёл до submit, мы знаем точно, какая кнопка вела к конверсии — добавляем её в form_id через :<cta>. Полный payload лида (тот, что летит на бэкенд) тоже несёт обогащённый form_id.

В Sheets/Looker колонку form_id достаточно разделить по : — получите две размерности: form_location (modal / final / hero) и form_trigger (hero / pricing-offer / countdown-reserve / …). Сводная по form_trigger × count of conversions = рейтинг «какая CTA на странице приводит к конверсии».

Поля внутри lead-блока в payload (form_success + бэкенд)

Этап 5 — Лид зафиксирован

Этап 6 — Покупка (вне сайта, server-side)

Универсальный пакет атрибуции

Любое событие в браузере уже несёт стандартный набор «откуда пришёл» — он зашивается на первом заходе и хранится в sessionStorage. Реализация — в src/conversion/attribution.ts + src/scripts/page-init.ts + Layout.astro.

Правило first-touch: значение записывается только если оно не пустое и в storage ещё ничего нет. Это значит, что атрибуция рекламы переживает внутреннюю навигацию по сайту — не теряется на втором клике.

Кто принимает события

Два приёмника, каждый отвечает за своё:

Дедупликация Pixel + CAPI — браузер шлёт событие с eventID = submission_id, шлюз шлёт то же событие с тем же eventID. Meta видит оба и считает один раз. Это даёт качество выше, чем у каждого из них по отдельности (особенно на iOS Safari, где ITP режет браузерный пиксель).

Yandex Metrika на этот сайт не подключаем — Yandex Direct в медиаплане пока не используем. Если позже зайдём в этот канал, добавим счётчик и серверный goal отдельным шагом; yclid в атрибуции уже захватывается «на будущее».

Что отвечает на какой вопрос отчёта

Чтобы не утонуть в событиях, держим в голове, какое из них на что отвечает:

Статус и план

✅ Готово сейчас (Этапы 1–2, 4–5 браузерные)

• page_view, section_view, cta_click — работают
• Полный цикл формы (form_view → start → step → submit → success → error)
• generate_lead на /thank-you с атрибуцией
• Атрибуция (UTMs, click-IDs, session_id) собирается на каждом заходе

🟡 Неделя 1 — Доделать Meta Pixel

База уже стоит через GTM (Pixel ID 662311819389495, PageView срабатывает). Осталось:

• Добавить тег Meta Pixel — Lead в GTM на триггер event - form_success с eventID = submission_id для будущей CAPI-дедупликации
• Документировать Pixel ID в sites-config.json (metaPixel.pixelId)
• (Опционально, позже): вынести базовый пиксель из GTM в Layout.astro через @websites/analytics, если решим бороться за production-grade reliability (даёт +5–10% доставки событий, особенно на iOS Safari)

🟡 Неделя 2 — Engagement-события

• video_* для VSL (VSL.astro — YouTube IFrame API)
• whatsapp_click для плавающего FAB
• scroll_depth (25/50/75/90%)
• outbound_click для ссылок на IG/YT/wa.me

🟡 Неделя 3 — Server-side (самое важное для ROAS)

• Шлюз принимает Продамус webhook «оплачено»
• Из шлюза идёт Purchase в Meta CAPI с тем же eventID, что и у Lead
• Дублирующий серверный Lead (CAPI) для покрытия iOS Safari

🟡 Неделя 4 — Путь A (Instagram Lead Ads)

• Прием webhook Meta Lead Ads на шлюзе
• Эхо в CAPI как Lead с campaign IDs из webhook
• Связка с Путём B по номеру телефона («Поток данных»)

🔲 После запуска

• form_abandon (когда увидим реальные drop-off точки)
• Кастомные размерности GA4 для отчёта по вариантам
• Server-side GA4 Measurement Protocol (если понадобится больше signal)

CTA → cta_location

Каждое событие cta_click несёт cta_location = значение data-cta на кликнутом элементе. Это же значение появляется как суффикс в обогащённом form_id (если CTA открыл модалку, в которой произошла конверсия). Полный список CTA на проекте:

Точки входа (хук на трафик)

Прогрев в середине страницы

Близко к покупке

Пост-конверсионные (на /thank-you)

Хром сайта

Итого: ~16 уникальных CTA. Все ловятся одним делегированным listener в src/scripts/page-init.ts — если повесили data-cta на новый элемент, событие cta_click появится автоматически, отдельной проводки не нужно.

Связь с другими документами

• Воронка и точки атрибуции — «Поток данных»
• Техническая интеграция (шлюз, amoCRM, Meta CAPI, Продамус) — «Интеграция»
• Critical path сборки — «План действий»
• Definition of Done по трекингу — «Definition of Done» (раздел «Трекинг»)