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

Главные метрики и события для оперативного старта

Аналитика на сайте: какие события и цели настроить в первую очередь - иллюстрация

Конверсии: отправка формы/заявки, звонок, покупка (если e-commerce).
Микроконверсии: клик по телефону/мессенджеру, начало заполнения формы, добавление в корзину.
Качество трафика: источники/кампании (UTM), посадочные страницы, доля брендового трафика (по необходимости).
Воронка: просмотр карточки/услуги → действие (добавить/нажать/отправить) → успех (thank-you/успешный статус).
Техническое здоровье: 404/500, JS-ошибки, скорость ключевых страниц, проблемы оплаты.

Обязательные события: что настроить в первую очередь и почему

Это подходит большинству сайтов с целями лидогенерации или продаж: вы быстро получаете измеримые конверсии и можете сравнивать каналы. Не стоит усложнять схему на старте, если нет доступа к коду/GTМ, нет стабильной структуры страниц или бизнес не определил, что считать лидом (тогда события будут спорными и непроверяемыми).

Отправка формы (lead_submit) - приоритет: высокий. Цель/конверсия для оценки эффективности каналов и страниц.
Клик по телефону/мессенджеру (contact_click) - приоритет: высокий. Закрывает часть лидов, которые не оставляют форму.
Просмотр ключевой страницы (view_item / view_service) - приоритет: средний. База для воронок и сегментации интереса.
Успешная покупка (purchase) - приоритет: высокий (если интернет‑магазин). Дает деньги, ROAS/CPA и атрибуцию.

Событие	Цель (что измеряем)	Приоритет	Метод реализации (практично)
lead_submit (успешная отправка формы)	Лид/заявка	Высокий	DataLayer/GTМ по событию успеха (ответ сервера/показ thank-you), в GA4 - conversion, в Метрике - цель по JS-событию
contact_click (tel:/wa:/tg:)	Контакт без формы	Высокий	GTМ: click на ссылках tel:, wa.me, t.me; в Метрике - цель по клику/JS-событию
view_item / view_service	Интерес к продукту/услуге	Средний	GA4: рекомендованные события e-commerce или кастом; Метрика: просмотр URL/контентные цели (если структура стабильна)
add_to_cart	Намерение купить	Средний	DataLayer e-commerce, отправка в GA4; Метрика: e-commerce или JS-событие
purchase	Продажа и выручка	Высокий	GA4 e-commerce purchase с transaction_id/value/currency/items; Метрика: e-commerce (покупка)
error_404 / server_error	Потери конверсии из-за ошибок	Средний	Событие по шаблону 404/коду ответа (где возможно), логирование JS ошибок (без PII)

Воронки конверсии: ключевые точки пользовательского пути

Чтобы корректно строить воронки и диагностировать провалы, заранее обеспечьте единые названия событий, стабильные условия их срабатывания и доступы. Для задач уровня intermediate обычно достаточно связки GTM + GA4 + Метрика и тестового окружения (или хотя бы staging с теми же формами).

Доступы: редактор/админ GA4, Яндекс Метрики, Google Tag Manager (или доступ к коду сайта) и рекламные кабинеты (по необходимости).
Технический контракт: список событий, их параметры, условия срабатывания, запрет на передачу персональных данных (email/телефон/ФИО) в аналитику.
Единый слой данных (желательно): DataLayer для форм и e-commerce, чтобы настройка событий в GA4 не зависела от верстки.
План тестирования: тестовые заказы/лиды, сценарии ошибок (неуспешная оплата, валидация формы), проверка дублей.

view_product_list → view_item - приоритет: средний. Понимание, где "теряется" интерес.
begin_checkout - приоритет: высокий (e-commerce). Ключевой шаг перед оплатой.
form_start - приоритет: средний. Выявляет проблемы UX формы раньше, чем падение submit.
payment_error - приоритет: высокий (если есть оплата). Отличает маркетинговую проблему от платежной.

Отслеживание продаж: транзакции, возвраты и атрибуция дохода

Риски и ограничения перед стартом (учтите до того, как включать e-commerce):

