Ценность заказа передаётся без скидки: как исправить аналитику

В корзине одновременно существуют сумма позиций, скидка, бонусы, доставка, налог и итог к оплате. Если frontend берёт исходный subtotal, а backend и рекламная система ожидают net revenue, один заказ получает разные значения в интерфейсе, CRM и аналитике.

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

Что проверить в первую очередь

Для проблемы «в событие конверсии передаётся сумма заказа до скидки» сначала зафиксируйте один воспроизводимый пример: точное время, идентификатор объекта, пользователя или операции, входные данные, версию приложения и фактический результат. Отдельно запишите ожидаемое поведение: событие содержит документированную фактическую ценность, валюту и идентификатор заказа, а скидки, доставка, налог и возвраты учитываются одинаково во всех каналах. Это не формальность. Без исходной точки легко принять временное совпадение за исправление, изменить сразу несколько условий и потерять возможность доказать настоящую причину сбоя.

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

• Зафиксируйте точное определение метрики value для каждой системы.
• Сверьте subtotal, item_discount, order_discount, bonus, shipping, tax и grand_total.
• Проверьте валюту и единицы измерения: рубли либо копейки.
• Убедитесь, что frontend не отправляет событие до окончательного перерасчёта заказа.
• Проверьте дубли client-side и server-side события по transaction ID.

Почему возникает проблема

Видимый симптом обычно находится в конце цепочки. Пользователь видит неверный статус или отказ, хотя первичная ошибка могла произойти в API, фоновой задаче, кеше, очереди, внешнем сервисе либо при проверке доступа. Основной риск этого сценария: рекламные отчёты завышают выручку и окупаемость, из-за чего алгоритмы оптимизации и бизнес-решения получают неверный сигнал. Поэтому исправление только интерфейса или ручная правка итоговой записи часто скрывает проблему, но не устраняет её.

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

• В шаблон аналитики подставляется catalog price вместо фактической цены строки заказа.
• Промокод применяется после формирования события purchase.
• Скидка хранится отрицательным числом и ошибочно вычитается дважды или прибавляется.
• Серверная интеграция передаёт сумму платежа, а браузерная — сумму товаров до скидки.
• Возврат корректирует заказ, но не отправляет adjustment в аналитику.

Пошаговая диагностика

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

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

• Снимите payload события непосредственно перед отправкой, не полагаясь только на интерфейс отладчика.
• Сопоставьте transaction ID с неизменяемым снимком строк заказа на момент оплаты.
• Пересчитайте value из quantity, final unit price и распределённой скидки.
• Проверьте округление на уровне строки и заказа для нескольких ставок налога.
• Найдите один transaction ID в браузерных и серверных потоках и проверьте дедупликацию.

Как определить ценность заказа для аналитики

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

Надёжная реализация хранит бизнес-состояние явно и не пытается восстановить его только по экрану, случайному логу или последнему webhook. У каждого значимого действия должен быть стабильный идентификатор, понятный владелец, версия правила и проверяемый переход статуса. Повторная доставка одного события не должна создавать второе действие, а запоздавшее событие не должно возвращать объект в невозможное состояние.

• Order totals рассчитываются в одном сервисе и сохраняются вместе с версией формулы.
• Событие purchase формируется из подтверждённого снимка, а не из текущей корзины браузера.
• Каждая сумма передаётся в одной валюте и одной единице.
• Transaction ID стабилен для дедупликации клиентского и серверного каналов.
• Refund или adjustment ссылается на исходный заказ и корректирует выбранную метрику.

Как исправить проблему

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

Если затронуты существующие записи, сначала сформируйте dry-run: список объектов, старое значение, предлагаемое новое значение и основание для изменения. Обновление должно быть идемпотентным, ограниченным точной выборкой и сопровождаться аудитом. Для финансовых данных, прав доступа и персональной информации предпочтительны компенсирующие записи, а не переписывание истории.

