Сравнение товаров и избранное в 1С-Битрикс: настройка и польза для конверсии

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

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

Зачем магазину сравнение и избранное

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

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

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

Сравнение и избранное как этапы выбора

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

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

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

Что такое сравнение товаров в 1С-Битрикс

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

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

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

Компонент catalog.compare и его логика

Технически сравнение в 1С-Битрикс отдаёт компонент bitrix:catalog.compare — или, в терминах комплексного каталога, соответствующий режим внутри catalog. Он отвечает за три вещи: принять товар в сравнение, хранить набор добавленных позиций и построить по ним таблицу свойств. Кнопка «Сравнить» на карточке и в списке — это часть шаблонов catalog.element и catalog.section, которая шлёт товар в этот механизм.

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

Несколько практических моментов по компоненту:

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

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

Какие характеристики выводить в сравнении

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

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

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

Полная таблица против «только различия»

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

Оба режима нужны, и вот когда какой полезен:

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

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

Что такое избранное и отложенные

Избранное (в разных магазинах его называют «Избранное», «Отложенные», «Список желаний», wishlist) — это личный список товаров, которые покупатель отметил, чтобы вернуться к ним позже. В отличие от корзины, избранное не подразумевает намерения купить прямо сейчас: это «мне интересно, посмотрю ещё» или «хочу, но не сегодня». Разделять эти два списка важно, потому что у них разная роль в голове покупателя.

Разница между корзиной и избранным принципиальна:

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

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

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

Штатный список отложенных товаров

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

У штатного подхода есть плюсы и ограничения, которые стоит понимать:

• Плюс — переиспользование корзины. Отложенные хранятся тем же модулем, что и корзина, поэтому связка «отложил → перенёс в корзину» работает естественно и надёжно.
• Плюс — привязка к пользователю. Для авторизованного покупателя отложенные сохраняются на стороне сервера и доступны с любого устройства после входа.
• Нюанс — отделить от корзины визуально. Поскольку технически это «отложенная корзина», важно в интерфейсе чётко разделить «в корзине» и «в избранном», чтобы покупатель не путался.
• Нюанс — под богатый вишлист может понадобиться доработка. Если нужны папки списков, публичные ссылки на список желаний или несколько списков — базового механизма мало, и делают отдельное хранилище на пользовательском свойстве или highload.

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

Хранение для гостя: cookie и сессия

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

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

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

Хранение для авторизованного: профиль

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

Что даёт серверное хранение для авторизованного:

• Кроссдевайсность. Отложил с телефона в метро — открыл дома на ноутбуке и купил. Список един на всех устройствах после входа.
• Долговечность. Список не зависит от cookie и живёт столько, сколько существует аккаунт. Покупатель может вернуться через месяц.
• Основа для коммуникаций. Поскольку список привязан к пользователю с контактами и согласиями, на его основе можно строить напоминания и триггерные письма (об этом — в разделе про CRM).
• Личный кабинет. Избранное логично живёт в личном кабинете рядом с историей заказов, повторным заказом и подписками.

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

Перенос гостевого списка при входе

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

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

Практические правила такого переноса:

1. Сливать, а не заменять. Гостевые товары добавляются к уже сохранённым у пользователя, а не затирают их. Дубли схлопываются.
2. Переносить при входе и при регистрации. Оба сценария — и вход существующего, и создание нового аккаунта — должны сохранять гостевой список.
3. Не терять при таймауте. Если сессия успела истечь до входа, восстановить уже нечего — поэтому важен разумный срок жизни гостевого списка.
4. Показать результат. После входа покупателю полезно увидеть, что его список на месте («ваши отложенные сохранены»), — это снимает тревогу.

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

Избранное и возврат покупателя

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

Как избранное работает на возврат:

• Список ждёт при следующем визите. Авторизованный покупатель заходит и видит своё избранное там же, где оставил, — ничего не потеряно, можно продолжить с того же места.
• Блок «Вы откладывали». Ненавязчивое напоминание на главной или в каталоге возвращает внимание к отложенным товарам без давления.
• Личный кабинет как точка возврата. Избранное рядом с историей заказов и повторным заказом делает кабинет местом, куда покупатель заходит осознанно.
• Триггер по событию. Отложенный товар подешевел или заканчивается — при согласии на коммуникации это повод для аккуратного напоминания.

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

«Уведомить о поступлении» и снижении цены рядом

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

Уведомить о поступлении. Если товара нет в наличии, худший исход — покупатель уходит ни с чем. Кнопка «Уведомить о поступлении» ловит его контакт: человек оставляет e-mail, а когда товар появляется, система напоминает ему. В 1С-Битрикс это отдаёт штатный компонент подписки на товар — он собирает подписки и рассылает уведомления при появлении остатка. Это прямая альтернатива потерянному спросу: вместо «нет — до свидания» получается «нет сейчас — напомним, когда будет».

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

