Серверне відстеження конверсій за допомогою коротких посилань

Браузерний піксель - це той елемент атрибуції, який ламається першим. Apple Intelligent Tracking Prevention обмежує сторонні файли cookie та погіршує передачу реферера; блокувальники реклами видаляють мережевий виклик пікселя ще до того, як він покине сторінку; iOS 14.5 App Tracking Transparency настільки знизив якість сигналу Meta для трафіку з iPhone, що самі Meta тепер розглядають браузерний піксель лише як резервний варіант.

Серверне відстеження конверсій - це рішення, з яким погоджуються всі. Проте багато хто помиляється саме в реалізації. У цій статті ми розглянемо архітектуру, в якій сервіс скорочення посилань володіє click_id - що робить скорочувач, що робить ваш бекенд, чого очікують рекламні платформи зі свого боку, а також модель дедуплікації, яка запобігає подвійному обліку, коли спрацьовують і браузерні, і серверні події.

Три платформи, на які команди найчастіше передають дані: Meta CAPI, GA4 Measurement Protocol, TikTok Events API. Mixpanel, Klaviyo та Pinterest приймають дані схожої структури з назвами полів, специфічними для кожного вендора. Я зупинюся детально на Meta та GA4, оскільки вони складають більшу частину бюджетів; інші працюють за тим самим шаблоном.

Чому саме серверна сторона#

Якщо коротко: браузер більше не є надійним джерелом сигналу. Довша версія варта розуміння, оскільки вона визначає, як ви налаштовуєте дедуплікацію.

Три фактори погіршують відстеження на стороні браузера:

Партиціювання файлів cookie та обмеження терміну їх дії. Safari ITP партиціює файли cookie за доменом верхнього рівня та обмежує термін дії власних (first-party) файлів cookie, встановлених скриптом, до 7 днів (або 24 годин після виявлення відомого міжсайтового трекера). Firefox Total Cookie Protection робить схоже партиціювання. Brave та інші розширення для конфіденційності йдуть ще далі. Процес атрибуції через first-party cookie, який працював у 2018 році, більше не працює у 2026-му.

Блокувальники реклами. uBlock Origin, AdBlock Plus, Pi-hole, NextDNS та блокувальники на рівні мережі постачаються з готовими правилами для connect.facebook.net, googletagmanager.com, analytics.tiktok.com та решти поверхні маркетингових тегів. Піксель ніколи не спрацьовує; конверсія ніколи не реєструється.

iOS App Tracking Transparency та зміни у відстеженні посилань в iOS 17. ATT знизив якість сигналу Meta. iOS 17 Link Tracking Protection поширив це на параметри запиту в режимі приватного перегляду та в Пошті, видаляючи fbclid, gclid та низку інших параметрів ще до відкриття посилання.

Сумарний ефект для типового магазину на Shopify з великою часткою трафіку з iOS: браузерні пікселі втрачають 25-40% конверсій. Точне число залежить від вашого міксу трафіку; бренди косметики та одягу з великою кількістю користувачів iOS знаходяться на верхній межі. Арифметика відновленого доходу - це те, що виправдовує інженерну роботу: для магазину з оборотом €10 млн на рік і 30-відсотковою прогалиною в атрибуції пікселя, відновлення навіть половини цієї прогалини означає €1,5 млн атрибутованого доходу, повернутого платформам, які його згенерували.

Серверна передача конверсій закриває більшу частину цієї прогалини. Вона не закриває її повністю - існують конверсії, де click_id ніколи не був зафіксований (органічний пошук, прямі заходи, пошук за брендом), які жоден CAPI не відновить, - але вона закриває прогалину, що виникла через блокування на стороні браузера.

Архітектура#

Потік даних складається з чотирьох кроків: реклама → коротке посилання → сайт → серверна передача.

Рекламна платформа → коротке посилання. Цільовим посиланням у креативі Meta або Google Ads є коротке посилання. Користувач клікає; обробник на межі (edge handler) сервісу скорочення фіксує подію кліку та перенаправляє на цільову URL-адресу з доданим click_id.

Коротке посилання → сайт. До цільової URL-адреси додається ?elido_click=<id> (налаштовується для кожного робочого простору). Тег-менеджер сайту або код теми зчитує його та записує у first-party cookie або, що важливіше, у кастомний атрибут кошика чи замовлення.

Сайт → замовлення. Коли користувач завершує замовлення (кошик Shopify відправлено, замовлення WooCommerce створено, безголовий кошик конвертовано), click_id знаходиться в атрибутах/метаданих запису про замовлення. Це точка стабільної передачі - як тільки click_id потрапляє в замовлення, він більше не залежить від терміну дії файлів cookie чи тривалості сесії браузера.

