E-commerce и маркетплейсы — запуск, рост, автоматизация

Стоит ли участвовать в Ecom Expo: опыт компании и результаты

Wed, 01 Jul 2026 08:28:02 +0300

Выставки в 2026 работают?

Всем привет!

Вот и прошла первая половина года. Как у вас дела с целями на 2026-й? Получилось выполнить хотя бы 50% запланированного?

У нас нет. Значит, есть над чем работать.

На прошлой неделе мы второй раз в жизни участвовали в выставке со своим стендом — на Ecom Expo. До этого весной были на выставке «Селлеры и Маркетплейсы», поэтому уже есть с чем сравнить.

На первой выставке мы получили около 20 лидов. Пока в контракт превратился только один. Если считать только его, стоимость привлечения выглядит пугающе — около 300 тысяч рублей. Но в B2B сделки живут долго, поэтому окончательные выводы делать рано. Часть переговоров еще продолжается.

С Ecom Expo впечатления совсем другие.

Посетителей было заметно больше, и это чувствовалось буквально во всем. Мы собрали около 60+ лидов, а количество содержательных разговоров выросло примерно втрое. Основной интерес был к нашему репрайсеру GuardPrice. Забавно, что мы стояли в зале, который больше ориентирован на разработку и интеграции, хотя целевая аудитория продукта в основном находилась в соседнем павильоне с маркетинговыми сервисами. Если бы знали это заранее, выбрали бы другое место. Но даже так люди сами находили наш стенд.

По услугам разработки и внедрению CRM тоже были обращения, хотя их оказалось значительно меньше. Это вполне ожидаемо: на подобных мероприятиях все же чаще приходят за готовыми продуктами, чем за заказной разработкой.

Если говорить о самой выставке, то не очень понравилась площадка в «Тимирязев Центре».

Само пространство современное, удобное и выглядит отлично. Но организация сцен оставила вопросы. Они никак не отделены от основной выставочной зоны: нет ни стен, ни звукоизоляции. В результате несколько сцен одновременно создают постоянный фоновый шум. Разговаривать приходится почти криком, и к концу второго дня голос просто заканчивается. Не завидую спикерам — выступать в таких условиях явно непросто.

Кстати, еще один практический вывод: удобная обувь — обязательна. Не просто удобная, а максимально удобная. Беговые кроссовки, Crocs или что-то похожее. Два дня почти без перерывов на ногах ощущаются намного тяжелее, чем кажется заранее.

По аудитории тоже было интересно. До выставки казалось, что основной поток составят небольшие продавцы и селлеры. На практике среди примерно сотни людей, с которыми мы пообщались, около трети представляли уже достаточно зрелый средний бизнес, а 8–10 компаний — это действительно крупные игроки рынка, которых легко найти в рейтингах крупнейших компаний российского e-commerce. И, что особенно приятно, многие из них интересовались именно репрайсером.

Конечно, окончательные выводы можно будет делать только после обработки всех лидов и завершения переговоров. Но уже сейчас могу сказать, что с точки зрения вложенных денег, времени и полученного опыта участие в выставке себя оправдало.

Поэтому осенью обязательно повторим. В сентябре едем со стендом на Retail Week.

Посмотрим, какие выводы сделаем после третьей выставки.

Что на самом деле стоит за развитием репрайсера для маркетплейсов

Wed, 17 Jun 2026 17:07:20 +0300

«Да это Claude за час сделает»

Всем привет 👋

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

Логично предположить, что свободного времени становится больше. Но почему-то получается ровно наоборот.

Больше всего времени сейчас уходит на продукт. За кажущейся простотой и популярной мыслью «да это Клод за час навайбкодит» обычно скрывается огромное количество нюансов. И чем глубже копаешь, тем больше понимаешь, что основная работа начинается уже после того, как первая версия заработала.

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

Свои прокси вместо арендованных

С самого начала продукт был довольно автономным и почти не зависел от внешних сервисов. Но одна зависимость всё-таки оставалась прокси.

Долгое время мы их закупали у сторонних поставщиков. Казалось бы, что тут может пойти не так? На практике многое.

Мы перепробовали множество провайдеров и сервисов. Где-то была слишком агрессивная ротация IP, где-то качество адресов оставляло желать лучшего. Но главная проблема была в другом отсутствие стабильности.

Система могла спокойно работать неделю, а потом в самый неподходящий момент прокси просто исчезал на несколько часов. Для репрайсера это критично.

Поэтому мы решили сделать следующий шаг и перейти на собственную инфраструктуру прокси. Теперь сами отбираем IP по нашим требованиям и контролируем качество работы. Это не самая заметная функция продукта, но именно такие вещи дают реальную надёжность.

Когда отказоустойчивость перестаёт быть теорией

Продолжая тему стабильности.

До недавнего времени ядро системы располагалось на инфраструктуре Бегета, и в целом всё работало отлично. Но весной произошло несколько неприятных историй подряд.

Судя по комментариям провайдера, на магистральных каналах возникли серьёзные проблемы. В какой-то момент одновременно выпали основной и резервный провайдеры. Для большинства проектов это неприятность. Для сервиса, который должен работать постоянно, уже серьёзный риск.

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

После этого стало понятно, что хранить все яйца в одной корзине плохая идея.

Сейчас мы активно смотрим в сторону Selectel, Яндекс Облака, Reg.ru и других площадок. Параллельно перестраиваем архитектуру продукта в сторону сервисного подхода. Не микросервисы ради модного слова, а разумное разделение системы на независимые компоненты.

В моём понимании «много сервисов» это не сотни. Уже около десяти независимых сервисов позволяют переживать отдельные сбои без остановки всей системы.

Апрель и май получились довольно увлекательными, бессонными и местами незабываемыми. Но именно такие месяцы обычно заставляют принимать правильные инфраструктурные решения.

Что ещё делаем

Пока занимались вопросами надёжности, работа над самим продуктом не останавливалась.

Оптимизировали существующие стратегии, в том числе с точки зрения безопасности. Начали разработку стратегий на основе UNIT-экономики каждого товара. Продолжаем развивать поддержку новых площадок Золотое Яблоко, Лемана ПРО, М.Видео и других маркетплейсов.

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

Новый человек в команде продукта

И, наверное, самое важное изменение за последнее время.

К команде присоединился новый коллега. Я в шутку называю его цифровым разнорабочим. Да простит меня Рома.

По сути, он будет совмещать сразу несколько ролей: аккаунтинг, project management и product management.

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

Впрочем, как и всегда, время покажет.

Ну и напоследок.

Если давно хотели пересечься лично, напоминаю, что уже на следующей неделе будет Ecom Expo. Мы будем там со своим стендом. Подробности здесь: https://t.me/alexeyitru/206

Буду рад увидеться и пообщаться вживую.

Измеряем B2B SaaS одной метрикой — почему это почти невозможно

Wed, 20 May 2026 14:43:03 +0300

В какой-то момент и до нас докатилась необходимость начать нормально измерять продукт. Не в формате «ну вроде продажи идут» или «по ощущениям всё неплохо», а цифрами.

Сразу оговорюсь: рассказывать про виды метрик, North Star, retention и прочие правильные термины я не буду. Про это уже написаны сотни статей и сняты тысячи видео людьми куда умнее меня. Расскажу лучше, как это постепенно появляется у нас.

Кажется, мы постепенно переросли стадию подтверждения гипотезы из серии: «О, кто-то действительно готов за это платить деньги». А это уже немного другой этап. На нем продукт перестает быть просто «интересной штукой» и начинает превращаться в систему, где важно понимать, что именно растет, почему растет и где всё может внезапно начать ломаться.

И тут начинается самое интересное.

Одной метрикой

Как и многие, вначале хотелось найти какую-то одну волшебную цифру. Посмотрел на неё утром и сразу понял: всё хорошо или пора тушить пожар.

Но это работает плохо. Особенно если сервис в целом должен функционировать автономно. У нас нет классической истории, где пользователь каждый день открывает приложение, тыкает настройки и проводит внутри по три часа. Поэтому DAU, MAU и прочие красивые графики в нашем случае не всегда что-то реально покажут.

Потому что клиент может вообще не заходить в систему неделю и это будет означать не проблему, а наоборот: всё работает стабильно.

В итоге приходит понимание, что смотреть приходится сразу на несколько слоев продукта:
— деньги,
— техническое здоровье,
— поведение клиентов,
— маркетинг,
— стабильность инфраструктуры.

И только вместе это начинает давать более-менее честную картину.

Первое, с чего начали

Самое очевидное — деньги.

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

А вот разработку и развитие продукта сюда специально не включаем. Потому что это уже скорее инвестиции, а не операционные расходы. Иначе можно случайно прийти к выводу, что продукт убыточен просто потому, что вы активно его развиваете.

Хотя здесь, конечно, у каждого своя логика учета.

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

Неважные технические метрики

Для B2B SaaS технические метрики иногда важнее продуктовых.

Потому что пользователь может простить неидеальный интерфейс. Может простить сложную настройку. Но вот если у него перестала корректно работать автоматизация это уже проблема.

Поэтому хотим начать отслеживать:
— количеством активных профилей,
— числом товаров под контролем,
— количеством успешных обработок,
— товарами, ушедшими в перерасчет,
— ошибками обработки,

На практике, думаем, это поможем быстро замечать перекосы на маркетплейсах. Где-то поменялась логика, где-то API начал отвечать через раз, где-то очередной «эксперимент» площадки сломал половину логики.

Раньше такие вещи замечались через поддержку: клиент пишет, что «что-то странное». Сейчас многие проблемы видно еще до обращения клиента. И это, наверное, одна из самых полезных частей всей истории с метриками.

Маркетинг

Отдельная история — маркетинговые показатели. Смотрим на CAC, органический трафик, количество лидов и пытаемся всё это сопоставлять с деньгами.

Потому что лиды сами по себе довольно опасная метрика. Их может быть много, но если они плохо конвертируются или быстро отваливаются, ценности в этом немного.

Вообще, чем дальше, тем сильнее появляется ощущение, что почти любая метрика без контекста легко вводит в заблуждение.

Можно радоваться росту регистраций и не замечать, что половина пользователей не доходит до запуска. Можно радоваться росту оборота и не видеть, что вместе с ним растут расходы. Можно смотреть на MRR и не замечать, что support уже начинает задыхаться. Цифры без контекста иногда вредят даже больше, чем их отсутствие.

Самая сложная часть

Из экономических показателей пытаемся следить за:
MRR, ARPA, CLTV и TCV.

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

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

Самая грустная часть

Самое забавное, что продукт про автоматизацию, а сами мы аналитику до сих пор собираем почти вручную. Что-то лежит в CRM. Что-то в таблицах. Где-то цифры обновляются автоматически, где-то руками.

И в какой-то момент начинаешь понимать, что следующая задача — это уже не сбор метрик, а сбор метрик о метриках. Потому что когда данных становится много, появляется новая проблема: как не утонуть в них и не начать принимать решения только потому, что график красиво растет вправо вверх.

Акции на маркетплейсах: как формируется цена и почему падает маржа

Tue, 05 May 2026 15:46:39 +0300

Про акции на маркетплейсе и медианную цену

Ни для кого не секрет, что акции на маркетплейсах — это почти главный инструмент продвижения. Дополнительные плашки на карточке, буст в выдаче, рост трафика — все это напрямую конвертируется в продажи. Вопрос только в том, какой ценой.

В детали типов акций углубляться не будем. Важно другое: в большинство акций можно попасть автоматически, если товар проходит по условиям. Площадка берет медианную цену за последние 1–3 месяца и снижает ее на 10–30%, чтобы сформировать «выгоду» для покупателя. Именно от этой логики дальше строится вся экономика.

Главная проблема: цена против трафика

Если коротко — усидеть на двух стульях не получится. Нельзя одновременно активно участвовать в акциях и жестко удерживать цену на целевом уровне.

Единственный рабочий вариант — планомерно поднимать медианную цену. Тогда вход в акции будет происходить уже от вашей целевой РРЦ, а не от заниженной базы. Это длинная игра, но других стабильных вариантов нет.

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

Как мы работаем с акциями

Подход у нас одинаковый для всех маркетплейсов. Разница только в нюансах API.

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

Если товар оставили в акции, система просто ждет ее окончания. После завершения — автоматически возвращает цену в нужный диапазон. Это безопасный сценарий, но без контроля внутри акции.

Когда включена работа с акциями по API, начинается уже более точная логика. Система получает список активных акций и проверяет каждый товар — с учетом того, что он может участвовать сразу в нескольких.

Дальше все упирается в ограничение маркетплейса: есть максимальная цена в акции, которая рассчитывается от медианной. Выше нее подняться нельзя.

Система считает целевую цену для попадания в РРЦ и сравнивает ее с этим потолком. Если расчетная цена ниже — все просто, мы обновляем цену и остаемся в акции. Но так бывает редко.

Если расчетная цена выше — есть два варианта. Либо мы выходим из акции и возвращаем контроль над ценой, либо остаемся, но ставим максимально допустимую цену внутри акции. Во втором случае мы жертвуем коридором РРЦ, но сохраняем трафик.

Что в итоге

Акции — это не просто инструмент роста, это компромисс между объемом продаж и маржой. И чем раньше это принимаешь, тем проще строится стратегия. Хоть мы пока не умеем автоматически возвращать товары в «выгодные» акции — слишком много переменных в расчете, но в ближайшее время будет MVP по этому поводу.

Стратегии ценообразования на маркетплейсах: РРЦ, конкуренты, юнит-экономика и ошибки

Thu, 23 Apr 2026 14:37:12 +0300

Стратегии ценообразования, о которых все говорят, и как они ломаются в реальности

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

Разберу основные стратегии, с которыми сталкиваемся на практике.

РРЦ как ориентир

Самая базовая история это РРЦ. Некоторая “идеальная” цена, которую хочется удерживать во всех каналах: офлайн, маркетплейсы, сайт, дилеры.

Как она формируется сейчас не важно. Важно другое. РРЦ это ориентир, а не стратегия.

