От нажатия до оплаченной сделки
На сайте с прямыми контактами посетитель нажимает телефон или мессенджер. Событие Метрики фиксирует этот шаг, если аналитика доступна, но дальнейший разговор происходит вне страницы. Подтвердить его можно по фактической переписке, журналу звонков или записи сотрудника.
- Названия статусов в таблице условные. При внедрении их сопоставляют с действующим процессом компании. Один человек может пройти все этапы, поэтому складывать эти события в число клиентов нельзя.
На телефоне таблицу можно прокрутить вправо.
| Этап | Пример записи | Источник | Что известно |
|---|---|---|---|
| Нажатие контакта | contact_phone / contact_telegram | Событие сайта | Контактом воспользовались |
| Общение состоялось | contact_received | Журнал звонков, переписка, CRM | Есть реальный запрос |
| Запрос подходит | qualified | Статус и комментарий сотрудника | Соответствует согласованным критериям |
| Сделка оплачена | paid | Первичная учётная система | Подтверждена оплата |
Если на сайте есть форма
Разведите попытку отправки, успешную передачу и фактическое получение обращения. Положительный ответ API может означать только принятие сервисом: проверьте его смысл и получение записи в целевом канале. Прочтение человеком — ещё один отдельный факт.
Событие успеха показывают только после предусмотренного подтверждения. Проведите тест успешной отправки и ошибки; убедитесь, что тестовая запись дошла и помечена для исключения из отчёта. Для сайта без форм этот сценарий не нужен: измеряются его реальные контактные действия.
Как связать источник без лишних данных
UTM-метки описывают рекламный источник и кампанию. Они не должны содержать телефон, email или имя покупателя. Для внутренних примеров используйте синтетические идентификаторы: L-001, L-002. Реальные правила связи с CRM определяют по доступным полям и функциям интеграции.
Проверьте, какие события видны при отказе от аналитики и при блокировщике. Если часть контактов не измеряется, отразите это ограничение, вместо того чтобы приравнивать счётчик к полной базе обращений.
Пример устранения дублей
В примере связь записей уже известна. В реальной работе её нельзя угадать по близкому времени событий: нужны разрешённый идентификатор или подтверждение сотрудника. Правила повторного обращения и новой задачи фиксируют заранее.
На телефоне таблицу можно прокрутить вправо.
| Запись | Что произошло | Решение при сверке |
|---|---|---|
| L-001 / событие A | Нажатие телефона | Сохранить как контактный клик |
| L-001 / запись B | Сотрудник подтвердил разговор | Один состоявшийся контакт по тому же запросу |
| L-001 / запись C | Повторный вопрос по этой задаче | Не создавать второй уникальный лид |
| L-002 / запись D | Другой подтверждённый запрос | Учесть отдельный лид |
Ежемесячная сверка
- Выберите один период, часовой пояс и определения показателей.
- Сопоставьте расходы, события сайта и записи первичной системы.
- Исключите тесты, дубли и нецелевые запросы по зафиксированным правилам.
- Отдельно отметьте обращения без источника и незакрытые сделки.
- Объясните расхождения до расчёта стоимости лида или окупаемости.
Цены и сценарии актуальны на дату обновления и не являются гарантией результата. Перед запуском нужен расчёт по конкретной нише, географии и воронке.