CRM-аналитика
Какие события заказа должны запускать сценарии CRM
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Магазин отправляет «спасибо за покупку» сразу после создания заказа, хотя оплата ещё не прошла. Просьба оставить отзыв приходит до доставки, а предложение расходников — после отмены. В каждом случае письмо может быть технически настроено правильно. Ошибка находится в смысле события, которое запускает сценарий.
Событие — запись о произошедшем изменении: заказ создан, платёж подтверждён, посылка вручена. Состояние — то, что известно об объекте сейчас. Одно событие меняет состояние, но не описывает все стороны заказа.
Для CRM полезно хранить оплату, исполнение и возвраты отдельно. Тогда сценарий выбирает нужный факт и проверяет, остался ли он актуальным к моменту отправки.
Не сводите заказ к одной лестнице статусов
Последовательность «создан — оплачен — доставлен» выглядит удобно, но не покрывает оплату при получении, частичную отгрузку и возврат одной позиции. Заказ может быть частично оплачен и частично доставлен одновременно.
В модели Shopify финансовый статус и статус исполнения представлены разными полями. Это полезный пример разделения смыслов. При этом статус исполнения нельзя автоматически считать доказательством вручения покупателю: для конкретного сценария нужно проверить, какое событие доставки даёт ваш источник. [1]
В контракте данных опишите отдельные факты: сумма подтверждённых платежей, состав отгрузок, вручённые позиции, отмены и возвращённые товары. CRM-маркетологу не обязательно читать весь технический формат, но он должен понимать, какое условие соответствует обещанию в сообщении.
Выберите событие под задачу клиента
| Сценарий | Подходящее основание | Проверка перед действием |
|---|---|---|
| Подтверждение оформления | Заказ принят системой | Есть ли действующий заказ и верный адресат |
| Напоминание об оплате | Есть ожидающий оплаты остаток | Не поступил ли платёж или отмена |
| Остановка напоминания о корзине | Заказ соответствует корзине по принятому правилу | Не учитывается ли чужой или неуспешный заказ |
| Запрос отзыва о товаре | Подтверждено получение и прошло время использования | Не возвращён ли товар |
| Пополнение расходников | Нужная позиция получена | Количество и следующая покупка |
Таблица — начальная модель. Например, магазин может останавливать рекламу корзины уже после создания заказа, а не после оплаты: дальше клиенту нужна помощь с оплатой, а не повторное предложение той же покупки. Это бизнес-решение следует закрепить явно.
Передавайте устойчивые ключи и версии
Order ID — постоянный код заказа; line item ID — код конкретной позиции заказа. SKU обозначает товарную единицу каталога и не заменяет ID позиции: один товар может встретиться в заказе несколько раз с разными условиями.
Событию нужен собственный ID и время фактического изменения. Для обновления состояния полезна версия заказа из источника. Если события пришли не по порядку, более старое изменение не должно возвращать уже отменённый заказ в состояние «создан».
Не полагайтесь только на время получения. Stripe, например, прямо не гарантирует доставку событий в порядке возникновения. Это ограничение конкретного сервиса иллюстрирует, почему потребитель должен проверять порядок и текущее состояние самостоятельно. [2]
Разделите вход в сценарий и право на отправку
Заказ мог подходить для сценария утром, а к вечеру измениться. Поэтому событие запуска и проверка перед сообщением решают разные задачи. Первое объясняет, почему появился кандидат; вторая — можно ли действовать сейчас.
Для напоминания об оплате повторно проверьте остаток к оплате и действительность заказа. Для отзыва — получение нужной позиции и отсутствие исключающего возврата. Для допродажи — контекст покупки и применимые ограничения коммуникационной политики.
Если источник критичных данных недоступен, заранее задайте поведение: отложить сообщение, использовать ограниченно допустимую копию состояния или отменить действие. Решение зависит от цены ошибки, а не только от удобства платформы.
Условный пример частичной доставки
В заказе две позиции: кофемашина и фильтры. Кофемашину вручили во вторник, фильтры доставят в пятницу. Общий статус «частично исполнен» не отвечает на вопрос, можно ли просить отзыв о кофемашине.
Сценарий отзыва опирается на вручение конкретной позиции и заданную паузу на использование. Напоминание о пополнении фильтров начинается от их получения и учитывает количество. Если клиент отменил недоставленные фильтры, этот сценарий вообще не запускается.
В аналитике заказ остаётся одним заказом. Количество событий доставки не превращается в количество покупок. Финансовый результат пересчитывается отдельно по платежам, учитываемой выручке, возвратам и согласованным затратам.
Не восстанавливайте порядок по названию статуса
Правило «доставлен важнее оплачен» не заменяет модель заказа. При оплате при получении финансовое подтверждение может прийти позже вручения. После доставки возможен возврат, а после частичной отмены — дополнительная отгрузка.
В контракте опишите допустимые переходы для каждой независимой части состояния. Если источник даёт версию, уточните, относится ли она ко всему заказу или только к оплате. Версии разных сущностей нельзя сравнивать как одну общую последовательность.
Для заказа из нескольких магазинов одного проекта ключ может включать источник и локальный order ID. Иначе заказ 125 из магазина A совпадёт с заказом 125 из магазина B. При переносе между системами сохраняют таблицу соответствий, чтобы новое техническое имя не создало вторую покупку и повторный вход в сценарий.
Принимайте интеграцию на сложных заказах
Подготовьте набор: неоплаченный заказ, оплата частями, оплата при получении, две доставки, отмена после оплаты, частичный возврат и повторная передача события. Для каждого укажите ожидаемые сообщения и те, которые должны быть остановлены.
Проверьте также позднее поступление старого статуса. В журнале сценария должны сохраняться ID заказа, событие входа, состояние при последней проверке и причина решения.
Результат — не просто список названий событий. Это договорённость о том, какой подтверждённый факт нужен каждому обращению к клиенту и как система замечает, что ситуация уже изменилась.
Источники
[1] Shopify. Order. GraphQL Admin API. Поля customer, billingAddress, shippingAddress, displayFinancialStatus и displayFulfillmentStatus. Версия 2026-07. Проверено 22.09.2026.
[2] Stripe. Receive Stripe events in your webhook endpoint. Техническая документация. Разделы Event ordering, Handle duplicate events, Automatic retries и Handle events asynchronously. Проверено 22.09.2026.