Как только появляется реальный рынок, все начинает расходиться. Акции, скидки площадок, серые поставки, давление дилеров. В итоге РРЦ остается на бумаге, а в жизни начинается борьба за фактическую цену продажи.

Следование за конкурентами

Вторая популярная модель это смотреть на конкурентов и повторять за ними. Выбирается одна или несколько карточек и дальше цена двигается вслед за ними.

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

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

Юнит-экономика

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

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

И здесь начинается сложность. Нужно собрать данные, поддерживать их в актуальном состоянии и правильно учитывать в расчете. Мы сейчас как раз двигаемся в эту сторону и готовим такую модель у себя. Посмотрим, как она поведет себя в реальности.

Рост оборота и красивые стратегии

Отдельный класс решений это “умные” стратегии вроде роста оборота или маржинальности.

На бумаге все выглядит убедительно, пока не смотришь внутрь.

Простой пример. Есть диапазон цены 100–150 рублей. Ставим цель увеличить оборот. Что делает система. Роняет цену до 100, продажи растут. Когда остаток уменьшается, поднимает до 150.

В отчетах все хорошо. Оборот вырос, метрика выполнена. По факту вы просто продали товар дешевле, чем могли. Такие стратегии отлично оптимизируют цифры, но не всегда оптимизируют бизнес.

Попытка нащупать спрос

Еще одна идея это динамически менять цену и смотреть на реакцию продаж. Подняли, посмотрели. Опустили, посмотрели. Попробовали найти баланс.

Проблема в том, что рынок живет не только ценой. Продажи могут вырасти из-за рекламы, сезона, погоды или действий конкурентов. А система в этот момент считает, что это ее заслуга и продолжает двигаться в ту же сторону.

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

Что еще

Есть ещё ряд стратегий, которые в классическом ритейле считаются нормой, но на маркетплейсах встречаются заметно реже. Например, ценообразование от канала (channel-based pricing), когда одна и та же позиция стоит по-разному в зависимости от точки продаж, или премиальная модель (value-based pricing), где цена сознательно выше рынка за счёт бренда и позиционирования. В офлайне и D2C это работает, потому что меньше прозрачности и больше контроля над клиентским опытом. На маркетплейсах же всё лежит “на одной полке”, и разница в цене быстро становится проблемой, а не преимуществом.

Туда же можно отнести стратегии осознанного демпинга (penetration pricing) или, наоборот, удержания цены относительно лидера рынка (price leadership). Формально это разные подходы, но по сути — попытка занять понятную роль: либо самый дешёвый, либо “как у лидера”. В реальности такие модели требуют запаса прочности и дисциплины, иначе быстро уходят либо в минус, либо в постоянную реакцию на чужие действия.

И, наконец, есть более операционные модели — например, stock-based pricing, когда цена зависит от остатков. Логика здравая: ускоряем оборачиваемость или, наоборот, дорабатываем маржу на дефиците. Но на маркетплейсах это упирается в ограничения площадок, акции, комиссии и ту же РРЦ. В итоге все эти стратегии существуют, но применяются точечно и редко становятся основой — слишком много внешних факторов, которые их ломают.

Что в итоге

Если собрать все вместе, видно простую вещь. У каждой стратегии есть ограничения. РРЦ не выдерживает реальности. Конкуренты непредсказуемы. Юнитка сложна в реализации. “Умные” стратегии дают красивую картинку, но не всегда результат. Эксперименты дают шум. В итоге не существует одной правильной модели. Есть только комбинация подходов и постоянная работа с данными.

Куда смотрим дальше

Сейчас у себя мы сфокусировались на следующем уровне. Работа с акциями на маркетплейсах.

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

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

Первый выход в офлайн: репрайсер на SIM 2026 — опыт участия в конференции «Селлеры и маркетплейсы»

Wed, 04 Mar 2026 09:19:46 +0300

Конференция «Селлеры и маркетплейсы 2026»: первый офлайн-опыт с репрайсером

Давно не писал. Последние пару недель выдались напряжёнными и продолжают такими быть. На прошлой неделе мы впервые вывели продут в офлайн и поехали на конференцию селлеры и маркетплейсы. Это был первый ивент для продукта, и первый для компании за долгое время.

Выставка проходила в Кластере Ломоносов. Само пространство классное — современное, аккуратное, технологичное. Но локация, мягко говоря, не самая удобная ощущение «у чёрта на куличиках». Возможно, это тоже повлияло на трафик. В целом прошло порядка 1000–1500 человек за два дня. Мы ожидали большего потока, но аудитория оказалась довольно узкой и профильной, что для нас скорее плюс.

Организация в целом на хорошем уровне. Программа местами вызывала ощущение, что всё можно было уместить в один день, но это уже вкусовщина. Главное — гипотеза по продукту подтвердилась: проблема есть, рынок её признаёт, и решение для своей когорты клиентов заходит.

Лучше всего нас понимали производители и дистрибьюторы. У них другой горизонт планирования и другой взгляд на управление ценой. Селлеры же, для которых в фокусе оборот и маржинальность здесь и сейчас, реагировали ожидаемо: «Как можно жертвовать СПП?» В этих диалогах мы выглядели почти сумасшедшими, но это нормально — просто разные модели мышления и разные цели бизнеса.

Почти в каждом разговоре поднимался вопросы: чем вы отличаетесь от конкурентов, они стояли через пару стендов от нас и в чем отличия форматов: SaaS или коробка. Если объёмы небольшие — логичен SaaS. Если большие, с требованиями к инфраструктуре и контролю — коробка. Мы сознательно развиваем оба направления, потому что всё зависит от потребностей клиента.

По цифрам: собрали порядка 30 контактов, из них около 10 — действительно суперцелевые. Плюс дополнительно пообщались по внедрению CRM и заказной разработке — неудивительно, проблемы у всех похожие. Сейчас разбираем контакты и назначаем ВКС, по итоговой конверсии говорить рано, но первый срез уже позволяет сделать вывод.

По стоимости привлечения целевого лида контекст пока выгоднее выставки. Выставка это время, подготовка, логистика, стенд и два дня полной концентрации. Контекст масштабируется проще и управляется системнее. При этом офлайн даёт глубину общения, быстрый сбор обратной связи и понимание языка рынка — а это тоже актив.

Со стендом мы, кстати, знатно лоханулись. Он был большой, но ниже метра ничего не было видно всё перекрывала стойка и мы сами. По сути издалека было непонятно, что у нас вообще происходит. Первый опыт — фиксируем ошибки и идём дальше.

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

В результате приняли решение публично вести лог изменений на сайте, скоро он появится на сайте. Туда будем складывать все крупные и средние доработки по проекту.
Поедем ли ещё? Да. Несмотря на экономику в пользу контекста, минимум одну выставку летом и одну осенью планируем. Увидимся в офлайне.

Черные лебеди в SaaS: как один закон и один анонс могли похоронить наш продукт

Thu, 19 Feb 2026 12:26:40 +0300

Иногда ты просыпаешься утром и понимаешь, что твоего продукта может просто не стать.

Не потому что плохой код или ушли клиенты, а потому что где-то приняли решение, которое меняет правила игры. 2026 год для нас начался именно так — с двух анонсов, которые теоретически могли обнулить рынок репрайсеров.

Закон, который мог обнулить рынок

С 1 октября 2026 года в России вступает первый закон о платформенной экономике. Он регулирует маркетплейсы, сервисы доставки, такси и другие цифровые площадки-посредники. Государство фиксирует правила для огромного рынка, делая его более прозрачным и управляемым, но при этом не вмешивается напрямую в экономику платформ.

Маркетплейсы больше не смогут резко менять условия: о повышении комиссий, штрафов и изменении правил нужно уведомлять за 45 дней. Запрещены необоснованные блокировки, вводится обязательная система досудебных споров. Площадка не может снижать цену без согласия продавца — можно установить минимальную цену.

На первый взгляд — хорошие новости для селлеров. Но если смотреть с позиции продукта, который работает с ценообразованием, возникает вопрос: а не убивает ли это саму потребность в репрайсерах? Если рынок становится «справедливее», если площадки не могут произвольно вмешиваться в цену, нужен ли внешний инструмент?

Теоретически такой закон мог просто обнулить рынок. Мы даже не считали детально сценарий влияния, но в худшем варианте рынок мог сократиться почти до нуля. Однако фундамент остаётся прежним: комиссии, штрафы и маркетинговые механики никто не ограничивает, а контроль над спросом всё равно у платформ. Формулировки могут поменяться, но монопольная сила площадок никуда не исчезает. Поэтому главный вопрос — даст ли закон селлерам полноценно управлять «зелёной» ценой — скорее всего, нет.

Репрайсер от Ozon

Вторым «чёрным лебедем» стал анонс собственного репрайсера от Ozon для WB и Ozon. Пока это пилот для ограниченного числа продавцов, но сам факт выхода платформы в эту зону — сигнал. Если маркетплейс делает собственный инструмент, логичный вопрос: зачем тогда сторонние сервисы?

Первая обратная связь от селлеров показала, что «зелёную» цену инструмент держит нестабильно — часто уходит ниже. Возможно, это баг, возможно — особенность алгоритма, и его поправят. Про WB пока рано что-то утверждать. Но важно другое: у платформы всегда больше данных и больше контроля над финальной ценой, чем у внешнего сервиса. И если такой продукт доведут до стабильной версии, это меняет рынок.

История знает немало внутренних продуктов крупных компаний, которые так и не стали массовыми. Вспоминается целое кладбище инициатив того же Яндекса. Поэтому пилот — это ещё не приговор, но сигнал, который нельзя игнорировать.

Что это значит для нас

Самое важное в этой истории — не закон и не Ozon. А то, что SaaS, построенный вокруг платформ, зависит от чужих решений. Сегодня ты оптимизируешь их экономику, завтра они меняют правила или выходят со своим инструментом.

При этом реальность сложнее и не сводится к драме. У нас есть решение для Яндекс Маркета, и сейчас это сильная сторона. Рынок постепенно движется в сторону модели, похожей на США, где платформы усиливают контроль над экономикой, а выигрывают в первую очередь производители. Если этот тренд закрепится, инструменты управления ценой никуда не исчезнут — просто изменится их роль.

Черные лебеди в продукте — это не всегда катастрофа. Чаще это напоминание о том, что ты играешь на чужом поле. И если строишь бизнес вокруг маркетплейсов, нужно быть готовым к тому, что изменения извне могут в любой момент закончить историю продукта. Вопрос лишь в том, станет ли это концом или точкой следующего роста.

Математика против пороговых скидок

Fri, 13 Feb 2026 09:16:41 +0300

Продолжаем вести историю изменений по продукту. Как вы поняли из предыдущего поста, мы едем с ним на выставку.

Посмотрим, что из этого получится. Про экономику обязательно отдельно напишу, когда будут данные и можно будет говорить предметно. А пока — что успели сделать с начала года и какие выводы для себя сделали.

С аутричем вышла интересная история. Мы его протестировали и пока притормозили. На старте казалось, что выйти на нужных селлеров будет относительно просто, но реальность оказалась сложнее. Достучаться до правильного человека в e-commerce куда труднее, чем кажется изнутри продукта. Это не значит, что канал плохой, но усилий он требует больше, чем мы закладывали.

Зато отлично себя показывает контекстная реклама. Сейчас получаем квалифицированных лидов примерно по 1500 рублей, и для нашей экономики это рабочая модель. Плюс постепенно начинает давать результат SEO. Не быстрый инструмент, но устойчивый. Параллельно развивали сайт и в итоге перевезли его на Битрикс — редактировать контент становилось все сложнее, а продукт растет, информации становится больше. Нужно было навести порядок, иначе начинаются операционные косты там, где их можно было избежать.

Также добавили новые направления по работе с Lamoda, Лемана Про и М.Видео. Расширяем покрытие аккуратно, без резких движений, но последовательно.

Эксперимент с биллингом вместо тарифов

Отдельно расскажу про изменение модели оплаты. Раньше у нас были просто тарифы. Но по факту запросы клиентов оказались слишком разными. У кого-то десятки товаров, у кого-то тысячи. У кого-то агрессивная частота обновления, у кого-то спокойный режим. В рамках фиксированных тарифов это начинало ломать логику.

Поэтому мы перешли на модель биллинга с баланса от запуска. Теперь у клиента есть счет, а списание происходит по факту использования. По сути — оплата за потребление, а не за абстрактный пакет возможностей. Нам кажется, что это более честная и гибкая модель, но посмотрим, как она покажет себя на дистанции.

Нелинейные скидки — главная математика

Продолжаем бороться с нелинейными скидками и авторизацией. Если вы продаете на маркетплейсах, то наверняка замечали, что цены могут сильно отличаться для разных покупателей. Влияет регион, выбранный ПВЗ, логистика, персональные механики площадки. Это делает задачу репрайсинга куда сложнее, чем кажется со стороны.

Мы отказались от индивидуальной авторизации под каждого клиента и перешли к единой авторизации для Ozon и Яндекс Маркета, которая смотрит цены как покупатель в Москве. Пока мониторим стабильность решения. Если покажет себя хорошо, добавим еще 3–5 регионов для сравнения.

А теперь пример, чтобы было понятно, в чем сложность. Товар на Яндекс Маркете. Передаем цену 5124 ₽ — покупатель видит 3293 ₽. Передаем 5224 ₽ — покупатель видит уже 4112 ₽. Мы меняем входную цену всего на 100 рублей, а итоговая цена для покупателя скачет почти на 1000. Это эффект пороговой скидки, и он ломает линейную логику расчета.

Чтобы работать с такими сценариями, мы разработали новую стратегию расчета с использованием естественного и искусственного интеллекта. Формула стала сложнее и требует большего количества шагов, но зато позволяет точнее подбираться к целевому значению. Важно понимать, что при старте нового профиля нужно 3–4 запуска, чтобы система собрала статистику и вычислила рабочие цены. Это не баг, это этап калибровки.

Фичи к выставке и упрощение онбординга

К ближайшей выставке допиливаем две функции, которые давно просили клиенты. Первая — возможность принудительного ручного запуска всех товаров или конкретного товара из личного кабинета. Раньше такая опция была только у админов, и это, честно говоря, было недальновидным решением.

