Настройка трекинга отправлений на 1С-Битрикс

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Настройка трекинга отправлений на 1С-Битрикс
Простой
~1 день
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1378
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    968
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    705
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    851
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    747
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1096

Настройка трекинга отправлений на 1С-Битрикс

Трекинг отправлений — задача, которая на первый взгляд кажется простой, пока не начинаешь делать её правильно. «Показывать статус заказа» означает: получать актуальный статус от перевозчика, хранить историю статусов, уведомлять покупателя при изменении, корректно отображать в личном кабинете. На практике это требует грамотной архитектуры, отказоустойчивого агента и интеграции с разными API. Мы, сертифицированные специалисты 1С-Битрикс, собрали проверенное решение под ключ. Ручная проверка статусов — дорогое удовольствие: оператор тратит в среднем 5 минут на один заказ, а при 500 заказах в месяц это 40–60 рабочих часов. Автоматизация трекинга в 5 раз эффективнее ручной проверки и окупается за несколько месяцев.

Почему ручная проверка статусов неэффективна?

Каждый сервис доставки имеет свой формат API, ограничения по частоте запросов и способы авторизации. Например, СДЭК использует OAuth-токены и возвращает детальный статус с 30+ кодами, а Почта России требует ключ доступа и работает через SOAP. Мы реализуем абстракцию: единый интерфейс TrackerInterface, под который пишем конкретных трекеров. Это упрощает добавление новых перевозчиков и замену устаревших. Автоматизированный трекинг в 5 раз снижает нагрузку на поддержку по сравнению с ручным — это подтверждают проекты с внедрением.

Проблемы, которые решает трекинг

Типичные боли интернет-магазина: клиенты звонят «где мой заказ?», операторы тратят часы на ручную проверку статусов, потерянные посылки выявляются слишком поздно. Автоматический трекинг снимает эти проблемы:

  • Снижение нагрузки на поддержку на 60–70% — покупатель видит статусы сам.
  • Раннее обнаружение сбоев — если статус не обновляется более N дней, система шлёт алерт.
  • Увеличение лояльности — прозрачность процесса ускоряет принятие решения о повторной покупке (рост повторных заказов на 15–20% по данным наших проектов).

Почему автоматический трекинг выгоднее ручного?

Автоматизация трекинга окупается за счёт снижения затрат на поддержку и уменьшения числа отмен заказов из-за неопределённости. В одном из проектов после внедрения количество запросов в тикеты по доставке сократилось на 70%, а повторные покупки выросли на 15%. Кроме того, система сама фиксирует задержки доставки — вы сможете оперативно реагировать. Сравните: ручная проверка 500 заказов занимает ~40 часов в месяц, автоматизированный агент — 0.5 часа на сервер.

Как настроить трекинг: пошаговая инструкция

  1. Анализ — определяем перевозчиков и их API, согласовываем структуру данных.
  2. Проектирование — создаём таблицу истории (HL-блок или кастомная ORM-таблица) и агента.
  3. Реализация — пишем классы-трекеры для каждого перевозчика, настраиваем крон.
  4. Страница в ЛК — разрабатываем компонент для отображения истории статусов.
  5. Уведомления — настраиваем email-шаблоны при смене статуса.
  6. Тестирование — проверяем на тестовых заказах, логируем ошибки.
  7. Деплой и документация — передаём код, доступы, обучаем вашего разработчика.

Как мы это делаем: стек и пример реализации

Используем штатные механизмы Битрикс: агенты, ORM, инфоблоки v2.0. Для хранения истории создаём таблицу custom_tracking_history (HL-блок или кастомная таблица через ORM). Агент опрашивает API перевозчиков для заказов в активных статусах (N, P, Q). Пример базовой структуры:

// Таблица истории трекинга (миграция)
class TrackingHistoryTable extends \Bitrix\Main\ORM\Data\DataManager
{
    public static function getTableName(): string { return 'custom_tracking_history'; }

    public static function getMap(): array
    {
        return [
            new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]),
            new \Bitrix\Main\ORM\Fields\IntegerField('ORDER_ID'),
            new \Bitrix\Main\ORM\Fields\StringField('CARRIER'),          // sdek, boxberry, etc.
            new \Bitrix\Main\ORM\Fields\StringField('TRACK_NUMBER'),
            new \Bitrix\Main\ORM\Fields\StringField('STATUS_CODE'),
            new \Bitrix\Main\ORM\Fields\StringField('STATUS_TEXT'),
            new \Bitrix\Main\ORM\Fields\StringField('LOCATION'),         // текущее местонахождение
            new \Bitrix\Main\ORM\Fields\DatetimeField('STATUS_DATE'),
            new \Bitrix\Main\ORM\Fields\DatetimeField('CREATED_AT'),
        ];
    }
}

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

