Аналитика по вариантам товара: размеры, цвет и обмены

Что ломается в аналитике, когда у товара много вариантов

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

Первая типичная проблема - размеры и цвета «разъезжаются» между системами. В карточке товара вы видите «черный, M», а в заказ уходит «Black, Medium» или внутренний код. Из-за этого аналитика не может правильно склеить данные: часть продаж попадает в один вариант, часть - в другой, а иногда варианты выглядят как разные товары.

Дальше «плывут» метрики. Обычно первыми начинают врать конверсия по товару и по варианту (кажется, что M продается хуже, чем есть), выручка и средний чек (продажи распадаются на «мини-товары»), остатки и оборачиваемость (вариант есть на складе, но в отчетах он будто закончился), возвраты и отмены (уезжают в другой товар или не уменьшают продажи), маржинальность (скидки, доставка, комиссии привязываются не туда).

Отдельная боль - обмены размеров. Покупатель берет S, меняет на M. Если обмен отражен как «новая продажа» без корректного возврата, вы получаете раздутую выручку и завышенную конверсию. Если, наоборот, обмен записан только как возврат, кажется, что товар «проваливается» по продажам. А когда обмены делают вручную, часть операций вообще не попадает в данные, и вы теряете понимание реальной доли проблемных размеров.

Самый опасный сценарий - когда каждый вариант живет как отдельный товар. Тогда появляются десятки карточек вместо одной, ломается поиск по каталогу, копятся дубли в рекламе и аналитике, а отчеты по товару становятся бессмысленными. Например, «Футболка Basic, черная» распадается на 6 товаров по размерам, и вы уже не можете честно ответить: модель успешная или нет, какие цвета и размеры реально тянут выручку, и где именно вы теряете деньги на обменах.

Базовые понятия: товар, вариант и SKU без путаницы

Чтобы аналитика по вариантам товара была точной, важно сразу договориться о терминах. Тогда продажи, остатки и конверсия не расползаются из-за разных названий одного и того же.

Представьте карточку: футболка «Basic», цвет черный, размеры S, M, L.

Товар (product) - это модель: «Футболка Basic» как одна сущность в каталоге. У товара есть бренд, описание, категория, базовые фото.

Вариант (variant) - конкретная комбинация атрибутов, которую покупают: «Basic, черный, размер M». Именно варианты должны попадать в события покупки и в отчеты по наличию.

SKU (артикул) - складской идентификатор для учета и отгрузки. Чаще всего один вариант = один SKU, но важнее другое: SKU должен быть уникальным и не меняться задним числом.

Какие поля держат отчетность в порядке

В событиях и таблицах лучше заранее разделить уровни идентификаторов:

• item_id: постоянный ID товара (модели), не зависит от размера и цвета
• variant_id: постоянный ID варианта (цвет + размер), меняется только если это реально новый вариант
• SKU: складской артикул, совпадает с вариантом или с партией, но всегда уникален
• name: человекочитаемое название, может меняться, но не должно быть ключом

Если строить отчеты по названию или артикулу, любые правки в админке ломают историю. Переименовали «Basic» в «Basic 2.0» или поменяли формат артикула - и старые продажи внезапно окажутся в другом сегменте.

Как отличать правку карточки от нового товара

Правка карточки - это когда меняется описание, фото, цена, тексты, но смысл модели тот же. Тогда item_id остается прежним.

Новый товар появляется, когда меняется сама модель или ее базовые характеристики, которые делают ее другой единицей анализа: другой крой, бренд, линейка, назначение. В таком случае создавайте новый item_id, а не «переписывайте» старый, иначе сравнение по сезонам станет нечестным.

Стратегия SKU для одежды: чтобы хватило и складу, и отчетам

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

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

Иногда отдельный SKU на каждую комбинацию не обязателен. Например, если вы продаете предзаказ и ведете учет только по модели (без остатков по вариантам) или если цвет выбирается как кастомизация без отдельного хранения. Тогда SKU может быть на уровне модели, а размер и цвет фиксируются как атрибуты заказа. Это усложняет возвраты и обмены, поэтому такой подход стоит выбирать осознанно.

