![\"\"](\"https:\/\/alexeyit.ru\/pictures\/meteor.png\")
\n<\/div>\nВсем привет. Два прошлых поста подряд, кажется, немного исчерпали запас букв для этого канала. Буду исправляться и стараться писать регулярнее.<\/p>\n
Новости последних дней все видели, поэтому подробно пересказывать их не буду. Для маркетплейса потеря даже крупного склада — неприятность, но всё же малая доля общей инфраструктуры. А вот для селлеров ситуация совсем другая.<\/strong><\/p>\n Даже если выплаты в итоге покроют стоимость товара — что само по себе не гарантировано, — деньги могут оказаться заморожены на месяцы.<\/strong> А у кого-то на складах лежали товары на десятки и сотни миллионов рублей. В общем, сил всем, кого это затронуло.<\/p>\n Вероятно, после таких историй усилится тренд на отгрузку с собственных складов и распределение товаров между разными фулфилментами.<\/strong> Возможно, появятся отдельные страховые продукты. Посмотрим, как рынок отработает этот риск.<\/p>\n На фоне происходящего коллега, который занимается нашим продуктом, задал логичный вопрос: не выстроятся ли теперь селлеры в очередь на выход с маркетплейсов?<\/strong><\/p>\n Если они уйдут, торговать на площадках будет некому. А если некому торговать, то и наш репрайсер становится не нужен. Логика вроде бы есть.<\/p>\n Но я слабо верю, что продавцы массово откажутся от маркетплейсов и резко начнут строить собственные интернет-магазины. Скорее рынок адаптируется: кто-то перейдёт на отгрузку со своего склада, кто-то распределит остатки между несколькими площадками и фулфилментами, кто-то застрахует товар.<\/p>\n Риск никуда не исчезнет, но бизнес найдёт способы с ним жить.<\/strong><\/p>\n Я уже писал, что для нашего репрайсера и его аналогов есть два действительно больших риска. Первый — государственное регулирование, которое может серьёзно изменить или вообще зарубить текущую модель. Второй — сами маркетплейсы, которые могут технически ограничить работу подобных сервисов.<\/strong><\/p>\n Если реализуется один из этих сценариев, вариантов немного: закрыть продукт из-за отсутствия рынка или развернуться в соседнее направление — например, в аналитику или другие инструменты для селлеров.<\/p>\n Проблема в том, что оба риска потенциально фатальные, но практически неуправляемые.<\/strong> Да, можно заранее вложить время и деньги в запасное направление. Но тогда часть внимания и ресурсов уйдёт из основного продукта, а событие, к которому мы готовились, может вообще не произойти.<\/p>\n В итоге можно несколько лет готовиться к концу света и пропустить вполне обычные проблемы, которые действительно происходят каждый день.<\/strong><\/p>\n Я это всё к тому, что нет особого смысла постоянно переживать о рисках, которые от нас не зависят и на которые мы почти не можем повлиять.<\/strong><\/p>\n В первую очередь работать стоит с тем, что с высокой вероятностью произойдёт и при этом может сильно ударить по бизнесу.<\/strong> В самом простом виде приоритет риска можно оценить через произведение вероятности на размер возможного ущерба:<\/p>\n Вероятность × ущерб = приоритет риска.<\/strong><\/p>\n Конечно, правильно оценить и вероятность, и последствия — отдельная задача. Но даже такая примитивная модель полезнее, чем обсуждение всех возможных катастроф подряд.<\/p>\n Коллега посоветовал составить карту рисков. И тут внезапно выяснилось, что её у нас нет ни по продукту, ни в агентстве.<\/strong> Опача. Будем исправлять. Возможно, заодно получится отдельный текст о том, как мы её составляли и что обнаружили.<\/p>\n Ну и короткое завершение. Кажется, мы вошли во вкус с выставками, поэтому осенью поедем ещё на одну или несколько. Ближайшая — E-Retail Forum 2026, которая пройдёт 22–23 сентября.<\/strong> Осталось не так много времени. Буду рад увидеться и пообщаться лично.<\/p>\n",
"date_published": "2026-07-23T13:31:54+03:00",
"date_modified": "2026-07-23T13:31:50+03:00",
"tags": [
"Личный опыт и размышления",
"Управление проектами и командами"
],
"image": "https:\/\/alexeyit.ru\/pictures\/meteor.png",
"_date_published_rfc2822": "Thu, 23 Jul 2026 13:31:54 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "150",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/meteor.png"
]
}
},
{
"id": "149",
"url": "https:\/\/alexeyit.ru\/all\/reyting-runeta-2026-webest-voshel-v-top-3-e-commerce-top-10-bitr\/",
"title": "Рейтинг Рунета 2026: Webest вошел в топ-3 e-commerce, топ-10 Битрикс24 и топ-30 по технической поддержке",
"content_html": " Астрологи объявили неделю двух постов 😊<\/strong><\/p>\n Хвастаться, конечно, не очень красиво. Но если иногда не рассказать о своих результатах, то о них никто и не узнает.<\/span><\/p>\n На днях вышли обновленные рейтинги Рунета, и в этом году мы показали хороший результат.<\/span><\/p>\n В категории e-commerce заняли <\/span>3 место в среднем сегменте<\/strong>. Здесь, правда, сами себе поставили небольшую претензию. Средним сегментом мы, конечно, занимаемся, но уже около года целимся в верхний. Значит, в следующем рейтинге будем штурмовать уже его.<\/span><\/p>\n Среди CRM-интеграторов поднялись на <\/span>9 место<\/strong>. Год назад были ниже, так что движение идет в правильную сторону.<\/span><\/p>\n Отдельно радует направление Битрикс24. Мы остаемся одним из всего <\/span>10 партнеров<\/strong>, обладающих сертификатом <\/span>Битрикс24 Enterprise среднего уровня<\/strong>, а также входим в <\/span>топ-10 партнеров Битрикс24<\/strong> по официальному рейтингу. Для нас это один из самых важных показателей.<\/span><\/p>\n Еще впервые попали в рейтинг по технической поддержке. Раньше он назывался «Развитие», теперь — просто «Поддержка». Итог — <\/span>24 место<\/strong>. Не первое, конечно, но специалистов в этой сфере очень много, поэтому буду скромно говорить, что мы в <\/span>топ-30 России<\/strong>. Звучит вполне достойно. 🙂<\/span><\/p>\n Есть и другие отраслевые рейтинги — промышленность, пищевая отрасль и другие. Там тоже уверенно держимся в двадцатке и тридцатке, но это уже приятные бонусы.<\/span><\/p>\n И напоследок хочется сказать спасибо команде Рейтинга Рунета. За последний год они проделали действительно огромную работу: полностью переработали личный кабинет, сделали более прозрачным сбор и модерацию данных, серьезно улучшили сами рейтинги. Ну и отдельное удовольствие — наблюдать, что творилось в общем чате. 😄<\/span><\/p>\n Анатолий, Александр и вся команда Рейтинга Рунета — спасибо за ваш труд и удачи в следующих обновлениях!<\/span><\/p>\n <\/p>\n",
"date_published": "2026-07-01T08:38:55+03:00",
"date_modified": "2026-07-01T08:38:51+03:00",
"tags": [
"Личный опыт и размышления",
"Управление проектами и командами"
],
"image": "https:\/\/alexeyit.ru\/pictures\/baron.png",
"_date_published_rfc2822": "Wed, 01 Jul 2026 08:38:55 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "149",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/baron.png"
]
}
},
{
"id": "148",
"url": "https:\/\/alexeyit.ru\/all\/stoit-li-uchastvovat-v-ecom-expo-opyt-kompanii-i-rezultaty\/",
"title": "Стоит ли участвовать в Ecom Expo: опыт компании и результаты",
"content_html": " Всем привет!<\/span><\/p>\n Вот и прошла первая половина года. Как у вас дела с целями на 2026<\/strong>-й? Получилось выполнить хотя бы 50% запланированного?<\/span><\/p>\n У нас нет<\/strong>. Значит, есть над чем работать.<\/span><\/p>\n На прошлой неделе мы второй раз в жизни участвовали в выставке со своим стендом — на Ecom Expo<\/strong>. До этого весной были на выставке «Селлеры и Маркетплейсы<\/strong>», поэтому уже есть с чем сравнить.<\/span><\/p>\n На первой выставке мы получили около 20 лидов<\/strong>. Пока в контракт превратился только один. Если считать только его, стоимость привлечения выглядит пугающе — около 300 тысяч рублей.<\/strong> Но в B2B сделки живут долго, поэтому окончательные выводы делать рано. Часть переговоров еще продолжается.<\/span><\/p>\n С Ecom Expo впечатления совсем другие.<\/strong><\/p>\n Посетителей было заметно больше, и это чувствовалось буквально во всем. Мы собрали около 60+ лидов, а количество содержательных разговоров выросло примерно втрое. Основной интерес был к нашему репрайсеру GuardPrice<\/strong>. Забавно, что мы стояли в зале, который больше ориентирован на разработку и интеграции, хотя целевая аудитория продукта в основном находилась в соседнем павильоне с маркетинговыми сервисами. Если бы знали это заранее, выбрали бы другое место. Но даже так люди сами находили наш стенд.<\/span><\/p>\n По услугам разработки и внедрению CRM тоже были обращения, хотя их оказалось значительно меньше. Это вполне ожидаемо: на подобных мероприятиях все же чаще приходят за готовыми продуктами, чем за заказной разработкой.<\/span><\/p>\n Если говорить о самой выставке, то не очень понравилась площадка в «Тимирязев Центре».<\/strong><\/span><\/p>\n Само пространство современное, удобное и выглядит отлично. Но организация сцен оставила вопросы. Они никак не отделены от основной выставочной зоны: нет ни стен, ни звукоизоляции. В результате несколько сцен одновременно создают постоянный фоновый шум. Разговаривать приходится почти криком, и к концу второго дня голос просто заканчивается. Не завидую спикерам — выступать в таких условиях явно непросто.<\/span><\/p>\n Кстати, еще один практический вывод: удобная обувь — обязательна. Не просто удобная, а максимально удобная. Беговые кроссовки, Crocs<\/strong> или что-то похожее. Два дня почти без перерывов на ногах ощущаются намного тяжелее, чем кажется заранее.<\/span><\/p>\n По аудитории тоже было интересно. До выставки казалось, что основной поток составят небольшие продавцы и селлеры. На практике среди примерно сотни людей, с которыми мы пообщались, около трети представляли уже достаточно зрелый средний бизнес, а 8–10 компаний — это действительно крупные игроки рынка, которых легко найти в рейтингах крупнейших компаний российского e-commerce. И, что особенно приятно, многие из них интересовались именно репрайсером<\/strong>.<\/span><\/p>\n Конечно, окончательные выводы можно будет делать только после обработки всех лидов и завершения переговоров. Но уже сейчас могу сказать, что с точки зрения вложенных денег, времени и полученного опыта участие в выставке себя оправдало.<\/span><\/p>\n Поэтому осенью обязательно повторим. В сентябре едем со стендом на Retail Week.<\/strong><\/span><\/p>\n Посмотрим, какие выводы сделаем после третьей выставки.<\/span><\/p>\n <\/p>\n",
"date_published": "2026-07-01T08:28:02+03:00",
"date_modified": "2026-07-01T09:08:44+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Личный опыт и размышления",
"Репрайсер"
],
"image": "https:\/\/alexeyit.ru\/pictures\/IMG_2651.png",
"_date_published_rfc2822": "Wed, 01 Jul 2026 08:28:02 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "148",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/IMG_2651.png"
]
}
},
{
"id": "147",
"url": "https:\/\/alexeyit.ru\/all\/chto-na-samom-dele-stoit-za-razvitiem-repraysera-dlya-marketpley\/",
"title": "Что на самом деле стоит за развитием репрайсера для маркетплейсов",
"content_html": " «Да это Claude за час сделает»<\/strong><\/p>\n Всем привет 👋<\/p>\n Пишу всё реже, но стараюсь хотя бы раз в неделю появляться здесь. Казалось бы, лето сезон отпусков, а B2B традиционно начинает жить в режиме «давайте после лета». Почти как «давайте после праздников».<\/p>\n Логично предположить, что свободного времени становится больше. Но почему-то получается ровно наоборот.<\/p>\n Больше всего времени сейчас уходит на продукт. За кажущейся простотой и популярной мыслью «да это Клод за час навайбкодит» обычно скрывается огромное количество нюансов. И чем глубже копаешь, тем больше понимаешь, что основная работа начинается уже после того, как первая версия заработала.<\/p>\n Поэтому расскажу про несколько изменений, которые мы сделали в репрайсере за последние месяцы.<\/p>\n С самого начала продукт был довольно автономным и почти не зависел от внешних сервисов. Но одна зависимость всё-таки оставалась прокси<\/strong>.<\/p>\n Долгое время мы их закупали у сторонних поставщиков. Казалось бы, что тут может пойти не так<\/strong>? На практике многое<\/strong>.<\/p>\n Мы перепробовали множество провайдеров и сервисов. Где-то была слишком агрессивная ротация IP, где-то качество адресов оставляло желать лучшего. Но главная проблема была в другом отсутствие стабильности<\/strong>.<\/p>\n Система могла спокойно работать неделю, а потом в самый неподходящий момент прокси просто исчезал на несколько часов. Для репрайсера это критично.<\/p>\n Поэтому мы решили сделать следующий шаг и перейти на собственную инфраструктуру прокси. Теперь сами отбираем IP по нашим требованиям и контролируем качество работы. Это не самая заметная функция продукта, но именно такие вещи дают реальную надёжность.<\/p>\n Продолжая тему стабильности.<\/p>\n До недавнего времени ядро системы располагалось на инфраструктуре Бегета, и в целом всё работало отлично. Но весной произошло несколько неприятных историй подряд.<\/p>\n Судя по комментариям провайдера, на магистральных каналах возникли серьёзные проблемы. В какой-то момент одновременно выпали основной и резервный провайдеры. Для большинства проектов это неприятность. Для сервиса, который должен работать постоянно, уже серьёзный риск.<\/p>\n Самое неприятное даже не в самом инциденте. Самое неприятное, когда такие ситуации начинают повторяться. А у нас это были не единичные случаи, а несколько сбоев подряд с интервалом примерно в неделю<\/strong>.<\/p>\n После этого стало понятно, что хранить все яйца в одной корзине плохая идея.<\/p>\n Сейчас мы активно смотрим в сторону Selectel, Яндекс Облака, Reg.ru и других площадок. Параллельно перестраиваем архитектуру продукта в сторону сервисного подхода. Не микросервисы ради модного слова, а разумное разделение системы на независимые компоненты.<\/p>\n В моём понимании «много сервисов» это не сотни. Уже около десяти независимых сервисов позволяют переживать отдельные сбои без остановки всей системы.<\/p>\n Апрель и май получились довольно увлекательными, бессонными и местами незабываемыми. Но именно такие месяцы обычно заставляют принимать правильные инфраструктурные решения.<\/strong><\/p>\n Пока занимались вопросами надёжности, работа над самим продуктом не останавливалась.<\/p>\n Оптимизировали существующие стратегии, в том числе с точки зрения безопасности. Начали разработку стратегий на основе UNIT-экономики каждого товара. Продолжаем развивать поддержку новых площадок Золотое Яблоко, Лемана ПРО, М.Видео и других маркетплейсов.<\/p>\n Ну и, как обычно, огромное количество небольших улучшений, которые редко попадают в релизные заметки, но ежедневно делают систему лучше.<\/p>\n И, наверное, самое важное изменение за последнее время.<\/p>\n К команде присоединился новый коллега. Я в шутку называю его цифровым разнорабочим<\/strong>. Да простит меня Рома.<\/p>\n По сути, он будет совмещать сразу несколько ролей: аккаунтинг, project management и product management.<\/p>\n По мере роста продукта становится всё сложнее держать всё в голове и одновременно заниматься развитием, клиентами и операционкой. Поэтому рассчитываю, что это усиление позволит сделать продукт ещё более стабильным и предсказуемым.<\/p>\n Впрочем, как и всегда, время покажет.<\/p>\n Ну и напоследок.<\/p>\n Если давно хотели пересечься лично, напоминаю, что уже на следующей неделе будет Ecom Expo. Мы будем там со своим стендом. Подробности здесь: https:\/\/t.me\/alexeyitru\/206<\/a><\/a><\/p>\n Буду рад увидеться и пообщаться вживую.<\/p>\n",
"date_published": "2026-06-17T17:07:20+03:00",
"date_modified": "2026-06-17T17:10:07+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Личный опыт и размышления",
"Управление проектами и командами"
],
"image": "https:\/\/alexeyit.ru\/pictures\/iun.png",
"_date_published_rfc2822": "Wed, 17 Jun 2026 17:07:20 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "147",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/iun.png"
]
}
},
{
"id": "146",
"url": "https:\/\/alexeyit.ru\/all\/kogda-pokazatel-stanovitsya-celyu-zakon-gudharta-prostymi-slovam\/",
"title": "Когда показатель становится целью: закон Гудхарта простыми словами",
"content_html": " Недавно узнал, что у всей этой истории с KPI и метриками есть официальное название — закон Гудхарта<\/strong>.<\/p>\n Хотя сама идея для меня новой не стала. За годы работы с проектами постоянно сталкивался с одной и той же проблемой.<\/p>\n Когда показатель становится целью, он перестает быть хорошим показателем.<\/p>\n<\/blockquote> И чем дольше в менеджменте, тем больше убеждаешься, что проблема обычно не в KPI. Проблема начинается тогда, когда люди перестают отличать цель от способа ее измерения.<\/p>\n Почти любой показатель появляется как попытка ответить на разумный вопрос. Как понять, что все работает эффективно<\/strong>? Смотрим производительность<\/strong>. Как понять, что клиенты довольны? Измеряем NPS. Как понять, что поддержка справляется? Следим за скоростью ответа.<\/p>\n Пока показатель остается инструментом наблюдения, все работает нормально. Но стоит привязать к нему премию, рейтинг или повышенное внимание руководства, и люди начинают оптимизироваться уже не под результат, а под сам показатель.<\/p>\n Хотите увеличить количество закрытых задач — получите дробление задач<\/strong>. Хотите загрузить сотрудников на 100<\/strong>% — получите очереди и постоянные переключения между работой. Хотите улучшить SLA — получите быстрые ответы вместо полезных. Хотите увеличить количество лидов — получите лиды. Правда, это совсем не гарантирует рост продаж.<\/p>\n Самое неприятное, что внешне система выглядит успешной. Графики растут, отчеты становятся красивее, показатели улучшаются. <\/p>\n Наверное, поэтому нужно настороженно относится к управлению исключительно через цифры. Без них нельзя управление на одних ощущениях обычно заканчивается не лучше. Но и считать цифры конечной истиной тоже опасно.<\/p>\n Для разработчика целью является не количество закрытых задач, а создание полезного продукта. Для поддержки не скорость ответа, а решение проблемы клиента. Для бизнеса не количество встреч, звонков или коммерческих предложений, а создание ценности, за которую готовы платить.<\/p>\n Мне нравится аналогия с автомобилем<\/strong>. Показатели<\/strong> это приборная панель. Скорость, обороты двигателя и уровень топлива помогают понимать, что происходит с машиной. Но если водитель начнет считать целью удерживать стрелку спидометра на определенной отметке, поездка может закончиться довольно быстро.<\/p>\n Это ситуация, когда человек понимает, по какому критерию его оценивают, и начинает улучшать именно критерий, а не результат. Причем чаще всего это происходит не из злого умысла. Люди просто адаптируются к системе. Если система считает успехом определенную цифру, то именно эту цифру и начинают улучшать.<\/p>\n Поэтому хороший показатель — это тот, который сложно улучшить без реального улучшения результата. А рядом с любым KPI полезно держать простой вопрос:<\/p>\n «Если этот показатель вырастет в два раза, станет ли клиенту, проекту или бизнесу действительно лучше?»<\/p>\n Если ответ неочевиден, то, возможно, мы измеряем не то.<\/p>\n Забавно, что Чарльз Гудхарт сформулировал свой закон еще в 1975 году. Прошло больше полувека, а большинство управленческих проблем вокруг метрик по-прежнему выглядят одинаково.<\/p>\n Мы все еще пытаемся управлять реальностью через показатели. А реальность все еще оказывается сложнее отчетов.<\/p>\n",
"date_published": "2026-06-04T12:30:28+03:00",
"date_modified": "2026-06-04T12:30:20+03:00",
"tags": [
"Личный опыт и размышления",
"Управление проектами и командами"
],
"image": "https:\/\/alexeyit.ru\/pictures\/gurh.png",
"_date_published_rfc2822": "Thu, 04 Jun 2026 12:30:28 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "146",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/gurh.png"
]
}
},
{
"id": "145",
"url": "https:\/\/alexeyit.ru\/all\/izmeryaem-b2b-saas-odnoy-metrikoy-pochemu-eto-pochti-nevozmozhno\/",
"title": "Измеряем B2B SaaS одной метрикой — почему это почти невозможно",
"content_html": " В какой-то момент и до нас докатилась необходимость начать нормально измерять продукт. Не в формате «ну вроде продажи идут<\/strong>» или «по ощущениям всё неплохо<\/strong>», а цифрами.<\/p>\n Сразу оговорюсь: рассказывать про виды метрик, North Star, retention и прочие правильные термины я не буду. Про это уже написаны сотни статей и сняты тысячи видео людьми куда умнее меня. Расскажу лучше, как это постепенно появляется у нас.<\/p>\n Кажется, мы постепенно переросли стадию подтверждения гипотезы из серии: «О, кто-то действительно готов за это платить деньги»<\/strong>. А это уже немного другой этап. На нем продукт перестает быть просто «интересной штукой» и начинает превращаться в систему, где важно понимать, что именно растет, почему растет и где всё может внезапно начать ломаться.<\/p>\n И тут начинается самое интересное.<\/p>\n Как и многие, вначале хотелось найти какую-то одну волшебную цифру. Посмотрел на неё утром и сразу понял: всё хорошо или пора тушить пожар.<\/p>\n Но это работает плохо. Особенно если сервис в целом должен функционировать автономно. У нас нет классической истории, где пользователь каждый день открывает приложение, тыкает настройки и проводит внутри по три часа. Поэтому DAU, MAU и прочие красивые графики в нашем случае не всегда что-то реально покажут.<\/p>\n Потому что клиент может вообще не заходить в систему неделю и это будет означать не проблему, а наоборот: всё работает стабильно.<\/p>\n В итоге приходит понимание, что смотреть приходится сразу на несколько слоев продукта: И только вместе это начинает давать более-менее честную картину.<\/p>\n Самое очевидное — деньги.<\/p>\n Смотрим, сколько получили и сколько потратили. Пока в расходах считаем рекламу, серверы, телефонию, покупку ПО и прочую инфраструктуру.<\/p>\n А вот разработку и развитие продукта сюда специально не включаем. Потому что это уже скорее инвестиции, а не операционные расходы. Иначе можно случайно прийти к выводу, что продукт убыточен просто потому, что вы активно его развиваете.<\/p>\n Хотя здесь, конечно, у каждого своя логика учета.<\/p>\n Интересный момент: когда начинаешь регулярно смотреть на финансовые показатели, внезапно выясняется, что некоторые «очевидно полезные» вещи пользы почти не дают. А какие-то мелкие доработки, наоборот, влияют на деньги сильнее, чем ожидалось.<\/p>\n Для B2B SaaS технические метрики иногда важнее продуктовых<\/strong>.<\/p>\n Потому что пользователь может простить неидеальный интерфейс. Может простить сложную настройку. Но вот если у него перестала корректно работать автоматизация это уже проблема.<\/p>\n Поэтому хотим начать отслеживать: На практике, думаем, это поможем быстро замечать перекосы на маркетплейсах. Где-то поменялась логика, где-то API начал отвечать через раз, где-то очередной «эксперимент» площадки сломал половину логики.<\/p>\n Раньше такие вещи замечались через поддержку: клиент пишет, что «что-то странное». Сейчас многие проблемы видно еще до обращения клиента. И это, наверное, одна из самых полезных частей всей истории с метриками.<\/p>\n Отдельная история — маркетинговые показатели. Смотрим на CAC, органический трафик, количество лидов<\/strong> и пытаемся всё это сопоставлять с деньгами.<\/p>\n Потому что лиды сами по себе довольно опасная метрика. Их может быть много, но если они плохо конвертируются или быстро отваливаются, ценности в этом немного.<\/p>\n Вообще, чем дальше, тем сильнее появляется ощущение, что почти любая метрика без контекста легко вводит в заблуждение.<\/p>\n Можно радоваться росту регистраций и не замечать, что половина пользователей не доходит до запуска. Можно радоваться росту оборота и не видеть, что вместе с ним растут расходы. Можно смотреть на MRR и не замечать, что support уже начинает задыхаться. Цифры без контекста иногда вредят даже больше, чем их отсутствие.<\/p>\n Из экономических показателей пытаемся следить за: Пока без фанатизма, но хотя бы появляется понимание: В B2B довольно легко получить ситуацию, когда один крупный клиент визуально «рисует» вам отличный месяц. Хотя системного роста при этом может и не быть. Или наоборот: продукт растет очень правильно и устойчиво, но выглядит это скучно и медленно.<\/p>\n Самое забавное, что продукт про автоматизацию, а сами мы аналитику до сих пор собираем почти вручную. Что-то лежит в CRM. Что-то в таблицах. Где-то цифры обновляются автоматически, где-то руками.<\/p>\n И в какой-то момент начинаешь понимать, что следующая задача — это уже не сбор метрик, а сбор метрик о метриках<\/strong>. Потому что когда данных становится много, появляется новая проблема: как не утонуть в них и не начать принимать решения только потому, что график красиво растет вправо вверх.<\/p>\n",
"date_published": "2026-05-20T14:43:03+03:00",
"date_modified": "2026-05-20T14:42:56+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Личный опыт и размышления",
"Репрайсер"
],
"image": "https:\/\/alexeyit.ru\/pictures\/0_ZjYSm_q36J4KChdn.jpg",
"_date_published_rfc2822": "Wed, 20 May 2026 14:43:03 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "145",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/0_ZjYSm_q36J4KChdn.jpg"
]
}
},
{
"id": "144",
"url": "https:\/\/alexeyit.ru\/all\/akcii-na-marketpleysah-kak-formiruetsya-cena-i-pochemu-padaet-ma\/",
"title": "Акции на маркетплейсах: как формируется цена и почему падает маржа",
"content_html": " Ни для кого не секрет, что акции на маркетплейсах — это почти главный инструмент продвижения. Дополнительные плашки на карточке, буст в выдаче, рост трафика — все это напрямую конвертируется в продажи. Вопрос только в том, какой ценой.<\/p>\n В детали типов акций углубляться не будем. Важно другое: в большинство акций можно попасть автоматически, если товар проходит по условиям. Площадка берет медианную цену за последние 1–3 месяца и снижает ее на 10–30%, чтобы сформировать «выгоду» для покупателя. Именно от этой логики дальше строится вся экономика.<\/p>\n Если коротко — усидеть на двух стульях не получится. Нельзя одновременно активно участвовать в акциях и жестко удерживать цену на целевом уровне.<\/p>\n Единственный рабочий вариант — планомерно поднимать медианную цену<\/strong>. Тогда вход в акции будет происходить уже от вашей целевой РРЦ, а не от заниженной базы. Это длинная игра, но других стабильных вариантов нет.<\/p>\n Отдельно добавляет сложности история с «скрытыми» механиками вроде эластичного бустинга. Формально это тоже акция, но через API ее не видно. Для автоматизации это превращается в серую зону, где система не до конца понимает, что происходит с ценой.<\/p>\n Подход у нас одинаковый для всех маркетплейсов. Разница только в нюансах API.<\/p>\n Если работа с акциями выключена, система пытается менять цену напрямую. Если после нескольких итераций итоговая цена на витрине не меняется, появляется сигнал: товар, скорее всего, участвует в акции. В этот момент система перестает «биться в стену» и фиксирует ситуацию. Это по сути ручной режим — вы сами решаете, оставаться в акции или нет.<\/p>\n Если товар оставили в акции, система просто ждет ее окончания. После завершения — автоматически возвращает цену в нужный диапазон. Это безопасный сценарий, но без контроля внутри акции.<\/p>\n Когда включена работа с акциями по API, начинается уже более точная логика. Система получает список активных акций и проверяет каждый товар — с учетом того, что он может участвовать сразу в нескольких.<\/p>\n Дальше все упирается в ограничение маркетплейса: есть максимальная цена в акции, которая рассчитывается от медианной. Выше нее подняться нельзя.<\/p>\n Система считает целевую цену для попадания в РРЦ и сравнивает ее с этим потолком. Если расчетная цена ниже — все просто, мы обновляем цену и остаемся в акции. Но так бывает редко.<\/p>\n Если расчетная цена выше — есть два варианта. Либо мы выходим из акции и возвращаем контроль над ценой, либо остаемся, но ставим максимально допустимую цену внутри акции. Во втором случае мы жертвуем коридором РРЦ, но сохраняем трафик.<\/p>\n Акции — это не просто инструмент роста, это компромисс между объемом продаж и маржой. И чем раньше это принимаешь, тем проще строится стратегия. Хоть мы пока не умеем автоматически возвращать товары в «выгодные» акции — слишком много переменных в расчете, но в ближайшее время будет MVP по этому поводу. <\/p>\n",
"date_published": "2026-05-05T15:46:39+03:00",
"date_modified": "2026-05-05T15:46:36+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Личный опыт и размышления"
],
"image": "https:\/\/alexeyit.ru\/pictures\/sale-1.png",
"_date_published_rfc2822": "Tue, 05 May 2026 15:46:39 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "144",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/sale-1.png"
]
}
},
{
"id": "143",
"url": "https:\/\/alexeyit.ru\/all\/strategii-cenoobrazovaniya-na-marketpleysah-rrc-konkurenty-yunit\/",
"title": "Стратегии ценообразования на маркетплейсах: РРЦ, конкуренты, юнит-экономика и ошибки",
"content_html": " Продолжаем продуктовую историю. С начала года провели много ВКС, показывали продукт, общались с рынком. Были и небольшие магазины с десятками SKU, и производители с ассортиментом в десятки тысяч позиций. Почти в каждом разговоре упирались в один и тот же вопрос: как управлять ценой.<\/span><\/p>\n Разберу основные стратегии, с которыми сталкиваемся на практике.<\/span><\/p>\n Самая базовая история это РРЦ. Некоторая “идеальная” цена, которую хочется удерживать во всех каналах: офлайн, маркетплейсы, сайт, дилеры.<\/span><\/p>\n Как она формируется сейчас не важно. Важно другое. РРЦ это ориентир, а не стратегия.<\/span><\/p>\n Как только появляется реальный рынок, все начинает расходиться. Акции, скидки площадок, серые поставки, давление дилеров. В итоге РРЦ остается на бумаге, а в жизни начинается борьба за фактическую цену продажи.<\/span><\/p>\n Вторая популярная модель это смотреть на конкурентов и повторять за ними. Выбирается одна или несколько карточек и дальше цена двигается вслед за ними.<\/span><\/p>\n На первый взгляд логично. Не выпадаешь из рынка, не проседаешь по заказам. Но проблема в том, что вы не знаете, что происходит у конкурента.<\/span><\/p>\n Он может распродавать остатки, работать в ноль или в минус, завозить товар в серую или просто демпинговать, чтобы выбить других. Да, можно ограничивать диапазон и не падать слишком низко. Но если кто-то целенаправленно идет вниз, эта стратегия все равно проиграет. Вы просто едете следом.<\/span><\/p>\n Третья стратегия это расчет цены через юнитку. Считаем все: себестоимость, логистику, эквайринг, комиссии маркетплейсов, налоги, склад, людей. Добавляем целевую маржу и получаем цену, при которой бизнес зарабатывает.<\/span><\/p>\n Звучит правильно, но есть нюанс. Такая цена не может быть статичной. Она зависит от десятков факторов и должна меняться вместе с ними.<\/span><\/p>\n И здесь начинается сложность. Нужно собрать данные, поддерживать их в актуальном состоянии и правильно учитывать в расчете. Мы сейчас как раз двигаемся в эту сторону и готовим такую модель у себя. Посмотрим, как она поведет себя в реальности.<\/span><\/p>\n Отдельный класс решений это “умные” стратегии вроде роста оборота или маржинальности.<\/span><\/p>\n На бумаге все выглядит убедительно, пока не смотришь внутрь.<\/span><\/p>\n Простой пример. Есть диапазон цены 100–150 рублей. Ставим цель увеличить оборот. Что делает система. Роняет цену до 100, продажи растут. Когда остаток уменьшается, поднимает до 150.<\/span><\/p>\n В отчетах все хорошо. Оборот вырос, метрика выполнена. По факту вы просто продали товар дешевле, чем могли. Такие стратегии отлично оптимизируют цифры, но не всегда оптимизируют бизнес.<\/span><\/p>\n Еще одна идея это динамически менять цену и смотреть на реакцию продаж. Подняли, посмотрели. Опустили, посмотрели. Попробовали найти баланс.<\/span><\/p>\n Проблема в том, что рынок живет не только ценой. Продажи могут вырасти из-за рекламы, сезона, погоды или действий конкурентов. А система в этот момент считает, что это ее заслуга и продолжает двигаться в ту же сторону.<\/span><\/p>\n Если добавить сюда низкую частоту покупок по многим товарам, становится понятно, что делать достоверные выводы сложно.<\/span><\/p>\n Что еще <\/strong><\/p>\n Есть ещё ряд стратегий, которые в классическом ритейле считаются нормой, но на маркетплейсах встречаются заметно реже. Например, ценообразование от канала (channel-based pricing), когда одна и та же позиция стоит по-разному в зависимости от точки продаж, или премиальная модель (value-based pricing), где цена сознательно выше рынка за счёт бренда и позиционирования. В офлайне и D2C это работает, потому что меньше прозрачности и больше контроля над клиентским опытом. На маркетплейсах же всё лежит “на одной полке”, и разница в цене быстро становится проблемой, а не преимуществом.<\/span><\/p>\n Туда же можно отнести стратегии осознанного демпинга (penetration pricing) или, наоборот, удержания цены относительно лидера рынка (price leadership). Формально это разные подходы, но по сути — попытка занять понятную роль: либо самый дешёвый, либо “как у лидера”. В реальности такие модели требуют запаса прочности и дисциплины, иначе быстро уходят либо в минус, либо в постоянную реакцию на чужие действия.<\/span><\/p>\n И, наконец, есть более операционные модели — например, stock-based pricing, когда цена зависит от остатков. Логика здравая: ускоряем оборачиваемость или, наоборот, дорабатываем маржу на дефиците. Но на маркетплейсах это упирается в ограничения площадок, акции, комиссии и ту же РРЦ. В итоге все эти стратегии существуют, но применяются точечно и редко становятся основой — слишком много внешних факторов, которые их ломают.<\/span><\/p>\n Если собрать все вместе, видно простую вещь. У каждой стратегии есть ограничения. РРЦ не выдерживает реальности. Конкуренты непредсказуемы. Юнитка сложна в реализации. “Умные” стратегии дают красивую картинку, но не всегда результат. Эксперименты дают шум. В итоге не существует одной правильной модели. Есть только комбинация подходов и постоянная работа с данными.<\/span><\/p>\n Сейчас у себя мы сфокусировались на следующем уровне. Работа с акциями на маркетплейсах.<\/span><\/p>\n Регулировать цену и выходить из акций, когда это становится невыгодно, мы уже умеем. Следующий шаг понять, в какие акции вообще стоит заходить.<\/span><\/p>\n Потому что участвовать во всех значит терять маржу. Не участвовать значит терять оборот. И вот здесь начинается самая интересная часть, когда цена перестает быть просто числом и становится управленческим решением.<\/span><\/p>\n <\/p>\n",
"date_published": "2026-04-23T14:37:12+03:00",
"date_modified": "2026-04-23T14:54:28+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Личный опыт и размышления"
],
"image": "https:\/\/alexeyit.ru\/pictures\/market-1.png",
"_date_published_rfc2822": "Thu, 23 Apr 2026 14:37:12 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "143",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/market-1.png"
]
}
},
{
"id": "142",
"url": "https:\/\/alexeyit.ru\/all\/menedzher-na-avtopilote-pochemu-my-prinimaem-tysyachi-resheniy-v\/",
"title": "Менеджер на автопилоте: почему мы принимаем тысячи решений в день и не управляем ими",
"content_html": " Слово “менеджер<\/strong>” давно испортилось. Когда-то это был нормальный термин про управление, принятие решений, сейчас чаще что-то из серии “вам удобно говорить?<\/strong>” или просто размытая должность, за которой непонятно, что стоит. Цифровой разнорабочий. Менеджер по продажам, по клиентам, по развитию, по маркетингу — ролей много, но восприятие у слова стало довольно токсичным<\/strong>.<\/p>\n Возможно, это только моё ощущение, но я с этим сталкиваюсь регулярно. У себя мы даже сознательно ушли от части таких формулировок. Менеджер проектов стал руководителем проектов<\/strong>, менеджер по продажам — специалистом клиентского сервиса<\/strong>. Не потому что это кардинально меняет суть работы, а потому что Побег с маркетплейсов<\/h2><\/p>\n
Риски продукта<\/h2><\/p>\n
Вероятность × ущерб<\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/baron.png\")
\n<\/div>\nВыставки в 2026 работают? <\/strong><\/h1><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/IMG_2651.png\")
\n<\/div>\n![\"\"](\"https:\/\/alexeyit.ru\/pictures\/iun.png\")
\n<\/div>\nСвои прокси вместо арендованных<\/h2><\/p>\n
Когда отказоустойчивость перестаёт быть теорией<\/h2><\/p>\n
Что ещё делаем<\/h2><\/p>\n
Новый человек в команде продукта<\/h2><\/p>\n
Когда показатель становится целью<\/h1><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/gurh.png\")
\n<\/div>\nЛомаем метрики<\/h2><\/p>\n
Цифры как цель<\/h2><\/p>\n
Растягивать линейку<\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/0_ZjYSm_q36J4KChdn.jpg\")
\n<\/div>\nОдной метрикой<\/strong><\/h2><\/p>\n
— деньги,
— техническое здоровье,
— поведение клиентов,
— маркетинг,
— стабильность инфраструктуры.<\/p>\nПервое, с чего начали<\/strong><\/h2><\/p>\n
Неважные технические метрики<\/strong><\/h2><\/p>\n
— количеством активных профилей,
— числом товаров под контролем,
— количеством успешных обработок,
— товарами, ушедшими в перерасчет,
— ошибками обработки,<\/p>\nМаркетинг<\/strong><\/h2><\/p>\n
Самая сложная часть<\/strong><\/h2><\/p>\n
MRR, ARPA, CLTV и TCV<\/strong>.<\/p>\n
— сколько реально приносит клиент,
— насколько окупаются привлечение и поддержка,
— как меняется качество клиентской базы,
— где начинается рост, а где просто увеличение нагрузки.<\/p>\nСамая грустная часть<\/strong><\/h2><\/p>\n
Про акции на маркетплейсе и медианную цену <\/strong><\/h3><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/sale-1.png\")
\n<\/div>\nГлавная проблема: цена против трафика<\/strong><\/h3><\/p>\n
Как мы работаем с акциями<\/strong><\/h3><\/p>\n
Что в итоге<\/strong><\/h3><\/p>\n
Стратегии ценообразования, о которых все говорят, и как они ломаются в реальности<\/strong><\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/market-1.png\")
\n<\/div>\nРРЦ как ориентир<\/strong><\/h3><\/p>\n
Следование за конкурентами<\/strong><\/h3><\/p>\n
Юнит-экономика<\/strong><\/h3><\/p>\n
Рост оборота и красивые стратегии<\/strong><\/h3><\/p>\n
Попытка нащупать спрос<\/strong><\/h3><\/p>\n
Что в итоге<\/strong><\/h3><\/p>\n
Куда смотрим дальше<\/strong><\/h3><\/p>\n
Ты менеджер. Просто не осознал этого<\/strong><\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/pilot.png\")
\n<\/div>\n