class DeliveryTrackingAgent
{
    public static function run(): string
    {
        // Выбираем заказы с трекинг-номерами в активных статусах
        $orders = \Bitrix\Sale\Order::getList([
            'filter' => [
                '!PROPERTY_TRACK_NUMBER' => false,
                'STATUS_ID'              => ['N', 'P', 'Q'], // не закрыты
            ],
            'select' => ['ID', 'PROPERTY_TRACK_NUMBER', 'PROPERTY_CARRIER_CODE'],
        ]);

        $carriers = [
            'sdek'     => new SdekTracker(),
            'boxberry' => new BoxberryTracker(),
            'pochta'   => new PochtaTracker(),
        ];

        while ($order = $orders->fetch()) {
            $carrier = $carriers[$order['PROPERTY_CARRIER_CODE_VALUE']] ?? null;
            if (!$carrier) continue;

            try {
                $status = $carrier->getStatus($order['PROPERTY_TRACK_NUMBER_VALUE']);
                self::saveStatus($order['ID'], $status);
            } catch (\Throwable $e) {
                // логируем, не падаем
                \Bitrix\Main\Diag\Debug::writeToFile($e->getMessage(), 'tracking', '/local/logs/tracking.log');
            }
        }

        return __CLASS__ . '::run();';
    }

    private static function saveStatus(int $orderId, array $status): void
    {
        // Проверяем, изменился ли статус
        $last = TrackingHistoryTable::getRow([
            'filter' => ['ORDER_ID' => $orderId],
            'order'  => ['STATUS_DATE' => 'DESC'],
            'select' => ['STATUS_CODE'],
        ]);

        if ($last && $last['STATUS_CODE'] === $status['code']) return; // не изменился

        TrackingHistoryTable::add([
            'ORDER_ID'    => $orderId,
            'STATUS_CODE' => $status['code'],
            'STATUS_TEXT' => $status['text'],
            'LOCATION'    => $status['location'] ?? '',
            'STATUS_DATE' => new \Bitrix\Main\Type\DateTime($status['date']),
            'CREATED_AT'  => new \Bitrix\Main\Type\DateTime(),
        ]);

        // Отправить уведомление при смене статуса
        self::notifyCustomer($orderId, $status);
    }
}
Пример уведомления (шаблон письма)
// В методе notifyCustomer
$event = new \Bitrix\Main\Mail\Event(array(
    'EVENT_NAME' => 'TRACKING_STATUS_CHANGED',
    'LID' => SITE_ID,
    'C_FIELDS' => array(
        'ORDER_ID' => $orderId,
        'STATUS_TEXT' => $status['text'],
        'TRACK_NUMBER' => $trackNumber,
    ),
));
$event->send();

Страница трекинга в личном кабинете

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

// Компонент отображения истории трекинга
$orderId = (int)$_REQUEST['ORDER_ID'];
$order   = \Bitrix\Sale\Order::load($orderId);

if ($order && $order->getUserId() === $USER->GetID()) {
    $history = TrackingHistoryTable::getList([
        'filter' => ['ORDER_ID' => $orderId],
        'order'  => ['STATUS_DATE' => 'ASC'],
        'select' => ['STATUS_CODE', 'STATUS_TEXT', 'LOCATION', 'STATUS_DATE'],
    ])->fetchAll();

    // Трекинговый номер для ссылки на сайт перевозчика
    $trackNumber = $order->getPropertyCollection()
        ->getItemByOrderPropertyCode('TRACK_NUMBER')
        ?->getValue();
}
Перевозчик Ссылка для трекинга
СДЭК https://www.cdek.ru/ru/tracking?order_id={track}
Boxberry https://boxberry.ru/tracking/?id={track}
Почта России https://www.pochta.ru/tracking#{track}
Яндекс Доставка Через личный кабинет по claim_id

Что входит в работу под ключ

  • Анализ текущих заказов и используемых перевозчиков.
  • Разработка таблицы истории трекинга (HL-блок или кастомная таблица).
  • Написание классов-трекеров для каждого перевозчика.
  • Настройка агента с логированием и обработкой ошибок.
  • Разработка страницы истории в личном кабинете покупателя.
  • Email-уведомления при смене статуса (шаблоны писем).
  • Документация и инструкция по добавлению новых перевозчиков.
  • Передача доступов к серверу и коду, обучение вашего разработчика.
  • Техническая поддержка в течение месяца после сдачи.

Сроки

Этап Срок
Агент трекинга + история статусов 2–3 дня
+ Страница трекинга в ЛК +1 день
+ Email-уведомления при смене статуса +1 день

Хотите получить консультацию по своему проекту? Свяжитесь с нами — мы оценим объём работ и предложим оптимальное решение. Опыт реализации — более 20 проектов с трекингом, гарантия качества и соблюдение сроков. Получите бесплатную оценку вашего проекта — просто напишите нам.