Вторая — упрощенная форма создания профиля. Сейчас интерфейс во многом выглядит как панель программистов для программистов, что не лучшим образом влияет на онбординг. Мы делаем сценарий проще: нажимаешь «Создать», выбираешь маркетплейс, вводишь токен, выбираешь товары, ставишь РРЦ, задаешь частоту обновления — и запускаешь. Минимум лишних шагов.

При этом даже в текущем, не самом простом интерфейсе, есть пользователи, которые самостоятельно создают и запускают профили без нашей помощи. Это хороший сигнал.

Движение без иллюзий

Есть и другие мелкие задачи, которые решаем по мере поступления. Продукт постепенно взрослеет. Где-то через эксперименты, где-то через пересборку модели оплаты, где-то через математику скидок, которая на бумаге выглядит красиво, а в реальности ведет себя совсем иначе.

Работаем дальше. Увидимся на выставке. Буду рад пообщаться лично и обсудить, как у вас устроена экономика на маркетплейсах.

Яндекс Кит для интернет-магазина: что это, как работает и стоит ли запускать сайт

Wed, 04 Feb 2026 10:26:41 +0300

Новое начало маленьких интернет-магазинов?

Кажется, ниша небольших интернет-магазинов на WP и Тильде либо умирает, либо уверенно движется в эту сторону. И нет, это не про вайб-кодинг — он только расправляет крылья, посмотрим, куда его занесёт. Сегодня хочется поговорить про другое. Про Яндекс Кит.

Мы недавно участвовали в вебинаре для партнеров, кого пригласили посмотреть продукт изнутри. И вот что он из себя представляет.

По сути, это классический облачный конструктор, очень жёстко заточенный под e-commerce. Не универсальный «сайт обо всём», а именно магазин. И ключевая ставка здесь сделана на дизайн и на интеграции — то, на чём обычно всё и ломается.

С этим у Кита как раз всё неплохо. Базовый набор — ровно то, что нужно: обмен с 1С, «МойСклад», Яндекс Маркет, интеграция с Ozon и WB, retailCRM, amoCRM, Bitrix24. Можно подключить свой домен, фирменный стиль по мелочи, всё как положено.
По оплатам — Яндекс Pay и CloudPayments.
По логистике — Яндекс, СДЭК, Ozon Логистика.

В итоге со старта получается очень приятный и взрослый набор, без ощущения «песочницы».

Отдельно стоит сказать про одну из ключевых фишек — бесшовную интеграцию с Yandex ID. Что это даёт на практике? Более высокую конверсию за счёт того, что данные пользователя уже заполнены. А если карта привязана — покупка превращается буквально в пару кликов. Для небольшого интернет-магазина это огромная разница.

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

Создаётся ощущение, что Яндекс что-то знал про рынок маркетплейсов и волну селлеров, которые оттуда пойдут. Вопрос который был в воздухе: зачем свой интернет-магазин, если можно выложить карточки на маркетплейс и сразу получать продажи? Со своим интернет-магазином нужно думать про маркетинг, трафик, аналитику, повторные продажи. Это сложно и долго.

Но реальность сейчас такая: если ты продал на маркетплейсах на 5 млн рублей, 2–2,5 млн из них ты спокойно отдал в виде комиссии, логистики и маркетинговых сборов. И тут возникает вполне логичный вопрос — а неужели на своём интернет-магазине нельзя привлечь клиентов хотя бы на эти же 2 млн? При этом данные пользователей остаются у тебя, их можно догревать, возвращать, продавать повторно. А это уже совсем другая экономика.

Так что рынок разработки интернет-магазинов умер? И да, и нет.

Этот вопрос поднимался ещё в тот момент, когда маркетплейсы начали активно захватывать рынок. Зачем свой магазин, если это затраты, куча проблем, ресурсы и неочевидная отдача? Ответ пришёл со временем. Свой интернет-магазин — это бренд и прямой доступ к клиенту. А значит, меньше зависимости от правил площадки и чуть более спокойный сон.

В итоге что получается. Рынок разработки интернет-магазинов не умрёт. Яндекс Кит просто займёт свою нишу, отжав у Тильды, WP и части типовых решений на Битриксе проекты небольших e-commerce. Если нужно что-то сложное, нетривиальное или B2B — вариантов по-прежнему немного, и кастом никуда не денется.

Со своей стороны мы планируем активно пробовать Яндекс Кит как ещё один инструмент быстрого запуска для небольших e-commerce-проектов, где городить что-то большое и сложное просто нецелесообразно.

Инструменты меняются. Смысл — нет.

PIM-система для e-commerce: зачем нужна, когда внедрять и какие бывают решения

Tue, 20 Jan 2026 09:33:22 +0300

PIM: дорого, сложно. И почему без него иногда нельзя

Праздники закончились, пора вкатываться в рабочий ритм. На праздники был простой план: написать много контента. По факту контента написать не получилось, зато отлично прокачались новые когнитивные связи на падел-корте. Но сейчас не об этом.

Конец года оказался богатым на проекты, где так или иначе всплывала тема внедрения или серьёзной переработки системы хранения товарных данных. В простонародье это PIM. Product Information Management. Формально PIM почти всегда уже есть. Иногда эту роль выполняет CMS или 1С или какая то иная система. Где-то лежат описания, где-то характеристики, где-то изображения.

До определённого момента этого хватает. А потом наступает состояние, когда дальше так жить невозможно. Не потому что «так принято», а потому что становится больно. Больно обновлять каталог, больно создавать новые товары, больно выходить на маркетплейсы и поддерживать порядок.

Когда всё начинает ломаться?

Проблемы редко появляются резко. Обычно они накапливаются. Контент начинают править в нескольких системах одновременно. Характеристики дублируются и расходятся. Картинки теряются, переименовываются вручную и живут без связи с товаром. SKU начинают вести себя как отдельные сущности, но управлять ими по-прежнему пытаются как попало.

В какой-то момент 1С перестаёт быть чисто учётной системой и превращается в неудобный редактор контента. CMS начинает хранить вообще всё подряд. Никто уже не может ответить, где находится «истина», а любое изменение превращается в риск что-то сломать.

И именно здесь появляется PIM. Не как ещё одна модная платформа, а как попытка навести порядок в данных.

Зачем вообще нужен?

Ключевая мысль, которую важно принять сразу. PIM не заменяет 1С и не конкурирует с CMS. У каждой системы своя роль.

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

Как только это разделение ответственности зафиксировано, дальше архитектура начинает складываться сама собой.

Входные требования

За последние проекты у нас сформировалась довольно приземлённая памятка с требованиями которые мы выдвигаем при выборе. PIM должен разворачиваться на своём сервере. Желательно быть реализованным на понятном и не экзотическом стеке, чтобы при необходимости систему можно было развивать своими силами. Важно, чтобы модель данных нормально поддерживала работу с товарами и SKU как с разными сущностями. И конечно, чтобы интеграции с сайтом и маркетплейсами либо уже существовали, либо были реализуемы без сверхусилий.

Если на старте эти требования игнорировать, дальше почти всегда начинается дорогостоящий кастом.

Akeneo. Классический PIM без сюрпризов

Akeneo — это зрелая и понятная PIM-система. Очень хорошо подходит для каталогов с большим количеством атрибутов, сложной структурой и аккуратной моделью данных. У неё сильное сообщество, понятная логика работы и адекватная Community-версия.

Но важно понимать ограничения. Akeneo почти не решает задачи интеграции с маркетплейсами из коробки. Всё, что связано с Ozon, Wildberries и подобными площадками, придётся проектировать и реализовывать самостоятельно. DAM-возможности в бесплатной версии тоже достаточно базовые. В итоге это отличный фундамент, но с расчётом на последующую разработку.

Pimcore. Максимальная гибкость, максимальная ответственность

Pimcore — это уже не просто PIM, а целая платформа. Здесь можно собрать PIM, DAM, MDM и много чего ещё в одном контуре. Возможности почти безграничны, но за это приходится платить сложностью.

Для работы с маркетплейсами и выгрузками данных в Pimcore практически неизбежно понадобится Data Director. Это отдельный коммерческий модуль, который позволяет настраивать импорт, экспорт и трансформацию данных без глубокого кода. С ним жить сильно проще, но он не бесплатный и не решает всё автоматически.

Pimcore отлично подходит компаниям с сильной технической командой и пониманием, зачем им такая гибкость. Без этого внедрение легко превращается в бесконечный проект.

Ensi PIM. Прикладной подход для e-commerce

Ensi — это решение с явным фокусом на e-commerce и маркетплейсы. Модель данных проще, зато сразу ориентирована на практические сценарии. Интеграции с маркетплейсами доступны в коммерческой версии, и это сильно сокращает время выхода в прод.

Минус здесь тоже очевиден. Меньше универсальности и больше зависимости от вендора. Некоторые функции доступны только в PRO-версии, и при масштабировании важно заранее понимать, на каких условиях система будет развиваться дальше.

Как всегда важен контекст

Главная ошибка, которую мы видим снова и снова, это попытка сделать идеальный PIM сразу. На практике работает только итерационный подход. Сначала выносится контент из CMS. Потом аккуратно отсоединяется контентная часть от 1С. Затем расширяется модель атрибутов. И только после этого имеет смысл активно развивать интеграции с маркетплейсами.

PIM не нужен всем. Но если ассортимент растёт, маркетплейсы становятся важным каналом, а контент начинает жить своей жизнью, вопрос уже не в том, нужен ли PIM. Вопрос в том, сколько будет стоить отложенное решение.

UX/UI и AB-тестирование: почему редизайн с гарантией роста конверсии не работает

Mon, 01 Dec 2025 17:52:09 +0300

Не так давно общались с одним e-com. У ребят всё в целом нормально, но пришли они с задачей поднять конверсию с условных пяти до семи процентов за счёт редизайна.

Посмотрели метрики, текущий UX и все хотелки и быстро поняли: подписываться под такие вещи — это форма самообмана. Никто не может честно гарантировать, что набор изменений в интерфейсе точно даст рост в два процента. Можно верить, надеяться, но это не про управление продуктом.

Мы предложили идти через мелкие изменения и замеры конкретных метрик. Зацепили гипотезами, показали, что так безопаснее и прозрачнее. Но понимания не нашли. Клиент хотел увидеть в ТЗ формулировку «вырастить конверсию в N раз» и переложить риски на исполнителя. Как цель это звучит красиво, но чтобы под такое подписаться, нужно быть либо слишком самоуверенным, либо рассчитывать на удачу. Мы туда не пошли.

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

С технической стороны тоже всё не так романтично. В Битриксе есть встроенные AB-тесты, которые автоматически делят трафик. Работает, но выглядит архаично. Есть Яндекс Метрика и её же Varioqub в базовом виде. Можно развернуть Varioqub on-prem и крутить тесты в больших объёмах. Все эти решения рабочие, но вопрос никогда не в инструменте. Вопрос в том, что мы пытаемся померить и зачем.

И здесь встаёт немой вопрос. Готовы ли вы подписаться под разработку UX/UI с гарантированным результатом? Для меня это почти как обещание построить дом, который понравится всем соседям, будет вечным, красивым и вообще идеальным при любых вкусах. Так не работает.

Ну и последняя мысль, которая обязательно всплыла в процессе. Такие работы точно нельзя продавать по модели time & material. Если вам перекладывают риск на достижение результата, то TM размывается, превращается в лотерею и работает против исполнителя. Если уж подписываться под такую историю, выигрыш должен быть действительно значительным, иначе проще сразу сказать «нет».

Покупки в ChatGPT: почему новый «убийца e-commerce» не взлетит

Tue, 25 Nov 2025 17:29:18 +0300

Очередной убийца традиционного e-commerce

Сегодня прочитал новость, что в ChatGPT собираются встраивать прямые покупки (сама новость была 29 сентября). Примерно так: пишешь ему «найди красную рубашку», и если есть подходящий магазин с товарами тебя тут же ведут к оформлению заказа и списанию денег.

Первая мысль была проста: выглядит сомнительно. Магазин в чате?

Есть стойкое ощущение, что IT-рынок каждый год пытается продать идею «покупки там, где покупать неудобно». Telegram Apps еще, уже пробовали. Яндекс экспериментировал с покупками прямо в поиске тоже не взлетело. Наверное было еще очень больше количество эксперементов и на других платформах.

Теперь очередь ChatGPT? Но чат это не каталог. Нет плитка. Нет списков, фильтров, избранного и все что удобно. Человечество двадцать лет шлифовало UX интернет-магазинов, чтобы стало как-то удобно. А тут попытка заменить интерфейс диалогом.

В России в ближайшее время мы все равно это не получим. OpenAI работает через Stripe, Shopify, Etsy и прочий западный стек.

Но даже глобально я не вижу здесь преимущества. Покупка в чате не быстрее, не понятнее и ничем не лучше привычного интерфейса. А если тебе покажут “рекомендованную рубашку”, на каком основании?

Технически реализовать покупку вообще не проблема. Гораздо сложнее другое: как туда загрузить товары так, чтобы алгоритм показал именно твою красную рубашку?

Каталоги это вечная борьба за место в выдаче. Маркетплейсы годами строили сложные алгоритмы ранжирования, а теперь все это хотят положить в голову модели.

По сути OpenAI делает новый поисковик с кнопкой «купить», что логично при наличии аудитории. Но уже была статистка: даже когда ChatGPT даёт ссылку, почти никто не переходит наружу. Даже если функция покупки была доступна сейчас в РФ, стоит крепко подумать стоит ли отдавать трафик ради заказов из чата.

OpenAI логично пытается удержать человека внутри своей экосистемы и в этом смысле покупки прямо в чате идеально вписываются в стратегию.

Новый убийца традиционного e-commerce? Скорее ещё один эксперимент, который выглядит красиво в презентации, но в реальном поведении пользователей мало что меняет. По крайней мере, пока.

Почему классический репрайсер для Ozon и Wildberries уже не работает — и что мы строим вместо него

Wed, 19 Nov 2025 14:39:32 +0300

SaaS был ошибкой? Возможно. Часть 4

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