Ключевой принцип - стабильность. После запуска нельзя менять:

• внутренний ID товара и варианта (то, на чем держится аналитика)
• значение SKU, если оно уже попало в заказы и отчеты
• правила формирования SKU (иначе получите дубли и «разные» товары в статистике)

Если нужно переименовать товар для витрины, меняйте название, фото, описание, но не идентификаторы.

Чтобы не плодить дубли, заранее задайте связку: товар (модель) -> вариант (размер + цвет) -> SKU (складская единица). На одну комбинацию атрибутов должен приходиться один вариант и один SKU. Если у вас несколько складов, не создавайте новые SKU под каждый склад - храните остатки как «SKU + склад». Иначе отчеты начнут считать один и тот же вариант разными продажами.

Заложите будущее сразу. Даже если сегодня у футболки только белый и черный, продумайте, как добавите «молочный», «графит», новые размеры и ростовки, не ломая старые коды. Практичный вариант - фиксированный шаблон SKU, где есть место под модель, цвет и размер (например, TSH-104-WHT-M).

Мини-сценарий: футболка TSH-104 продается в M и L, цвет белый. Если вы позже добавите «молочный» и поменяете WHT на MLC, не переиспользуйте старый SKU. Создайте новый вариант и новый SKU. Тогда аналитика покажет реальную историю: что покупали раньше, а что появилось позже.

Если вы собираете магазин в TakProsto, удобно сразу зафиксировать правила по вариантам и SKU в planning mode, чтобы витрина, бэкенд и события аналитики опирались на одну и ту же схему.

Размеры и цвета: как стандартизировать атрибуты

Если у размеров и цветов нет единого стандарта, варианты начинают плодиться: «M», «Medium», «48», «48-50» становятся разными сущностями. В итоге аналитика показывает ложных лидеров продаж, а склад и отчеты расходятся.

Размер: один формат на весь каталог

Сначала выберите, в какой системе вы продаете: международная S-M-L, российская 44-46 или джинсовая W/L. Дальше заведите правило: в карточке варианта хранится структурированный размер, а в названии варианта он только отображается.

Минимум правил, который обычно спасает от хаоса:

• Одна система для одной категории: футболки только S-M-L, брюки только W/L, обувь только EU.
• Диапазон пишется единообразно: либо «44-46», либо «44/46» (выберите один формат).
• Не смешивайте «M» и «46» в одной сетке. Если нужно, храните второе значение отдельным полем, например «размер_в_другой_системе».
• Ростовку, ширину и посадку храните отдельными полями (например, «рост» 176, «ширина» W32, «посадка» high).
• Для детских размеров фиксируйте логику: по росту (92, 98) или по возрасту (2Y, 3Y), но не одновременно.

Цвет: договоритесь, что такое «один цвет»

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

Удобная схема:

• Базовый цвет: коротко и стабильно («черный», «белый», «синий»).
• Оттенок: опционально («графит», «молочный», «индиго»).
• Принт и фактура не должны быть цветом: «леопард», «меланж» лучше хранить как «принт» или «текстура».
• Локализация единая: не смешивайте RU и EN в одном каталоге.
• Если поставщик прислал «Navy Blue», маппите в ваш словарь: базовый «синий», оттенок «navy».

Что делать с универсальными размерами и товарами без размеров: используйте явное значение «ONESIZE» или «NO_SIZE» (а не пустоту). Например, кепка: размер «ONESIZE», цвет «черный». Тогда обмены по размеру не будут случайно записываться как разные товары, а фильтры и отчеты останутся чистыми.

Небольшой пример: худи приходит от разных поставщиков как «M», «48-50» и «Medium». Если вы приводите это к одному полю «размер_основной = M», а поставщицкое значение храните отдельно, то в отчетах продажи и обмены будут собираться по одному варианту, а не по трем похожим.