Дубли purchase из-за повторной загрузки страницы "Спасибо" или повторной отправки события - проверяйте уникальность transaction_id.
Передача персональных данных в параметрах/URL (email/телефон/ФИО) - это нельзя отправлять в GA4/Метрику; чистите query-string и события.
Несогласованная валюта/суммы (доставка, скидки, налоги) - заранее договоритесь, что такое "выручка" в аналитике.
Тестовые заказы попадают в прод-отчеты - маркируйте тестовые транзакции и исключайте их фильтрами/аудиториями.
Разные источники "платеж успешен" (банк, агрегатор, CRM) - выберите единственный источник истины для события purchase.

Определите модель дохода и состав заказа

Зафиксируйте, какие поля вы передаете: transaction_id, value, currency, items, скидки/доставка. Это снизит расхождения между админкой и отчетами.
- Согласуйте, включать ли доставку в value и как учитывать промокоды.
- Определите, что считается "возвратом": отмена до отгрузки или фактический refund.
Сделайте событие purchase устойчивым к дублям

Событие "покупка" должно отправляться один раз на уникальную транзакцию. Лучший путь - отправка по серверному подтверждению или по защищенному статусу заказа.
- Если используете thank-you страницу: блокируйте повторные отправки (локальный флаг, проверка transaction_id).
- Если используете GTM: добавьте условие, что transaction_id не пустой и ранее не отправлялся.
Подключите e-commerce в GA4 и включите конверсии

Передайте рекомендованные события (view_item, add_to_cart, begin_checkout, purchase) и пометьте purchase как конверсию. Это ядро для отчетов по доходу и атрибуции.
- Убедитесь, что параметры items содержат хотя бы item_id или item_name.
- Не передавайте в параметрах PII (email/телефон/ФИО, комментарии менеджера).
Настройте e-commerce в Яндекс Метрике и сопоставьте с GA4

Включите электронную коммерцию и убедитесь, что структура корзины/покупки совпадает по логике с GA4 (даже если поля отличаются). Это упростит сверку.
- Проверьте, что события дохода не приходят с задержкой или пачкой после оплаты.
- При необходимости заведите цель "покупка" дополнительно (например, по событию e-commerce).
Провалидируйте атрибуцию и качество данных

Сделайте несколько тестовых заказов из разных источников (органика/контекст/UTM) и сверьте: источник, сумма, transaction_id, число покупок. Это финальный контроль перед тем, как масштабировать настройка целей в Google Analytics 4 и рекламную оптимизацию.
- Проверьте, что UTM не "затираются" редиректами и платежными доменами.
- Проверьте кросс-домен (если оплата на другом домене/поддомене).

Если вам нужно быстро закрыть весь контур (события + цели + e-commerce + валидация) и нет ресурсов внутри команды, практичный вариант - заказать настройку веб аналитики с фиксированным ТЗ и приемкой по чек-листу ниже.

Оценка трафика и кампаний: события для источников и UTM

Задача блока - сделать так, чтобы можно было честно сравнивать рекламные кампании и посадочные страницы. Здесь важно не столько количество событий, сколько корректная разметка, отсутствие саморефералов и единый стандарт UTM.

utm_validation (проверка разметки) - приоритет: средний. Не отдельное событие для пользователя, а внутренняя проверка/логика в GTM.
outbound_click - приоритет: низкий/средний. Полезно, если вы ведете на внешние сервисы (прайсы, партнеры).
call_tracking_lead - приоритет: высокий (если коллтрекинг). Должен связываться с источником/кампанией.
crm_status_won - приоритет: средний. Если есть интеграция с CRM, помогает считать качество лидов (без ПДн).

Чек-лист проверки результата (после того как вы "настроить аналитику на сайте" и включили конверсии):

UTM-метки сохраняются после редиректов (http→https, www, слэш) и не пропадают при переходах внутри сайта.
Нет саморефералов (ваш домен не появляется как источник визита/покупки).
Конверсии (лид/покупка) видны в GA4 как Conversions и в Метрике как цели/достижения.
События не дублируются при обновлении страницы, возврате назад, повторном клике.
Тестовая кампания с UTM отображается корректно по источнику/каналу/кампании.
Кросс-домен настроен, если платеж/форма на отдельном домене или поддомене.
Параметры URL с потенциальной PII не попадают в отчеты (очищены/замаскированы).
В Метрике и GA4 одинаково трактуются ключевые конверсии (одно и то же условие успеха).

Техметрики и поведение: ошибки, время загрузки и клики по важным элементам

Технические и поведенческие события помогают объяснить "почему просела конверсия", когда трафик не менялся. Делайте их дозированно, чтобы не утонуть в шуме и не собрать лишние данные.