Месяц кастдевов

За это время провёл около двадцати интервью с бизнесом и людьми, которые так или иначе связаны с маркетплейсами: от продуктовых специалистов до руководителей направлений МП. Хотел понять простую вещь — кто и как управляет ценами, где автоматизация действительно работает, а где все по-старинке.

И выводы получились неоднозначные. В SaaS-сегменте проблема, ради которой всё затевали, почти отсутствует, вроде. Возможно, идти туда — ошибка. Но мы всё равно проверим — иногда истинная боль прячется глубже.

А вот в enterprise-историях проблема подтверждается. Каждый решает её по-своему, костылями и полуавтоматом. У селлеров с небольшим ассортиментом всё проще — там хватает существующих сервисов. Я насчитал больше двадцати живых решений, и у каждого свои особенности: ограничение на количество товаров, странные тарифы и отсутствие нормальных интеграций. Всё руками, о связке с 1С или динамическими ценами часто даже не мечтают.

Сменить позиционирование

На фоне всех этих находок стало понятно, что классическое слово «репрайсер» давно умерло. Актуальность была пару лет назад, сегодня это звучит как термин из музейной витрины. Поэтому решили честно обновить концепцию. Теперь это омниканальная платформа мониторинга, анализа и управления ценами.

Так получается точнее и честнее отражать то, что мы реально делаем — и то, чего нет у конкурентов.

Что сделали по разработке

Перезапустили сайт решения. Хотелось собрать всё на Тильде, но пошли другим путём — сделали максимально примитивно, чтобы проверить конверсию самого подхода. Личного кабинета пока нет, но рассчитываем довести его до ума за ближайшие одну–три недели.

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

Личный кабинет стал чуть красивее обычного орчида, но ещё не тот результат, от которого отваливается челюсть, но в целом окей. Зато сделали авторизацию через email и OTP — СМС подключим позже.

Интересные находоки

Нашли хак на Ozon. Если товар стоит в акции, менять цену нельзя — она пишется, но берётся медианная. Однако если сначала вынуть товар из акции, обновить цену и вернуть обратно — всё работает. Абсолютно легально, пока.

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

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

По мелочам — навели порядок в настройках, закрыли баги, подтянули инфраструктурные детали.

Что дальше

В ближайшее время запускаем рекламу. Начнём с Директа — понятно, что это не самый эффективный канал для нашего типа продукта, но нам нужно проверить прямой спрос, экономику клика и набрать людей на первичный кастдев. Вероятнее всего, этот канал приведёт селлеров с небольшим оборотом — и возможно, у них просто нет проблемы. Это тоже нужно подтвердить или опровергнуть.

Параллельно будем выходить в аутрич через Telegram, чтобы дотянуться до среднего и крупного сегмента. Тут уже интереснее — посмотрим, что получится.

В разговоры с экспертами добавился новый блок — прикидка трендов. Что будет дальше?

API может стать платным. Больно, но не смертельно. Цена персонализируется до безумия — непонятно, что будет с РРЦ и МРЦ. Запрет на изменение цен по API? Сомнительно, но и на это у нас есть запасной вариант.

Далее по плану.

Запускаем SaaS.
Доделываем стратегии.
Включаем рекламу и аутрич.
А дальше — посмотрим, что покажут цифры и люди.

Цепи Маркова в e-commerce: как предсказывать поведение клиентов и находить сбои в системах

Fri, 24 Oct 2025 16:12:33 +0300

Недавно на YouTube наткнулся на видео про цепи Маркова. Объяснение было бодрым, простым и в отличие от универа — даже понятным. В институте эту тему нам давали сухо: формулы, матрицы переходов, вероятности. Тогда я не мог до конца понять, зачем это всё.

Так что же это за зверь такой — цепи Маркова?

Если коротко, это способ описать последовательность событий, где каждое следующее зависит от предыдущего. Не от всего, что было до этого, а только от последнего шага. Пример: если человек посмотрел кроссовки, то с вероятностью 60% он кликнет на носки, а если уже на носках — то скорее всего добавит их в корзину. Вот и вся магия.

Сама концепция цепей Маркова родилась в 1906 году — и, что любопытно, началась она со спора. Павел Некрасов, монархист и профессор, утверждал, что закон больших чисел работает только для независимых событий — вроде бросков монеты. А вот социалист Андрей Марков с этим не согласился.

Суть спора была в том, распространяется ли закон больших чисел на зависимые события — когда каждое следующее испытание связано с предыдущим. И Марков не просто поспорил — он это доказал. Так появилась идея, что можно описывать последовательности, где каждый шаг зависит от предыдущего, но всё равно подчиняется вероятностным закономерностям.

История, кстати, куда интереснее, чем кажется. Если будет настроение — найди видео про этот спор, там и математика, и характеры, и немного идеологии.

Рекомендации и ценообразование
Все эти блоки “с этим покупают” и “вам может понравиться” — чистая цепь Маркова.
Система не “угадывает”, она просто знает, что после чайника чаще всего открывают фильтры, потом кружки, а потом уже идут в корзину. Алгоритм подсовывает следующее звено, чтобы не дать цепи оборваться.

Поведение покупателей на скидках — тоже цепочка.
“Цена упала → CTR вырос → корзины заполнились → возврат вырос → скидку убрали → продажи просели”.
А теперь представьте, что система видит эту последовательность заранее и подстраивает стратегию — вот уже и “умное ценообразование” готово.

Применять этот подход можно в самых разных местах, не только в рекомендациях и ценообразовании. Например, для анализа логов и поведения систем. Когда что-то идёт не так — запрос падает, очередь зависает, сервис отвечает с задержкой — важно не просто увидеть ошибку, а понять, как она возникла. Если собрать последовательности событий и рассчитать вероятность переходов между ними, можно увидеть закономерности. По сути, это та же цепь Маркова, только вместо покупателя у нас процесс, а вместо корзины — сбой в логах.

Например, алгоритм PageRank от Google можно рассматривать как модель цепи Маркова: каждую страницу можно считать состоянием, а переходы между страницами — вероятностями переходов в цепи.

Такие модели хорошо ложатся на предиктивную аналитику: прогнозирование нагрузки, отказов, пиков активности. На этом принципе построены многие инструменты мониторинга — они не просто ловят инциденты, а предсказывают, где “цепь может порваться”.

И если смотреть шире — весь современный искусственный интеллект вырос из этой идеи. Марковские цепи стали базой для языковых моделей, генераторов речи, автозавершения текста. Любая нейросеть сегодня в том или ином виде опирается на вероятностные переходы между состояниями. Просто теперь этих состояний миллиарды, и они учатся не на монетах, а на петабайтах данных.

В итоге, цепи Маркова — это не про математику ради математики.
Это про понимание вероятностей, которые движут вашим процессами. Про то, как данные превращаются в действия. И про то, что даже “случайность” в поведении клиентов на самом деле довольно предсказуема — если у вас достаточно истории кликов, заказов и цен.

Из чего состоит e-commerce: CMS, PIM, CRM, ERP и другие ключевые системы

Thu, 07 Aug 2025 09:40:42 +0300

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

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

Среди систем: CMS, PIM, CRM, ERP, OMS, WMS, MDM, DAM, BI, CDP, MAP, RPA, PLM, SCM, TMS, POS, EDI, CXM, HCM и другие. В одной компании может быть всего две, а в другой — больше десятка, распределённых между командами и странами.

Но мы сегодня остановимся на тех, которые чаще всего встречаются в практике и находятся на слуху — особенно у тех, кто уже вышел за пределы базовой CMS и ищет, как масштабироваться.

CMS: витрина, на которую всё завязано

Начнём с привычного. CMS — это то, что видит клиент. Главная страница, карточка товара, каталог, фильтры, корзина. В России лидирует 1С-Битрикс — почти стандарт де-факто. После него — Tilda, особенно в сегменте D2C и брендов. WordPress с WooCommerce всё ещё используется, но в ecom-сегменте реже.

Что важно: в больших проектах CMS — не только витрина. Это ещё и связующее звено между контентом, заказами и данными о пользователях. Но вот данные о товарах, их характеристиках, SKU, остатках и даже фото — это всё должно подтягиваться не из CMS, а из других систем. Хотя технически CMS это умеют, на масштабе такое решение начинает разваливаться.

И тут появляется PIM.

PIM: откуда берутся карточки

Когда у вас 30 товаров — можно завести всё в CMS руками. Когда 300 — уже неудобно. Когда 30 000 — без PIM не обойтись.

PIM (Product Information Management) — это система, где живёт товарный справочник. Не просто название и цена, а полное описание: материалы, состав, категории, фото, видео, сезонность, комплектации, переводы, SEO-данные, атрибуты для фильтров, иерархия товаров, артикулы, SKU.

Серьёзные PIM-системы работают как единый источник правды: именно оттуда контент забирают CMS, маркетплейсы, ERP, реклама. Часто внутри PIM уже есть базовый DAM (Digital Asset Management) — для хранения фоток и видео, но в сложных случаях DAM может быть отдельным решением.

Примеры систем в РФ: Akeneo (в том числе русифицированные кастомизации), Pimcore, InSales PIM, собственные разработки на базе 1С или PostgreSQL.

CRM: кто купил, кто вернулся, кто ушёл

Когда CMS показывает товар, а PIM наполняет карточку, следующий шаг — клиент. CRM — это уже не про витрину, а про отношения. Кто купил, когда, с какими проблемами, какие письма отправлялись, какие пуши сработали, кто давно не возвращался и кого пора бы вернуть.

CRM-системы бывают условно трёх типов:

Коробочные all-in-one: Битрикс24, RetailCRM
Облачные коммуникационные: amoCRM, Kommo, Mindbox (частично)
Тяжёлые корпоративные: Salesforce, Dynamics 365, SAP CRM

В малом и среднем бизнесе чаще всего используется либо Битрикс24, либо RetailCRM — особенно если есть фокус на повторных продажах и омниканале.

CRM — точка, где собираются заказы, обращения, история взаимодействия. И именно она часто становится «сердцем» всей системы, если нет полноценной ERP.

MDM: чтобы не было «двойников»

Когда товар и клиент попадают в разные системы — начинается хаос. Один и тот же товар может быть в CRM, ERP и CMS с разными ID. Один и тот же клиент может появиться в рассылке дважды с разными адресами. Чтобы этого избежать, появляется MDM — Master Data Management.

Это система, которая отвечает на главный вопрос: как выглядит эталонная версия товара, клиента, поставщика или даже магазина? Она связывает между собой PIM, ERP, CRM и склады, и именно через неё часто происходит нормализация данных.

MDM особенно важен, если у компании несколько бизнесов или стран. Или если в продуктовой линейке сотни тысяч SKU, а бизнес растёт за счёт новых каналов. Без централизованного справочника любые аналитики становятся неактуальными.

В РФ чаще всего используют кастомные MDM на базе 1С, PostgreSQL или крупных ERP (SAP, Oracle).

ERP: сколько осталось, сколько купили и кому должны

ERP — это бухгалтерия, финансы, движение товаров и запасов. Если PIM — про контент, то ERP — про цифры: закупки, поставки, остатки, бюджеты, план-факт, себестоимость.

Иногда ERP может быть и CRM, и OMS, и PIM — особенно в мире SAP. Но в большинстве e-commerce проектов ERP — это связка с бухгалтерией и складами, а всё, что связано с клиентом и контентом — выносится наружу.

Наиболее популярные в РФ: 1С ERP, SAP, Microsoft Dynamics, Галактика.

WMS: логика склада

WMS — это система, которая знает, где физически лежит каждый товар. Как его собрать, упаковать и отгрузить. Без неё невозможно реализовать нормальную сборку заказов, особенно при большом ассортименте.

Если вы используете маркетплейсы или 3PL, часть функций WMS уходит туда. Но если вы работаете со своим складом — без неё никак. В WMS прописываются адреса ячеек, сценарии сборки, правила FIFO/LIFO, работа курьеров и сборщиков.

Примеры систем в РФ: InStock WMS, Logisticus, Solvo, 1С:WMS, Boxy.

OMS: что куда поедет

Когда заказ сделан, начинается самое интересное: кому отдать, со склада или магазина, доставить или самовывозом, сколько резервировать и когда отправлять. Этим управляет OMS — Order Management System.

OMS — это мозг маршрутизации заказов. Именно она принимает решение, какой склад отгрузит товар, как собрать, сколько отложить и какие статусы показывать клиенту. В идеале она же умеет общаться с курьеркой и 3PL.

Примеры: NewIT OMS, RetailCRM OMS, Salesforce Order Management, собственные модули в 1С и Битриксе.

3PL и TMS: доставка под контролем

Интеграции с курьерскими службами, маркетплейсами, складами фулфилмента — всё это про 3PL и TMS.

3PL — это внешние склады и доставки (СДЭК, Ozon Rocket, Wildberries FBO/FBS). TMS — система, которая управляет маршрутизацией и логикой доставки: отбор исполнителей, контроль статусов, SLA и возвраты.

Для бизнеса важно, чтобы OMS, WMS и TMS были связаны. Иначе не будет нормального трекинга, резервов и управления рисками. Популярные решения: Shiptor, Dostavista, Bringo, Boxberry, Dalli.

BI: всё, что можно посчитать

Последняя остановка — аналитика. BI-системы позволяют собрать данные из всех предыдущих систем и ответить на главный вопрос: что у нас работает, а что нет.

Сколько заказов приходит с повторных клиентов, какая утилизация склада, как распределяются бюджеты на маркетинг, где падает конверсия, в какой момент теряем заказы. Всё это — про BI.

Примеры: Яндекс DataLens, Power BI, Qlik, Tableau, Redash.

Итого

Подсистем в e-commerce гораздо больше. Где-то PIM встроен в ERP, где-то CMS тянет на себе ещё и CRM, а где-то вся логика построена вокруг OMS. Главное — понимать, какую задачу решает каждая из систем и как они между собой взаимодействуют.. Где-то PIM встроен в ERP, где-то CMS тянет на себе ещё и CRM, а где-то вся логика построена вокруг OMS. Главное — понимать, какую задачу решает каждая из систем и как они между собой взаимодействуют.

