Сохранение данных покупателя для повторных заказов

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

Эта статья — о том, как в магазине на 1С-Битрикс правильно и безопасно сохранять данные покупателя, адреса и профили доставки, чтобы повторный заказ оформлялся за пару кликов. Разберём профили покупателя, автоподстановку, повтор заказа из истории, токенизацию карт и требования 152-ФЗ. Если у вас уже есть учётная система, часть этой логики удобно закрывать автоматизацией продаж и склада на 1С.

Почему повторный заказ решает экономику магазина

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

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

Что именно стоит сохранять

«Сохранить данные покупателя» — это не одна сущность, а несколько разных наборов, у каждого своя логика хранения и свои риски.

• Контактные данные. ФИО, телефон, e-mail — основа профиля, подставляется в каждый заказ.
• Адреса доставки. Город, улица, дом, индекс, комментарий курьеру; у активных клиентов их несколько.
• Реквизиты для B2B. Название компании, ИНН, КПП, юридический адрес — для счетов и закрывающих документов.
• Предпочтения. Привычный способ доставки и оплаты, удобный интервал, пункт выдачи.
• История и корзины. Прошлые заказы, отложенные товары, избранное — для повтора и допродаж.

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

Профили покупателя в модуле «Интернет-магазин»

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

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

Автоподстановка данных в оформление заказа

Само по себе хранение профиля бесполезно, если покупатель всё равно заполняет форму заново. Ценность появляется, когда данные автоматически подставляются в оформление. Компонент оформления заказа (sale.order.ajax) умеет брать значения из выбранного профиля и заполнять ими поля по умолчанию.

Хорошо настроенная автоподстановка делает следующее:

1. Определяет профиль по умолчанию. Обычно это последний использованный — с него и начинается оформление.
2. Заполняет свойства заказа. ФИО, телефон, адрес и реквизиты подтягиваются из профиля без участия клиента.
3. Оставляет только выбор. Покупателю нужно подтвердить доставку и оплату, а не вводить данные заново.
4. Позволяет переключиться. Если адрес другой — клиент выбирает второй профиль или правит поля, и это сохраняется на будущее.

Чем короче путь от корзины до кнопки «Оплатить», тем выше конверсия повторных заказов. Именно здесь сохранённые данные превращаются в деньги.

Несколько адресов и профилей доставки

Для активных клиентов один адрес — редкость. Розничный покупатель возит заказы домой и на работу, а оптовик — на разные объекты, склады и филиалы. Поэтому важно хранить несколько адресов и давать удобно выбирать нужный при оформлении.

Реализовать это можно двумя путями: несколько профилей покупателя (по профилю на адрес) или отдельная справочная сущность адресов, связанная с пользователем. Второй вариант гибче для сложных B2B-сценариев: адреса можно выносить в свою таблицу через ORM, помечать основной, хранить контактное лицо и график приёмки на каждом объекте.

• Последний использованный — по умолчанию. Это ускоряет типовой повторный заказ.
• Список для выбора. Остальные адреса доступны в один клик, без повторного ввода.
• Быстрое добавление. Новый адрес добавляется прямо в оформлении и запоминается.
• Связь с логистикой. Для опта к адресу привязывают склад отгрузки и условия доставки.

Повтор заказа из истории

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

Чтобы повтор работал честно, он должен учитывать текущее состояние каталога:

• Актуальная цена. В корзину попадает сегодняшняя цена, а не та, что была в прошлом заказе.
• Наличие. Отсутствующие позиции подсвечиваются, а не добавляются молча.
• Замены. Если товар снят с продажи, стоит предложить аналог.
• Кратность и упаковки. Для опта количество подгоняется под правила заказа.

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

Данные карт и оплата в один клик

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

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

Гость против авторизованного клиента

Ключевая развилка: сохранять данные можно надёжно только у авторизованного пользователя. Для гостя доступны лишь временные механизмы.

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

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

Безопасность и 152-ФЗ

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

1. Согласие и политика. Согласие на обработку ПДн и доступная политика конфиденциальности — обязательны при сборе данных.
2. Хранение в РФ. Персональные данные россиян хранятся на серверах в России.
3. Минимизация. Храните только то, что реально нужно для заказов, и не дольше, чем необходимо.
4. Право на удаление. Пользователь должен иметь возможность удалить свой профиль и данные.
5. Ограничение доступа. К профилям клиентов допускаются только нужные роли в админке, действия логируются.

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

Хранение через D7 и производительность

Когда стандартных профилей не хватает — например, для сложной структуры адресов, объектов доставки или предпочтений — данные выносят в собственные сущности через D7 ORM. Это даёт чистую модель, типизированные поля, связи с пользователем и удобные выборки.

Чтобы хранение не тормозило витрину, придерживаются нескольких принципов:

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

Про правильную работу с ORM и построение таких моделей у нас есть подробный разбор в статье про D7 ORM в Битрикс, а безопасно доставлять такие доработки на боевой сайт помогает CI/CD и деплой.

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

• Хранение номеров карт у себя. Прямой путь к утечке и нарушению PCI DSS. Только токенизация у провайдера.
• Профиль есть, но не подставляется. Данные сохранены, а форма всё равно пустая — эффекта для конверсии нет.
• Один адрес на клиента. Активный покупатель вынужден каждый раз вводить новый адрес заново.
• Сбор данных без согласия и политики. Нарушение 152-ФЗ ещё до первой продажи.
• Открытый доступ к профилям. Любой менеджер видит все ПДн клиентов, действия не логируются.
• Повтор заказа без проверки наличия. В корзину попадают снятые с продажи товары и старые цены.
• Ставка на cookie для гостя. Данные теряются при смене устройства или очистке браузера.

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

1. Профили настроены. Свойства заказа сгруппированы в профили покупателя и корректно сохраняются.
2. Автоподстановка работает. Профиль по умолчанию подставляется в оформление, поля предзаполнены.
3. Несколько адресов. Клиент хранит и выбирает адреса, последний использованный — по умолчанию.
4. Повтор заказа. Кнопка наполняет корзину с учётом актуальных цен и наличия.
5. Оплата токеном. Повторная оплата идёт через токенизацию провайдера, карты у магазина нет.
6. 152-ФЗ закрыт. Согласие, политика, хранение в РФ, минимизация и право на удаление.
7. Доступ ограничен. К профилям допущены только нужные роли, действия логируются.
8. Проверено на реальных клиентах. Прогнан повторный заказ от входа до оплаты на боевых данных.

Вывод

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

При этом всё, что вы храните, — персональные данные, а карты вообще остаются у провайдера. Заложите безопасность и 152-ФЗ сразу, храните данные через аккуратную модель на D7 и синхронизируйте с 1С — и сохранённый профиль станет одним из самых доходных элементов вашего магазина, а не источником рисков.