Wishlist и избранное: стоит ли вкладываться в разработку

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

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

Что такое wishlist и зачем он покупателю

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

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

Три роли избранного

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

Что уже умеет 1С-Битрикс из коробки

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

Этого достаточно для минимального сценария «сохранить и вернуться вручную». Но у штатного механизма есть потолок:

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

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

Избранное, сравнение и корзина — не путать

Частая ошибка ТЗ — свалить в один компонент три разных сценария. У избранного, сравнения и корзины разные задачи и разная логика хранения.

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

Когда избранное реально повышает конверсию

Избранное работает не везде одинаково. Его ценность прямо зависит от того, как покупают в вашей нише. Оно даёт эффект там, где решение о покупке растянуто во времени.

• Длинный цикл выбора. Мебель, техника, оборудование, дорогая одежда — товар редко берут в первый визит.
• Высокая доля возвратных визитов. Если люди возвращаются на сайт по несколько раз перед покупкой, им нужна «память».
• Заметные колебания цены. Там, где бывают акции и скидки, уведомление о снижении цены реально возвращает покупателя.
• Дефицитные позиции. Если товар часто уходит в «нет в наличии», уведомление о возврате — сильный триггер.

В этих сценариях wishlist перестаёт быть закладками и становится каналом возврата — по сути, вашей собственной, бесплатной альтернативой ретаргетингу. Именно поэтому решать про избранное надо на данных о поведении, а не по принципу «у конкурента есть».

Когда это пустая трата бюджета

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

• Товар импульсный и дешёвый. Расходники, мелочи, FMCG берут в один визит — откладывать нечего.
• Мало повторного трафика. Если почти весь трафик разовый, некому получать уведомления и возвращаться.
• Нет ресурса на рассылки. Уведомления о цене и наличии некому настроить и вести — механика простаивает.
• Проблемы важнее. Медленная корзина или кривой мобильный чекаут крадут выручку прямо сейчас — их и надо чинить.

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

Гость или авторизация: где хранить список

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

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

1. Гость добавляет свободно. Список хранится в куках или локальном хранилище браузера, без барьера регистрации.
2. При авторизации — слияние. Накопленный гостевой список бесшовно переносится в профиль и больше не теряется.
3. Синхронизация между устройствами. Авторизованный список одинаков на телефоне и на компьютере.
4. Мягкое приглашение войти. «Войдите, чтобы сохранить избранное» — как выгода, а не как барьер на входе.

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

Уведомления о цене и наличии

Здесь и начинается та часть, за которую действительно стоит платить. Список без уведомлений — пассивная полка, о которой покупатель забудет. Список с уведомлениями — рабочий канал возврата.

Технически это фоновая проверка: агент или очередь заданий в 1С-Битрикс периодически сравнивает текущую цену и остаток товаров из избранного с зафиксированными значениями. При снижении цены или возврате в наличие срабатывает триггер и уходит письмо или пуш. Цены и остатки при этом обновляются обменом с учётной системой — качество уведомлений напрямую зависит от качества этого обмена.

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

Чтобы уведомления работали надёжно на потоке, их выносят в очередь и фоновую обработку. Как строить фоновые задачи и очереди на 1С-Битрикс без просадки сайта, мы разбираем в материале про D7 ORM в 1С-Битрикс, а сами такие сценарии закрываем услугой автоматизации на 1С.

Избранное в B2B: сохранённые списки заказа

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

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

Производительность на большом каталоге

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

• Не дёргайте базу в основном запросе. Состояние избранного для каждого товара нельзя тянуть внутри запроса каталога — это убьёт скорость на больших списках.
• Отдельный AJAX для состояния. Подсветку «в избранном» подгружайте отдельным лёгким запросом после отрисовки каталога.
• Кэшируйте счётчик. Число товаров в избранном в шапке кэшируется, а не считается на каждый чих.
• Дружите с композитным сайтом. Каталог отдаётся из кэша, а личное состояние избранного догружается поверх — как динамический блок.

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

Как оценить окупаемость до разработки

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