Как настроить события аналитики для вариантов товара

Чтобы аналитика по вариантам товара не разваливалась, каждому событию нужны понятные идентификаторы. Названия (типа «Футболка базовая, черная») меняются, а отчеты должны жить годами.

Минимальный набор событий

Держите базовую цепочку, чтобы видеть, где именно «теряются» продажи и какие варианты реально покупают:

• Просмотр карточки товара (view_item)
• Выбор варианта (select_variant), если есть переключение размера или цвета
• Добавление в корзину (add_to_cart)
• Покупка (purchase)
• Возврат или обмен (refund или exchange)

Ключевой принцип: в каждое событие передавайте и уровень товара, и уровень варианта.

Что именно передавать, чтобы отчеты сходились

Используйте стабильные ID:

• product_id: постоянный идентификатор модели (не название)
• variant_id: постоянный идентификатор связки «цвет + размер»
• sku: складской код (если есть), удобно для сверки с остатками
• attributes: color, size (в стандартизированном виде)
• price и currency, quantity

Пример структуры параметров (логика, не привязана к конкретной системе):

{
  "event": "add_to_cart",
  "product_id": "TSHIRT-BASE",
  "variant_id": "TSHIRT-BASE|BLACK|M",
  "sku": "TSH-BLK-M",
  "attributes": {"color": "black", "size": "M"},
  "price": 1490,
  "quantity": 1
}

Отдельно передавайте скидки и промокоды. Не пытайтесь «вшить» их в price товара, иначе выручка начнет расходиться между отчетами. Рабочая практика: item_price (цена до скидок), item_discount, order_discount, promo_code, shipping и tax как поля заказа.

Чтобы не потерять данные при обновлении каталога, не меняйте product_id и variant_id при переименованиях и редизайне карточки. Если меняется логика вариантов, создавайте новые variant_id, а старые оставляйте в истории, чтобы прошлые заказы и события продолжали корректно сходиться.

Обмены размеров и возвраты: как отражать их в отчетности

Возврат и обмен выглядят похоже для клиента, но для метрик это разные истории. Возврат уменьшает проданные единицы и выручку (вплоть до нуля, если заказ полностью вернули). Обмен чаще всего не меняет выручку, но меняет состав отгрузок и статистику по вариантам (например, вместо M уехал L).

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

Есть два рабочих способа записи обмена:

1. Два связанных действия: возврат исходного варианта + отгрузка нового варианта. Подход точнее для склада и дает честную картину по размерам.

2. Одно действие “exchange” с деталями «что было» и «на что поменяли». Так проще по событиям, но часто сложнее по учету остатков.

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

• original_order_id (исходный заказ)
• original_line_id (строка товара в заказе)
• from_sku и to_sku (какой вариант меняют и на какой)
• exchange_id (единый идентификатор обмена)
• reason (не подошел размер, брак, не понравилась посадка)

Метрики лучше разделять: «заказы» и «выручка» считаются по оплатам исходных заказов, а обмены идут отдельным счетчиком - сколько раз меняли, с каких размеров на какие, какой процент обменов по каждой модели.

Пример: клиент купил футболку, SKU TSHIRT-BLK-M, и поменял на TSHIRT-BLK-L. В выручке ничего не меняется, но по вариантам должно быть видно, что M чаще уходит в обмен, а L чаще остается. Так быстрее находятся проблемы в размерной сетке или карточке товара.

Если вы строите магазин в TakProsto, заранее заложите поля exchange_id и связь с original_order_id в схему данных, чтобы обмены не «размазывались» по отчетности и не превращались в лишние продажи.

Пошагово: внедряем схему вариантов и аналитики в магазине

Начните с простого правила: аналитика должна понимать, что именно купили (вариант), а склад - что именно списать (SKU). Когда эти идентификаторы смешаны, аналитика быстро превращается в набор противоречивых цифр.

Рабочая последовательность, которая обычно дает чистые отчеты уже на первой неделе:

