Ссылки из письма: редиректы, UTM и проверка заказа
Проверка ссылки из письма до заказа: сохранение UTM на редиректах, различие клика и сессии, события оплаты и безопасные тестовые данные.
В редакторе письма ссылка выглядит правильно, после отправки оборачивается трекером, затем страница делает ещё один редирект. Итоговые UTM могут потеряться на любом переходе. Проверять надо полученное письмо, а не только URL, который вставили в шаблон.
Карта перехода на одну строку
Запишите исходный адрес, адрес трекера сервиса, промежуточные переходы и конечный URL. Для каждого шага отметьте, сохраняется ли query string и открывается ли нужный товар или предложение. Мобильное приложение и браузер могут вести по разным маршрутам, поэтому проверяйте те сценарии, которые реально доступны аудитории.
Справка Google Analytics по UTM описывает source, medium, campaign и content. Для теста используйте вымышленные идентификаторы кампании; email, телефон и имя в URL не нужны. Параметры могут попасть в историю браузера и журналы.
Проверка без настоящего заказа клиента
- Отправьте разрешённое тестовое письмо на свой технический адрес.
- Нажмите каждую содержательно разную ссылку: кнопка, текст, карточка товара.
- Проверьте конечный адрес и доступность предложения на компьютере и телефоне.
- В тестовой среде либо согласованном безопасном сценарии проверьте событие полезного действия.
- Сверьте источник и идентификатор транзакции в доступной отладке, не публикуя данные покупателя.
Не создавайте реальную оплату только ради проверки метки, если это не разрешённый тест. Когда сквозной сценарий недоступен, честно зафиксируйте границу: переход и параметры подтверждены, передача покупки пока не проверена.
Что означает каждое расхождение
| Наблюдение | Возможная причина | Следующая проверка |
|---|---|---|
| Клик есть, страница не открылась | Ошибка редиректа или назначения | Конечный HTTP и путь |
| Страница открылась, источника нет | Потеря параметров или настройки аналитики | Финальный URL и событие |
| Заказ в CRM есть, события нет | Ошибка отправки purchase | Серверный реестр и отладка |
| Один заказ пришёл несколько раз | Повторная отправка события | Идентификатор заказа |
Это список гипотез для проверки, а не автоматические диагнозы. Блокировка аналитики тоже может дать разрыв между человеком на сайте и отсутствующей сессией. Email-клик и веб-сессия измеряются разными системами и не обязаны совпадать по количеству.
UTM не заменяют идентификатор заказа
Для покупки нужен устойчивый уникальный идентификатор. Google Analytics использует transaction_id для дедупликации web-покупок. Параметры кампании описывают касание, но не позволяют определить, что две строки относятся к одному заказу.
Подробная сверка разобрана в статье об одном заказе в двух отчётах. Не переносите адрес отслеживания письма в публичную документацию: в нём может находиться персональный токен контакта.
Сохраните результат проверки
В рабочем протоколе достаточно даты, версии шаблона, типа устройства, сценария, ожидаемого и фактического результата. Скриншот полезен, но не заменяет список проверенных переходов. При изменении домена, трекера или редиректа повторите затронутую часть пути.
Возвращайте вывод в email-процесс. Для анализа дальнейших продаж понадобится учёт возвратов, а для очистки исходного сигнала — проверка автоматических кликов. Исправленная ссылка доказывает рабочий переход, а не будущую окупаемость кампании.
Длинная ссылка должна сохранять смысл
Проверьте значения с пробелами, кириллицей и уже существующими параметрами. Повторное кодирование может изменить адрес, а неудачное добавление знака вопроса — потерять часть запроса. Не исправляйте это вручную в каждом письме: единое правило сборки ссылок легче проверять и поддерживать. Для примеров используйте тестовый домен и вымышленные названия, не персональные маркеры получателя.
Ссылка после авторизации или перехода в приложение иногда теряет исходный контекст. Решите, какой источник должен сохраниться и в каком событии он проверяется. Если система не умеет связать веб-переход с заказом в другом канале, это ограничение измерения. Его нельзя закрыть предположением, что все заказы с промокодом обязательно пришли из одного письма.
После изменения шаблона повторите проверку хотя бы затронутых типов ссылок. Удобно хранить список: место в письме, ожидаемое предложение, конечная страница, параметры и проверенный результат. Тогда поломка одной кнопки не потеряется среди общих цифр кампании. Отдельно проверьте срок действия предложения: технически рабочая ссылка на уже недоступную акцию тоже нарушает пользовательский сценарий, хотя сервер честно возвращает успешный статус.