Ошибка №1: событие отправляется "на клик по кнопке", а не "на успешный результат" (особенно формы и оплаты) - конверсии завышаются.
Ошибка №2: один и тот же триггер повешен и в коде, и в GTM - двойные события и двойные конверсии.
Ошибка №3: нет фильтрации тестовых действий (менеджеры/разработчики "накликивают" статистику).
Ошибка №4: в события попадают поля форм или query-параметры с ПДн (email/телефон/ФИО) - риск блокировок и юридических проблем.
Ошибка №5: клики считаются по CSS-классам, которые часто меняются - события "ломаются" после релиза.
Ошибка №6: важные кнопки отслеживаются без контекста (не передается идентификатор товара/страницы) - отчеты не применимы.
Ошибка №7: нет мониторинга 404/500 и JS-ошибок - падение конверсии заметно слишком поздно.

js_error - приоритет: средний. Отправляйте только тип/код/страницу, без пользовательских данных.
page_load_issue - приоритет: низкий/средний. Сигнализирует о проблемных страницах (например, через собственные пороги/события).
cta_click (клик по ключевому CTA) - приоритет: средний. Делайте на уровне стабильных атрибутов (data-*) вместо классов.
search_use (поиск по сайту) - приоритет: средний. Полезно для контента и ассортимента; запросы очищайте от PII.

Риски и соответствие: управление персональными данными и минимизация ошибок учета

Если вы не можете безопасно или стабильно реализовать события "в лоб", выбирайте альтернативный подход, который снижает риски и упрощает поддержку.

Серверная отправка ключевых конверсий - уместно для purchase/успешной оплаты и лидов из CRM. Меньше дублей, проще контроль, легче исключить PII (передаете только обезличенные идентификаторы и суммы).
Единый DataLayer-контракт - уместно при частых изменениях интерфейса. События привязаны к бизнес-логике, а не к верстке; проще поддерживать настройка событий в GA4 и Метрику.
Минимальный "MVP измерений" на 2-4 недели - уместно, когда нет уверенности в определениях лида. Ставите 3-5 событий высокого приоритета, валидируете, затем расширяете.
Аудит и приемка по чек-листу вместо расширения трекинга - уместно, когда конверсий мало и важнее качество: дубли, саморефералы, утечки PII, корректность источников.

Практически: сначала обеспечьте безопасную базу (лид/покупка/контакты), затем переходите к расширению. Отдельно проверьте, что настройка целей в Яндекс Метрике и GA4 опирается на одинаковые условия "успеха", иначе цифры будут конфликтовать.

Практические ответы по типичным проблемам настройки

Почему цели по форме считаются, но лидов в CRM меньше?

Чаще всего цель стоит на клик по кнопке, а не на успешный ответ сервера. Перенесите триггер на "успех" (thank-you/статус) и добавьте защиту от повторной отправки.

Как правильно сделать настройку целей в Google Analytics 4 для лидов?

В GA4 создайте/получите событие успешной отправки (например, lead_submit) и отметьте его как Conversion. Убедитесь, что событие срабатывает один раз на один успешный лид.

Как выполняется настройка целей в Яндекс Метрике, если нет GTM?

Используйте цели по посещению страницы "спасибо" или по клику, но это менее надежно. Если есть разработчик, попросите добавить reachGoal/событие в код на успешном результате.

Почему в GA4 мало событий или они приходят с задержкой?

Проверьте блокировщики, Consent Mode/согласие, корректность контейнера GTM и то, что событие отправляется на прод-домене. Для диагностики используйте DebugView и тестовые сценарии.

Как избежать дублей purchase при перезагрузке страницы?

Передавайте уникальный transaction_id и блокируйте повторную отправку при уже зафиксированном ID. Лучше отправлять purchase по подтвержденному статусу заказа (сервер/бекенд).

Что нельзя отправлять в события и параметры?

Нельзя передавать персональные данные: email, телефон, ФИО, адрес, любые идентификаторы, которые прямо идентифицируют человека. Очистите URL-параметры и не кладите значения полей форм в аналитику.

Когда имеет смысл заказать настройку веб аналитики вместо самостоятельной?

Когда нет доступа к коду/GTM, требуется e-commerce и кросс-домен, или важна юридическая чистота данных. В договоренности закрепите список событий, критерии "без дублей/без PII" и процедуру приемки.