Как эти инструменты соотносятся с избранным:

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

Кнопки в карточке товара

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

Как расставить приоритеты на карточке:

• «В корзину» — доминанта. Главная кнопка контрастная и крупная, вокруг неё — воздух. Это центр гравитации блока покупки.
• «В избранное» и «Сравнить» — вторичны. Обычно это иконки (сердечко и «весы»/«диаграмма») рядом с главной кнопкой, визуально тише её. Уместны подписи или подсказки при наведении.
• Понятная обратная связь. После клика иконка меняет состояние (закрашивается, «уже в избранном»), а счётчик в шапке обновляется. Молчание рождает повторные клики и сомнение.
• Повторный клик — удаление. Нажатие на активную иконку убирает товар из списка. Это ожидаемое поведение переключателя.
• Не требовать вход для добавления. Гость должен иметь возможность отложить сразу, а предложение войти («чтобы сохранить список») показывают мягко и после, а не как барьер перед действием.

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

Кнопки в списке каталога

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

Что учесть для кнопок в каталоге:

• Иконка на плитке, не мешающая клику по товару. Сердечко избранного часто ставят в угол карточки товара, но так, чтобы оно не перехватывало основной клик по названию/картинке, ведущий в карточку.
• Добавление без перезагрузки. Клик по «отложить» или «сравнить» отрабатывает через AJAX: товар добавляется, иконка меняется, счётчик растёт — страница не перезагружается, позиция скролла не теряется.
• Сравнение прямо из списка. Кнопка «Сравнить» на плитке позволяет набрать кандидатов, не заходя в каждую карточку. Когда набрано несколько — заметная плашка «Сравнить (3)» ведёт к таблице.
• Единое состояние с карточкой. Если товар отложен из карточки, в списке он тоже должен показываться отложенным, и наоборот. Список один — представлений много.

Технически кнопки в списке — это часть шаблона компонента catalog.section (список товаров раздела), и они шлют товар в те же механизмы сравнения и отложенных, что и карточка. Важно, чтобы каталог при этом не терял в скорости: список кэшируется целиком, а индивидуальное состояние «уже отложено/в сравнении» подмешивается поверх кэша, иначе каждая персональная плитка ломала бы общий кэш. Об этой связке — в разделе про кэш.

Мобильный UX сравнения и избранного

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

Что меняется на мобильном:

• Таблица сравнения не влезает по ширине. Три-четыре товара в столбцах на узком экране не помещаются. Решения: горизонтальная прокрутка с «липким» первым столбцом характеристик, показ двух товаров одновременно или карточный вид «характеристика за характеристикой».
• Режим «только различия» становится критичным. На мобильном сокращение таблицы до значимых строк — не роскошь, а условие того, что сравнением вообще можно пользоваться.
• Крупные зоны нажатия. Иконки избранного и сравнения должны попадать под уверенное нажатие большим пальцем, а не под ноготь; между ними — достаточный отступ, чтобы не промахнуться.
• Избранное и счётчики в шапке. Иконка избранного со счётчиком в мобильной шапке или нижней панели держит список под рукой на любом экране.
• Добавление без ухода со страницы. Отложить товар — одно касание с мгновенной обратной связью, без перезагрузки и без потери позиции в длинном списке.

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

Влияние на конверсию

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

Где именно они работают на конверсию:

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

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

Избранное как сигнал для CRM и рассылок

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

Как использовать избранное в коммуникациях (аккуратно и по согласию):

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

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

Кэш и производительность списков

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

Правильный подход — разделить общее и персональное:

1. Разметку кнопок держат в общем кэше. Сами иконки «Сравнить» и «В избранное» одинаковы для всех и кэшируются вместе со списком.
2. Персональное состояние подмешивают поверх. Что именно уже отложено и значения счётчиков подгружают отдельно — так, чтобы это не ломало общий кэш страницы.
3. Механизмы подмешивания. Обычно это composite-режим (динамические области поверх статичной страницы), отдельный AJAX-запрос состояния/счётчиков после загрузки или небольшой некэшируемый фрагмент. Выбор зависит от нагрузки.
4. Счётчики в шапке — отдельно. Число товаров в сравнении и избранном в шапке обновляют лёгким запросом, а не пересборкой всей страницы.

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

Реализация: компоненты и свойства

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