Если вы строите e-commerce с нуля — не обязательно брать всё сразу. Но понимать, куда вырастет проект и какие блоки появятся позже — важно. Это и есть архитектура. Не в смысле кода, а в смысле бизнеса.

Как перенести сайт без потерь: данные, заказы, пользователи, бонусы

Mon, 14 Jul 2025 12:57:56 +0300

Почему запуск “с чистого листа” — это чаще про миграцию, чем про новизну

Примерно 30–40% наших проектов — это запуск с чистого листа. Иногда так и есть: никакого кода, никаких интерфейсов, просто идея и желание начать. Но на практике чаще всего «чистый лист» оказывается с заметками на полях. Даже если нет легаси-кода и серверов в подвале — почти всегда есть пользователи, бонусы, заказы, каталоги — всё это должно куда-то переехать. И чем раньше мы начнём думать об этом, тем спокойнее будет запуск.

Привычные интерфейсы — не трогаем
Если в старом интерфейсе поиск был по центру — стоит оставить его там и в новой версии. Люди к этому привыкли, и даже если вы полностью перезапускаете платформу, не надо ломать то, что уже работает. Визуальные паттерны — это не баг, это капитал, и с ним нужно обращаться бережно.

Каталог и бонусы: выглядит просто, но с нюансами
С каталогом товаров всё обычно проще. Чаще всего он приходит из внешней системы: 1С, Excel, XML, PIM — не суть. Там всё более-менее понятно. Согласовали структуру — и вперёд. Ошибки начинаются тогда, когда база плохо структурирована, а на старом проекте это держалось на костылях. Выгружаем — и получаем не структуру, а хаос.

Бонусные системы и программы лояльности тоже выглядят как простой блок. Табличка с баллами, пару фильтров — и поехали. Но есть нюанс: бонусы всегда привязаны к пользователю. Второй нюанс, история начислений и списаний тоже лучше перенести. Если вы не сохранили корректные связи или потеряли часть базы при переносе — придётся объяснять каждому, куда делись его накопления.

Миграция пользователей
Сами пользователи переносятся несложно. Для большинства систем есть штатные механизмы. Но есть один подводный камень — пароли. Если ваша старая платформа (например, тот же Битрикс) хранила пароли в виде хешей — вы не сможете их просто вытащить.

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

Заказы — самая глубокая связка
Одна из самых сложных структур при миграции. У заказа есть статус, история оплат, доставки, корзина, покупатель, иногда — привязка к внешним системам. Это не одна таблица, целый набор сущностей, каждая из которых состоит из своего набора данных.

Мы в своей практике чаще всего идём по пути прямого импорта: сначала переносим пользователей, затем — связанные с ними заказы. Главное — правильно сопоставить ID старых и новых сущностей, иначе вы получите тысячи «висячих» заказов, которые ни к кому не привязаны.

Иногда, чтобы не лезть в сложную структуру заказов, проще выбрать альтернативный подход: настроить обратную выгрузку заказов, опыливателей из системы в 1С, а потом обратно. Это требует работы со стороны 1С, но в итоге ваши клиенты смогут видеть всю свою историю покупок, даже если они делались не через интернет-магазин.

Универсальных рецептов нет
Вопреки распространённому мнению, «проект с нуля» почти всегда начинается с миграции. Даже если вы переходите с Битрикса на Битрикс, будет масса нюансов. Если переезжаете с чего-то вроде WooCommerce или Тильды — тем более.

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

Перед стартом такого «нуля» нужно сделать только одно: собрать максимум информации. Где и как хранятся данные, какие блоки обязательны, какие связаны друг с другом. Уже от этого будет зависеть стратегия: что переносить, что можно выкинуть, а что воссоздать с нуля. Иногда проще не мигрировать, а построить новое — с учётом всех прошлых ошибок.

Как повысить конверсию в eCommerce: сравнение платёжных решений — редирект, SDK и ввод карты на сайте

Fri, 04 Jul 2025 09:41:00 +0300

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

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

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

И я задумался: сам бы я пришёл к себе на консультацию как директор агентства? Наверное, да, но не факт. А если бы я был директором e-commerce проекта? Вероятно, нет.

Поэтому с сегодняшнего утра — курс корректируем. Буду больше писать о том, в чём мы сильны: разработка и развитие B2B / D2C / B2C ecommerce-проектов.

Погнали.

Что не так с оформлением заказа
Как проходит оплата в типичном интернет-магазине на Bitrix или другом типовом движке?
Форма заказа — часто многошаговая. Потом сообщение: «Спасибо, ваш заказ оформлен, сейчас мы переведём вас на оплату». Следом — редирект на платёжный шлюз, где вводим данные карты, иногда повторно. Оплачиваем, нажимаем «вернуться на сайт».
Итого — два редиректа, три интерфейса. И куча поводов для сомнений и отказа от покупки. Особенно если это повторный заказ или импульсная покупка.

Как делают маркетплейсы
Вот кто действительно короли в этом процессе — маркетплейсы. Они не просто обрабатывают платежи, они выжимают максимум. Оформление заказа там — это одна кнопка, если заказ повторный. Карта уже сохранена, адрес ПВЗ стоит, оформление — по сути, мгновенное. Никаких лишних переходов, одно окно, одна кнопка. Всё продумано под повторные заказы, минимальное трение.

Какие есть варианты, если хочется так же
Если вы хотите принимать оплату картой прямо на сайте, у вас есть два пути. Первый — обрабатывать данные карты самостоятельно. Это значит, что ваш сервер будет напрямую принимать номер карты (PAN), срок действия, CVV и другие чувствительные данные. Такой подход возможен, но связан с огромными сложностями: вы обязаны пройти полную сертификацию PCI DSS (уровень 1), настроить сквозное шифрование, защиту каналов передачи, использовать сертифицированные HSM-модули и регулярно проходить аудит. Это дорого, долго, и требует штатных специалистов по безопасности. Любая ошибка — и вы нарушаете международные стандарты, рискуя не только деньгами, но и репутацией.

Второй путь — использование SDK/API от платёжной системы. В этом случае пользователь визуально вводит данные карты у вас на сайте, но технически эти данные отправляются напрямую платёжному провайдеру. Ваш сервер не видит и не хранит информацию карты — вы получаете только токен, с которым уже можно списывать средства. Это решение не требует сложной сертификации, укладывается в минимальные требования PCI DSS (SAQ A) и значительно упрощает внедрение. Вы получаете современный UX и безопасность без лишних затрат и рисков.

Мы в проектах чаще используем SDK/API или редирект (классика)— в зависимости от задач клиента, типа заказов и повторных покупок.

Что даёт ввод карты прямо на сайте (SDK или самостоятельный приём)
Плюсы:
– Повторная покупка — одна кнопка
– Меньше отказов — пользователь не покидает сайт

Минусы:
– Ограниченная вариативность — СБП и др. нужно подключать отдельно
– Не все готовы вводить данные на малознакомом сайте

Что выбрать?
Если вы не входите в топ-100 eCom по DataInsight, но хотите увеличить повторные заказы и не терять клиента на каждом шаге — SDK будет отличным решением. Редирект — это рабочий компромисс. Но если вы хотите UX как у маркетплейсов — без SDK никак.

В следующих постах разберём практику:
— Зачем вам PIM-система и как внедрять
— Интегрируем логистику без привязки к внешним сервиса
— Что должно быть в личном кабинете eCom-проекта
— Делаем бонусныу систему и при чем тут фальшивомонетничество

Проблемы при миграции Битрикс24 на Астра Линукс: кейс отказа от Apache и перехода на Nginx + PHP-FPM

Tue, 01 Jul 2025 18:09:11 +0300

Когда «ускорение» оборачивается откатом

Любая оптимизация несёт в себе риск. Особенно если речь идёт о корпоративной системе с тысячами пользователей, десятками бизнес-процессов и высокой критичностью к стабильности.

Мы работаем с крупными инсталляциями Битрикс24: по 2000–3000 активных пользователей в системе, десятки интеграций, сложная автоматизация. В один момент перед нами встал вызов: перейти на импортозамещённое окружение, включая «Астра Линукс» и отказ от привычного Apache в пользу связки Nginx + PHP-FPM.

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

Как это выглядело: миграция «в лоб»

Решение принималось быстро. Никто не давил — просто все были за эффективность. Apache решили не использовать: «устаревший», «тяжёлый», «нам всё равно нужно больше производительности».

Мы развернули новое окружение:

ОС: Astra Linux
Web-сервер: Nginx
PHP: PHP-FPM
СУБД: PostgreSQL

На тестовом сервере всё работало. Проверяли мы, клиент, снова мы. Формально — продукт был готов к миграции. Все ключевые функции: CRM, бизнес-процессы, коммуникации, документы — выглядели стабильными.

Назначили день Х, перенесли файлы и базу, запустились.

И началось: падение стабильности без Apache

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

Самое странное: всё это работало на тесте. Ошибки были нелогичными, хаотичными. Казалось, что система живёт своей жизнью. Обычные HTTP-запросы вели себя непредсказуемо.

Мы ушли в дебаг:

Начали с логов
Проверили сокеты
Запустили трассировку пакетов
Сравнили поведение Nginx и Apache на одном и том же коде

Результаты нас неприятно удивили.

Почему Bitrix24 «любит» Apache

Коробочная версия Битрикс24 до сих пор во многих местах завязана на особенности работы Apache:

Использование .htaccess файлов
Обработка нестандартных заголовков
Проксирование для мобильных клиентов
Роутинг внутри REST API

Да, формально Bitrix работает и под Nginx. Да, на сайте есть конфигурации. Но под капотом — множество нюансов, которые не эмулируются простыми правилами nginx.conf.

Когда мы пытались сымитировать Apache-правила в Nginx — устраняя одни баги, ломались другие.
Мобильные приложения отказывались работать. REST-запросы возвращали пустые данные. Архивы не скачивались.
А клиент уже работал на новом сервере. Проект в бою. Откат — сложный. Ресурсы на пределе.

Что мы сделали: откат к проверенному решению

Решение оказалось не героическим, а здравым: поставить Apache.

Мы подняли Apache параллельно, перевели конфигурацию, протестировали.
Большинство проблем исчезло.
Платформа снова начала работать стабильно.

Что из этого вынесли: уроки и рекомендации

Всегда читайте рекомендации вендора

Вендор указывает не просто так, что поддержка Apache является приоритетной. Это не маркетинг, а техническая реальность. Игнорировать — значит платить временем и репутацией.

Неочевидные функции — ваши лучшие тест-кейсы

Мы добавили в свой чек-лист для QA:

Проверка zip-архивации
Синхронизация календарей
Интеграции с мобильными устройствами

Именно они вскрывают глубинные архитектурные зависимости, которые не заметны при базовой проверке интерфейсов.

Не «ускоряйтесь», пока не знаете цену ускорения

Да, отказ от Apache выглядит как оптимизация. Но если это приводит к нестабильной работе ядра — вы теряете больше, чем выигрываете. Особенно в B2B-проектах, где SLA, штрафы и сложные договорные отношения.

И напоследок: импортозамещение — это не просто про «поставить галочку»

Никакой сарказм. Мы поддерживаем курс на импортонезависимость. Но подход должен быть зрелым:

Тестируйте заранее
Учитывайте legacy-архитектуру
Не бойтесь “старых” решений, если они решают задачу
Apache — не панацея, но и не зло

Если вы переходите на Астра Линукс, внимательно пересмотрите архитектуру вашего веб-стека. Иногда лучше не экспериментировать с критически важными модулями, особенно если вы работаете с Bitrix24.

Как маркетплейсы душат селлеров — и другие новости мая

Tue, 10 Jun 2025 15:51:51 +0300

Май прошёл, выдался «полупраздничным» — коротким, но богатым на события, поэтому продолжим нашу рубрику #дайджест.

Причём основная масса новостей снова про маркетплейсы. Похоже, что классический e-commerce теряется на фоне громких изменений в экосистемах Wildberries, Ozon и Яндекс.Маркета. Так что — это скорее не дайджест e-commerce, а сводка с поля битвы маркетплейсов. Поехали.

Комиссионный удар: WB и Ozon закручивают гайки
С июня Wildberries и Ozon поднимают комиссии почти для всех категорий товаров. Рост — в среднем на 4,5–5 п.п. Параллельно обсуждаются «платная скорость», внутренние банки, комиссии за вывод, новая логистика.

Логично, гайки крутятся там, где есть хотя бы какая-то маржа. Пока селлеры ещё живы — можно подкрутить. Пора делать свой ecom?

Путин о маркетплейсах: рынок будет чище
Цитата месяца: «Маркетплейсы — это дыра, на которую надо обратить внимание». Власть начала пристально следить за оборотом, подделками и схемами.

И в этом есть плюс. Если площадки хотят расти дальше, без госрегулятора не обойтись. Хотя бы в серых зонах.

Судебные баталии вокруг маркетплейсов
Контрафакт, споры о данных, авторские права — площадки всё чаще оказываются в судах. Wildberries, Ozon, Яндекс.Маркет получают иски, селлеры требуют прозрачности.

Нормальный этап взросления. Площадки — не просто витрина, а инфраструктура. Значит, и ответственность теперь будет взрослая. Почитайте интересную историю о покупке Айфона основателем DNS Дмитрием Юрьевич.

Новые платежи и логистика: эксперимент WB
Wildberries тестирует «Приоритетный заказ» — ускоренную обработку за 39 ₽. Добавили полную предоплату, ночную доставку, оставление у двери. Деньги можно вывести без комиссии — если через их банк.

Ещё один способ выжать больше из одного заказа. Или попытка вернуть доверие? Поживём — увидим.

FBS от «Магнита»: наконец-то
Магнит.Маркет переходит с FBO на FBS. Это значит — больше селлеров и в 3 раза шире ассортимент.

Новый-старый игрок. Конкуренция оживёт? Берём попкорн, следим за фиолетовыми и синими.

Кризис офлайн-ритейла
Kari, Спортмастер, Ostin — убытки. Люди покупают меньше, уходит трафик из ТЦ. Ставка — на экономию и оптимизацию.

