Mindbox и Tilda: какие события описать до подключения маркетинговых сценариев
Как составить план событий сайта для Mindbox: смысл действия, источник подтверждения, поля, идентификаторы и проверка качества данных перед запуском сценариев.
Сначала определите, какое решение должен запускать каждый сигнал с сайта. Чем точнее смысл события и условия его отправки, тем проще проверить маркетинговый сценарий и найти ошибку.
Начните с действия, ради которого собираете данные
Запрос «передавать все действия посетителя» не объясняет, зачем бизнесу каждый сигнал. Начните с нескольких конкретных задач: сохранить обращение, учесть интерес к категории, остановить неуместное сообщение после покупки. Затем определите минимальные данные, без которых эта задача не работает.
События без понятного применения увеличивают объём настройки и затрудняют разбор. Если команда пока не знает, что делать с показом каждого декоративного блока, такой сигнал можно отложить. Первую версию легче проверить на ограниченном наборе действий с ясным результатом.
Дайте каждому событию точное определение
Название «покупка» недостаточно: человек мог нажать кнопку, оформить заказ или завершить оплату. Для каждого события запишите момент отправки и систему, которая подтверждает факт. Просмотр страницы благодарности сам по себе не доказывает, что деньги поступили.
В официальной инструкции Mindbox описаны передача контактов из форм Tilda и действий на сайте через GTM. Конкретный способ подключения, операции и допустимый состав данных выбирают для проекта. Внедрение трекера не заменяет проектирование событий и проверку подтверждённых покупок.
| Сигнал | Что нужно определить |
|---|---|
| Просмотр товара | Какой товар и когда просмотр считается состоявшимся |
| Отправка обращения | Успешная отправка какой формы |
| Создание заказа | Идентификатор и подтверждённый состав |
| Оплата | Источник подтверждения и связь с заказом |
| Отмена | Какое действие прекращает дальнейший сценарий |
Разделите данные события и данные клиента
Сумма и состав относятся к конкретному заказу, а контакт — к профилю. Не стоит заменять историю покупок последним значением поля «любимый товар», если оно вычисляется случайным просмотром. Данные должны позволять восстановить действие и его контекст.
Решите, какие идентификаторы передаются и как ведёт себя сценарий, пока посетитель не определён. Не связывайте людей только по похожему имени. Для каждого поля отметьте источник, обязательность и поведение при отсутствии значения. Состав передаваемых контактов согласуйте с действующими настройками согласий и обработки данных.
Проверьте повторы и запоздавшие сообщения
Одно действие может прийти повторно после обновления страницы или сетевого сбоя. Определите, где повтор допустим как новое наблюдение, а где он должен быть распознан как уже обработанный факт. Две реальные покупки и две доставки одного сообщения нельзя различать только по телефону.
Отдельно проверьте порядок событий. Если подтверждение оплаты пришло позже создания заказа, сценарий должен учитывать это изменение. Если отмена уже известна, старый сигнал не должен снова возвращать заказ в активную коммуникацию. Правила зависят от конкретной цепочки и требуют проверки на примерах.
Сверьте технические события с реальной историей
Пройдите путь тестового посетителя: просмотр, форма, заказ, подтверждение и отмена там, где она предусмотрена. Составьте ожидаемую последовательность и сравните её с журналом передачи и результатом в Mindbox. Проверяйте не только наличие записи, но и поля, профиль и отсутствие лишних запусков.
PXL Perfect подключает Mindbox к Tilda под согласованные сценарии. Начать обсуждение можно с такой таблицы событий и одного маршрута клиента. Это позволит оценить нужные операции, выделить серверные подтверждения и запускать коммуникации после проверки качества данных.