• Создайте единый серверный mapper заказа в схему аналитического события.
• Передавайте final item price и отдельные поля скидки вместо восстановления суммы на стороне получателя.
• Документируйте включение доставки и налога для каждого рекламного канала.
• Отправляйте событие только после фиксации итогов оплаты и защищайте его стабильным transaction ID.
• Добавьте корректирующие события для полного и частичного возврата.

Безопасный порядок внедрения

• Сохраните конфигурацию, связанные записи и необходимые журналы; отдельно проверьте, что резервную копию действительно можно восстановить.
• Воспроизведите проблему на тестовом объекте и сохраните результат до изменения, чтобы после выпуска сравнить одинаковые сценарии.
• Внесите минимальное изменение под системой контроля версий, опишите причину, ожидаемый эффект, ограничения и точный способ отката.
• Прогоните нормальный сценарий, ошибочный ввод, повтор одного запроса, два параллельных запроса и временную недоступность зависимости.
• Выпустите изменение на ограниченную долю трафика или один процесс, если архитектура это позволяет, и сравните метрики со старой версией.
• Только после стабильного наблюдения выполните контролируемое исправление исторических данных и сохраните итоговый отчёт.

Как проверить результат

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

Критерии приёмки сформулируйте до выпуска. Каждый пункт должен давать однозначный ответ «выполнено» или «не выполнено», а не субъективную оценку. Если тест невозможно повторить автоматически, оставьте короткий регрессионный чек-лист с тестовыми данными и ожидаемыми статусами.

• Заказ без скидки совпадает в базе, платеже и аналитике.
• Промокод на заказ и скидка на позицию дают правильный net total без двойного вычитания.
• Бонусы и бесплатная доставка учитываются по утверждённой формуле.
• Повторная загрузка страницы не создаёт вторую конверсию.
• Полный и частичный возврат корректируют ценность исходного transaction ID.

Типичные ошибки при исправлении

• Исправлять число только в одном теге, оставляя серверную отправку прежней.
• Использовать цену из DOM как источник финансового события.
• Смешивать рубли и копейки либо валюты без явного кода.
• Считать скидку всегда процентом, игнорируя распределение и округление.
• Удалять старую конверсию вместо отправки поддерживаемой корректировки.

Опаснее всего исправление, которое убирает заметный симптом ценой отключения проверки, ослабления прав или потери аудита. Такое изменение может сделать интерфейс «зелёным», но увеличить ущерб при следующем сбое. Если временный обход всё же необходим, ограничьте его срок, пользователей и область действия, добавьте мониторинг и заранее назначьте дату удаления.

Как предотвратить повторение

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

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

• Расхождение суммы оплаченных заказов и value аналитических событий по дню.
• Доля событий без currency или transaction ID.
• Количество дублей одного заказа по каналам отправки.
• Сумма скидок и возвратов, не отражённых в рекламной аналитике.
• Отклонение ROAS после исправления формулы относительно бухгалтерской выручки.

Что подготовить для технического разбора

• Короткое описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время возникновения, идентификатор тестового объекта и версии всех затронутых компонентов.
• Обезличенные фрагменты журналов до и после ошибки с единым correlation ID.
• Список последних изменений, результаты уже выполненных проверок и условия, при которых симптом исчезает.
• Безопасный доступ к тестовой среде либо минимальный пример, не содержащий паролей, токенов и персональных данных.

Частые вопросы

Включать ли доставку в value?

Это зависит от цели отчёта и требований площадки. Главное — письменно зафиксировать формулу и применять её одинаково.

Что делать с налогом?

Передавать по документации конкретной системы и хранить отдельные totals, чтобы не угадывать состав общей суммы.

Можно ли брать сумму платежа?

Иногда да, но платёж может включать несколько заказов, бонусы или последующие корректировки, поэтому нужна сверка с моделью заказа.

Когда нужна помощь специалиста

Если аналитика завышает ценность заказов, я могу проверить расчёт totals, dataLayer, серверные события, дедупликацию и возвраты. Для оценки нужны обезличенный пример заказа, payload события и принятая формула выручки.