Офлайн съёживается, онлайн растёт. Ждём эпоху мини-магазинов при ПВЗ?

Мемы в тренде: нейросети продают
На Wildberries вырос спрос на товары с AI-мемами — футболки, кружки, постеры. Контент стал товаром. Генерация смысла приносит маржу.

Прикольно, недорого, и можно запускать у себя. Почему нет?

Салат вместо ресторана
Готовая еда на дом обгоняет кафе. В топе — салаты и супы. Супермаркеты перетягивают бюджет заведений.

Тренд предыдущего дайджеста подтверждается. Еда ближе, доставка быстрее. Самокат везёт — попкорн есть.

Программы лояльности стали валютой
64% россиян участвуют в программах лояльности. Средняя экономия — 1100 ₽ в месяц. Лидеры — супермаркеты и дискаунтеры.

Почему до сих пор нет единой биржи бонусов? Обмен баллов из «Магнита» на скидки в «Ленте»? Стартап?

Ozon и Яндекс — медиаплатформы? Наверное, да
Яндекс запустил конструктор магазинов, Ozon — генератор контента. Теперь важно не только продавать, но и удерживать внимание.

Экосистемы расширяются. Банки, путешествия, инструменты для селлеров — цель одна: оставить пользователя внутри приложения как можно дольше.

Email-маркетинг в 2025: зачем B2B-компаниям продолжать рассылки, даже если нет прямых продаж

Wed, 28 May 2025 08:36:05 +0300

В 2025 году говорить об email-маркетинге — это почти как использовать кремень при наличии зажигалки.

Особенно когда вокруг — ИИ-агенты, которые пишут персональные офферы в личку клиентам и аккуратно заходят в мессенджеры. Быстро, умно, технологично.

Но я думаю email жив. Более того — он держится крепче, чем многие новомодные каналы. Особенно в B2B, где цикл сделки длинный, а путь к доверию не проложишь одной глянцевой посадочной.

Мы рассылаем дайджесты уже больше пяти лет. Раз в месяц, иногда чаще — новости, кейсы, закулисье, контент по ситуации. За это время перепробовали многое: и покупные базы (признайтесь, кто не грешил?), и ручную сегментацию, и разный формат писем. Пробовали делать и персонализированные письма, и массовые по шаблону. CRM — молчит. За всё это время — ни одного подтверждённого лида по UTM-меткам.

Зачем продолжать?
Даже при отсутствии прямых продаж мы не остановились. Почему? Потому что email для нас — не канал продаж. Это канал присутствия. Это ещё одно касание, ещё один способ напомнить о себе в нужный момент.

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

Так клиент не забывает, что мы живы, работаем, развиваемся. Он видит, что у нас новые проекты, кейсы, наймы, релизы. И когда ему понадобится подрядчик — шансы, что он вернётся к нам, становятся гораздо выше.

Показатели?
Теперь немного честной аналитики. Средняя открываемость наших писем — около 15%. Кликабельность — примерно 1%. Цифры скромные, но они стабильны. И это главное. Мы не ждём от email взрывных продаж. Мы вкладываем в устойчивое присутствие в информационном поле клиента.

Эти 15% открытий — это пара десятков людей каждую неделю, которые получают свежий сигнал: “Мы есть. Мы живые. Мы на связи.” А если от них даже один вспомнит о нас в нужный момент — это уже ROI, который не всегда увидишь в цифрах.

Как подойти к рассылке
Начать стоит с базы. Покупать — бессмысленно. Лучше аккуратно собирать её через формы на сайте, добавив согласие на маркетинговые рассылки. Сделайте отдельную форму подписки на новости — её читают не только потенциальные клиенты, но и партнёры, подрядчики, просто любопытные.

Мы используем Юнисендер — простой сервис, не перегруженный ненужным. А дальше всё упирается в контент. Многие говорят: “Нам нечего писать”. Это неправда. Если вы публикуете кейсы, делаете продуктовые апдейты, делитесь новостями компании — у вас уже есть материал. Просто упакуйте его бережно и дружелюбно.

Продаж не будет.
Email — это не спринт, это марафон. Не стоит ждать мгновенных сделок. Но стоит ждать эффект накопления. Мы регулярно слышим: “Читаем вашу рассылку”, “Видели новый кейс”, “Спасибо, что напомнили”. Иногда спустя полгода или даже год после первой встречи. Это работает.

Самое удивительное — насколько часто крупные компании с большими базами своих B2B-клиентов игнорируют email вообще. Хотя у них — сотни тысяч контактов и идеальный повод для запуска рассылки. Мы не специализируемся на таких проектах, но пару раз запускали пилоты — и даже базовый подход показывал отличные результаты.

Как ускорить сайт на Битрикс: полный гайд по оптимизации скорости загрузки

Tue, 20 May 2025 08:38:38 +0300

По статистике, на Битриксе работает около ~ 11% сайтов в РФ. Это не мало, для сравнения тильда и WP ~ 59%.

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

Продолжая тему из прошлого поста, собрал в формате гайда наш рабочий подход к анализу и ускорению сайтов на Битрикс — от базовой диагностики до продвинутых решений, которые реально дают прирост.

Общие шаги анализа

Собрать обратную связь. Какие страницы тормозят? Какие действия? Где затыки?
Проверить системные требования. CPU, RAM, дисковая подсистема — всё должно быть в норме.
Оценить загрузку сервера. top, htop, Task Manager — загруженность ЦП, памяти, диска.
Проверить географию. Сервер должен быть в РФ, а не на экваторе.
Дальше — по слоям: локация → сервер/ПО → окружение → backend → frontend.

Анализ сервера

Скорость диска. Проверь через hdparm, fio. Норма — от 150 МБ/с.
Доступность сервера. Не перегружен ли ботами? Смотри access.log.
Ошибки. error.log, php_errors.log — критические сбои и ошибки.
PHP. Настройки opcache, memory_limit, max_execution_time.
MySQL. Проверь query_cache, innodb_buffer_pool_size, tmp_table_size.
Cron. Нагрузка от зацикленных или тяжёлых заданий.
Свободные ноды. Хватает ли ресурсов под процессы?
Свободное место. Минимум 5–10 ГБ должно быть свободно.

Анализ базы данных

Диагностика Битрикс. Встроенный инструмент: /bitrix/admin/performance.php.
Медленные запросы. slow_query_log, инструмент в phpMyAdmin, EXPLAIN.
Индексы. Наличие по часто используемым полям.
Очистка. b_event_log, b_search_content — чистим старое.
Жирные таблицы. Например, b_sale_fuser может распухнуть до гигабайтов.

Анализ кода и модулей

Включить отладку. Кол-во запросов, время ответа.
Кэш и композит. Должны быть включены и корректно работать.
Пользовательский код. Отключить свои компоненты, проверить init.php.
Отключение модулей. Через /bitrix/admin/module_admin.php. Всё лишнее — в архив.
Профайлер. /bitrix/admin/perfmon_panel.php — ищем долгие участки.
Тяжёлые функции. CIBlockElement::GetList, CSaleOrder::GetList — аккуратно.
Обмены. С 1С и прочими системами — могут грузить базу и API.

Оптимизация фронтенда

Сокращение запросов. Анализ в браузере — DevTools.
Кеширование. Проверить, работает ли компонентный кеш.
Минификация CSS/JS. Через /bitrix/admin/performance_tuning.php.
GZIP. Должен быть включён для статики.
Изображения. Сжатые, современный формат (WebP).
Внешние подключения. Шрифты, YouTube, картинки — переложить внутрь проекта.

Тестирование нагрузки

Стресс-тест. Apache JMeter, k6 — симуляция пользователей.
Сессии. Где возможно — убрать session_start().
Очередь заданий. Проверить /bitrix/admin/agent_list.php, лучше — cron.
Кэш серверных данных. Redis / Memcached > файловый кэш.

Инфраструктурные проверки

Сетевые задержки. ping, traceroute.
CDN. Для ускорения статики.
Балансировка. Если есть балансировщики — проверяем распределение.
Актуальность ПО. Версии PHP, MySQL, модули Битрикс — обновлены?

План Б: смена окружения и архитектуры

Если всё выше сделано, а сайт всё ещё медленный — пора подумать о смене окружения:

Apache + mod_php
PHP-FPM
PHP-PM
FrankenPHP
RoadRunner
Swoole
NGINX Unit

Что выбрать — зависит от контекста. Универсального ответа нет.

Железо: когда ускорение начинается с «железа»

Если проект живёт на «железе», к которому страшно прикасаться — пора на апгрейд.

Процессор

Битрикс активно использует одноядерные операции → важна производительность на ядро.
Частота — от 3.5 ГГц. Желательно с Turbo Boost (Intel) или Precision Boost (AMD).
Кэш L2/L3 — чем больше, тем лучше.
Новые архитектуры (Intel Alder Lake, AMD Zen 3) дают реальный прирост.
Пример: Intel Core i7-13700K с архитектурой Raptor Lake — на голову выше старых Xeon.

Диски

Только SSD. Лучше — NVMe (но не любой: смотри IOPS, задержки, скорость записи/чтения).

Дополнительно

Elasticsearch — для поиска, фильтров, сортировки, каталогов.
Kafka, RabbitMQ, Datareon — брокеры очередей.
Часть рекомендаций актуальна и для Битрикс24, но у него требования к окружению ещё выше.

Это должно помочь.

Если нужно — делаем аудит. Если сам — сохраняй текст, используй как чеклист.

Дайджест новостей апреля 2025: E-commerce и всё, что рядом

Wed, 14 May 2025 08:45:00 +0300

Майские праздники позади — пора включаться в работу. Уже давно крутится идея собрать короткий, но ёмкий дайджест новостей из мира e-commerce, ритейла и всего, что идёт рядом.

Планирую собирать обзор раз в месяц — не сухой список ссылок, а с человеческим взглядом. Для старта взял апрель.

1. ChatGPT и DeepSeek отбирают трафик у Google

ИИ-сервисы вроде ChatGPT и DeepSeek увеличили трафик интернет-магазинов США на 1200% за год. В предновогодний сезон — на 1300%. С сентября 2024-го число визитов удваивается каждые два месяца.

Новость не свежая, но ключевая. Поведение клиентов меняется. Рынок, как всегда, адаптируется. Ждите SEO 2.0: оптимизация под ChatGPT, Grok и прочие. Это уже не будущее — это понемногу «вчера».

2. Wildberries реформирует рейтинг товаров

С апреля WB пересчитывает рейтинги: из формулы исключают изменённые отзывы и комментарии не по теме — например, жалобы на очереди в ПВЗ.

Шаг в правильную сторону. Надеемся, за этим последует следующий: борьба с фейками, накрутками и отзывами «за промокод».

3. Ozon разрешил отказаться от автоакций с нюансами

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

Контроль над скидками — это вечный фронт для селлеров. Или платишь за видимость, или теряешь охваты. Кстати, мы как раз скоро анонсируем коробочное решение по управлению акциями и скидками.

4. Платная упаковка возвратов на Ozon

У FBS-селлеров на Ozon автоматически активировалась услуга “Упаковка возвратов” — 9 рублей за каждую единицу.

Мелочь? Да. Но таких «мелочей» всё больше — и в сумме это уже ощутимо. Маркетплейсы и дальше будут потихоньку крутить гайки

5. Точный таргетинг рекламы на Wildberries

Теперь можно настраивать рекламу на конкретные города и регионы.

Вроде круто, но нужно помнить что WB это не магазин, а рекламная площадка.

6. Лента внедряет видеораспознавание весовых товаров

Ритейлеры внедряют системы видеораспознавания для автоматизации продажи весовых товаров, что снижает очереди и повышает точность учёта.

Это не просто про технологии и экономию — это про комфорт. И да, такие вещи, как КСО, — это не про оптимизацию издержек, а это элемент заботы.

7. «Магнит» приобрёл «Азбуку вкуса»

«Магнит» купил сеть «Азбука вкуса», что позволит ему войти в премиум-сегмент. Дополнительно с АБ Магниту получил три РЦ и пять фабрик-кухонь.

«Магнит» врывается в премиум-сегмент. Будем надеяться что АБ останется таким же самобытным и в их ассортимент не появятся позиции Магнита.

8. Ozon тестирует доставку личных посылок между ПВЗ

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

Расширение логистика — это всегда интересно. Поскорее бы ecom решение выложили.

9. СберМегаМаркет тестирует подписки на доставку

Подписка за 299 рублей в месяц даёт бесплатную доставку заказов от 500 рублей.

Лояльность через подписки — рабочая модель. Amazon Prime как пример. Но вопрос: почему бы не включить доставку в стоимость товара и назвать её бесплатной?

10. Wildberries штурмует финтех с WB Pay

WB запустила сервис WB Pay для оплаты покупок на сторонних сайтах. Пока это пилот на сайтах партнёров, но скоро сервис охватит весь рунет и даже офлайн-магазины (через оплату смартфоном).

С одной стороны — это шаг в сторону удобства, а с другой — маркетплейс собирает ещё больше данных, чтобы перетянуть покупателей? Если ваши цены ниже, чем на маркетплейсах, возможно, что карточка в выдаче может «полететь вниз». Посмотрим.

11. Распаковки рулят

Исследование: 39% россиян смотрят видео с распаковками, 12% покупают под их влиянием, 66% — иногда. Гаджеты, одежда и косметика — лидеры.

Готовая задача в roadmap?

12. Будущее продуктового ритейла

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

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

Что такое D2C: как бренды зарабатывают без посредников

Fri, 09 May 2025 16:39:47 +0300

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

Это называется D2C (Direct-to-Consumer) — модель, при которой производитель сам занимается продажами, маркетингом и логистикой.

Почему бренды идут в D2C?

Раньше всё было просто: завод делает товар → отдаёт его оптовикам → они продают ритейлерам → покупатель видит товар на полке и берёт. Сейчас производители всё чаще обходятся без этих цепочек. Почему? Потому что это даёт больше контроля над брендом, прямой контакт с клиентом, выше прибыль и гибкость в запуске новых продуктов.