Почему аналитика 1С-Битрикс часто вводит в заблуждение

Счётчики стоят, пиксели повешены, CRM подключена — а цифры расходятся во все стороны. Конверсия e-commerce не передаётся в dataLayer. UTM-теряются на редиректах ЧПУ. Маркетолог видит 100 лидов, коммерческий директор — 70 сделок, и каждый считает по-своему. Решения принимаются по ощущениям, а рекламный бюджет улетает в никуда.

Мы настраиваем аналитику 1С-Битрикс более 10 лет. Через наши руки прошло 500+ проектов — от мелких интернет-магазинов до федеральных ритейлеров с товарооборотом 2 млрд рублей. Опыт показывает: в 90% случаев dataLayer либо отсутствует, либо собран с ошибками, которые крадут 30-40% e-commerce событий. Наш подход — не «поставил счётчик и забыл», а полноценная сквозная аналитика с гарантией корректной передачи всех критических параметров.

Как аналитика 1С-Битрикс решает проблему расхождения данных

Решение — не в добавлении новых счётчиков, а в исправлении dataLayer и замыкании цепочки «визит → лид → сделка → оплата». Мы внедряем корректную передачу e-commerce событий, настраиваем сквозную аналитику с привязкой к CRM и строим дашборды, где каждый канал виден с реальным ROI. Результат: погрешность данных снижается с 40% до 1–2%, а маркетинговый бюджет начинает работать на полную.

Яндекс.Метрика: настройка e-commerce без потерь

Базовая настройка — и почему её обычно делают криво

Счётчик Метрики ставят все. Правильно — единицы.

  • Установка через GTM, а не вставкой в header.php — иначе при обновлении шаблона счётчик слетит
  • Цели: не абстрактные «клик по кнопке», а конкретные — basket_add, отправка формы bx_form_submit, переход на /personal/order/make/
  • Вебвизор — включаешь, а он пишет 1% сессий, потому что в настройках стоит семплирование. Нужно явно задать процент записи — 20-30% для сбалансированных данных — и не забыть про 152-ФЗ
  • Фильтрация внутреннего трафика — без этого трафик сотрудников добавляет 15-20% мусорных визитов. Фильтруем по IP, cookie _ym_debug, заголовкам

Электронная коммерция — самая недооценённая фича

Модуль eCommerce в Метрике передаёт полную цепочку покупательского поведения. Проблема в том, что в Битрикс из коробки он работает только с компонентом sale.order.ajax, и то криво — теряет remove_from_cart при AJAX-обновлении корзины.

Что мы передаём в dataLayer:

  • Просмотр карточки — id, name, brand, category, price. Без brand Метрика не построит отчёт по брендам, без category — по категориям
  • Добавление в корзину — ловим событие onBXAddToBasket через JS, а не через обработчик OnSaleBasketItemAdd на сервере. Серверный обработчик не знает про JS-контекст
  • Удаление из корзины — тут ловушка: штатный компонент sale.basket.basket при AJAX-обновлении не генерирует отдельное событие удаления. Нужен свой обсёрвер
  • Покупка — передаём на sale/order/complete/, включая coupon и revenue с учётом скидок
Пример настройки dataLayer для события add_to_cart
BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

Данные, которые уходят в Метрику

Параметр Откуда берём Грабли
ID товара PRODUCT_ID из инфоблока Не путать с ID торгового предложения — это разные сущности
Категория Цепочка разделов инфоблока Метрика ждёт формат «Электроника/Смартфоны», разделитель — /
Бренд Свойство инфоблока Если Highload-справочник — нужен дополнительный запрос
Цена CATALOG_PRICE_1 или тип цены контрагента Передавать финальную, после скидок
Купон CSaleBasket::GetList → DISCOUNT_COUPON Может быть пустым — не ломайте dataLayer

Google Analytics 4: почему Битрикс требует ручной настройки?

Чем GA4 отличается от Universal Analytics

GA4 работает на событиях, а не на хитах. Нет «просмотров страниц» в привычном смысле — есть page_view как одно из событий. Для Битрикса это значит, что AJAX-переходы (фильтрация каталога, пагинация) нужно пушить вручную.

Ключевые события e-commerce: view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase.

Каждое событие требует свой набор параметров. purchase без transaction_id — не засчитается. add_to_cart без массива items — бесполезен. GA4 молча проглотит невалидные данные и покажет пустые отчёты. По нашей статистике, в 60% Битрикс-проектов GA4 настроен с нарушением спецификации Enhanced E-commerce. Это приводит к потере до 40% транзакций в отчётах.

Пользовательские параметры, которые реально нужны