1. Посмотрите долю возвратных визитов. Много возвратов перед покупкой — избранное почти наверняка полезно.
2. Оцените длину цикла выбора. Дни и недели между первым визитом и покупкой — сигнал в пользу списка.
3. Проверьте частоту скидок и дефицита. Есть чем триггерить уведомления — значит, есть отдача.
4. Начните с MVP. Штатное избранное плюс простое уведомление о цене — минимальная версия.
5. Измерьте A/B-тестом. Сравните конверсию и возвраты с включённым и выключенным списком.
6. Масштабируйте по результату. Растите механику только там, где цифры подтвердили эффект.

Реализация в 1С-Битрикс пошагово

Если решение принято, сборка полноценного избранного на 1С-Битрикс идёт по понятной последовательности. Названия пунктов зависят от редакции, но логика такая:

1. Включите штатное избранное. Активируйте компонент отложенных товаров и кнопку в карточке и каталоге.
2. Заведите хранение гостя. Настройте список в куках или локальном хранилище для неавторизованных.
3. Сделайте слияние при входе. Гостевой список переносится в профиль при авторизации без потерь.
4. Добавьте фиксацию цены и остатка. При добавлении товара сохраняйте текущую цену и наличие для сравнения.
5. Настройте агент проверки. Фоновая задача сравнивает текущие значения с зафиксированными и триггерит уведомления.
6. Подключите рассылку и CRM. Сегменты по избранному и триггерные письма о цене и наличии.
7. Оптимизируйте каталог. Состояние избранного — отдельным AJAX, счётчик кэшируется.
8. Настройте аналитику. Отслеживайте добавления и путь «избранное → покупка», чтобы измерять эффект.

Уведомления, слияние списков и связка с CRM — это уже не «кнопка», а полноценная логика на стороне сервера. Такие вещи мы реализуем в рамках автоматизации на 1С, чтобы фоновые проверки и рассылки работали надёжно и не тормозили сайт.

Частые ошибки

• Делают избранное «потому что модно». Без анализа цикла выбора и возвратов список простаивает и не окупается.
• Смешивают со сравнением. Один компонент на два сценария ломает оба.
• Требуют регистрацию на входе. Барьер убивает добавления — гостю нужно разрешить сразу.
• Теряют гостевой список. Нет слияния при авторизации — покупатель заходит и не находит отложенное.
• Список без уведомлений. Пассивная полка без писем о цене и наличии не возвращает покупателя.
• Тянут состояние в запросе каталога. Подсветка «в избранном» в основном запросе роняет скорость на больших списках.
• Не меряют эффект. Механику наращивают без A/B-теста и потом не знают, работает ли она.

Чек-лист внедрения

1. Окупаемость проверена. Есть длинный цикл выбора и возвратный трафик по данным аналитики.
2. Сценарии разделены. Избранное, сравнение и корзина — три разных компонента.
3. Гость не заблокирован. Добавление доступно без регистрации, список сливается при входе.
4. Уведомления настроены. Работают триггеры на снижение цены и возврат в наличие.
5. Обмен корректен. Цены и остатки для уведомлений приходят обменом стабильно.
6. Каталог не просел. Состояние избранного грузится отдельным AJAX, счётчик кэширован.
7. B2B-форма учтена. Для опта есть сохранённые списки заказа с количеством и кратностью.
8. Эффект измеряется. Настроена аналитика пути «избранное → покупка» и запущен A/B-тест.

Вывод

Вопрос «стоит ли вкладываться в wishlist» не имеет универсального ответа — и в этом вся суть. Сам список избранного в 1С-Битрикс почти бесплатен: он есть в базовом функционале. Платить имеет смысл за то, чего в нём нет и что превращает закладки в канал продаж: уведомления о цене и наличии, синхронизацию между устройствами, связку с CRM и аналитику.

Эта надстройка окупается там, где покупатель думает перед покупкой днями и возвращается на сайт, — и почти не окупается на импульсных дешёвых товарах. Поэтому решайте на данных: посмотрите цикл выбора и возвраты, соберите дешёвый MVP, измерьте эффект A/B-тестом и наращивайте механику только там, где цифры её оправдали. Так избранное станет не украшением, а рабочим инструментом возврата покупателей.