Клиент собрал корзину на телефоне в обеденный перерыв, вечером сел за компьютер — а там пусто. Или закрыл вкладку, вернулся через день, и товары исчезли. Каждый такой случай — это не просто раздражение: это заказ, который почти состоялся, но сорвался на ровном месте. В интернет-магазине на 1С-Битрикс корзина по умолчанию живёт в браузере гостя, и без дополнительной работы она не переживает смену устройства, а иногда и перезапуск браузера.
В этой статье разберём, как надёжно сохранять корзину между сессиями и устройствами на 1С-Битрикс: как устроена корзина модуля «Интернет-магазин», за что отвечает FUSER_ID, как правильно сливать гостевую и клиентскую корзины при входе и как не превратить восстановленную корзину в источник ошибок. Практическую настройку и доработку такой логики мы делаем в рамках услуг по автоматизации на 1С.
Коротко
- Гостевая корзина привязана к FUSER_ID в cookie — на другом устройстве или после потери cookie она «исчезает».
- Кросс-девайс корзина возможна только для авторизованного клиента: она привязывается к пользователю, а не к браузеру.
- При входе гостевую и сохранённую корзины нужно осознанно сливать: решить судьбу дубликатов и количества.
- Восстановленную корзину обязательно валидируйте по наличию и цене, а старые записи чистите по TTL.
Почему корзина «теряется» и что это стоит
«Потеря» корзины почти никогда не означает, что данные физически удалились. Позиции остаются в базе, но пользователь смотрит на магазин под другим идентификатором и своей корзины не видит. С точки зрения бизнеса разница нулевая: клиент считает, что всё пропало, и часто уходит, а не собирает заказ заново.
Цена вопроса выше, чем кажется. Значительная часть заказов оформляется не за один заход: человек добавляет товары, уходит подумать, сравнивает, возвращается. Если между заходами корзина не сохраняется, вы теряете именно «зреющие» заказы — самые прибыльные, где клиент уже определился. Поэтому сохранение корзины относится не к техническим мелочам, а к прямой работе с конверсией.
Как устроена корзина в 1С-Битрикс
В основе лежит модуль «Интернет-магазин» (sale). Содержимое корзины хранится в таблице базы данных (исторически b_sale_basket), где каждая строка — это позиция: товар или торговое предложение, количество, цена на момент добавления, набор свойств. Ключевое поле привязки — FUSER_ID, идентификатор «покупателя» в терминах модуля.
Важно понимать: FUSER_ID — это не то же самое, что USER_ID (идентификатор аккаунта). FUSER_ID существует у любого посетителя, включая анонимного гостя, и именно к нему привязываются позиции корзины. У авторизованного пользователя FUSER_ID стабильно связан с его аккаунтом, у гостя — живёт в cookie. Работа с корзиной в современном коде идёт через объекты D7 (\Bitrix\Sale\Basket, \Bitrix\Sale\Fuser), а не через старые процедурные функции — это надёжнее и предсказуемее. Про переход на объектную модель мы писали в материале про D7 ORM в Битрикс.
FUSER_ID, cookie и время жизни сессии
Для гостя связь «браузер — корзина» держится на cookie. Битрикс кладёт FUSER_ID в cookie (в разных версиях это BITRIX_SM_SALE_UID и связанные значения), и пока cookie жива, гость видит свою корзину. Проблемы начинаются, когда cookie теряется.
- Истёк срок cookie. Если время жизни короткое, через несколько дней гость получает новый FUSER_ID и «пустую» корзину.
- Другое устройство или браузер. Cookie не переносится между телефоном и десктопом — там свой FUSER_ID.
- Приватный режим. В инкогнито cookie не сохраняется после закрытия окна.
- Чистка cookie. Пользователь или расширение удалили cookie — корзина «отвязалась».
Гость против авторизованного клиента
Всё сохранение корзины делится на два принципиально разных сценария, и путать их нельзя.
| Аспект | Гость | Авторизованный клиент |
|---|---|---|
| К чему привязана корзина | FUSER_ID в cookie браузера | FUSER_ID, связанный с аккаунтом |
| Между сессиями | Пока жива cookie | Всегда |
| Между устройствами | Нет | Да |
| Устойчивость | Низкая | Высокая |
| Ценность для маркетинга | Ограниченная | Высокая (известен клиент) |
Вывод простой: по-настоящему надёжное сохранение и кросс-девайс возможны только для авторизованного клиента. Поэтому задача сохранения корзины тесно связана с задачей мягко подтолкнуть гостя к входу или регистрации — именно вход «сшивает» корзину с человеком, а не с браузером.
Слияние корзин при входе в аккаунт
Самый ответственный момент — когда гость авторизуется. У него может быть свежая гостевая корзина в этом браузере и одновременно «старая» корзина, привязанная к аккаунту с прошлого визита на другом устройстве. Их нужно осознанно объединить, а не потерять одну из них.
Битрикс частично сливает корзины сам при входе, но политику слияния почти всегда доопределяют под бизнес:
- Ловим событие входа. Обработчик на OnAfterUserLogin получает управление сразу после авторизации.
- Находим обе корзины. Гостевой FUSER_ID (из cookie) и FUSER_ID пользователя.
- Решаем судьбу дубликатов. Если товар есть в обеих корзинах — суммировать количество, взять большее или оставить свежее гостевое значение.
- Переносим уникальные позиции. Всё, чего нет в клиентской корзине, перепривязываем к пользователю.
- Чистим гостевую. После переноса гостевые записи удаляем, чтобы не плодить дубли.
Ошибка на этом шаге дорого стоит: неверное слияние либо теряет часть товаров, либо задваивает количество. Логику стоит покрыть автотестами и обкатать на реальных сценариях. Такую доработку событий и бизнес-логики модуля продаж мы выполняем в рамках автоматизации продаж и склада на 1С.
Кросс-девайс: одна корзина на всех устройствах
Кросс-девайс корзина — это то, ради чего всё затевается: клиент начал на телефоне, продолжил на компьютере и не потерял ни одной позиции. Технически это следствие правильной работы с авторизацией: как только пользователь вошёл под своим аккаунтом на любом устройстве, он видит корзину, привязанную к его FUSER_ID, а не к конкретному браузеру.
Практические нюансы, которые делают кросс-девайс приятным:
- Быстрый вход. Чем проще авторизоваться (по телефону, соцсети, коду), тем чаще гость превращается в клиента с сохранённой корзиной.
- Ненавязчивое напоминание. Если гость собрал корзину, мягко предложить войти, чтобы «сохранить и продолжить с любого устройства».
- Синхронизация мини-корзины. Счётчик и содержимое в шапке должны обновляться персонально на каждом устройстве.
Валидация позиций при восстановлении
Восстановить корзину — не значит просто показать старые строки. Между заходами мир изменился: товар мог закончиться, подорожать, стать неактивным, а торговое предложение — исчезнуть. Показывать такую корзину «как есть» опасно: клиент оформит заказ на неактуальных условиях, а потом получит расхождение.
Поэтому при показе сохранённой корзины каждую позицию перепроверяют:
- Наличие. Товар есть на складе и активен? Если нет — пометить и предложить аналог.
- Цена. Актуальная цена совпадает с зафиксированной? Если изменилась — показать это явно.
- Доступность предложения. Выбранный вариант (размер, цвет) ещё существует.
- Права клиента. Для B2B — доступен ли товар и цена его группе.
Битрикс умеет помечать недоступные позиции стандартными средствами, но именно UX-часть — как честно и мягко сообщить клиенту об изменениях — стоит продумать. Молчаливое удаление позиции из восстановленной корзины разрушает доверие сильнее, чем честное «этот товар закончился».
TTL, чистка и рост базы
Обратная сторона сохранения корзин — они копятся. По умолчанию Битрикс не удаляет незаказанные позиции, и за годы работы таблица корзины может разрастись до миллионов строк, замедляя запросы. Нужна политика TTL и регулярная чистка.
| Тип корзины | Рекомендуемый TTL | Чем чистить |
|---|---|---|
| Гостевая, брошенная | 30–90 дней | Агент или cron-скрипт |
| Клиентская, брошенная | 90–180 дней | Cron с выгрузкой в CRM перед удалением |
| Оформленные (в заказе) | Не трогать | Хранятся как история заказа |
Чистку выносят в фоновую задачу — штатный агент Битрикса или отдельный cron-скрипт. Cron надёжнее агентов, которые в Битриксе запускаются «на хите» и могут не отработать при низком трафике. Как правильно организовать фоновые задачи и не завязывать их на посетителей, мы разбираем в контексте инфраструктуры и BitrixVM.
Корзина и композитный сайт
Композитный сайт кэширует HTML страниц и отдаёт статику мгновенно — но корзина у каждого своя, и её нельзя запекать в общий кэш. Иначе один посетитель увидит товары другого. Поэтому мини-корзину в шапке и блок корзины выносят в динамическую область.
На практике это значит: статический каркас страницы отдаётся из кэша, а персональные блоки (счётчик корзины, её содержимое, цена клиента) догружаются отдельным AJAX-запросом или через механизм динамических областей композита. Так вы сохраняете и скорость композитного сайта, и корректную персональную корзину. Само хранилище корзины при этом на сервере, поэтому кэш страниц ей не угрожает — угрожает только неправильная попытка закэшировать персональный блок.
Реализация пошагово
Сборка надёжного сохранения корзины на 1С-Битрикс складывается из понятной последовательности. Конкретные названия настроек зависят от редакции, но логика такая:
- Продлите cookie покупателя. Увеличьте срок жизни идентификатора FUSER_ID, чтобы корзина переживала перерывы в одном браузере.
- Работайте через D7. Операции с корзиной ведите через \Bitrix\Sale\Basket и \Bitrix\Sale\Fuser, а не устаревшие процедурные функции.
- Опишите слияние на входе. Обработчик OnAfterUserLogin объединяет гостевую и клиентскую корзины по вашей политике дубликатов.
- Добавьте валидацию при показе. Наличие, цена, доступность предложения и прав группы проверяются при каждом восстановлении.
- Вынесите корзину из кэша. Мини-корзина и блок корзины — динамические области композита или AJAX.
- Настройте TTL и чистку. Cron-скрипт удаляет старые брошенные корзины, при необходимости выгружая их в CRM.
- Проверьте кросс-девайс. Соберите корзину гостем на телефоне, войдите, откройте на десктопе — позиции на месте и слиты корректно.
Брошенные корзины и триггерные письма
Сохранённая корзина — это ещё и топливо для маркетинга. Брошенные корзины авторизованных клиентов можно передавать в CRM или систему рассылок и запускать триггерные письма «вы забыли товар». Это один из самых окупаемых сценариев работы с корзиной.
Чтобы это работало корректно, передачу данных о корзине делают через защищённый механизм — обычно REST-обмен или вебхуки в CRM. Здесь важна безопасность: данные клиента и содержимое корзины не должны утекать наружу. Как правильно защищать такие интеграции, мы разбираем в статье про REST, вебхуки и безопасность в Битрикс. А если под задачу нужен собственный компонент или модуль, полезен материал про разработку модуля Битрикс.
Частые ошибки
- Короткая cookie. Идентификатор покупателя живёт часы — корзина теряется даже в одном браузере.
- Нет слияния при входе. Гость авторизуется и теряет либо свежую, либо старую корзину.
- Слияние задваивает количество. Дубликаты складываются неверно, и клиент видит удвоенные позиции.
- Показ без валидации. В корзине висит товар, которого нет в наличии или он подорожал, — заказ оформляется на неактуальных условиях.
- Мини-корзина в кэше. Персональный блок закэширован статически, посетитель видит чужие товары.
- Нет чистки. Таблица корзины разрастается на миллионы строк и тормозит магазин.
- Ставка на localStorage. Корзину «сохраняют» только в браузере — кросс-девайс и серверная валидация не работают.
Чек-лист внедрения
- Срок cookie продлён. FUSER_ID гостя живёт недели, а не часы.
- Код на D7. Корзина обрабатывается через объектную модель Sale.
- Слияние настроено. OnAfterUserLogin объединяет корзины по описанной политике дубликатов.
- Валидация включена. При показе проверяются наличие, цена, предложение и права группы.
- Кросс-девайс проверен. Одна корзина видна на телефоне и десктопе после входа.
- Композит настроен. Мини-корзина вынесена в динамику, статика отдаётся из кэша.
- TTL и чистка работают. Cron удаляет старые брошенные корзины, ценные — выгружаются в CRM.
- Триггеры подключены. Брошенные корзины уходят в рассылки через защищённый обмен.
Вывод
Сохранение корзины между сессиями и устройствами — это не одна галочка, а связка решений: продлённая cookie для гостя, привязка к аккаунту для кросс-девайса, аккуратное слияние при входе, честная валидация восстановленных позиций и дисциплина чистки. Каждый из этих элементов закрывает свою утечку конверсии, а вместе они превращают корзину в надёжный инструмент, а не в источник разочарований.
На 1С-Битрикс всё это реализуется штатными средствами модуля «Интернет-магазин» плюс небольшой обвязкой на D7 и событиях. Начните с продления cookie и корректного слияния при входе — это даст самый быстрый эффект, — а затем добейте кросс-девайс, валидацию и чистку. В результате «зреющие» заказы перестанут срываться на пустой корзине, а клиенты смогут спокойно возвращаться к покупкам с любого устройства.