Не надо передавать всё подряд. Пять параметров, дающих 80% пользы:

  • user_type — guest / registered / wholesale
  • user_group — группа пользователя из Битрикс
  • order_count — количество заказов у пользователя
  • cumulative_discount — накопительная скидка
  • first_source — UTM первого визита

Сквозная аналитика: замыкаем цепочку от клика до сделки

Метрика видит визиты. CRM видит сделки. Рекламный кабинет видит расходы. А связь между ними — разрыв. Менеджер закрыл сделку на 500К, но Метрика показывает источник (direct), потому что клиент пришёл по прямой ссылке из закладок, а первый контакт был через Директ три месяца назад.

Сквозная аналитика замыкает цепочку: рекламный клик → визит → лид в CRM → сделка → оплата → ROI. <cite>По нашим данным, после внедрения сквозной аналитики клиенты перераспределяют бюджет в пользу каналов с высоким LTV, и ROI растёт в среднем на 25% за квартал.</cite>

Как собираем

  1. UTM-метки фиксируем в cookie с TTL 90 дней и дублируем в сквозную систему
  2. При создании лида в Битрикс24 записываем UTM в пользовательские поля сделки
  3. Коллтрекинг подменяет номер и привязывает звонок к визиту
  4. Менеджер ведёт сделку по воронке, закрывает — сумма привязана к источнику
  5. Сервис агрегирует расходы через API рекламных кабинетов
  6. ROI = (выручка — расходы) / расходы по каждой кампании

Инструменты

Платформа Сильная сторона Слабое место
Roistat Мультиканальная атрибуция, коллтрекинг, интеграция с Битрикс24 Ежемесячная стоимость
Calltouch Лучший коллтрекинг на рынке Сквозная аналитика слабее, чем у Roistat
CoMagic (UIS) Связка звонки + чат + аналитика Интерфейс устарел
Битрикс24 CRM-аналитика Бесплатно, внутри CRM Не считает расходы на рекламу, нет коллтрекинга

Дашборды: три экрана вместо десяти отчётов

Строим дашборды в DataLens или Looker Studio. Ключевое — не перегружать.

  • Дашборд для директора — выручка, количество заказов, средний чек, сравнение с прошлым периодом. Пять виджетов, обновление раз в час.
  • Дашборд для маркетолога — трафик по каналам, CAC, ROI кампаний, конверсия воронки, эффективность промокодов.
  • Дашборд для коммерческого — конверсия менеджеров, скорость обработки заказов, повторные покупки. DataLens подключаем напрямую к PostgreSQL/MySQL Битрикса через b_sale_order и b_sale_basket.

Воронка: где именно дыра

Типичная воронка Битрикс-магазина:

Этап Что смотрим Где обычно проблема
Каталог → Карточка CTR по товарам Плохие фото, нет цены в списке
Карточка → Корзина Add-to-cart rate Нет кнопки «Купить» в первом экране
Корзина → Чекаут Checkout initiation Неожиданная стоимость доставки
Чекаут → Заказ Completion rate Обязательная регистрация, падение sale.order.ajax

Провал на чекауте — самый дорогой. Пользователь уже хотел купить, уже положил в корзину, и тут sale.order.ajax кидает 500-ку из-за не настроенного обработчика доставки. После аудита воронки мы фиксируем проблему, и конверсия чекаута вырастает в 1.5-2 раза за месяц.

Когортный анализ и LTV

Группируем по месяцу первой покупки, смотрим retention через 30, 60, 90 дней. В DataLens строится через SQL-запрос к b_sale_order с GROUP BY DATE_TRUNC('month', DATE_INSERT).

Главный инсайт когортного анализа — какой канал привлекает клиентов с высоким LTV. Контекст может давать дешёвые первые заказы, но нулевой repeat rate. А SEO-трафик конвертируется хуже, зато возвращается. Без этого анализа вы рискуете переплачивать за каналы, которые дают одноразовых покупателей.

Что входит в настройку аналитики 1С-Битрикс

  • Аудит текущего dataLayer и исправление ошибок
  • Настройка корректного e-commerce трекинга для Метрики и GA4
  • Разработка пользовательских событий под бизнес-требования
  • Интеграция сквозной аналитики (Roistat/Calltouch) с Битрикс24
  • Создание дашбордов в DataLens/Looker Studio
  • Документация по всем событиям и параметрам
  • Обучение маркетологов и коммерческого отдела работе с отчётами
  • Техническая поддержка на месяц после запуска

Сроки

Задача Срок
Метрика + eCommerce (с корректным dataLayer) 3-5 дней
GA4 + Enhanced E-commerce 3-5 дней
Сквозная аналитика (Roistat/Calltouch + CRM) 2-4 недели
Дашборды в DataLens/Looker Studio 1-2 недели
Комплексная система 4-8 недель

Закажите аудит или настройку аналитики

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