Порядок внедрения обычно такой. Сначала на уровне свойств каталога отмечают, какие характеристики участвуют в сравнении, и продумывают набор под каждую ветку каталога. Затем в шаблонах catalog.element и catalog.section добавляют (или доводят) кнопки «Сравнить» и «В избранное» с корректной обратной связью и работой без перезагрузки. Дальше настраивают страницу сравнения на catalog.compare с режимом «только различия» и кнопкой «В корзину» из таблицы. Избранное поднимают на механизме отложенных, отдельно продумывая хранение для авторизованного и перенос гостевого списка при входе. Наконец, решают вопрос кэша: персональное состояние выносят поверх общего кэша, а счётчики в шапке обновляют лёгким запросом.

Ключевой принцип реализации — работать шаблонами и настройками, а не переписыванием компонентов. Штатные catalog.compare, механизм отложенных и компонент подписки покрывают основные сценарии; их доводят до продающего вида шаблоном и настройкой свойств. Глубокая доработка нужна только под нестандартные требования (публичные вишлисты, несколько списков, сложная логика уведомлений о цене). Такой подход бережёт обновляемость платформы и не ломает связку каталога с корзиной и оформлением заказа.

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

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

• В сравнение выводят все свойства подряд. Тридцать строк вместо значимых пяти; главное тонет в деталях, режима «только различия» нет.
• Таблица сравнения не читается на мобильном. Широкие столбцы уезжают за экран без горизонтальной прокрутки и «липкого» столбца характеристик.
• Сравнение — тупик. Из таблицы нельзя добавить товар в корзину, и покупатель, выбрав, вынужден искать его заново.
• Избранное смешано с корзиной. «Отложить» кладёт товар в корзину, покупатель путается между «на подумать» и «беру сейчас».
• Гостевой список теряется при входе. Авторизация обнуляет собранное избранное вместо переноса в профиль — покупатель теряет работу.
• Избранное не сохраняется для авторизованного. Список привязан только к cookie, и на другом устройстве человек его не видит.
• Вход требуется для добавления. Гостю не дают отложить товар сразу, барьер авторизации отпугивает на стадии интереса.
• Нет обратной связи по клику. Иконка не меняет состояние, счётчик не обновляется — покупатель жмёт повторно и сомневается, сработало ли.
• Кнопки-приманки размывают фокус. «Сравнить» и «В избранное» такие же яркие, как «В корзину», и растаскивают внимание с покупки.
• Персональное состояние ломает кэш. Состояние «уже отложено» попало в кэшируемый шаблон, каталог замедлился.
• Нет «уведомить о поступлении» на товаре без остатка. Заинтересованный покупатель уходит ни с чем вместо того, чтобы оставить контакт.
• Рассылки по избранному без меры и согласия. Тёплый сигнал превращают в спам, от которого отписываются.

Чек-лист сравнения и избранного

Сведём всё в практический список, по которому удобно принимать готовность инструментов перед запуском или после доработки.

1. Набор свойств для сравнения продуман. В таблицу выводятся только характеристики, влияющие на выбор; решающие — вверху; свой набор под каждую ветку каталога.
2. Есть режим «только различия». Переключатель заметен, скрывает совпадающие строки; на мобильном особенно полезен.
3. Сравнение ведёт к покупке. У каждого товара в таблице — кнопка «В корзину», сравнение не тупик.
4. Таблица адаптивна. На узком экране — горизонтальная прокрутка с «липким» столбцом характеристик или карточный вид.
5. Избранное отделено от корзины. «Отложить» и «В корзину» — разные списки с разной ролью; интерфейс это чётко показывает.
6. Гость может отложить без входа. Добавление доступно сразу, предложение войти — мягкое и после действия.
7. Для авторизованного список сохраняется. Избранное живёт в профиле, доступно с любого устройства, переживает закрытие браузера.
8. Гостевой список переносится при входе. При авторизации и регистрации собранное сливается с постоянным, а не затирается.
9. Обратная связь по клику есть. Иконка меняет состояние, счётчик в шапке обновляется, повторный клик убирает из списка.
10. Кнопки не спорят с «В корзину». Сравнение и избранное вторичны визуально, главная кнопка доминирует.
11. Рядом — «уведомить о поступлении» и снижение цены. На отсутствующем/дорогом товаре ловим контакт вместо потерянного спроса.
12. Кэш не сломан. Персональное состояние подмешивается поверх общего кэша; каталог не замедлился.
13. Мобильный UX проверен на устройстве. Крупные зоны нажатия, добавление без перезагрузки, читаемая таблица — проверено на реальном телефоне.
14. Избранное подключено к CRM/рассылкам по согласию. Список используется как сигнал для уместных, редких напоминаний, а не для спама.

Вывод

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

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