1. Зафиксируйте схему идентификаторов и нейминг. Определите, что будет item_id (модель), variant_id (модель + атрибуты) и SKU (то, что лежит на полке). Запишите правила так, чтобы их мог повторить контент-менеджер.

2. Приведите каталог к одному справочнику размеров и цветов. Выберите единую сетку (S/M/L или 44/46/48) и единые названия цветов (например, только «черный», без «black» и «чёрный»). Синонимы оставьте как отображаемые названия, но не как аналитические значения.

3. Настройте события так, чтобы они всегда передавали три поля: item_id, variant_id и SKU. В заказе, просмотре карточки, добавлении в корзину и оплате должны уходить одинаковые идентификаторы, иначе воронка по вариантам распадется.

4. Прогоните тестовые сценарии на «игрушечных» заказах. Сделайте покупку, затем возврат, затем обмен размера (как две операции: возврат старого варианта и отгрузка нового). Проверьте, что выручка, количество и остатки сходятся по variant_id и по SKU.

5. Закрепите правила для контента и поддержки. Обмены и ручные правки карточек чаще всего ломают систему: добавили новый цвет с другим написанием, поменяли размерную сетку, «склеили» варианты в одну позицию.

Если вы собираете магазин на TakProsto, эти правила удобно описать в planning mode и провести идентификаторы через фронтенд, бэкенд и события без разночтений.

Частые ошибки, из-за которых отчеты перестают совпадать

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

Главная ошибка - менять SKU или идентификатор варианта после первых продаж. В итоге продажи и остатки начинают «жить» в разных сущностях: часть истории остается на старом коде, часть уходит на новый. Если нужно переименовать, делайте это через отдельное поле (например, «внутреннее название»), а SKU держите стабильным.

Вторая частая проблема - путаница между «товаром» и «вариантом». Например, под каждую расцветку создают новый товар, а размеры внутри ведут свободным текстом. Или наоборот: создают варианты там, где должна быть отдельная модель. Это ломает сравнение конверсии и маржинальности между моделями.

Третий блок ошибок связан с атрибутами. Если размеры и цвета записываются как попало (S, Small, 44, 44RU; «черный», «Чёрный», black), отчеты дробятся на десятки почти одинаковых значений. Нужен справочник: один язык, один формат, одна раскладка, без лишних пробелов.

Еще один «тихий убийца» отчетности - обмены без причины. Когда клиент меняет M на L, это сигнал: не совпадает сетка размеров, описание, посадка или фото. Если причина не фиксируется, вы видите только шум и не можете улучшить карточку.

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

• продажа (первичный заказ)
• возврат (минус к выручке и количеству)
• обмен (связка возврата и новой отгрузки с одной причиной)
• доплата/частичный возврат (разница при обмене)

Пример: клиент купил футболку и обменял размер два раза. Правильный отчет покажет одну покупку и два обмена, а не «три продажи».

Быстрый чеклист: проверяем, что аналитика не сломана

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

Проверьте идентификаторы и данные в событиях

Выберите 3-5 популярных моделей и пройдитесь по пути: карточка -> корзина -> оплата -> возврат или обмен.

Проверьте, что:

• У варианта есть постоянный идентификатор (variant_id), а SKU читается человеком и не меняется при переименовании товара.
• В событии покупки передается и модель, и конкретный вариант (размер/цвет), и финальная цена (после скидок и промокодов).
• В корзине и в заказе совпадают размер и цвет: не должно быть ситуации, когда покупатель выбирал M, а в аналитике уехало в L.
• Сумма выручки в аналитике сходится с оплатами хотя бы на небольшой выборке (например, 20-30 заказов за день).
• Доставка и упаковка не «прилипают» к товару как часть цены варианта (иначе сравнение вариантов по цене станет грязным).

Проверьте обмены и складскую правду

Обмен размера не должен делать вид, что у вас стало больше заказов или продаж, чем было.