Когда компания контролирует весь процесс, она не зависит от чужих решений. Например, если магазин решит убрать товар с полок или изменить цену, производитель ничего не сможет сделать. В D2C такого нет — ты сам решаешь, как продвигать продукт, какие акции запускать и как выстраивать работу с аудиторией. Это особенно важно для премиальных брендов, которым важно сохранять ценность товара и не участвовать в бесконечных скидках.

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

Как работает D2C?

Представь, что ты производишь, скажем, уникальный кофе в капсулах. Вместо того чтобы отдавать его в супермаркеты, ты создаёшь сайт, запускаешь рекламу в соцсетях, общаешься с клиентами напрямую и сам организуешь доставку. Именно так работают Tesla, Apple и Nike — они минимизируют участие посредников.

Важную роль здесь играет маркетинг. Если раньше достаточно было попасть на полки магазинов, то теперь нужно самому привлекать покупателей. Чаще всего это делается через социальные сети, блогеров и таргетированную рекламу. Контент, который создаёт бренд, становится ключевым инструментом продвижения. Люди больше не хотят просто покупать товар — им важно, кто его производит, какие ценности у компании, какая у неё история. Поэтому бренды рассказывают о себе, делятся закулисьем производства, показывают реальные отзывы и общаются с аудиторией напрямую.

Другой важный момент — логистика. В классической модели этим занимаются дистрибьюторы и ритейлеры, а в D2C всё ложится на плечи производителя. Нужно организовать доставку, продумать систему возвратов, наладить работу склада. Многие компании сотрудничают с фулфилмент-центрами, которые берут на себя часть этих задач. Это позволяет сосредоточиться на продажах и маркетинге, не отвлекаясь на операционные процессы.

Какие подводные камни? ⚠️

D2C — это не только выгоды, но и вызовы. Маркетинг, логистика, клиентский сервис — всё ложится на плечи бренда. Нужно самому привлекать клиентов, решать вопросы доставки и разбираться с возвратами.

Главная сложность — конкуренция. Выйти на рынок может каждый, но без сильного маркетинга тебя просто не заметят. Кроме того, людям сложно менять привычки. Если они привыкли покупать бытовую химию в супермаркете, то просто создать сайт недостаточно, чтобы они начали заказывать её онлайн.

Есть ещё один нюанс — юридическая и финансовая сторона. Когда ты работаешь с ритейлом, они берут на себя часть ответственности: налоги, лицензии, возвраты. В D2C этим занимается сам производитель. Нужно оформлять документы, следить за соблюдением законов, работать с платежными системами и решать вопросы с клиентами.

D2C в России: взлетит или нет? 🇷🇺

Модель уже работает. В то же время всё больше российских компаний тестируют D2C. Например, производители косметики и одежды активно запускают свои онлайн-магазины, развивают продажи через соцсети и напрямую работают с клиентами. Люди привыкают заказывать товары в один клик, получать их на следующий день и напрямую общаться с брендом без лишних посредников.

Так что будущее у D2C есть. Вопрос только в том, насколько быстро он станет новой нормой.

Тренды в e-commerce и B2B на 2025 год: что изменилось и какие технологии стоит учитывать

Mon, 28 Apr 2025 10:34:38 +0300

Изначально я хотел написать про тренды в e-commerce на 2024 год. Но треть 2025-го уже пролетела, и стало интересно: куда в реальности повернули эти тренды? Что изменилось?

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

Что происходит с трендами в e-commerce

Все как было, так и осталось.

Искусственный интеллект продолжает «обещать изменить всё», но пока без революций.
Дополненная реальность вроде бы рядом, но массового прорыва нет.
Социальная коммерция мелькает в прогнозах, но глобального взлета тоже не видно.
Омниканальность активно развивается: кто не строит мост между онлайном и оффлайном — тот проигрывает.
Мобильный шопинг на коне: смартфон давно стал главной торговой площадкой.
Маркетплейсы, вопреки ожиданиям, начинают терять темпы: пользователи ищут новые пути.

В общем, e-commerce тренды сдвинулись чуть-чуть, но в целом остались на месте. Смотреть туда стало скучно.

А вот в B2B-коммерции начинается движ

Вместо предсказаний трендов — решил провести мини-исследование: что реально происходит в B2B по материалам пяти западных и нескольких российских источников.

Что пишут на Западе (где якобы «впереди планеты всей»)?
Из 40+ перечисленных пунктов на разных сайтах чаще всего встречались:

Рост влияния ИИ для гиперперсонализации и прогнозов.
Видео-контент в B2B: короткие, точечные ролики о продуктах и выгодах.
Микроконтент для «точечного попадания» в клиента.
Социальные сети для персонализированного общения.
Сокращение количества «сырого» AI-контента — упор на работу в паре человек + ИИ.
Развитие частных сообществ клиентов и партнеров.
Использование данных о намерениях для продажи/покупки.

Российские тренды похожи, но более сдержанные. Акцент на развитие клиентского опыта, удобство платформ, осторожное внедрение AR/VR и работу с данными.

Наш реальный опыт: как B2B запускается в проектах

По нашему опыту в студии, B2B-проекты обычно запускаются в двух сценариях:
Либо «быстро, чтобы было и работало» — и тогда про UX/UI помнят постольку-поскольку, либо решение уже существует и новый запуск идет по всем канонам проектирования: проработанный UX, полноценный UI, полное погружение в задачи пользователей.

Интерфейсы, конечно, важны, но далеко не всегда это приоритет на старте. Часто в B2B выигрывает тот, кто просто быстрее решит проблему клиента.

Мои выводы

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

UX становится всё важнее в B2B. Люди привыкли к удобным решениям в B2C, и теперь этого же ждут от B2B-платформ. Удобство перестало быть «опцией» — это базовое требование.

Мобильные решения плотно входят в B2B. Рабочие процессы переносятся в смартфоны. Мобильный доступ — это уже не бонус, а стандарт.

Омниканальность в B2B — новая реальность. Клиенты клиентов хотят получать единый опыт: онлайн, офлайн, поддержка, мобильное приложение — всё должно работать как одна система.
С AI нужно быть аккуратнее. Искусственный интеллект — полезный инструмент, но не магическая палочка. Его стоит внедрять точечно: на отдельные задачи, где он реально повышает эффективность, а не ради «чекбокса трендовости».

Итог

Глобальных сдвигов в трендах нет, но клиенты становятся требовательнее. Кто умеет быстро адаптироваться под их ожидания — тот выигрывает.
Не хайповать, а делать удобные, эффективные продукты — вот что действительно важно в 2025 году.

Четырнадцать миллионов шестьсот двадцать пять вариантов

Fri, 28 Mar 2025 09:37:01 +0300

Любую задачу можно решить бесконечным количеством способов. В разработке эта бесконечность обычно сжимается до двух-трех относительно адекватных вариантов.

Эта история возникла после недавнего спора с товарищем. Когда-то мы помогали ему с eCommerce, но сегодня уже нет, и поэтому обсуждение попало сюда.

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

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

Вариант 1: «Барский» 👑

Создаем новое ограничение у службы доставки: время начала и окончания работы. Главное, чтобы на сервере было корректно установлено московское время. Выносим настройку в оформление доставки — готово. Делать это относительно несложно, поскольку у Битрикса есть штатные механизмы для расширения ограничений по доставке, оплате и даже скидкам.

Плюсы: решение гибкое, настроить его сможет практически любой пользователь.

Вариант 2: «Жестко в коде» 🖥️

Прописываем логику прямо в коде — можно на PHP, можно на JavaScript. Определяем, когда показывать доставку, а когда нет. Главное — правильное серверное время. Можно скрывать доставку (не лучший вариант) или исключать ее из массива данных — здесь уже масса решений.

Этот вариант проще первого, но если что-то потребуется поменять, придется снова звать разработчика. В проекте, о котором идет речь, используется Vue, так что можно реализовать логику и там. Однако вариант так себе.

Вариант 3: «Калашников» (простой и надежный) 🔫

Создаем два PHP-файла: один включает доставку, другой выключает. Запускаем их по cron в нужное время — и готово.

Гибкость: можно легко менять расписание в cron. Однако для этого потребуются хотя бы базовые знания. Сами скрипты для включения/выключения доставки напишет ChatGPT за пару минут. В итоге задача вместе с настройкой cron займет пару часов.

Выводы 🧐

Подобных вариантов можно придумать еще десятки — они будут находиться где-то в этом диапазоне, различаясь только трудозатратами.

Главный смысл этой истории: почти любую задачу можно решить разными способами, каждый из которых имеет свои плюсы и минусы. Мой товарищ выбрал cron, сократив время реализации с 20 до 4 часов. 🎯

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

С другой стороны, третий вариант — это «костыльное» решение, и на крупных проектах так делать нельзя: если подобных обработчиков будет сотни, возникнет хаос. Поэтому важно учитывать контекст задачи. 🚧

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

Кто убил конверсию? 😂

Tue, 25 Mar 2025 18:29:40 +0300

Эта история началась в январе, хотя все совпадения, как водится, случайны. Представьте ситуацию: интернет-магазин, начало года, продажи традиционно проседают. Трафик немного снизился, конверсия чуть изменилась — картина вполне ожидаемая.

Но вдруг происходит нечто странное: конверсия падает почти вдвое по сравнению с прошлым годом. Было 10%, стало 5%, хотя еще месяц назад она держалась на уровне тех же 10%. Бац — и просадка. Это десятки миллионов рублей. Точная цифра неизвестна, но масштаб проблемы ощутимый.

Первая мысль: где-то накосячили разработчики?

Естественно, первой версией было то, что разработчики что-то сломали. Может, корзина глючит или оформление заказа перестало работать? Или сервер лежал, а сайт был недоступен? Клиент уже идет к нам с шашкой наперевес, требуя разобраться и наказать виновных. Технические косяки действительно иногда влияют на конверсию — все мы люди, все ошибаемся. Главное — вовремя сделать выводы и не повторять таких промахов.

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

Следующий шаг — сам сайт. Оформление заказа функционирует без нареканий: цели на месте, скорость загрузки хорошая, доставка и платежные сервисы работают как часы. Ошибок нет. Была мысль, что проблема кроется в логистике — вдруг транспортные компании подвели или условия доставки ухудшились. Или, может, платежные шлюзы барахлили?

Но и тут мимо — всё в порядке.

Код и трафик: копаем глубже

Дальше решили проверить код, который выгружался на сайт. Ключевые сценарии — главная страница, каталог, карточка товара, корзина, оформление заказа — остались без изменений. Никаких подозрительных обновлений.

Тогда возникла гипотеза: а что, если дело в трафике? Мы не занимались продвижением этого проекта, но раз уж ситуация такая, полезли в Метрику. Может, раньше там крутилась рекламная кампания, которая давала волшебный трафик и удваивала конверсию? Смотрим — ничего подобного. Всё стабильно: органический трафик даже немного вырос и год к году, и месяц к месяцу. Логично было бы ожидать роста конверсии, но её, наоборот, обрубило.

Мы перебрали еще несколько гипотез, но ни одна не подтвердилась. Оставалось копать дальше.

Ассортимент под подозрением

В какой-то момент решили проверить ассортимент — вдруг 1С что-то напортачила? Интеграция там стандартная, всё должно работать как автомат. Логи интеграции показывают стабильность, никаких сбоев. История цен тоже в порядке: изменения разумные, без резких скачков вроде удвоения стоимости. В самой 1С, судя по данным, обновлений не выкатывали.

И тут нас осенило: а что с остатками? В штатном Битриксе логов остатков нет, но на этом проекте раньше уже были проблемы с интеграцией — она работала нестабильно. Поэтому мы сделали сохранение файлов обмена в отдельную директорию, так сказать, на память. За пару месяцев там накопилось достаточно данных. И вот что выяснилось: в какой-то момент остатки по части ассортимента обнулились. Речь о группе товаров, которая приносила основной оборот и пользовалась высоким спросом у клиентов. Так продолжалось примерно полторы недели.

Кто виноват и куда махать шашкой

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

Конечно, жаль, что интернет-магазин сразу не подсветил эту проблему. Тут нужна аналитика и мониторинг. Чтобы не оказаться в подобной ситуации, лучше заранее ставить алерты на ключевые позиции — по ценам и остаткам. Возможно, это можно настроить прямо в 1С, но у нас доступа к системе не было, так что быстро проверить не было возможности.

eCommerce эволюционирующий

Mon, 10 Mar 2025 20:04:35 +0300

В 2025 году маркетплейсы всё активнее поглощают классический eCommerce. Хотя вроде уже и нет. Пока неясно, выживет ли традиционный формат интернет-магазинов. Наверное да, но это не точно.

Крупные игроки вроде DNS чувствуют себя довольно уверенно. Что же делать компаниям поменьше или тем, кто только хочет выйти на рынок электронной коммерции?

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

Стартовый этап: готовое решение

Представим опытную компанию, которая уже несколько раз пыталась развивать eCommerce. Новый активный менеджер решает снова попробовать, но без долгосрочной разработки с нуля. Он ищет оптимальные варианты.

Рассмотрим эволюционный путь, который сложился в нашей практике. Сразу пропустим Tilda и прочие SaaS-решения — у них нет точек масштабирования. Мы с клиентом смотрим дальше, насколько это возможно в современных реалиях.

Начинаем с комбинации Битрикс + готовое решение. Можете критиковать, но качественно собранное готовое решение, поддающееся кастомизации, для старта вполне приемлемо. Особенно если учесть, что в него вложено около 1000 часов разработки, и маловероятно, что на стадии MVP вы создадите нечто подобное.

Главное преимущество — скорость запуска. Можно быстро стартовать, не беспокоясь о фронтенде и бэкенде, сразу делать интеграции и не переживать, что что-то не заработает. Такие проблемы возможны, но вероятность их возникновения ниже.

Развитие и первые ограничения

Проект запущен и работает. Интеграции сделаны и проверены, данные перемещаются без сбоев. Что дальше?

Следующий шаг — кастомизация проекта, улучшение отдельных компонентов вроде поиска, фильтров и т. п.

