Как автоматическая регистрация по номеру телефона в 2 раза снижает процент брошенных корзин

Почему покупатель уходит на последнем шаге

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

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

Что на самом деле стоит за «брошенной корзиной»

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

• «Зачем мне пароль, если я покупаю здесь впервые и, может быть, больше не вернусь?»
• «Почему я должен подтверждать email, если хочу просто получить заказ?»
• «Сколько ещё экранов мне предстоит пройти, прежде чем я смогу заплатить?»

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

Одно поле вместо пяти: как это работает технически

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

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

Безопасная реализация на 1С-Битрикс

В 1С-Битрикс не нужно переписывать компонент sale.order.ajax целиком. Достаточно добавить собственный AJAX-обработчик, который работает в паре с отправкой SMS-кода. Логика такая: покупатель вводит номер, сервер нормализует его, проверяет лимиты и отправляет код. Покупатель вводит код. Если код верный и пользователь с таким номером уже есть — он авторизуется. Если пользователя нет — создаётся новый аккаунт с случайным паролем, и заказ привязывается к нему. Пароль покупателю знать не обязательно: он входит по SMS-коду, а позже может задать пароль в личном кабинете, если захочет.

Нормализация телефона

Простейшая очистка от нецифровых символов не решает главной проблемы: один и тот же номер в форматах 8 (999) 123-45-67, +7 999 123 45 67 и 79991234567 создаст трёх разных пользователей. Для магазина это означает разорванную историю покупок и невозможность корректно идентифицировать клиента. Нужна нормализация с учётом страны и формата.

В 1С-Битрикс для этого есть штатные классы ядра — \Bitrix\Main\PhoneNumber\Parser и \Bitrix\Main\PhoneNumber\Formatter.

Парсер принимает сырую строку и возвращает объект номера. Дальше у объекта можно запросить формат E164 — канонический вид +79991234567, который и нужно хранить в базе:

use Bitrix\Main\PhoneNumber\Parser;
use Bitrix\Main\PhoneNumber\Format;

/**
 * Приводит номер телефона к формату E.164 (+79991234567).
 * Возвращает null, если номер невалиден.
 *
 * @param string $raw Сырой номер из формы
 * @return string|null
 */
function normalizePhone(string $raw): ?string
{
    $raw = trim($raw);
    if ($raw === '') {
        return null;
    }

    $parsed = Parser::getInstance()->parse($raw);

    if (!$parsed->isValid()) {
        return null;
    }

    return $parsed->format(Format::E164);
}

Если нужен только E164 без промежуточных проверок, у парсера есть ярлык normalizePhoneNumber(), который делает то же самое одной строкой:

$normalized = Parser::getInstance()->normalizePhoneNumber($_POST['phone'] ?? '');

Но для чекаута лучше использовать полный вариант с isValid(): он отсекает мусор до того, как номер попадёт в базу, и не создаёт пользователя на невалидный ввод. Штатный парсер сам определяет страну по префиксу, а страну по умолчанию берёт из настройки главного модуля phone_number_default_country. Для российского магазина это RU, и номер 8 (999) 123-45-67 корректно превращается в +79991234567 без самописных регулярок.

Серверная логика: три сценария вместо одного

Обработчик не должен принимать решения «на лету» без подтверждения. Для существующего пользователя авторизация происходит только после проверки SMS-кода. Для нового пользователя аккаунт создаётся также только после проверки кода. Это исключает захват чужого аккаунта по одному лишь номеру телефона.

<?php
define('NO_KEEP_STATISTIC', true);
require $_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_before.php';

if (!check_bitrix_sessid()) {
    http_response_code(403);
    echo json_encode(['error' => 'CSRF check failed']);
    exit;
}

$ip = $_SERVER['REMOTE_ADDR'];
$key = 'sms_send_'.$ip;
$count = apcu_fetch($key) ?: 0;
if ($count >= 5) {
    http_response_code(429);
    echo json_encode(['error' => 'Слишком много запросов']);
    exit;
}
apcu_store($key, $count + 1, 600);

$normalized = normalizePhone($_POST['phone'] ?? '');
if (!$normalized) {
    echo json_encode(['error' => 'Некорректный номер']);
    exit;
}

$code = random_int(100000, 999999);
saveSmsCode($normalized, $code); // храните HMAC-хэш кода, а не сам код
sendSms($normalized, 'Код подтверждения: '.$code);

echo json_encode(['success' => true, 'phone' => $normalized]);

После ввода кода второй обработчик проверяет его с ограничением попыток и только затем выполняет авторизацию или создание пользователя. Пароль генерируется криптографически стойким способом, а не через rand().

$password = bin2hex(random_bytes(16));

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

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

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

Соблюдение 152-ФЗ: что обязательно учесть

Регистрация по номеру телефона означает обработку персональных данных. И здесь есть несколько практических моментов, которые нельзя игнорировать.

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

• Разместите отдельный чекбокс «Я согласен на обработку персональных данных» рядом с формой, где вводится номер, и ссылку на политику конфиденциальности.
• Если планируются рекламные рассылки, добавьте второй, отдельный чекбокс — именно на маркетинговые сообщения. Один общий чекбокс «на всё» не соответствует требованиям.
• Обеспечьте хранение и передачу номера по защищённому каналу, ограничьте доступ сотрудников и подрядчиков к данным.
• Не создавайте «фиктивные» email без необходимости. Если аккаунт создаётся автоматически, лучше сгенерировать служебный адрес, но сразу предложить покупателю заполнить профиль и указать реальный email — например, за скидку на следующий заказ или доступ к закрытым акциям. Фиктивный адрес вредит доставляемости писем и портит базу.

Что получает бизнес

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

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

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

Микро-кейс: магазин электроники

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

С чего начать

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

Теги: 1С Битриксsale.order.ajax