Замовлення → серверна передача. Вебхук про оплату замовлення надходить від вашої комерційної платформи. Ваш бекенд (або Elido, якщо ви делегували це йому) зчитує click_id, знаходить облікові дані для передачі конверсій і надсилає POST-запит із конверсією на кожну підключену рекламну платформу. Платформи отримують конверсію та зараховують її відповідній кампанії.

Роль скорочувача - це click_id на другому етапі плюс оркестрація на четвертому. Перше - це просто; друге - це те, де інтеграція показує свою справжню цінність.

Дедуплікація: те, про що ніхто не згадує до релізу#

Найпоширеніша проблема в продакшені, яку я бачу, - це подвійний облік. Браузерний піксель все ще знаходиться на сторінці (команда не вимкнула його, бо хотіла мати резервний варіант для трафіку не з Safari), і серверна передача також спрацьовує. Meta приймає обидві події. Конверсія враховується двічі, алгоритм розподілу бюджету витрачає занадто багато, а під час наступного перегляду бюджету кампанії хтось помічає: "стривайте, чому наш зареєстрований ROAS утричі вищий за виручку?".

Рішенням є ідентифікатор дедуплікації. Meta CAPI приймає event_id. GA4 Measurement Protocol приймає client_id та transaction_id. TikTok Events приймає event_id. Якщо і браузер, і сервер надсилають ту саму подію з однаковим ID дедуплікації, платформа зараховує одну подію та ігнорує другу.

ID дедуплікації повинен мати однакове значення з обох сторін. ID замовлення підходить для подій купівлі - його бачать і браузерний піксель, і серверна передача. click_id підходить для попередніх подій (лід, додавання в кошик, перегляд контенту), де замовлення ще не існує.

Документація Meta з дедуплікації описує вікно відповідності: події, отримані протягом 48 годин одна від одної з однаковим event_id, вважаються дублікатами. Дедуплікація в GA4 на основі client_id схожа за принципом, хоча має менше документації.

Операційне правило: кожна серверна конверсія повинна містити ID дедуплікації, і цей ID повинен бути таким самим, який згенерував браузерний піксель. Ігнорування цього - це різниця між працюючою інтеграцією CAPI та тією, що тихо роздуває ваші показники протягом трьох місяців, поки хтось цього не помітить.

Вимоги до хешування#

І Meta CAPI, і TikTok Events вимагають, щоб ідентифікатори електронної пошти та номера телефону були хешовані за алгоритмом SHA-256 перед передачею. GA4 суворо цього не вимагає, але приймає такі дані. Хешування застосовується до ідентифікаторів клієнта - em (email), ph (телефон), fn (ім'я), ln (прізвище), ge (стать), db (дата народження), ct (місто), st (штат/область), zp (індекс), country (країна) - а не до метаданих події.

Є два нюанси. По-перше, формат має бути нормалізований перед хешуванням - нижній регістр, без пробілів, код країни видалено з номера телефону, дефіси видалено. Хешування [email protected] дасть інше значення, ніж хешування [email protected]; платформи очікують останнє. На сторінці вимог до параметрів Meta наведено правила нормалізації для кожного поля.

По-друге, хеш має бути у вигляді нижнього регістру шістнадцяткового формату (lowercase hex) без пробілів. SHA256("[email protected]") видає a3b6...; API очікує a3b6..., а не A3B6... і не \xa3\xb6.... Більшість SDK мов програмування повертають шістнадцятковий код у верхньому регістрі за замовчуванням; вам потрібно перевести результат у нижній регістр.

Якщо ви використовуєте ендпоінт Elido POST /v1/conversions, хешування обробляється на стороні платформи - ви надсилаєте необроблені email/телефон, Elido виконує нормалізацію та хешування відповідно до вимог кожної платформи та передає дані далі. Перевага полягає в одному наборі правил нормалізації для вашого бекенду замість трьох. Мінусом є те, що ви довіряєте Elido необроблені PII в момент передачі; запит шифрується під час передачі та не зберігається на сервері, але цю модель довіри варто розуміти перед налаштуванням.

Приклад Meta CAPI POST-запиту#

Що насправді очікує платформа. Ендпоінт: POST https://graph.facebook.com/v21.0/{pixel_id}/events. Тіло запиту - JSON.

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1716480000,
      "event_id": "order-acme-2026-05-23-001847",
      "action_source": "website",
      "event_source_url": "https://acme.example/checkout/thanks?order=001847",
      "user_data": {
        "em": ["a3b6...sha256 of email"],
        "ph": ["c4d7...sha256 of phone"],
        "client_user_agent": "Mozilla/5.0 ...",
        "client_ip_address": "203.0.113.42",
        "fbc": "fb.1.1716470000.AbCdEf",
        "fbp": "fb.1.1716470000.987654321"
      },
      "custom_data": {
        "currency": "EUR",
        "value": 89.5,
        "content_ids": ["sku-spring-jeans-32-blue"],
        "content_type": "product",
        "num_items": 1
      }
    }
  ],
  "test_event_code": "TEST12345",
  "access_token": "EAAxxxxxxx"
}

