Как проследить путь от клика до подтверждённой комиссии

ShopTools AI позволяет проверить промокоды и отдельно выбрать партнёрский переход. Подтверждённое снижение суммы не является покупкой, а клик не является комиссией. Для диагностики нужны события по обе стороны каждой границы.

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

Сначала определите смысл событий

• Track означает выбранный разрешённый партнёрский маршрут. Fallback означает запасной путь; вместе с режимом сохраняйте причину. Ни один режим не доказывает загрузку магазина.
• Landing обозначает наблюдавшееся попадание на ожидаемый домен. Не создавайте его синтетически из успешного ответа resolver.
• Scan описывает прогон очереди. Apply разделяйте на обнаружение поля, отправку и ответ; измеренное снижение суммы является отдельным результатом.
• Postback означает уведомление сети. Получение, сопоставление, подтверждение комиссии и выплата являются разными состояниями.

Показ карточки, копирование и открытие popup не являются применением. На сайте переход может предшествовать проверке; в расширении добровольная активация может следовать после неё. Стройте связи событий, не навязывая один линейный путь.

Разделите click, scan и checkout

В предлагаемой схеме checkout_id объединяет контекст оформления, scan_id обозначает прогон с попытками, а click_id обозначает намерение перейти. Новому переходу нужен свой ключ; parent_click_id сохраняет связь, но не заменяет дочерний ID.

Offer ID, сеть, target host и хеш кода служат контекстом, а не ключом продажи. Reload должен сохранять идентичность незавершённого прогона. Два запуска не следует объединять только потому, что проверялся одинаковый промокод.

Отсутствие события не является диагнозом

Для этапа различайте observed, not_observed и unobservable. Событие landing может отсутствовать из-за закрытой вкладки, блокировки, отказа скрипта или потери идентификатора. Разницу счётчиков нельзя сразу объявлять потерянными визитами.

Причины проверки также разделяйте: not_cart, field_missing, button_missing, none, submitted_unconfirmed и restore_failed. Неизвестный результат не является отказом магазина, а ненайденное поле не означает неработающий код.

Postback требует проверки и истории

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

Связывайте разрешённый subid с click_id и проверяйте сеть, оффер и временной контекст. При отсутствии связи оставляйте запись unmatched. Не приклеивайте её к последнему клику или одному хешу кода ради полного графика.

Сверяйте принятые уведомления с отчётом сети: статусы, сумму, валюту, комиссию и поздние изменения. Подтверждённую комиссию отделяйте от ожидаемой и фактически выплаченной. Ноль postback не доказывает ни отсутствие покупок, ни вину сети.

Сведите данные до расчёта конверсий

1. Выберите единицу анализа: событие, click_id, scan_id или транзакция. Не делите события одного уровня на людей другого.
2. Согласуйте период, часовой пояс, задержку поступления и версии схем. Отделите тестовый трафик и legacy-события.
3. Проверьте пропущенные ID, повторные записи, ошибки валидации и задержку телеметрии; затем сверяйте агрегат с исходными строками.
4. Выберите один необъяснимый разрыв и воспроизведите разрешённый сценарий. Исправляйте наблюдение или поведение по доказательствам, а не одновременно все части воронки.

Минимизируйте диагностический след

В проекте ограничьте payload причиной, версией, доменом, идентификаторами и нужными техническими признаками. Не отправляйте полный DOM, значения полей, товары или URL с токенами. Даже селектор может содержать данные и требует фильтрации.

Задайте срок хранения, доступ и дедупликацию причины в пределах сессии, чтобы один observer не породил поток повторов. Это требования к проекту, а не утверждение, что ShopTools ничего не собирает или обрабатывает всё только локально.

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