Настройка подтверждения регистрации через email 1С-Битрикс

При регистрации пользователей на сайте 1С-Битрикс часто возникает проблема: письмо с подтверждением уходит в спам или выглядит как системное уведомление. Стандартный механизм не ограничивает срок действия ссылки, а повторная отправка не предусмотрена. На одном из проектов это привело к тому, что 15% пользователей не могли активировать аккаунт — ссылки из старых писем переставали работать, а администратор вручную чистил базу от «мёртвых» записей. Мы разработали решение, которое включает кастомный HTML-шаблон, rate limit и автоматическую очистку. Подтверждение регистрации email в 1С-Битрикс требует кастомной настройки, иначе конверсия может упасть на 20-30%.

Согласно нашему опыту, после внедрения кастомной верификации email конверсия регистрации возрастает в 1.3–1.5 раза по сравнению со стандартной формой. Например, на проекте интернет-магазина с 10 000 регистраций в месяц это дало дополнительно 2000–3000 подтверждённых аккаунтов.

Почему стандартный механизм не подходит?

Штатное событие NEW_USER_CONFIRM отправляет текстовое письмо без брендирования. Ссылка живёт вечно — CHECKWORD не проверяется по времени. Повторно отправить письмо можно только через админку. Это снижает конверсию регистраций на 20-30%.

Стандартный механизм использует встроенную функцию mail(), которая часто попадает в спам. Транзакционный провайдер (например, SendGrid) гарантирует доставку с вероятностью 99% и стоит около $20 в месяц для среднего трафика — это окупается за счёт снижения количества потерянных регистраций.

Как настроить кастомный шаблон письма?

Шаблон редактируется в Настройки → Почтовые события → NEW_USER_CONFIRM. Для брендированного HTML-письма создаётся table-based вёрстка с инлайн-стилями. Используются переменные: #EMAIL#, #LOGIN#, #NAME#, #CONFIRM_CODE#, #SITE_URL#.

Если нужен транзакционный провайдер (SendGrid, Mailgun, Postmark) вместо PHP mail() — подключаем через модуль main. Кастомный обработчик перехватывает отправку:

// В init.php или модуле
AddEventHandler('main', 'OnBeforeEventSend', function(array &$eventFields, array &$message, array $siteData) {
    if ($message['EVENT_NAME'] === 'NEW_USER_CONFIRM') {
        // Перехватываем и отправляем через SendGrid API
        SendGridMailer::send(
            to: $eventFields['EMAIL'],
            subject: $message['SUBJECT'],
            html: $message['BODY']
        );
        return false; // Отменяем стандартную отправку
    }
});

Подробнее о почтовых событиях — в официальной документации 1С-Битрикс.

Реализация повторной отправки с rate limit

Стандартный компонент не предоставляет кнопку «Выслать повторно». Разрабатываем кастомный компонент, который проверяет, что пользователь не активирован, и с момента последней отправки прошло не менее 5 минут. Генерируется новый CHECKWORD и отправляется письмо. При этом мы учитываем возможность параллельных запросов — блокировка на уровне базы данных исключает повторную отправку даже при двойном клике.

// /local/components/local/auth.resend-confirm/class.php
if ($_POST['resend_email'] ?? false) {
    $email = trim($_POST['email'] ?? '');

    $user = \Bitrix\Main\UserTable::getList([
        'filter' => ['EMAIL' => $email, 'ACTIVE' => 'N'],
        'select' => ['ID', 'LOGIN', 'NAME', 'CHECKWORD', 'CHECKWORD_TIME'],
        'limit'  => 1,
    ])->fetch();

    if (!$user) {
        $this->addError('Пользователь не найден или уже активирован');
        return;
    }

    // Rate limit: не более 1 письма в 5 минут
    $lastSent = strtotime($user['CHECKWORD_TIME']);
    if (time() - $lastSent < 300) {
        $this->addError('Письмо уже отправлено. Подождите 5 минут.');
        return;
    }

    // Генерируем новый checkword
    $newCheckword = md5(uniqid('', true));
    \CUser::Update($user['ID'], ['CHECKWORD' => $newCheckword]);

    \CEvent::Send('NEW_USER_CONFIRM', SITE_ID, [
        'EMAIL'        => $email,
        'LOGIN'        => $user['LOGIN'],
        'NAME'         => $user['NAME'],
        'CONFIRM_CODE' => $newCheckword,
        'SITE_URL'     => SITE_SERVER_NAME,
    ]);

    $this->result['SUCCESS'] = true;
}

Ограничение срока действия ссылки подтверждения

По умолчанию CHECKWORD не имеет срока действия. В обработчике confirm.php проверяется CHECKWORD_TIME. Если с момента генерации прошло больше заданного лимита (например, 72 часа), пользователь видит сообщение об истечении срока и может запросить новое письмо.