Но развитие магазина приносит новые вызовы. Готовое решение содержит множество избыточного кода, и серьезная кастомизация либо невозможна, либо критически замедляет работу. Даже без кастомизации такие универсальные комбайны плохо справляются с возрастающей нагрузкой из-за обилия функциональности, что негативно влияет на скорость.

Модернизация фронтенда

Что делать? Бэкенд менять не хотим, админка и её возможности нас устраивают, тем более что с этой стороны проблем обычно немного. А вот фронтенд хочется сделать современнее, с плавной анимацией, да ещё и мобильное приложение добавить.

Решение: разрабатываем API. На базе текущего бэкенда создаём API для Битрикса, мы обычно используем микрофреймворк Slim — как-нибудь напишу об этом отдельно. Параллельно разрабатываем отдельный фронтенд — веб, мобильное приложение или что угодно другое. Связываем всё, и вуаля — у нас свой фронтенд, который можно развивать отдельной командой и который лучше справляется с нагрузкой.

Модернизация бэкенда

Теперь с фронтендом всё решено, у нас устойчивое решение, которое можно развивать долгое время большой командой. Но возникает следующая проблема: бэкенд уже обрабатывает тысячи заказов, и инфраструктура фреймворка Битрикс не справляется.

Следующий шаг — разделение на отдельные сервисы. Обычно начинают с каталога, который включает в себя поиск, фильтрацию, выдачу и т. д. Возможно, появится PIM-система или Elasticsearch. Создаётся шина данных, которая разгрузит обмены с внешними системами.

В результате получается своего рода «Франкенштейн»: фронтенд — отдельное приложение, API работает через Битрикс, а к нему подключена куча сервисов.

Полная модернизация

Следующим шагом развития становится полная замена бэкенда. Вероятно, выбор падёт на современный фреймворк типа Laravel с проектом, построенным по сервисной архитектуре, или изначально берётся что-то похожее.

В итоге мы получаем полноценную микросервисную систему с хорошим фронтендом и быстрым бэкендом.

Заключение

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

Описанный путь применим как для B2B, так и для B2C, и для любого коробочного решения — Битрикс использован лишь в качестве примера. Вы можете взять любую другую CMS и повторить этот подход.

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

РРЦ и маркетплейсы или как управлять ценами на OZON и Wildberries

Thu, 13 Feb 2025 08:20:51 +0300

Так уж сложилось, что мы работаем в e-commerce. А сегодня e-commerce — это, прежде всего, маркетплейсы. Следовательно, что? Верно, нужно быть там.

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

Какие варианты доступны?

Самописное решение — долго, дорого и мучительно поддерживать обновления API.
Готовый модуль — вполне рабочая история.
Агрегатор — промежуточное звено, которое не всегда удобно.
Прямая загрузка из 1С или аналогичной системы — можно, но дорого.
Ручной ввод — не наш метод.

Но сегодня речь не об этом.

Когда все на одном маркетплейсе

Допустим, вы — производитель. Заходите на D2C, а у вас уже есть сеть дилеров, которым настоятельно рекомендуете придерживаться РРЦ (рекомендованной розничной цены).

И вот вы все дружно оказываетесь на одном маркетплейсе. Пусть будет Фиолетовый или Синий — не суть важно. И тут начинается танец с бубном вокруг цены.

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

Для клиента — прекрасно. Для вас, как производителя, не очень: дилеры начинают ругаться, появляется ценовой хаос и другие неприятные последствия.

Как решить проблему?

Мы протестировали несколько подходов и остановились на таком:

Формируем список товаров, которые загружаются на маркетплейсы.
Получаем актуальный список товаров, представленных на площадках.
Используем парсер — свой или готовый (главное, чтобы можно было выгружать данные в CSV или API).
Парсим цены несколько раз в день.
Сверяем полученные данные с нашими РРЦ:
- Если цена в норме — ничего не меняем.
- Если цена ниже РРЦ — пересчитываем нашу цену и обновляем на маркетплейсе.
- Если цена выше РРЦ — откатываемся назад, значит, скидка уже ушла.

Как это работает технически?

Все это можно реализовать внутри Bitrix или вынести в отдельный сервис на Laravel. Да, есть небольшие задержки в обновлении, но на практике лаг не критичный.

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

Так что, если вы производитель и хотите контролировать РРЦ на маркетплейсах, автоматизация — ваш лучший друг.

Персонализация в e-commerce: помощь пользователям или эксплуатация личных данных?

Fri, 07 Feb 2025 16:32:40 +0300

Персонализацию в e-commerce принято восхвалять как прекрасный способ выстраивания прочных и длительных отношений с клиентами.

Но давайте посмотрим правде в глаза: персонализация — это просто еще один инструмент, помогающий компаниям увеличивать продажи через оптимизацию рекомендаций и пользовательского

Случайные рекомендации: благо или проблема?

Когда я делаю покупки онлайн, мне часто предлагают самые неожиданные товары. Недавно я добавил в корзину на одном из маркетплейсов джемпер (конечно, исключительно в исследовательских целях), и мне тут же порекомендовали еще джемперы, брюки — логично... странные носки.. какой-то согреватель для ног... и детский телескоп — что это вообще такое?

Меня лично не задевают такие нерелевантные рекомендации по двум причинам. Во-первых, я рад, что не возникнет искушению добавить в заказ больше вещей — все-таки стараюсь минимизировать потребление. Во-вторых, я доволен, что у маркеплейса недостаточно информации обо мне, чтобы рекомендовать действительно интересные товары.

Потребители жаждут персонализации

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

66% потребителей говорят, что не персонализированный контент может оттолкнуть их от покупки.

91% с большей вероятностью будут покупать у брендов, предлагающих релевантные рекомендации.

56% клиентов охотнее возвращаются на сайты с персонализированными товарными рекомендациями, а 74% испытывают разочарование, когда контент не персонализирован.

Более того, исследование Gartner показало, что клиенты, считающие электронные письма компаний нерелевантными и раздражающими, отписываются (48%) или прекращают сотрудничество с брендом (14%).

Почему люди готовы делиться личными данными?

Большинство из нас воспринимает это как компромисс. Мы позволяем сайту или компании использовать наши данные в обмен на следующие преимущества:

Экономия времени и сил

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

Чувство признания и понимания

Несмотря на обилие экранов и искусственного интеллекта в нашей жизни, мы остаемся людьми, жаждущими общения. Когда крупные компании отправляют нам персонализированные сообщения с нашим именем и рекомендуют товары, которые нам действительно нравятся, мы с радостью принимаем это, порой забывая, что для них мы просто номер в CRM-системе, где весь этот персонализированный контент автоматизирован ради увеличения продаж.

Проблема приватности данных

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

Звучит немного пугающе, не правда ли? Корпорации, изучающие нашу сущность, чтобы заставить нас потреблять больше? К сожалению, это происходит уже десятками лет, и технологии сбора и использования данных только совершенствуются.

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

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

Стоимость данных

«Наша способность собирать данные намного превосходит способность их осмысливать». Как отмечает отчет Gartner, в последние годы бренды электронной коммерции стали настоящими центрами сбора данных. Проблема в том, что огромные объемы данных остаются хаотичными и неточными.

Более того, чем больше данных вы собираете, тем больше ответственности берете на себя. К счастью, сегодня существуют законы и нормативные акты, обязывающие компании защищать информацию о клиентах. Хранение данных, особенно когда они просто лежат на сервере, имеет высокую стоимость.

Персонализация как бизнес-стратегия

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

И зачем компании хотят выделиться на рынке? Правильно, чтобы заработать больше денег! Персонализация:

Стимулирует продажи и повышает конверсию
Увеличивает среднюю стоимость заказа
Способствует повторным покупкам
Снижает количество брошенных корзин

Время переосмыслить подход к персонализации

Персонализация — это инструмент, и как любой инструмент, его влияние может быть как положительным, так и отрицательным, в зависимости от того, какого результата мы хотим достичь. Пока цель персонализации — «заставить пользователей покупать больше”.

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

Приоритет данных „нулевой стороны“ — информации, которой клиент сознательно и активно делится с бизнесом
Сбор данных по принципу opt-in — пользователи сами выбирают, какими данными делиться
Четкое объяснение преимуществ обмена данными
Сбор только необходимых данных

Примеры персонализации для интернет-магазина

Изменение контента:

Персонализация главной страницы с актуальными баннерами и товарами.
Сегментированный контент (разные коллекции, акции в зависимости от предпочтений).
Локализация контента (язык, валюта, условия доставки).
Контент на основе времени суток (например, товары для завтрака утром).
Динамические баннеры с подстройкой под интересы пользователя.
Демонстрация товаров в выбранной цветовой гамме.
Фотографии товаров с учетом сезона (зимняя или летняя коллекция).
Товары с учетом стиля пользователя (минимализм, классика и т. д.).
Фотографии с примерами использования товара (в интерьере, на модели).
Фото товаров, загруженные другими пользователями, на основе отзывов.

Интерактивные и визуальные персонализации:

Умный поиск с подсказками на основе истории запросов.
Фотографии товаров с возможностью менять цвет или конфигурацию.
Подбор фото с учетом геолокации (актуальные товары для региона).
Интерактивные фото товаров (например, анимация „360 градусов“).
Пользовательская галерея товаров, сортированная по популярности у аудитории.

Данные и аналитика:

Уведомления о наличии товара, интересующего пользователя.
Динамическое ценообразование в зависимости от активности клиента.
Контент на основе демографических данных (возраст, пол).
Контент на основе просмотров конкурентов (через ретаргетинг).
Автоматические push-уведомления об изменении статуса заказа или акциях.

Эти примеры можно реализовать с помощью встроенных инструментов CMS, таких как модули персонализации, CRM-маркетинг, умный фильтр, а также через интеграции с внешними сервисами (например, аналитики или рекомендаций).

Заключение

Важно не забывать что персонализация контента может быть как добром, так и злом. Плохие рекомендации никому не нужны. Поэтому внедрять ее нужно аккуратно, не забывая собирать статистику.

Маркетплейсы: рай для продавцов или билет в один конец?

Tue, 17 Sep 2024 15:48:58 +0300

В последние годы маркетплейсы стали доминирующей силой в сфере ecom. Они предлагают продавцам доступ к огромной аудитории, удобную логистику и кажущуюся простоту ведения бизнеса. Для покупателя так же отличный сервис, пара кликов и товар около дома. Однако так ли безоблачно будущее этой модели? Давайте рассмотрим текущую ситуацию и попробуем заглянуть в будущее.

Сегодня

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

Огромная аудитория

Миллионы потенциальных покупателей уже присутствуют на платформе. Проблема курицы и яйца уже давно решена.

Удобная логистика

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

Быстрый старт

Не нужно разрабатывать собственный сайт или приложение.

Режим «одного окна»:

Покупатели могут приобрести разные категории товаров в одном месте.

Однако за этими преимуществами скрываются существенные недостатки, которые становятся все более очевидными для продавцов.

Проблемы

Ужесточение условий

Маркетплейсы постоянно меняют правила игры, часто не в пользу продавцов. Например, Wildberries в 2022 году отключил личные кабинеты продавцов с рейтингом ниже 60%, а затем перестал работать по схеме «Маркетплейс» с теми, у кого рейтинг ниже 90%.

Высокие комиссии и штрафы

Комиссии могут достигать 25% от стоимости товара. Кроме того, существуют штрафы за различные нарушения, от несвоевременной поставки до ошибок в документах.

Отсутствие контроля над ценообразованием

Маркетплейсы часто проводят акции и распродажи без согласования с продавцами, что может приводить к продажам в убыток. Например, компания Don’t Worry была вынуждена продавать кофе на 10% ниже себестоимости из-за условий акции на платформе.

Высокая конкуренция

На одной странице с вашим товаром покупатель видит предложения конкурентов, что усложняет борьбу за клиента.

Отсутствие прямого контакта с покупателем

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

Ограниченная аналитика

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

Зависимость от алгоритмов площадки

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

Свой интернет-магазин?

Учитывая эти проблемы, многие продавцы начинают задумываться о создании или возвращении к собственным интернет-магазинам. Эта тенденция набирает обороты не только в России, но и на глобальном рынке, включая продавцов на Amazon.

Почитать про зарубежную практику можно тут: https://www.quora.com/unanswered/Why-are-e-commerce-sellers-leaving-Amazon

Свой магазин дает несколько существенных преимуществ.

Контроль над бизнесом

Вы сами устанавливаете правила, проводите акции и определяете ценовую политику.

Прямой контакт с клиентами

Возможность собирать данные о покупателях и выстраивать долгосрочные отношения.

Полная аналитика

Доступ к детальной информации о поведении пользователей на сайте.

Развитие бренда

Возможность создать уникальный образ и повысить узнаваемость бренда.

Отсутствие прямой конкуренции на странице товара

Покупатель видит только ваши предложения.

Гибкость в интеграциях

Возможность подключать различные сервисы и системы для оптимизации бизнес-процессов.

Снова проблемы

Однако переход на собственную платформу сопряжен с определенными трудностями:

Высокие начальные инвестиции

Разработка качественного интернет-магазина может стоить от 1 миллиона рублей.

Необходимость привлечения трафика

Придется самостоятельно заниматься продвижением и привлечением клиентов.

Организация логистики

Нужно будет решать вопросы хранения, упаковки и доставки товаров.

Техническая поддержка и обновления

Потребуется постоянно поддерживать работоспособность сайта и обновлять его.

Гибридная модель

Вероятно, будущее электронной коммерции лежит в балансе между маркетплейсами и собственными платформами. Использование маркетплейсов для привлечения новых клиентов и тестирования новых товаров.

Развитие собственного интернет-магазина для формирования лояльной аудитории и увеличения маржинальности.
Omnichannel-подход: интеграция онлайн и офлайн каналов продаж для создания единого пользовательского опыта.

Заключение

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

Будущее за теми компаниями, которые смогут эффективно использовать преимущества разных платформ, создавая уникальный опыт для своих клиентов и выстраивая долгосрочные отношения с ними. В этом контексте, инвестиции в создание и развитие собственной онлайн-платформы могут стать ключевым фактором успеха в долгосрочной перспективе.

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