Как связать рекламную ссылку с заявкой, оплатой и возвратом

В отчете есть переходы, в CRM есть заказы, но между ними нет связи. Маркетолог видит активность, менеджер видит продажи, а ответить на вопрос «какая ссылка привела этот заказ?» никто не может. Для этого недостаточно просто поставить счетчик: нужно сохранить связь между посещением и результатом.

В Teeb такая связь строится через идентификатор перехода и события с сервера магазина или CRM. Разберем путь данных, ошибки интеграции и учет возвратов. Это инструкция по измерению результата, а не обещание определить источник каждой покупки.

Атрибуция - правило, по которому результат относят к источнику. Человек мог увидеть пост, перейти по рекламе, вернуться по закладке и оплатить через неделю. Ответ зависит от того, какие касания система сохранила и какое правило применяет.

В Teeb для выбранных ссылок на подтвержденный сайт к адресу добавляется параметр _teeb_click. Магазин должен сохранить его и передать в событии как click_id. Сервис проверяет идентификатор и период привязки, затем связывает результат с данными перехода.

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

1. Откройте раздел «Покупки и заявки» и создайте подключение для своего сайта.
2. Выберите тестовый режим для проверки интеграции.
3. Добавьте TXT из карточки подключения и подтвердите владение сайтом.
4. Выберите ссылки, ведущие на этот сайт, и включите отслеживание.
5. Передайте разработчику настройки приема событий и серверный ключ подключения.

Подтверждение сайта магазина и подключение собственного короткого домена - отдельные действия. Если вы подтвердили go.example.com для коротких ссылок, это не означает, что автоматически подтвержден магазин на example.com.

Ключ подключения показывается при выдаче и должен храниться на сервере. Не передавайте его в адресной строке, клиентском JavaScript или публичном файле с примером.

При входе прочитайте _teeb_click и сохраните его на стороне магазина так, чтобы затем добавить к заявке или заказу. Если форма находится на другой странице, параметр не должен потеряться при внутреннем переходе. Конкретный способ хранения зависит от устройства сайта.

Особенно внимательно проверьте оплату на другом домене. Возврат с платежной страницы может не содержать исходного параметра, поэтому связь стоит хранить в самом заказе до перехода к оплате. Не восстанавливайте ее по совпадению суммы и времени.

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

Заявка означает, что пользователь оставил обращение. В Teeb для ее создания предусмотрено событие lead_created, для отмены - lead_cancelled. Договоритесь внутри команды, какое действие запускает событие: отправка формы, проверка контакта или другой явно выбранный этап.

Оплата передается событием purchase_paid после подтверждения платежа на сервере магазина. Нажатие кнопки «Оплатить» и открытие страницы успеха не всегда означают, что деньги получены. Источником должен быть проверенный статус вашей платежной системы или CRM.

Возврат передается событием purchase_refunded. Для отдельного возврата нужен устойчивый refund_id. Отмена заказа и возврат денег - разные события: не используйте отмену как замену сведениям о фактическом возврате.

События одной сущности связываются через entity_id. Для заявки и заказа используйте осмысленно разделенные идентификаторы согласно схеме интеграции. Не считайте, что совпадение текста номера автоматически превратит заявку в оплату.

Покупатель пришел по ссылке кампании и оформил заказ order-demo-42 на 10 000 руб. В заказе сохранен идентификатор перехода. После подтверждения оплаты сервер отправляет purchase_paid с суммой 1 000 000 в поле amount_minor и валютой RUB.

Через два дня возвращены товары на 2 000 руб. Отправляется purchase_refunded для того же заказа, с отдельным refund_id и суммой 200 000. Все имена и суммы в этом примере учебные.

После учета возврата остается 8 000 руб. Это сумма оплаты за вычетом возврата, а не прибыль: еще могут быть себестоимость, доставка, комиссии и расходы на привлечение. Не называйте этот показатель окупаемостью рекламы без остальных данных.

Если интеграция повторно доставит то же событие возврата, сумма не должна уменьшиться еще раз. Для этого сохраняют идентификаторы операции, а не генерируют новый номер при каждой попытке отправки.

Для каждого нового события создавайте event_id и сохраняйте его вместе с исходным содержимым. Если ответ потерялся, повторяйте то же событие с прежним event_id. Измененные данные под уже использованным идентификатором вызывают конфликт.

События подписываются на сервере по правилам API Teeb. При повторной доставке сохраняется смысл и содержимое события, а подпись формируется с актуальным временем. Здесь не используется Idempotency-Key из API создания коротких ссылок: это другой механизм.

Суммы передавайте целыми числами в минимальных единицах валюты. Для RUB это копейки. Не отправляйте имена, телефоны и email покупателей: для связи достаточно непрозрачных идентификаторов. Точная схема и правила подписи находятся в документации событий, а в карточке подключения доступны PHP-отправитель и пример магазина.

После приема событие обрабатывается в очереди. Проверяйте его итоговый статус и код причины в журнале событий. Ответ о приеме подтверждает доставку, но не гарантирует успешную привязку к ссылке.

Например, возврат может попасть в систему раньше события оплаты из-за порядка доставки. Он может ожидать оплату; это отличается от ошибки суммы или валюты. Не исправляйте все такие случаи удалением истории и повторной отправкой с новыми номерами.

Если результат остался без привязки, проверьте: был ли передан click_id, относится ли он к этому подключению, не произошло ли событие раньше перехода и не вышло ли за период привязки. В настройках источника Teeb период задается в днях; его изменение применяется к будущим переходам.

Ваш сайт передал один сохраненный идентификатор, а другая система могла применить собственную модель атрибуции и историю посещений. Например, Метрика описывает несколько моделей, которые по-разному распределяют результат между источниками.

Перед сравнением согласуйте период, часовой пояс, валюту, статус заказа и правило привязки. Уточните, по дате чего построен отчет: перехода, оплаты или возврата. Не складывайте рубли с другой валютой в одну сумму и не сравнивайте заявки одной системы с оплаченными заказами другой.

Непривязанные результаты полезно оставлять видимыми. Это помогает заметить потерянный параметр или пробел в интеграции. Распределять их по каналам наугад ради красивого отчета хуже, чем честно видеть долю неизвестного источника.

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

Тестовые и рабочие результаты в Teeb разделены. После успешной проверки настройте рабочее подключение с соответствующим ключом и подтверждением сайта. Следите за очередью ошибок и сроком действия ключа, чтобы продажи не исчезли из отчетов незаметно.

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