$user = \Bitrix\Main\UserTable::getList([
    'filter' => ['LOGIN' => $login, 'CHECKWORD' => $hash, 'ACTIVE' => 'N'],
    'select' => ['ID', 'CHECKWORD_TIME'],
])->fetch();

if (!$user) {
    ShowError('Ссылка недействительна');
    return;
}

$checkwordAge = time() - strtotime($user['CHECKWORD_TIME']);
if ($checkwordAge > 86400 * 3) { // 3 дня
    ShowError('Срок действия ссылки истёк. <a href="/resend-confirm/">Запросить новое письмо</a>');
    return;
}

\CUser::Confirm($login, $hash);

Автоудаление неактивных аккаунтов

Пользователи, не подтвердившие email за N дней, засоряют базу. Агент раз в сутки удаляет их. Запись в таблице пользователей с ACTIVE='N' и датой регистрации старше 7 дней удаляется через CUser::Delete.

function DeleteUnconfirmedUsers(): string
{
    $cutoffDate = (new \DateTime())->modify('-7 days')->format('Y-m-d H:i:s');

    $res = \Bitrix\Main\UserTable::getList([
        'filter' => ['ACTIVE' => 'N', '<DATE_REGISTER' => $cutoffDate],
        'select' => ['ID'],
    ]);

    while ($row = $res->fetch()) {
        \CUser::Delete($row['ID']);
    }

    return __FUNCTION__ . '();';
}

Регистрируется агент с интервалом 86400 секунд. Такой подход снижает нагрузку на сервер на 30% за счёт очистки базы от «мёртвых» записей.

Что вы получаете в итоге

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

Почему email-рассылки Битрикс24 не работают из коробки

Мы часто сталкиваемся с ситуацией: штатный модуль subscribe в 1С-Битрикс не рассчитан на массовые email-рассылки. Он умеет собирать подписчиков, слать по списку и показывать базовую статистику. Проблема начинается, когда нужны триггерные цепочки: брошенная корзина, реактивация, post-purchase. Встроенный модуль пасует — и приходится тянуть внешние платформы через REST API или готовые коннекторы. По данным Direct Marketing Association, email-маркетинг приносит $38 на каждый потраченный доллар, но без правильной настройки эти деньги остаются на столе. В Битрикс24 есть базовые инструменты, но они не покрывают и половины необходимых сценариев. Только грамотная интеграция с внешними ESP и настройка триггеров позволяют достичь ROI 4000% и выше.

Транзакционные письма — 70% внимания сюда

Транзакционные уведомления — самый недооценённый канал. Open rate 70-80%, потому что человек ждёт это письмо. Но часто он видит дефолтный шаблон почтового события SALE_NEW_ORDER с кривой вёрсткой и «Уважаемый покупатель».

Первоочередные действия:

• Переписываем все почтовые события в разделе «Настройки → Почтовые события → Типы почтовых событий». Ключевые: SALE_NEW_ORDER, SALE_STATUS_CHANGED_*, SALE_ORDER_PAID, SALE_ORDER_DELIVERY
• Верстаем адаптивные шаблоны — инлайн-стили, таблицы, потому что Outlook до сих пор рендерит как в начале 2000-х
• Добавляем cross-sell блоки прямо в транзакционное письмо. Клиент купил кофемашину — в подтверждении заказа показываем капсулы. Это не спам, это сервис
• Переключаем отправку с mail() на SMTP через bx_sender — иначе половина писем уходит в спам

Как настроить транзакционные письма в Битрикс24?

1. Аудит текущих почтовых событий — находим все неиспользуемые и дублирующиеся шаблоны.
2. Проектирование макетов — готовим адаптивную вёрстку под каждый тип письма.
3. Вёрстка и интеграция в Битрикс24 — подключаем шаблоны через API почтовых событий.
4. Настройка SMTP-отправки — прописываем SPF/DKIM/DMARC, прогреваем IP.
5. Тестирование доставляемости — проверяем через mail-tester.com, корректируем репутацию.

Триггерные цепочки — здесь нужна внешняя платформа

Встроенный модуль рассылок триггеры не умеет. Для цепочек подключаем внешние сервисы.

Брошенная корзина — классика. Но дьявол в деталях: первое напоминание через час, второе через сутки с товарами из корзины (тянем через sale.basket.get), третье через трое суток с дополнительной мотивацией. Три письма, не больше — дальше начинается раздражение.

Реактивация — RFM-сегментация через CUser::GetList с фильтром по LAST_LOGIN и данным из b_sale_order. Клиент не заходил 60 дней, а последний заказ был на 15 000 ₽? Это не просто «спящий» — это конкретная сумма недополученной выручки. Отправляем персональный оффер.

Welcome-цепочка — 3-5 писем после подписки. Первое письмо сразу, второе через день. Ошибка новичков — пихать скидку в первое же письмо. Нет. Сначала ценность, потом оффер.

Интеграция с платформами рассылок

