Избранное в интернет-магазине: сохранение, синхронизация и возврат

Как сделать избранное в интернет-магазине: гостевой список, объединение после входа, варианты товара, актуальные цены и остатки, удаление и аналитика.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

Определите, зачем покупатель сохраняет товар

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

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

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

Решите, что именно сохраняется

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

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

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

Гостевое сохранение должно иметь понятные границы

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

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

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

Кнопка должна подтверждать фактическое состояние

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

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

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

Объединение после входа требует явного правила

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

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

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

Синхронизация — это и добавление, и удаление

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

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

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

Каталог меняется после сохранения

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

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

Предложение аналога должно объяснять различия. Другой цвет, объём или размер — не тот же товар. Кнопка «Заменить» требует осознанного действия и обновляет сохранённый объект. В концепте «Отложено» недоступный вариант остаётся виден, а перенос в корзину блокируется до проверки актуального предложения. Данные и цены в макете учебные; реальный каталог и остатки к нему не подключены.

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

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

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

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

Подборки и общий доступ усложняют модель

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

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

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

Сохранение не означает согласие на рассылку

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

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

Управление подпиской должно работать независимо от сохранённой позиции. Удаление товара может отменять уведомление, если это явно заданное правило, но пользователь должен понимать результат. Повторная доставка события каталога не должна дублировать рассылку. Фоновый процесс проверяет актуальность подписки перед отправкой, а в системе остаётся объяснимый статус. Реальная доставка требует отдельной проверки канала, а не только готового текста письма.

Измеряйте путь возвращения, а не только сердечки

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

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

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

Что включить в задачу на разработку

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

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

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

Частые вопросы

Избранное должно работать без регистрации?

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

Что делать с товаром, которого больше нет?

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

Нужно ли удалять товар после добавления в корзину?

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

Гарантирует ли избранное рост конверсии?

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

Источники и пример реализации

Свойства браузерного хранения описаны в справке MDN по localStorage. Семантика обычных и переключаемых кнопок — в шаблоне Button Pattern W3C. Эти источники объясняют отдельные технологии, а правила объединения, каталога и покупательского пути требуют проектирования под магазин.

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

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