Аналитика по вариантам товара помогает держать отчеты точными: продуманная SKU-логика, корректные события и учет частых обменов размеров.
В магазине одежды один и тот же товар живет в десятках комбинаций: размер, цвет, иногда рост и посадка. Если варианты заведены как попало, отчеты начинают показывать разные «правды». На витрине все выглядит нормально, но цифры перестают сходиться между продажами, складом и аналитикой.
Первая типичная проблема - размеры и цвета «разъезжаются» между системами. В карточке товара вы видите «черный, M», а в заказ уходит «Black, Medium» или внутренний код. Из-за этого аналитика не может правильно склеить данные: часть продаж попадает в один вариант, часть - в другой, а иногда варианты выглядят как разные товары.
Дальше «плывут» метрики. Обычно первыми начинают врать конверсия по товару и по варианту (кажется, что M продается хуже, чем есть), выручка и средний чек (продажи распадаются на «мини-товары»), остатки и оборачиваемость (вариант есть на складе, но в отчетах он будто закончился), возвраты и отмены (уезжают в другой товар или не уменьшают продажи), маржинальность (скидки, доставка, комиссии привязываются не туда).
Отдельная боль - обмены размеров. Покупатель берет S, меняет на M. Если обмен отражен как «новая продажа» без корректного возврата, вы получаете раздутую выручку и завышенную конверсию. Если, наоборот, обмен записан только как возврат, кажется, что товар «проваливается» по продажам. А когда обмены делают вручную, часть операций вообще не попадает в данные, и вы теряете понимание реальной доли проблемных размеров.
Самый опасный сценарий - когда каждый вариант живет как отдельный товар. Тогда появляются десятки карточек вместо одной, ломается поиск по каталогу, копятся дубли в рекламе и аналитике, а отчеты по товару становятся бессмысленными. Например, «Футболка Basic, черная» распадается на 6 товаров по размерам, и вы уже не можете честно ответить: модель успешная или нет, какие цвета и размеры реально тянут выручку, и где именно вы теряете деньги на обменах.
Чтобы аналитика по вариантам товара была точной, важно сразу договориться о терминах. Тогда продажи, остатки и конверсия не расползаются из-за разных названий одного и того же.
Представьте карточку: футболка «Basic», цвет черный, размеры S, M, L.
Товар (product) - это модель: «Футболка Basic» как одна сущность в каталоге. У товара есть бренд, описание, категория, базовые фото.
Вариант (variant) - конкретная комбинация атрибутов, которую покупают: «Basic, черный, размер M». Именно варианты должны попадать в события покупки и в отчеты по наличию.
SKU (артикул) - складской идентификатор для учета и отгрузки. Чаще всего один вариант = один SKU, но важнее другое: SKU должен быть уникальным и не меняться задним числом.
В событиях и таблицах лучше заранее разделить уровни идентификаторов:
Если строить отчеты по названию или артикулу, любые правки в админке ломают историю. Переименовали «Basic» в «Basic 2.0» или поменяли формат артикула - и старые продажи внезапно окажутся в другом сегменте.
Правка карточки - это когда меняется описание, фото, цена, тексты, но смысл модели тот же. Тогда item_id остается прежним.
Новый товар появляется, когда меняется сама модель или ее базовые характеристики, которые делают ее другой единицей анализа: другой крой, бренд, линейка, назначение. В таком случае создавайте новый item_id, а не «переписывайте» старый, иначе сравнение по сезонам станет нечестным.
В одежде SKU часто становится источником путаницы: склад хочет точность по остаткам, а маркетинг - честную аналитику по вариантам. Хорошая схема закрывает оба требования без ручных правок каждый месяц.
Отдельный SKU почти всегда нужен на каждую комбинацию размера и цвета, если вы реально храните и продаете эти комбинации как разные складские позиции. Так склад видит остатки по каждой позиции, а отчеты понимают, что покупали и на что чаще меняют размер.
Иногда отдельный 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. Дальше заведите правило: в карточке варианта хранится структурированный размер, а в названии варианта он только отображается.
Минимум правил, который обычно спасает от хаоса:
Цвета ломают отчеты, когда «черный», «Black», «черн.» и «графит» живут как разные варианты. Здесь помогает словарь базовых цветов и отдельное поле для оттенка.
Удобная схема:
Что делать с универсальными размерами и товарами без размеров: используйте явное значение «ONESIZE» или «NO_SIZE» (а не пустоту). Например, кепка: размер «ONESIZE», цвет «черный». Тогда обмены по размеру не будут случайно записываться как разные товары, а фильтры и отчеты останутся чистыми.
Небольшой пример: худи приходит от разных поставщиков как «M», «48-50» и «Medium». Если вы приводите это к одному полю «размер_основной = M», а поставщицкое значение храните отдельно, то в отчетах продажи и обмены будут собираться по одному варианту, а не по трем похожим.
Чтобы аналитика по вариантам товара не разваливалась, каждому событию нужны понятные идентификаторы. Названия (типа «Футболка базовая, черная») меняются, а отчеты должны жить годами.
Держите базовую цепочку, чтобы видеть, где именно «теряются» продажи и какие варианты реально покупают:
Ключевой принцип: в каждое событие передавайте и уровень товара, и уровень варианта.
Используйте стабильные ID:
Пример структуры параметров (логика, не привязана к конкретной системе):
{
"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).
Самая частая ошибка - записать обмен как новый заказ. Тогда растут и выручка, и число заказов, хотя бизнес ничего дополнительно не заработал. Правильнее считать обмен как изменение исполнения исходного заказа.
Есть два рабочих способа записи обмена:
Два связанных действия: возврат исходного варианта + отгрузка нового варианта. Подход точнее для склада и дает честную картину по размерам.
Одно действие “exchange” с деталями «что было» и «на что поменяли». Так проще по событиям, но часто сложнее по учету остатков.
Чтобы отчеты не расходились, в любом случае держите связь с исходным заказом и фиксируйте причину. Минимальный набор полей для обмена:
Метрики лучше разделять: «заказы» и «выручка» считаются по оплатам исходных заказов, а обмены идут отдельным счетчиком - сколько раз меняли, с каких размеров на какие, какой процент обменов по каждой модели.
Пример: клиент купил футболку, SKU TSHIRT-BLK-M, и поменял на TSHIRT-BLK-L. В выручке ничего не меняется, но по вариантам должно быть видно, что M чаще уходит в обмен, а L чаще остается. Так быстрее находятся проблемы в размерной сетке или карточке товара.
Если вы строите магазин в TakProsto, заранее заложите поля exchange_id и связь с original_order_id в схему данных, чтобы обмены не «размазывались» по отчетности и не превращались в лишние продажи.
Начните с простого правила: аналитика должна понимать, что именно купили (вариант), а склад - что именно списать (SKU). Когда эти идентификаторы смешаны, аналитика быстро превращается в набор противоречивых цифр.
Рабочая последовательность, которая обычно дает чистые отчеты уже на первой неделе:
Зафиксируйте схему идентификаторов и нейминг. Определите, что будет item_id (модель), variant_id (модель + атрибуты) и SKU (то, что лежит на полке). Запишите правила так, чтобы их мог повторить контент-менеджер.
Приведите каталог к одному справочнику размеров и цветов. Выберите единую сетку (S/M/L или 44/46/48) и единые названия цветов (например, только «черный», без «black» и «чёрный»). Синонимы оставьте как отображаемые названия, но не как аналитические значения.
Настройте события так, чтобы они всегда передавали три поля: item_id, variant_id и SKU. В заказе, просмотре карточки, добавлении в корзину и оплате должны уходить одинаковые идентификаторы, иначе воронка по вариантам распадется.
Прогоните тестовые сценарии на «игрушечных» заказах. Сделайте покупку, затем возврат, затем обмен размера (как две операции: возврат старого варианта и отгрузка нового). Проверьте, что выручка, количество и остатки сходятся по variant_id и по SKU.
Закрепите правила для контента и поддержки. Обмены и ручные правки карточек чаще всего ломают систему: добавили новый цвет с другим написанием, поменяли размерную сетку, «склеили» варианты в одну позицию.
Если вы собираете магазин на TakProsto, эти правила удобно описать в planning mode и провести идентификаторы через фронтенд, бэкенд и события без разночтений.
Самые неприятные расхождения начинаются не в аналитике, а в каталоге и правилах учета. Один и тот же вариант должен оставаться тем же самым вариантом, даже если вы меняете описание, фото или цену.
Главная ошибка - менять SKU или идентификатор варианта после первых продаж. В итоге продажи и остатки начинают «жить» в разных сущностях: часть истории остается на старом коде, часть уходит на новый. Если нужно переименовать, делайте это через отдельное поле (например, «внутреннее название»), а SKU держите стабильным.
Вторая частая проблема - путаница между «товаром» и «вариантом». Например, под каждую расцветку создают новый товар, а размеры внутри ведут свободным текстом. Или наоборот: создают варианты там, где должна быть отдельная модель. Это ломает сравнение конверсии и маржинальности между моделями.
Третий блок ошибок связан с атрибутами. Если размеры и цвета записываются как попало (S, Small, 44, 44RU; «черный», «Чёрный», black), отчеты дробятся на десятки почти одинаковых значений. Нужен справочник: один язык, один формат, одна раскладка, без лишних пробелов.
Еще один «тихий убийца» отчетности - обмены без причины. Когда клиент меняет M на L, это сигнал: не совпадает сетка размеров, описание, посадка или фото. Если причина не фиксируется, вы видите только шум и не можете улучшить карточку.
И отдельно: не считайте обмен как новую покупку. Иначе выручка раздувается, конверсия выглядит лучше, чем есть, а возвратность занижается. Разделяйте типы операций:
Пример: клиент купил футболку и обменял размер два раза. Правильный отчет покажет одну покупку и два обмена, а не «три продажи».
В одежде с размерами и цветами ошибки обычно появляются тихо: общие цифры продаж выглядят нормально, но отчеты по вариантам начинают «плыть». Этот чеклист помогает быстро понять, где копать.
Выберите 3-5 популярных моделей и пройдитесь по пути: карточка -> корзина -> оплата -> возврат или обмен.
Проверьте, что:
Обмен размера не должен делать вид, что у вас стало больше заказов или продаж, чем было.
Возьмите несколько реальных обменов и убедитесь, что первоначальная продажа не задваивается, а движение выглядит как замена варианта (или как продажа плюс возврат, но без повторной выручки). Затем сравните остатки по размерам с тем, что показывает склад, хотя бы по одной модели и паре размеров.
Полезный контрольный отчет - доля обменов по моделям и отдельно по размерам. Он быстро подсветит, например, что у конкретной футболки 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), как пишутся названия (что входит в название, а что остается атрибутом), список атрибутов и их допустимые значения (размеры, цвета), а также какие события вы отправляете в аналитику и какие поля в них обязательны.
Минимум, который стоит закрепить документом:
Дальше назначьте одного ответственного, кто утверждает любые изменения каталога и трекинга. Это может быть продакт или операционный менеджер, но у него должно быть право сказать «нет» правке, которая ломает совместимость.
Первые 1-2 месяца поставьте в календарь еженедельную проверку данных: совпадают ли продажи по SKU со складом, не появились ли новые значения атрибутов, не упала ли доля событий с заполненными variant_id и sku, правильно ли отражаются обмены размеров.
Если магазин делаете с нуля, удобно сначала собрать прототип и схему вариантов в TakProsto, а затем зафиксировать структуру. В спорных ситуациях помогают снапшоты и откат. Когда схема устоится, заранее решите, как будете разворачивать проект: например, экспортировать исходники для хранения кода, а хостинг и домен подключать уже ближе к запуску (takprosto.ai).
Держите 3 уровня идентификаторов: product_id (модель), variant_id (цвет+размер), sku (складская единица). В событиях и заказах передавайте все три.
Не используйте название товара или отображаемый артикул как ключ — они меняются и ломают историю.
Потому что одно и то же может приходить как «M», «Medium», «48-50» или «Черный/Black». Аналитика воспринимает это как разные варианты и дробит продажи, конверсию и остатки.
Решение: справочник значений + маппинг поставщика в ваши стандарты.
Почти всегда — да, если вы храните и отгружаете эти комбинации отдельно. Тогда склад и отчеты видят честные остатки и продажи по каждой позиции.
Исключения возможны (например, предзаказ без учета остатков по вариантам), но тогда обмены и сверка со складом становятся заметно сложнее.
Меняйте name/описание/фото, но не трогайте product_id/variant_id/sku. Если идентификатор уже попал в заказы, его смена сделает «две версии» одного и того же товара в отчетах.
Если реально появился новый вариант (новый цвет/размер как отдельная позиция) — создавайте новый variant_id и новый sku.
Минимум:
view_item (просмотр карточки)select_variant (переключение размера/цвета)add_to_cartpurchaseКак правило, по оплатам исходных заказов: заказы и выручка считаются по платежам.
Обмены ведите отдельной сущностью (счетчик и разрезы), чтобы не раздувать продажи. В разрезе вариантов полезны два вида спроса: первичный выбор и «на руках после обменов».
Не записывайте обмен как новую покупку. Рабочие варианты:
exchange_id.exchange с полями from_sku и to_sku (если учет позволяет).Обязательно храните связь с исходным заказом: , .
Сделайте словарь:
И закрепите правило: один язык и одна раскладка по всему каталогу.
Используйте явное значение, например ONESIZE или NO_SIZE. Не оставляйте пусто: пустые значения часто превращаются в разные «псевдо-варианты» в разных системах.
Так фильтры, события и отчеты будут стабильно работать и для кепок, и для аксессуаров.
Проверка на небольшой выборке обычно ловит 80% проблем:
variant_id/sku для выбранного размера/цвета.purchase содержит цену, количество и скидки отдельными полями (а не «вшитыми» в цену товара).sku + склад, а не новыми SKU под каждый склад.Если вы собираете магазин в TakProsto, удобно заранее зафиксировать эти правила в planning mode и прогнать тестовые сценарии до запуска.
refundexchangeВо всех событиях передавайте product_id, variant_id, sku, а также attributes (size/color) в стандартизированном виде.
original_order_idoriginal_line_id