Три важливі моменти:

event_id - це ключ дедуплікації. Встановіть його рівним ID вашого замовлення; браузерний піксель Purchase встановлює таке саме значення. Meta виконує дедуплікацію в межах 48-годинного вікна відповідності.

fbc та fbp - це ідентифікатори cookie Meta. fbc - це ідентифікатор кліку (fbclid із цільової URL-адреси з префіксом); fbp - це ідентифікатор браузера з файлу cookie _fbp. Обидва є власними (first-party) з точки зору вашого домену, і їх можна зафіксувати на стороні сервера після того, як ви зберегли їх із цільової сторінки. Якщо у вас їх немає, рівень відповідності Meta падає; якщо вони є - рівень відповідності чудовий.

test_event_code дозволяє надсилати тестові події, які не враховуються у звітах продакшену. Завжди налаштовуйте це спочатку; перевіряйте в Events Manager Test Events перед тим, як запускати реальний трафік.

Еквівалент Elido API: POST /v1/conversions із {click_id, event_name: "Purchase", value, currency, order_id, customer: {email, phone}}. Elido нормалізує та хешує дані відповідно до специфікації Meta, знаходить fbc/fbp робочого простору за подією кліку та формує корисне навантаження CAPI.

Приклад GA4 Measurement Protocol POST-запиту#

Формат передачі GA4 схожий за структурою, але назви полів відрізняються. Ендпоінт: POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXX&api_secret=xxx.

{
  "client_id": "click-id-as-fallback-if-no-ga4-cookie",
  "user_id": "user-acme-12847",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "order-acme-2026-05-23-001847",
        "value": 89.5,
        "currency": "EUR",
        "items": [
          {
            "item_id": "sku-spring-jeans-32-blue",
            "item_name": "Spring Jeans 32 Blue",
            "quantity": 1,
            "price": 89.5
          }
        ],
        "engagement_time_msec": 1
      }
    }
  ]
}

Примітки:

client_id - це значення _ga з файлу cookie GA4, якщо воно наявне; якщо ні, click_id стає придатним резервним варіантом (оскільки GA4 створить сесію на його основі).

transaction_id - це ключ дедуплікації. Встановіть його рівним ID вашого замовлення, такому самому значенню, яке передає браузерна подія gtag purchase; GA4 виконує дедуплікацію в межах вікна своєї сесії.

engagement_time_msec має бути присутнім і позитивним, щоб подія враховувалася в атрибуції; встановлення значення 1 задовольняє цю вимогу.

api_secret налаштовується на рівні робочого простору. Документація GA4 MP описує процес налаштування облікових даних.

Семантика повторних спроб#

Платформи допускають повторні спроби; проте ви не можете робити їх наосліп. Три моделі є надійними.

Ідемпотентність за ID дедуплікації. Якщо event_id / transaction_id платформи - це ID замовлення, і ви повторно надсилаєте те саме навантаження, платформа виконує дедуплікацію - друге надсилання просто ігнорується. Це безпечно.

Експоненціальна затримка при 5xx. І Meta, і GA4 час від часу повертають помилки 5xx. Виконуйте повторну спробу із затримкою (1с, 2с, 4с, 8с до 60с, потім припиняйте). Повторні спроби повинні зберігати той самий event_id, щоб платформа дедуплікувала будь-які випадки часткового успіху.

Не повторюйте спроби при 4xx. Відповідь 4xx означає, що навантаження сформовано неправильно або облікові дані невірні. Повторна спроба це не виправить; вона лише витратить ліміт запитів (rate-limit). Запишіть це в лог, надішліть сповіщення та виправте причину.

Якщо ви використовуєте Elido, повторні спроби та затримки обробляються автоматично - POST /v1/conversions повертає відповідь негайно, а передача на платформи відбувається у фоновому режимі, при цьому стан повторних спроб можна відстежити через GET /v1/conversions/{id}. Якщо ви розробляєте власне рішення, черга (RabbitMQ, наш потік подій, AWS SQS) - це те місце, де реалізується логіка повторів.

