Отмена заказа в Метрике: как проверить историю целей
Смена статуса заказа не стирает ранее переданные цели: это прямо сказано в справке Метрики. Сначала определите, какое подтверждение оплаты должно давать сигнал paid, затем сравните текущее состояние заказов с историей целей. Ниже — такой разбор на шести вымышленных заказах без загрузки в Метрику и запуска рекламы.
Что понадобится
Скачайте файлы упражнения и распакуйте архив. Внутри — исходные события, условия, скрипт и сохранённые результаты. Для просмотра достаточно текстового редактора или таблицы; для повторного расчёта нужен Python 3.9 или новее. Аккаунт, токен и зарубежный платёж не нужны: упражнение выполняется локально, без сетевых запросов и платных сервисов.
Ручное время прохождения мы не измеряли. Сам скрипт в нашем запуске отработал менее секунды; это не оценка времени настройки CRM. Подробности — в записи упражнения.
1. Выберите способ передачи и смысл paid
Здесь используем полную передачу CRM с явным сопоставлением статусов, без дополнительных JavaScript-целей. Названия created, paid и cancelled — наши события; в сопоставлении статусов им назначены типы IN_PROGRESS, PAID и CANCELLED соответственно. Это схема для разбора, не готовый файл импорта.
В документации есть противоречие. Страница сопоставления статусов, относящаяся к полной передаче, обещает при CANCELLED цель «CRM: Заказ отменен». Но пример полного способа говорит, что при отмене новые цели не достигаются. Какой вариант сработает в конкретной интеграции, мы не проверяли.
В модели считаем только цели создания и оплаты; отдельную цель отмены не рассчитываем. Вывод о сохранении уже отправленных целей от этого противоречия не зависит: он отдельно подтверждён в правиле истории. Упрощённый способ здесь не моделируем: у него свой формат данных, где при PAID описаны сразу цели создания и оплаты.
До расчёта записали правило: paid означает, что получена и подтверждена вся сумма заказа. Заявка, обещание заплатить и неполная предоплата не подходят. Это наше определение сигнала для упражнения: название статуса само не проверяет платёж. Если обучать рекламу на более раннее действие, например заявку, сначала выясните, насколько оно отвечает вашей задаче; в этом разборе заявку оплатой не считаем.
Результат шага: у вас есть одна схема передачи и однозначное условие paid. Для наших данных оно записано в условиях упражнения, а каждая оплата подтверждена полями payment_confirmed и amount_received в исходном CSV.
2. Пройдите события одного заказа
Откройте events.csv из архива. В нём 15 событий для шести заказов; время задано часами от условного визита. Поля visit_linked со значениями 1 и 0 обозначают заранее заданный результат привязки, а не настоящий идентификатор посетителя. Все входы придуманы редакцией — исходный журнал.
Начните с заказа 03: created → paid → cancelled. В нашей полной схеме после создания в истории есть цель «CRM: Заказ создан», после оплаты добавляется «CRM: Заказ оплачен». Отмена меняет текущее состояние на CANCELLED, но обе цели остаются. Это применение правила истории целей: уже отправленные цели удалить из заказа нельзя, уникальная цель выполняется в заказе только один раз.
Сравните с заказом 02: created → cancelled. Оплаты у него не было, поэтому в истории остаётся только создание. Исходы обоих заказов можно проследить по строкам в журнале расчёта.
Сохраняйте один идентификатор на протяжении жизни заказа. В формате заказов id нужен для обновления статусов и связи заказа с клиентом; создание нового id на каждую смену состояния разрушит смысл нашего сравнения.
Результат шага: отмена после оплаты и отмена без оплаты дали одинаковый текущий статус, но разную историю целей.
3. Сравните две таблицы
Первая таблица показывает последнее состояние, а не число конверсий. В колонке «Возвращено» — денежный факт из учебного журнала. Отмена сама по себе не означает, что деньги уже вернулись покупателю.
| Заказ | Привязка к визиту | Сейчас | Возвращено, ₽ |
|---|---|---|---|
| 01 | Есть | PAID | 0 |
| 02 | Есть | CANCELLED | 0 |
| 03 | Есть | CANCELLED | 0 |
| 04 | Есть | PAID | 0 |
| 05 | Нет | PAID | 0 |
| 06 | Есть | CANCELLED | 8 000 |
Все строки — результат расчёта состояния. У 03 отмена уже есть, денежного возврата в журнале ещё нет. У 06 отмена и возврат показаны отдельными событиями.
Вторая таблица показывает ранее достигнутые цели создания и оплаты в привязанных визитах по правилам модели. Другие цели в неё не входят. Единица означает, что цель была достигнута для этого заказа, ноль — что в нашей истории её нет.
| Заказ | «Заказ создан» | «Заказ оплачен» |
|---|---|---|
| 01 | 1 | 1 |
| 02 | 1 | 0 |
| 03 | 1 | 1 |
| 04 | 1 | 1 |
| 05 | 0 | 0 |
| 06 | 1 | 1 |
Все строки — из истории целей, не из отчёта реального счётчика. Итого: пять созданных и четыре ранее оплаченных заказа с привязкой. Сейчас оплачены и не отменены только два привязанных заказа — 01 и 04. Четыре прошлые оплаты и два текущих оплаченных заказа — разные показатели.
Результат шага: историческая цель оплаты не равна количеству заказов, которые сейчас оплачены и не отменены. В нашем наборе расхождение объясняют 03 и 06, а не ошибка суммирования.
4. Отдельно проверьте позднюю оплату и отсутствие визита
Заказ 04 оплачен через десять суток после создания. В модели он уже привязан к визиту, а paid — обновление того же заказа. Согласно правилам привязки, заказы могут привязываться в пределах 21 дня от текущей даты; после успешной привязки изменения возможны в пределах 111 дней от начала визита. Позднее обновление уже привязанного заказа и первая отправка старого заказа — разные ситуации. Расчёт не проверяет эти окна автоматически: для 04 их соблюдение задано условием.
У заказа 05 есть оплата, но условный идентификатор не нашёл подходящего визита. В справке о привязке указано: такой заказ будет виден только в отчёте «Посетители и клиенты», не попадёт в другие отчёты; связанные цели не будут переданы в Директ. Поэтому у 05 в таблице состояния PAID, а в истории целей — нули. Это не потерянная оплата в CRM.
Для живой интеграции отдельно проверьте, какой идентификатор передаётся и нашёлся ли визит. Метрика рекомендует ClientId для более точной привязки; это правило идентификации, не основание смешивать форматы передачи. Личные данные покупателей в учебные файлы добавлять не нужно.
Результат шага: позднюю оплату не принимаем за отмену, а отсутствие привязки — за отсутствие денег.
5. Повторите расчёт и проверьте итог
В папке распакованного архива выполните:
python3 replay.pyОткройте после запуска таблицу состояния, историю целей, журнал расчёта и сводку: скрипт создаст их заново. Он завершится ошибкой, если paid не подтверждён полной суммой или результаты разойдутся с заранее записанными ожиданиями. Сеть и API не используются.
Проверьте сводку: orders — 6, current_cancelled — 3, historical_paid — 4, linked_paid_not_cancelled — 2. Полный ожидаемый итог лежит в архиве. Если итог не сходится, сначала проверьте, не заменили ли id заказа и не смешали ли историю целей с последним состоянием.
Для подготовки реальной автостратегии наш вывод такой: договоритесь, что именно подтверждает paid, проверьте привязку и отдельно посчитайте заказы, отменённые после оплаты. Не обещайте себе, что CANCELLED сотрёт прошлый обучающий сигнал. Здесь мы не выбираем настройки кампании, не моделируем рекламные списания и не проверяем, как Директ переобучится после отмены.
Денежный возврат также не следует подменять новой целью или отрицательной конверсией без отдельной спецификации вашей интеграции. В упражнении refund только увеличивает поле возвращённых денег; цели и статус он не меняет. Для расчёта потерь есть отдельный гайд о марже.
Как мы проверяли
Редакция сначала задала правило paid, схему полного способа и ожидаемые итоги, затем прошла 15 событий на шести вымышленных заказах локальным скриптом Python 3.14.4. В записи упражнения сохранены команда, версии, время, хеши входов и результаты. Доступ к CRM и счётчику не использовался; версия и тариф сервиса к этому локальному расчёту неприменимы. У страниц документации номер версии не указан.
Источники
Официальная справка открыта и проверена 20 октября 2026 года:
- Данные из CRM: привязка, её сроки и пример полного способа с отменой.
- Сопоставление статусов: типы, цели и сохранение истории.
- Формат заказов: идентификатор заказа и обновления.
- Упрощённый формат: отличие логики целей.
- Подготовка идентификаторов: ClientId и привязка.