Налаштування трекінгу відправлень на 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();
}

Що входить в роботу під ключ

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

Строки

Бажаєте отримати консультацію по своєму проєкту? Напишіть нам — ми оцінимо обсяг робіт і запропонуємо оптимальне рішення. Досвід реалізації — понад 20 проєктів з трекінгом, гарантія якості та дотримання термінів. Отримайте безкоштовну оцінку вашого проєкту — просто напишіть нам.

Чому аналітика 1С-Бітрікс часто вводить в оману?

Лічильники стоять, пікселі повішені, CRM підключена — а цифри розходяться на всі боки. Конверсія e-commerce не передається в dataLayer. UTM-мітки втрачаються на редиректах ЧПУ. Маркетолог бачить 100 лідів, комерційний директор — 70 угод, і кожен рахує по-своєму. Рішення приймаються на відчуттях, а рекламний бюджет летить у нікуди — за нашими даними, втрати через некоректну аналітику сягають 30–40% бюджету. Для магазина з витратами на рекламу 100 000 грн на місяць це 30–40 тис. грн щомісячних втрат.

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

Як аналітика 1С-Бітрікс вирішує проблему розбіжності даних?

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

Як виправити e-commerce трекінг у Яндекс.Метриці та GA4?

Базове налаштування — і чому його зазвичай роблять криво

• Встановлення через 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
            }]
        }
    });
});

Чому GA4 на Бітрікс вимагає ручного налаштування?

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% транзакцій у звітах.

Користувацькі параметри, які реально потрібні:

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

Що дає наскрізна аналітика на Бітрікс?

Метрика бачить візити. CRM бачить угоди. Рекламний кабінет бачить витрати. А зв'язок між ними — розрив. Менеджер закрив велику угоду, але Метрика показує джерело (direct), тому що клієнт прийшов за прямим посиланням із закладок, а перший контакт був через Директ три місяці тому.

Наскрізна аналітика замикає ланцюжок: рекламний клік → візит → лід в CRM → угода → оплата → ROI. Після впровадження клієнти перерозподіляють бюджет на користь каналів з високим LTV, і ROI зростає в середньому на 25% за квартал. Roistat показує на 40% точнішу атрибуцію порівняно з Calltouch за нашими тестами на великих проектах.

Як збираємо

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

Дашборди та воронка: де шукати діри

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

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

Провал на чекауті — найнайдорожчий. Користувач уже хотів купити, вже поклав у кошик, і тут 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-трафік конвертується гірше, зате повертається. Без цього аналізу ви ризикуєте переплачувати за канали, які дають одноразових покупців.

Терміни та вартість налаштування аналітики

Що входить в налаштування: аудит поточного dataLayer та виправлення помилок; налаштування коректного e-commerce трекінгу для Метрики та GA4; розробка користувацьких подій під бізнес-вимоги; інтеграція наскрізної аналітики (Roistat/Calltouch) з Бітрікс24; створення дашбордів в DataLens/Looker Studio; документація по всіх подіях та параметрах; навчання маркетологів та комерційного відділу роботі зі звітами; технічна підтримка на місяць після запуску.

Вартість розраховується індивідуально залежно від обсягу робіт та складності інтеграцій. Отримайте консультацію — ми проаналізуємо ваш поточний dataLayer та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.