CRM-аналитика
CRM в fashion с учётом размеров и возвратов
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Клиент заказал две пары джинсов, оставил одну и вернул вторую: не подошла посадка. Через неделю CRM предлагает ему ещё три модели в размере возвращённой пары. С точки зрения простого алгоритма всё логично: человек интересовался джинсами и уже покупал этот размер. С точки зрения клиента магазин проигнорировал результат примерки.
В fashion, то есть в продаже одежды, обуви и аксессуаров, рекомендация должна учитывать судьбу конкретной вещи после заказа. Заказанный размер показывает попытку выбора, сохранённая покупка — более сильный сигнал, а причина возврата помогает понять ограничение. При этом ни один из этих фактов не доказывает, что размер подходит самому владельцу аккаунта: вещь могла быть куплена в подарок.
Различайте заказ и результат примерки
Полезно различать состояния товарной строки: заказана, доставлена, заявлен возврат, принята обратно, обменена, осталась у покупателя к контрольной дате. Строка заказа — запись о конкретной позиции и её количестве. Один заказ может содержать вещи с разными дальнейшими состояниями.
Такое разделение поддерживается и в технических моделях. Например, ReturnLineItem в Shopify связывает возвращаемую позицию с исходной исполненной строкой, хранит причину возврата и количества на разных этапах обработки. Это пример структуры данных, а не доказательство роста продаж от определённой рекомендации.
Практическое правило CRM Lab: пока открыт возврат, не считайте вещь надёжным положительным сигналом и не предлагайте к ней комплект автоматически. Если клиент обменял размер, сохраните связь исходной и новой позиции. Денежный возврат, физическое получение вещи и закрытие обращения могут происходить в разные дни.
Размер храните вместе с контекстом
Размер «M» без бренда, модели и размерной сетки почти бесполезен. Даже у одного бренда посадка разных линеек может различаться. Храните обозначение производителя и нормализованный атрибут, если у компании есть проверенное правило сопоставления. Не создавайте универсальную таблицу соответствия только ради удобства сегментации.
Если человек указал «маломерит», это обратная связь о конкретной модели, а не команда увеличить размер во всех будущих предложениях. Аналогично возврат из-за дефекта ничего не говорит о посадке. Причина «не понравилось» не позволяет точно определить, что именно не устроило: цвет, материал, фасон или реальное качество.
| Сигнал | Осторожный вывод | Следующее действие |
|---|---|---|
| Вещь оставлена после примерки | Модель могла подойти | Предложить совместимые товары при актуальном наличии |
| Возврат из-за размера | Выбор размера оказался неудачным | Дать помощь по этой модели или явно предложить альтернативу |
| Возврат из-за дефекта | Был сбой качества | Сначала завершить сервисное решение |
| Несколько размеров одной модели | Возможно, заказ на примерку | Не считать каждый размер устойчивым предпочтением |
| Покупка обозначена как подарок | Получатель может быть другим | Не менять собственный размерный профиль покупателя |
Рекомендацию проверяйте по доступному варианту
Карточка «бестселлер сезона» не помогает, если нужного размера нет. Фильтр должен работать на уровне варианта товара: модель, цвет, размер, место исполнения заказа. Если доступны только соседние размеры, не подменяйте ими подходящий вариант без объяснения.
Перед отправкой исключите товары с неактуальной ценой, остановленной продажей или спорным соответствием. При переходе повторите проверку на сайте: письмо не может резервировать остаток само по себе. Для дефицитных размеров уведомление о наличии должно учитывать очередь и скорость расходования товара.
После возврата полезный следующий шаг зависит от причины. При проблеме с размером это консультация или сравнительная таблица измерений. При недовольстве материалом — другой состав. При нарушении доставки — восстановление сервиса. Универсальная скидка может стимулировать новый заказ, но не устранить повторяющуюся причину отказа.
Считайте результат с учётом поздних возвратов
Условный пример. В двух группах по 2 000 клиентов получено 300 и 330 новых заказов. После выбранного одинакового срока обработки возвратов в контрольной группе осталось 210 заказов без полного возврата, а в тестовой — 198. Первоначальный рост заказов на 10% не превратился в рост сохранённых покупок.
Допустим, итоговая выручка после возвратов составляет 1 050 000 и 990 000 рублей. После вычета себестоимости сохранённых товаров, логистики, обработки возвратов и расходов на коммуникации вклад равен 360 000 и 300 000 рублей. В этих условных данных рекомендация проигрывает на 60 000 рублей. Число кликов и отправленных заказов не меняет экономический вывод.
Для сравнения включайте в знаменатель всех случайно распределённых клиентов. Зафиксируйте горизонт с учётом реального срока возвратов и задержки их регистрации. Ранний отчёт обозначайте предварительным, а затем пересчитывайте по одинаковым правилам. Нельзя сравнивать контрольную группу, за которой наблюдали весь установленный срок, с недавно набранной тестовой группой.
Что передать в реализацию
Опишите четыре связанных правила: какой результат покупки считается положительным сигналом, как обрабатывается каждая причина возврата, на каком уровне проверяется наличие и когда фиксируется экономика. Добавьте тестовые профили с несколькими размерами, подарком, частичным возвратом и обменом.
Первый запуск лучше ограничить категорией с понятной размерной сеткой и достоверными причинами возврата. Если причин нет, начните с корректного исключения проблемных рекомендаций и сбора обратной связи. Сложная модель не восстановит смысл, который потерян в исходных данных.
Источники
Shopify. ReturnLineItem. GraphQL Admin API Documentation, версия 2026-07.