Как проверить спрос на товар на Озон до закупки и не поставить на кон весь бюджет
Я проверяю спрос через поисковые подсказки, выдачу, предложения конкурентов и сезонность, но ни один из этих источников не считаю обещанием продаж. Покажу, как сопоставить сигналы, рассчитать ограничения для закупки и превратить первую партию в проверку гипотезы.
Перед закупкой я могу найти товар в подсказках Озон, увидеть отзывы у соседних предложений и всё равно не получить ответа на главный вопрос — купят ли его у меня по цене, при которой останутся деньги. В моих магазинах чужая популярная карточка сама по себе не становится основанием для заказа поставщику. У неё другая история, условия доставки и накопленное доверие покупателей. Мне предстоит выйти рядом с ней с новым предложением, а не забрать её продажи вместе с похожим товаром. Поэтому проверку спроса я начинаю с разделения того, что вижу, и того, что только предполагаю.
До закупки мне нужны ответы на связанные, но разные вопросы: ищут ли такой товар, что именно хотят получить и могу ли я заработать на этом ожидании. Поисковая подсказка помогает с первым вопросом, изучение предложений — со следующим, а расчёт расходов может остановить закупку даже при заметном интересе покупателей. Точного будущего объёма продаж у меня на этом этапе нет. Вместо него я собираю основания для гипотезы и заранее определяю, сколько денег готов поставить на её проверку. Именно так я понимаю задачу «как проверить спрос на товар на Озон»: не угадать красивое число, а принять решение с понятными ограничениями.
Что можно понять по поисковым подсказкам
Я начинаю с языка покупателя, а не с названия в прайсе поставщика. Ввожу в поиск название товара, затем пробую формулировки через назначение, материал, совместимость или проблему, которую человек хочет решить. Подсказки сохраняю вместе с исходным запросом, чтобы потом не потерять смысл уточнений. Если поиск предлагает конкретное свойство, я проверяю, есть ли оно у моего будущего товара и понятно ли его преимущество без длинных объяснений. Так получается набор покупательских задач, а не просто список слов для карточки.
Наличие подсказки я не перевожу в количество заказов. Без данных о том, как она сформирована и за какой период, это лишь повод изучить запрос внимательнее. Отсутствие подходящей подсказки тоже не доказывает, что товар никому не нужен: покупатель может использовать другое название или приходить через соседнюю категорию. Для проверки я сравниваю формулировки между собой и смотрю, какие предложения появляются по каждой. Если один и тот же запрос приводит к товарам с разным назначением, складывать весь предполагаемый интерес в спрос на мою позицию нельзя.
Отдельно я записываю признаки намерения купить: нужный размер, комплектацию, условия применения, совместимость. Сам по себе общий интерес к категории ещё не означает готовность заказать конкретное исполнение. Поэтому полезная аналитика спроса на товары Озон начинается с узкого описания предложения: кому оно подходит и за какую задачу покупатель отдаст деньги. Если это описание пока расплывчатое, закупку я не ускоряю, а продолжаю проверку вариантов. Последовательность отбора самой идеи я подробнее разобрал в статье о том, , а здесь дальше смотрю на признаки спроса.
Как читать выдачу и что можно узнать о продажах конкурента
Следом я открываю выдачу по сохранённым запросам и фиксирую условия просмотра, включая регион доставки и дату. Это нужно, чтобы при повторном просмотре не принять изменение условий за движение спроса. Смотрю на цену сопоставимого исполнения, комплектацию, срок доставки, содержание карточки и рекламные пометки, если они показаны. Сравниваю именно предложение, которое покупатель может заказать, а не минимальную цену среди всех вариантов. Дешёвая позиция с другой комплектацией не становится моим прямым конкурентом только потому, что находится рядом.
На вопрос «как узнать, сколько продаж у конкурента» у меня нет обещания точного ответа без доступа к его данным. Внешний сервис может оценивать продажи по своей методике, но сначала я хочу понять источник, период расчёта и то, что именно считается продажей. Например, уменьшение наблюдаемого остатка может быть связано с заказами, перемещением товара или корректировкой доступного количества. Отзывы тоже не дают прямого пересчёта в продажи: они появляются с задержкой, а их связь с конкретным исполнением нужно проверять. Я использую такие признаки вместе, но не выдаю совпадение нескольких оценок за подтверждённый отчёт продавца.
В аналитике ниши Озон мне полезнее искать повторяющуюся картину у сопоставимых предложений, чем ориентироваться на заметного лидера. Проверяю, появляются ли свежие отзывы, сохраняется ли наличие, меняются ли цены и условия доставки при повторных наблюдениях. Эти признаки позволяют сформулировать гипотезу о текущем интересе, хотя сами по себе не объясняют причины изменений. Если всё внимание сосредоточено вокруг карточки с недоступными мне условиями, переносить её результат на свой запуск особенно рискованно. О том, где заканчиваются наблюдения и начинаются предположения, я отдельно написал в разборе аналитики конкурентов без догадок о чужих продажах.
Прогноз спроса: вместо среднего за период — линейный тренд с поправкой на день недели и запас на нестабильность. Разовые всплески (оптовый заказ, накрутка конкурента) отмечаются отдельно и не задирают рекомендацию.
Как не перепутать устойчивый спрос с сезонным всплеском
Снимок выдачи показывает условия просмотра в конкретный момент, а закупленный товар должен продаваться после приезда на склад. Между этими событиями проходит время, за которое интерес покупателей может измениться. Поэтому я сопоставляю доступную историю поискового интереса, датировку отзывов и сезон использования товара, не считая эти источники взаимозаменяемыми. Внешняя статистика запросов описывает интерес в своей поисковой среде, а не оплаченные заказы на Озон. Если исторических данных нет, я прямо записываю это как неопределённость, вместо того чтобы объявлять спрос стабильным по текущей выдаче.
Затем я раскладываю путь товара от оплаты поставщику до доступности покупателю. В него входят подготовка партии, перевозка, приёмка и другие этапы, которые действительно есть в моей схеме поставки. Сроки беру из своих договорённостей и наблюдений, а не подставляю универсальное обещание для любой поставки. После этого смотрю, попадёт ли товар в период использования или приедет, когда потребность уже ослабеет. Если интерес есть сейчас, а продавать я смогу заметно позже, текущая активность соседей не оправдывает размер будущей партии.
Для сезонного предложения я заранее рассматриваю сценарий, в котором часть товара останется после спада. Проверяю, можно ли перенести остаток без потери потребительских свойств, сколько будет стоить хранение и есть ли приемлемый способ освободить деньги раньше. Если ответ зависит от большой будущей скидки, её нужно учитывать при оценке риска ещё до оплаты поставщику. Нельзя одновременно рассчитывать на продажу по полной цене и считать распродажу безболезненным запасным выходом. Подробности такого календарного расчёта я собрал в статье о том, как планировать сезонные товары и не хранить остатки до следующего сезона.
«Мой склад» держит то, чего нет у Ozon: сколько лежит у вас, сколько едет из Китая и когда пора заказывать следующую партию, чтобы она успела к концу запаса.
Как посчитать закупку при неточной оценке спроса
Первым шагом я считаю результат от продажи единицы при выбранной цене. Из суммы, которую признаю доходом от продажи по своему учёту, последовательно вычитаю закупочную себестоимость, доставку товара до места продажи, подготовку и упаковку, затем расходы площадки по своей схеме работы. Следом учитываю продвижение и налоговую нагрузку, рассчитанную по правилам моего режима. Комиссии и услуги беру из актуальных условий для конкретного товара, а расходы на привлечение до запуска оставляю предположением, которое нужно проверить. Если исходной суммой служит уже очищенная от удержаний выплата, повторно вычитать те же удержания нельзя.
Следующим шагом я делаю осторожный вариант этого расчёта: проверяю результат при снижении цены, более дорогом привлечении и дополнительных расходах на возврат или обработку. Значения для проверки беру из предложений поставщиков, доступных условий и собственного опыта с сопоставимыми операциями, а при отсутствии основания оставляю расход неизвестным. Поступление денег по заказу ещё не означает, что все связанные с ним расходы уже известны. Поэтому рядом с расчётом держу резерв на незавершённые операции, не изображая его точной оценкой будущих возвратов. Если даже при исходных предположениях продажа не покрывает относящиеся к ней затраты, увеличение закупки не исправляет экономику.
Деньги, потраченные на первую партию, нельзя автоматически считать временно свободными до её продажи. Если спрос окажется слабее ожиданий, часть суммы застрянет в остатках, а часть уйдёт на расходы без возврата. Я не включаю в бюджет проверки деньги на обязательные платежи и поддержку действующих продаж. Положительный расчёт дохода с единицы не заменяет запаса денег на период, пока эта единица лежит без покупателя.
После расчёта единицы я определяю денежный предел закупки. Из доступного для проверки бюджета вычитаю затраты на запуск, отдельный бюджет продвижения, резерв на дополнительные операции и деньги на завершение проверки при слабых продажах. Остаток делю на сумму, которую нужно вложить в единицу до её продажи: закупку, подготовку и доставку в применимой части. Так получается ограничение по финансированию, а не прогноз количества заказов. Одни и те же расходы могут участвовать в расчёте дохода и движения денег, но внутри каждого расчёта я учитываю их без повторного вычитания.
Затем я проверяю ограничение по допустимой потере денег, отдельно от способности оплатить партию. Для каждого рассматриваемого объёма складываю связанные с проверкой расходы и вычитаю осторожную оценку чистой выручки от обычных продаж и выхода из остатков, не учитывая товар повторно. Если способ реализации остатков не подтверждён, я не закладываю спасительную выручку только потому, что она делает таблицу приятнее. Объём, при котором возможная потеря превышает мой заранее выбранный предел, исключаю, даже если денег на оплату достаточно. Из оставшихся вариантов выбираю тот, который подходит для проверки гипотезы с учётом минимальной партии поставщика и реалистичного сценария спроса; если подходящего варианта нет, закупку откладываю.
Первая партия должна проверить гипотезу, а не подтвердить надежду
Конкретная ошибка в таком расчёте — принять предполагаемые продажи конкурента за собственный план и заказать товар под этот объём. Тогда в таблице расходы на запуск распределяются на ожидаемые продажи, а непроданные единицы словно исчезают из денежной картины. При слабом старте фактические расходы на проданную единицу оказываются выше, деньги остаются в товаре, и для их возврата приходится менять цену или оплачивать дальнейшее хранение. Потеря от снижения цены считается напрямую: разницу между запланированной и фактической ценой умножаю на количество проданных со снижением единиц, а изменение связанных расходов считаю отдельно. Поэтому чужая оценка продаж у меня служит материалом для гипотезы, но не разрешением потратить весь бюджет.
До запуска я письменно формулирую, что именно должна подтвердить партия: покупатель выбирает это исполнение по моей цене, а завершённые продажи оставляют приемлемый результат после расходов. Заранее задаю условия, при которых продолжу проверку, изменю предложение или остановлю закупки, исходя из своего денежного предела и календаря товара. Потом разделяю причины слабого результата: предложение могли почти не увидеть, могли открыть и не выбрать либо заказать, но вернуть. Без достаточного доступа к аудитории отсутствие продаж не доказывает отсутствие спроса, однако и бесконечно оплачивать показы ради проверки нельзя. Изменения цены, карточки и продвижения я фиксирую по времени, чтобы не смешивать результаты разных условий.
После старта аналитика спроса Озон для меня переходит от внешних признаков к собственным наблюдениям и расходам. Я сопоставляю доступные данные о просмотрах и заказах с отменами, возвратами, фактическими начислениями и остатком товара, учитывая задержки появления информации. Именно потребность видеть экономику своих магазинов, а не доверять одной красивой оценке, привела меня к разработке SellOps; подход я описал на странице о том, как устроен сервис. Но никакой сервис не превращает чужие неизвестные продажи в достоверный факт и не снимает неопределённость нового запуска. Решение о повторной закупке я принимаю по собственным результатам с поправкой на сезон, изменение условий и деньги, необходимые до следующего поступления выручки.
Завтра я бы начал с таблицы по конкретному кандидату на закупку, а не с оплаты поставщику. В неё нужно перенести покупательские запросы, сопоставимые предложения, наблюдения о сезонности и отдельно пометить всё, что пока является предположением. Затем стоит заполнить расчёт результата с единицы, денежного предела партии и потерь при слабом сценарии, используя свои условия вместо чужих обещаний. Последняя запись перед решением — какой результат проверки позволит заказать следующую партию и при каком результате закупки остановятся. Если таблица держится только на надежде повторить продажи соседней карточки, для меня это основание продолжить проверку, а не увеличить заказ.