Разработка под e-commerce *

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

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

Сразу обозначу рамки. Это не статья про то, как увеличить маркетинговый бюджет, переделать витрину или заняться дисраптом. Здесь ровно один фокус: может ли AI‑агент улучшить ключевые метрики: конверсию, средний чек и удержание, в классическом fashion e‑commerce.

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

Часто дизайнеры и разработчики живут в разных вселенных. Одни думают о пикселях и user flows, другие — о latency & database queries. Но именно на стыке этих дисциплин рождаются самые эффективные и надёжные продукты. Давайте посмотрим, как ваши дизайн-решения могут стать первым и самым важным рубежом обороны для бэкенда.

Зачем это обывателю?

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

ну и на случай если упадет интернет как например у нас было в Испании когда все электричество пропало, хорошо бы иметь умного ИИ с которым можно будет пообщаться)

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

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

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

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

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

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

Но не спешите отчаиваться. Работа всё ещё есть, а вот правила игры изменились. Давайте вместе разбираться, что сделать, чтобы всё-таки найти работу и построить карьеру в ИТ.

Высококонкурентный рынок в e-commerce не прощает ͏ошибок. 89% клиентов готовы поменять сервис после одного негативного опыта в сервисе. При этом, привлечение нового͏ стоит бизнесу до 25 раз дороже, чем удержание текущего. Поэто͏му важность ка͏чества ͏сервиса становится н͏е вспомогательной, а важнейшей функцией, ͏которая вл͏ияет на ͏удержан͏ие, прибыль и͏ репутацию бренда.

Аналитик студии комплексной разработки цифровых решений CleverPumpkin Алёна Сорокина и эксперты «Сантехника-Онлайн», METRO и Gulliver Group разбирают какие инструменты клиентской поддержки помогают e-commerce продуктам расти и удерживать клиентов.

15 декабря в МГТУ им. Н.Э. Баумана (в питчинг-формате) прошел финальный Демо-день акселерационных программ «Умный город» и «Робототехника и беспилотные авиационные системы» (БАС). В течение трех месяцев студенческие команды под руководством опытных наставников последовательно работали над своими проектами. На мероприятии в МГТУ они представляли свои разработки бизнес-сообществу, инвестиционным фондам, институтам развития и другим заинтересованным сторонам, которые способствуют укреплению технологического суверенитета.

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

Всем привет. Я уже примерно 3 года занимаюсь ведением рекламы на маркетплейсах, в частности ВБ, и поскольку люблю все автоматизировать - разработкой и поддержкой инструмента для управления рекламными кампаниями и аналитикой через публичный API Wildberries.

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

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

Постараюсь описывать проблемы WB API не с позиции «пользователя, которому не понравилось», а с точки зрения интегратора, который отвечает за стабильную работу рекламы для нескольких клиентов с миллионными оборотами. Я сознательно опускаю детали реализации и не привожу конкретные ID кампаний и запросы, но описываю поведение, воспроизводимое на сотнях кампаний нескольких клиентов.

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

~300 строк кода.

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

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

Привет, на связи Ксюша, миддл-разработчик Surf. Миддлом я стала недавно. Когда я пришла в компанию, я, конечно, знала, что такое Git. Ну, по крайне мере, я так говорила. 

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

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

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

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

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

Давайте кратко разберем схему работы какого-то нашего приложения с официальным LLM-клиентом (например, OpenAI) + MCP:

Вы когда-нибудь пробовали найти на схеме зала, где могут сесть люди с особенностями передвижения, слабовидящие или, скажем, те, кому важно быть ближе к выходу? 

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

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

Привет, Хабр! Меня зовут Юля Анпилогова, я менеджер команды индивидуальных интеграций CDEK. Мы стали первыми, кто не только запустил интеграцию с Wildberries по схеме DBS (delivery by seller — доставка силами продавца), но и создал единую точку подключения к маркетплейсам WB и Ozon. Этот опыт оказался похож на квест. Курьеры, не привыкшие спрашивать код, лимиты запросов API Wildberries и покупательница Елена, заказавшая тестовый ежедневник — всё это оказалось его частью. Сегодня в статье расскажу, как мы прошли этот путь.

Сегодня на рынке B2B/B2C‑платформ в России конкурируют два подхода. Яркие представители этих подходов, Compo B2B Platform, созданная по принципам headless‑commerce, ориентирована на модульность и микросервисный подход. С другой стороны — 1С‑Битрикс Enterprise, один из самых распространённых в России корпоративных продуктов для веб‑разработки, выросший из CMS‑системы и ставший полноценной платформой для e‑commerce и корпоративных порталов.

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

Привет! Меня зовут Екатерина Морозова и я менеджер продукта «Спортивный помощник». В этой статье я расскажу, как работает наш чат-бот и как мы подняли процент закрытия чатов ботом до более, чем 80%.

Все говорят LLM, а я скажу NLU. А может ли бот без LLM обеспечить высокий процент автоматизации? Да, но…

Путь Спортивного помощника начался в далеком 2022 году. О генеративных моделях тогда было мало известно, и мы стояли перед выбором решения для автоматизации обработки вопросов клиентов в службу поддержки. Кнопочные боты показывали низкую эффективность, поэтому выбор был очевиден - использовать технологии распознавания естественного языка (NLU - Natural-language understanding) для определения намерения клиента.

Пять лет назад мы запустили интернет-магазин на Nuxt 2. За это время он превратился в классический монолит: вносить правки стало дорого, а сайт начал «задыхаться» под нагрузкой. Когда вышел Nuxt 3, перед нами встал выбор: пытаться оживить проект через Nuxt Bridge или переписать всё с нуля.

Мы проанализировали код и поняли: плавная миграция для нас — это путь к созданию «зомби-проекта». Слишком много фундаментальных отличий: Options API против Composition API, Vuex против Pinia, смена логики роутинга и несовместимость ключевых библиотек.

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

Внутри кейса:
• 4 технических «фаталити», которые делают миграцию легаси-монолита невозможной.
• Архитектура FSD + Nuxt 3: как мы подружили фронтенд с бэкендом на Symfony и навели порядок в зависимостях.
• Паттерн «Фабрика»: как упростить сложную логику доставки в Composition API.
• Бонус: почему благодаря правильному старту недавнее обновление с Nuxt 3 до Nuxt 4 заняло у нас минимум времени, в отличие от мучений с Nuxt 2.

Если вы всё еще поддерживаете проекты на второй версии и боитесь подступиться к обновлению — этот опыт для вас.