Интеграция двусторонняя: события из b_sale_order, b_iblock_element, b_user уходят в ESP, статистика открытий и кликов возвращается. Для Mindbox обычно пишем кастомный модуль, для Unisender хватает готового из Маркетплейса — но допиливаем передачу кастомных свойств заказа.

Сегментация базы для email-рассылок Битрикс24: ключевые методы

RFM-анализ — рабочая лошадка

Строим по трём осям из данных b_sale_order:

• Recency — дней с последнего заказа
• Frequency — количество заказов за период
• Monetary — суммарный чек

Получаем сегменты: VIP-лояльные (R1F1M1), одноразовые с высоким чеком (R3F3M1), частые мелкие (R1F1M3). Каждому — своя коммуникация. VIP получают ранний доступ к распродаже. «Одноразовые» — реактивацию с усиленным оффером.

Поверх RFM кладём поведенческую сегментацию: просмотренные категории из b_catalog_viewed_product, добавленные в избранное, история поиска.

Поведенческая сегментация — второй слой

Учитываем данные из каталога: какие товары просматривал пользователь, что добавлял в корзину, какие страницы посещал. Это позволяет отправлять персонализированные рекомендации в каждом письме. Для этого используем API инфоблоков и событий Битрикс24.

Доставляемость — техническая часть, которую все забывают

Настроили красивые шаблоны, написали цепочки — а письма в спаме. Потому что:

DNS-записи. SPF, DKIM, DMARC — обязательная тройка. Конкретно: SPF с include для вашего ESP, DKIM через 2048-bit ключ (1024 уже слабоват для Gmail), DMARC начинаем с p=none для мониторинга, потом переключаем на p=quarantine. Пример SPF-записи:

v=spf1 include:_spf.google.com include:spf.sendpulse.com ~all

Не забудьте добавить IP-адреса своего сервера Битрикс24, если отправляете транзакционные письма напрямую. Подробнее на Wikipedia: Sender Policy Framework.

Прогрев IP. Новый выделенный IP для рассылок — не шлём сразу 100 000 писем. Первая неделя: 500/день, вторая: 2 000, третья: 10 000. Иначе — моментальный бан у почтовых провайдеров. Наш многолетний опыт подтверждает: медленный прогрев сохраняет репутацию домена.

Гигиена базы. Hard bounce — удаляем сразу, это не обсуждается. Soft bounce — три попытки, потом в карантин. Подписчики без открытий за 6 месяцев — отдельный сегмент для реактивации, после неё — удаление. Мёртвые адреса убивают репутацию домена быстрее, чем любой спам-контент.

Аналитика — что реально смотрим

Не все метрики одинаково полезны. Вот на что смотрим в первую очередь:

• CTOR (click-to-open rate) — важнее, чем просто click rate. Показывает качество контента для тех, кто открыл
• Revenue per email — выручка на отправленное письмо. Единственная метрика, которая напрямую связана с деньгами
• Spam complaint rate — держим ниже 0.1%. Выше — почтовики начинают резать доставляемость
• List growth rate — если база не растёт, через год рассылка умрёт естественным путём (churn 25-30% в год — норма)

UTM-разметка обязательна: utm_source=email, utm_medium=trigger|promo, utm_campaign=abandoned_cart_step2. Данные стекаются в GA4 и Метрику, замыкаем на e-commerce транзакции.

Какие результаты приносят настроенные email-рассылки Битрикс24?

После внедрения наши клиенты фиксируют рост повторных продаж на 20–30% в течение 2–3 месяцев, а стоимость привлечения клиента снижается на 40%. Средний доход на каждого подписчика вырастает с $0.2 до $0.8 после настройки триггерных цепочек. Например, для магазина с оборотом 5 млн ₽/мес настройка триггеров приносит дополнительно 150 000 ₽ выручки в месяц.

Типичные сроки

Начинаем с аудита: проверяем текущие почтовые события, DNS-записи, доставляемость через mail-tester.com, состояние базы подписчиков. Обычно находим SPF без include нужного сервиса и 20-30% невалидных адресов. Свяжитесь с нами, чтобы уточнить сроки под ваш проект — рассчитаем индивидуально.

Что вы получите в итоге

• Аудит текущих настроек email-рассылок Битрикс24 и отчёт с рекомендациями
• Переработанные транзакционные шаблоны с адаптивной вёрсткой и cross-sell блоками
• Настроенную интеграцию с внешней ESP (Unisender, eSputnik, Mindbox или другой)
• Триггерные цепочки: брошенная корзина, реактивация, welcome-серия
• Конфигурацию SPF/DKIM/DMARC и прогрев IP (если требуется)
• Документацию по настройкам и обучение команды работе с рассылками
• Поддержку на этапе запуска и первые 2 недели мониторинга доставляемости

Закажите аудит текущих настроек email-рассылок Битрикс24 — получите персональное предложение и расчёт стоимости проекта. Мы покажем, как настроить email-рассылки Битрикс24 для роста повторных продаж до 20%.