Сохраните Transaction ID в браузере: чек-лист для Amplitude

Сохраните Transaction ID в браузере: чек-лист для Amplitude

Если у вас в B2B или e-com часть пути живёт между каналами, сессиями и устройствами, Transaction ID лучше не терять. Ниже — практический порядок действий, чтобы потом связывать событие, заказ и выручку без ручных костылей.

— **Определите, где рождается Transaction ID.**
Зафиксируйте единственный источник: форма, checkout, CRM-событие или серверный ответ.
Важно, чтобы ID создавался до передачи в аналитику и не менялся по дороге.

— **Запишите ID в браузерное хранилище.**
Сохраните значение в cookie и/или localStorage, если пользователю нужно вернуться позже.
Cookie удобнее для короткой жизни и передачи между страницами, localStorage — для более долгого удержания значения.

— **Проверьте срок жизни и логику очистки.**
Определите, когда ID должен исчезать: после успешной покупки, отмены или по тайм-ауту.
Если не чистить значение, можно получить дубли и ошибочную атрибуцию в последующих сессиях.

— **Передавайте ID в Amplitude как свойство события.**
Добавляйте Transaction ID в ключевые события: начало оформления, оплату, подтверждение заказа.
Так вы сможете связать фронт, сервер и отчёты по выручке в одной цепочке.

— **Синхронизируйте браузер и сервер.**
Проверяйте, что один и тот же Transaction ID уходит и из клиентского кода, и из серверной интеграции.
Это особенно полезно в privacy-first архитектуре, где last-click уже не даёт полной картины.

— **Сверьте случаи возврата пользователя.**
Если человек вернулся на сайт с тем же ID, убедитесь, что система не создаёт новый дубль.
Иначе ломается кросс-сессионная связка и портятся отчёты по конверсии.

Когда это пригодится: при настройке сквозной аналитики, ревенью-цепочек и проверки заказов в Amplitude, особенно если вы строите RevOps-модель и хотите меньше ручной сверки.

— @AmplitudeCookbookRuPro