Настройку аналитики удобно принимать по карте событий: короткому документу, где каждое действие связано с точным условием и контрольной проверкой. По нему заказчик понимает, что измеряется, а разработчик — в какой момент отправлять событие. Карта остаётся у команды после завершения подключения.
Ниже — заполняемый пример для сайта услуг с одной формой. Это учебная постановка, а не результаты измерений DDRW. Общую логику метрик, воронок и источников мы разобрали в руководстве по аналитике сайта. Здесь задача уже: согласовать пять действий и проверить конкретную настройку.
Если нужна реализация, пакет настройки аналитики и событий включает один действующий сайт, одну систему и до пяти согласованных событий на существующих элементах.
Начните с границы измерения
Предположим, компания принимает заявки на разработку сайта. На странице можно выбрать направление, открыть форму, отправить обращение или перейти в мессенджер. Сначала владелец определяет, какие вопросы хочет решать: находят ли люди форму, где возникает ошибка, доходит ли попытка до подтверждённого сохранения.
Для карты запишите адрес сайта, выбранную систему, номер счётчика или ресурс, перечень страниц и ответственного со стороны бизнеса. Отдельно укажите условия диагностической проверки: браузер, устройство, состояние согласия на аналитику и способ исключения тестовых данных из рабочих выводов.
Пять событий — объём этого примера, а не обязательный минимум для любого сайта. Если выбора направления нет, замените строку существующим полезным действием. Разработка нового переключателя только ради отчёта не относится к подключению аналитики.
У каждого события должен быть один владелец смысла. Маркетолог объясняет, зачем оно нужно; разработчик показывает точку отправки; принимающий работу сверяет условие с поведением сайта. Название само по себе этого договора не заменяет.
Заполните карту пяти действий
Идентификаторы в таблице условные. Их адаптируют к выбранной системе и существующим настройкам, проверяя, не собирается ли тот же факт автоматически или другим обработчиком.
| Событие | Когда отправлять | Когда не отправлять | Контрольная проверка |
|---|---|---|---|
service_select | Посетитель изменил направление в существующем переключателе | Начальное значение установилось при загрузке | Выбрать другое направление и сверить его код |
contact_open | По действию посетителя форма действительно открылась | Кнопка нажата, но форма не появилась | Открыть форму и увидеть один вызов за это открытие |
brief_error | Попытка отправки завершилась показом согласованной ошибки | Человек только печатает в поле | Отправить форму без обязательного контакта и проверить код ошибки |
brief_saved | Приложение подтвердило сохранение новой заявки | Получен только клик, начался запрос или произошёл отказ | Отправить учебную заявку и сверить подтверждённую запись |
messenger_click | Активирована ссылка на выбранный мессенджер | Ссылка просто появилась в видимой части экрана | Нажать ссылку и проверить код канала |
Для ошибки достаточно категории вроде contact_missing. Полный текст введённого сообщения или контакт посетителя в событие не включают. Для направления используют ограниченный справочник, например website и portal, а не произвольную строку из формы.
В Метрике пользовательская цель может передаваться методом reachGoal. Идентификатор связывают с соответствующей целью в счётчике. Вызов метода подтверждает отправку аналитического сигнала; содержание бизнес-события всё равно определяет команда сайта.
Разделите заявку, клик и последующий разговор
В примере brief_saved означает, что сайт подтвердил сохранение обращения. Это ещё не означает, что менеджер прочитал его, клиент подходит по задаче или заключён договор. Для следующих этапов нужны данные соответствующей системы и отдельный объём интеграции.
messenger_click показывает намерение перейти в канал связи. Человек может не открыть приложение, не написать сообщение или обратиться позже с другого устройства. Поэтому складывать такие клики с сохранёнными заявками под названием «полученные лиды» без пояснения нельзя.
В журнале приёмки удобно записать: «Заявка сохранена на сайте, событие появилось в диагностике». Если подтверждение сайта есть, а аналитического сигнала нет, ищут причину в сборе. Если события есть, а записи заявки нет, пересматривают точку отправки. Числа проверяют вместе с их значением.
Доставка заявки сотруднику — самостоятельная часть маршрута. Её можно разобрать по спецификации подключения Telegram или CRM, сохраняя разные критерии приёмки для аналитики и передачи обращения.
Проверьте дубли, возврат назад и ошибки
Пройдите обычный сценарий один раз, затем повторите его после перехода в другой раздел сайта. Для сайта без полной перезагрузки это особенно важно: форма может создаваться заново, а старый обработчик — оставаться активным. Повторная подписка способна породить два сигнала на одно действие.
Проверьте отдельно двойное нажатие, возврат назад, закрытие и повторное открытие формы, ошибку валидации, отказ сервера и повтор после отказа. Ожидаемое количество записывают заранее. Второе осознанное открытие формы может быть новым событием; повторный ответ о той же сохранённой заявке не становится новой заявкой.
Для просмотров страниц в GA4 также согласуют один способ учёта. Документация Google о page_view объясняет риск дублей при одновременном автоматическом и ручном сборе. У сайта с переходами через History API проверяют настройки истории отдельно: одного изменения начальной конфигурации может быть недостаточно.
Отсутствие дубля в одном сценарии не доказывает отсутствие всех возможных повторов. В акте приёмки перечислите проверенные пути и известные ограничения, чтобы результат можно было воспроизвести после следующего изменения сайта.
Передавайте безопасные параметры и сохраняйте протокол
Для этого примера достаточно кода направления, места формы, категории ошибки и канала мессенджера. Имя, телефон, email, текст обращения и секретные параметры ссылок аналитике не нужны. Google отдельно описывает ограничения на передачу персонально идентифицирующих сведений, в том числе через URL и заголовки страниц.
Способ уведомления и согласия на аналитику владелец согласует до подключения. Проверка не должна обходить отказ посетителя, ограничения браузера или блокировщик ради красивого отчёта. Если сбор ограничен, это фиксируют как условие, а не скрывают расхождение с административной системой.
Передаваемый комплект можно собрать из трёх листов: карта событий; журнал контрольных действий с датой, средой и результатом; инструкция, где найти настройки и кому сообщить об ошибке. На скриншотах диагностики не должно быть реальных контактов или ключей доступа.
Критерий завершения конкретен: у каждого согласованного события есть понятное условие, контрольный вызов в доступной диагностике и проверка отсутствия лишних вызовов в описанном сценарии. Настройка счётчика не обещает рост продаж и не заменяет анализ качества обращений.
Что входит в пакет DDRW
Настройка аналитики и событий рассчитана на один существующий сайт и одну систему: Яндекс Метрику или Google Analytics 4. В пакет входят до пяти согласованных событий, карта и показ проверки. Доступы и техническую возможность внедрения согласуем перед началом.
Электронная коммерция, CRM, серверное отслеживание, BI-панели, новые формы и юридическая оценка правил обработки данных требуют отдельной задачи. Актуальные цена и условия находятся в карточке услуги. До заказа достаточно подготовить адрес сайта и список действий, смысл которых вы хотите видеть в отчёте.