Тестовий режим та «сухий запуск» (dry-run)#

Найбільша помилка, яку роблять команди, - це пропуск «сухого запуску».

У Meta є Test Events. Ви встановлюєте test_event_code у навантаженні, події з'являються на панелі Test Events протягом декількох секунд, і ви перевіряєте структуру та дедуплікацію. Реальні події надходять через той самий ендпоінт, але без test_event_code.

У GA4 є DebugView. Ви встановлюєте debug_mode: 1 у параметрах події, події з'являються в DebugView, і ви виконуєте перевірку перед запуском реального трафіку.

У TikTok є схожий тестовий режим в інтерфейсі Events Manager.

Чек-лист перевірки короткий. Зробіть тестове замовлення, перевірте спрацювання вебхука про оплату, перевірте запуск серверної передачі, перевірте її появу на тестовій панелі платформи. Переконайтеся, що event_id збігається зі значенням браузерного пікселя. Переконайтеся, що ціна, валюта та content_ids виглядають правильно. Потім вимкніть тестовий режим і спостерігайте за першими десятьма реальними замовленнями.

Якщо ви пропустите цей крок, то дізнаєтеся, що інтеграція не працює, лише через три дні, коли звіти виявляться порожніми. Пропуск «сухого запуску» - найпоширеніша причина невдач, яку я бачу.

Поширені причини збоїв#

click_id відсутній у замовленні. Найпоширеніша проблема. Вже розглянута в статті про скорочувачі для електронної комерції; рішення полягає в тому, щоб прокинути click_id через кошик до замовлення.

Невідповідність хешу. [email protected], хешована без нормалізації, дає інше значення, ніж [email protected]. Платформи відхиляють відповідність, конверсія потрапляє в категорію без ідентифікатора, і у звітах Meta вона позначається як "unmatched". Рішення - правила нормалізації в документації параметрів Meta CAPI; краще рішення - делегувати хешування сервісу скорочення, щоб правила зберігалися в одному місці.

fbc не зафіксовано. Коли користувач переходить із реклами Meta, URL-адреса містить fbclid; сторінка повинна зафіксувати та зберегти його (зазвичай у кастомних атрибутах замовлення). Без fbc рівень відповідності Meta суттєво падає. Рішення - крок у тег-менеджері на цільовій сторінці, який записує fbc у first-party cookie або в атрибут кошика.

Неузгоджений ID дедуплікації. Браузерний піксель використовує ID замовлення; серверна сторона використовує UUID, згенерований у момент передачі. Обидві події приймаються, жодна не дедуплікується. Рішення - переконатися, що серверна передача використовує те саме значення event_id, яке згенерував браузерний піксель (ID замовлення для покупок є стандартною відповіддю).

Невідповідність валюти. Браузер надсилає USD (оскільки конфігурація gtag за замовчуванням - USD); сервер надсилає EUR (оскільки замовлення в євро). І GA4, і Meta в деяких контекстах відповідності розглядають валюту як частину підпису події, і конверсії реєструються, але не агрегуються коректно. Рішення - брати валюту із замовлення, а не з конфігурації на рівні сторінки.

Місце цього процесу в площині даних#

Передача конверсій - це лише одна частина ширшого пайплайну атрибуції. Базовою статтею для решти пайплайну є Як відстежувати UTM-кампанії від початку до кінця без CDP - у тому пості детально розглядаються шаблон UTM робочого простору, перевизначення на рівні кампанії, масовий імпорт та етап перевірки «сухим запуском». Ця ж стаття є глибоким зануренням у серверну передачу даних, яка замикає цей цикл.

Для отримання практичного посібника зверніться до документації з передачі конверсій - там ви знайдете покрокову інструкцію. Про архітектурні деталі того, як Elido передає дані, не перевищуючи ліміти платформ, читайте в пості про архітектуру фіксації кліків.

Читайте в кластері#

Суміжні статті в кластері функцій: Пояснення смарт-посилань (базова стаття), Вебхуки для подій посилань (загальна структура подій) та Передача конверсій у Meta CAPI (глибше занурення саме в Meta). Для ознайомлення з версією для маркетологів відвідайте solutions/marketers; сторінка продукту - сторінка функції відстеження конверсій.

Схожі статті в блозі#

• Серверне відстеження GA4 через рівень перенаправлення
• Пояснення атрибуції без файлів cookie: що все ще працює у 2026 році
• Атрибуція кліків після Safari ITP: що все ще працює у 2026 році
• Чому ми використовуємо наше аналітичне сховище для аналітики кліків (а не Postgres)