Возьмите несколько реальных обменов и убедитесь, что первоначальная продажа не задваивается, а движение выглядит как замена варианта (или как продажа плюс возврат, но без повторной выручки). Затем сравните остатки по размерам с тем, что показывает склад, хотя бы по одной модели и паре размеров.

Полезный контрольный отчет - доля обменов по моделям и отдельно по размерам. Он быстро подсветит, например, что у конкретной футболки S меняют на M в 2 раза чаще нормы. Это повод проверять сетку размеров или описание.

Пример из жизни: футболка с частыми обменами размеров

Представьте магазин одежды: базовая футболка в двух цветах (черный и белый) и размерах XS-XL. По продажам лидирует M, но служба поддержки видит повторяющуюся историю: покупают M, потом меняют на L. Если фиксировать только итоговые продажи, аналитика по вариантам товара начинает врать: кажется, что M идеален, хотя на деле он просто чаще попадает в обмен.

Чтобы отчеты не ломались, обмен лучше отражать как две связанные операции: возврат исходного варианта и отгрузка нового варианта, объединенные одним идентификатором обмена.

Пример корректных событий (упрощенно):

• Покупка: order_paid (sku=TSHIRT-BLK-M, size=M, color=black, qty=1, price=1990)
• Обмен: exchange_initiated (exchange_id=E123, from_sku=TSHIRT-BLK-M, to_sku=TSHIRT-BLK-L, reason=маломерит)
• Возврат старого: item_returned (exchange_id=E123, sku=TSHIRT-BLK-M, qty=1, refund=1990)
• Отгрузка нового: item_shipped (exchange_id=E123, sku=TSHIRT-BLK-L, qty=1, revenue=0)
• Если клиент доплатил (например, другая модель): доплата идет отдельной строкой платежа, а не «подменой» цены в исходной покупке.

Какие отчеты дают реальную картину: спрос по размерам в двух видах (первичный выбор и «итог на руках» после обменов и возвратов), доля обменов по размеру и цвету (например, M черный: 18% обменов в L), причины обменов.

Решения по данным обычно простые: поправить размерную сетку (добавить замеры в сантиметрах), поменять фото посадки на разных ростах, уточнить в описании ткань и усадку после стирки, а для проблемных размеров - подсказку «берите на размер больше» прямо на карточке товара.

Следующие шаги: как закрепить процесс и не откатываться назад

Чтобы аналитика по вариантам товара не развалилась через месяц, нужны не новые отчеты, а простые правила и дисциплина вокруг каталога. Чаще всего все ломается после «маленькой правки» названий, атрибутов или SKU, из-за которой события начинают собираться по-другому.

Соберите одну таблицу правил и держите ее как единственный источник истины. В ней должны быть: формат идентификаторов (товар, вариант, SKU), как пишутся названия (что входит в название, а что остается атрибутом), список атрибутов и их допустимые значения (размеры, цвета), а также какие события вы отправляете в аналитику и какие поля в них обязательны.

Минимум, который стоит закрепить документом:

• структура ID: product_id, variant_id, sku (и что нельзя менять задним числом)
• словарь атрибутов: размер, цвет, посадка и т.д. с едиными значениями
• правила именования: без «черн.» и «black» вперемешку
• список событий: просмотр, добавление в корзину, покупка, обмен, возврат
• правила корректировок: как отражаем обмены, чтобы не искажать выручку и конверсию

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

Первые 1-2 месяца поставьте в календарь еженедельную проверку данных: совпадают ли продажи по SKU со складом, не появились ли новые значения атрибутов, не упала ли доля событий с заполненными variant_id и sku, правильно ли отражаются обмены размеров.

Если магазин делаете с нуля, удобно сначала собрать прототип и схему вариантов в TakProsto, а затем зафиксировать структуру. В спорных ситуациях помогают снапшоты и откат. Когда схема устоится, заранее решите, как будете разворачивать проект: например, экспортировать исходники для хранения кода, а хостинг и домен подключать уже ближе к запуску (takprosto.ai).