PPC × Dev

Server-side tracking для e-commerce: GA4 + Meta CAPI з нуля до продакшну

25 лют. 2026 р.·6 хв читання

Після того як iOS 14.5 зламала client-side attribution, ad-blockers добили решту — серйозному e-commerce потрібен server-side tracking. Стандартна порада: купити GTM Server-Side за €120+/міс або найняти tracking-спеца. Жодне з цього не потрібно, якщо ви контролюєте свій сторфронт. Розберу як зробити server-side GA4 + Meta CAPI з того ж Node.js коду, що крутить магазин — з deduplication, EU-комплаєнсом і без помісячних fees-за-event.

Це технічний walkthrough. Якщо ви нетехнічний власник — таке вже входить у baseline online-store →, не upsell.

Чому server-side вже не опція

Дві структурні зміни:

1. iOS 14.5+ App Tracking Transparency. Meta втратила ~30% сигналу з iOS-користувачів. Pixel-only магазини бачать 40–60% розрив між тим, що Meta показує, і реальними продажами. Без server-side цей розрив невидимий.

2. Ad-blockers і tracking-prevention. Safari ITP і Firefox ETP обмежують third-party cookies. Brave і Firefox дефолтно блокують Pixel і GA. Client-side analytics зараз пропускає 25–40% e-commerce-подій на EU-ринках.

Результат: реклама бачить менше даних → оптимізує гірше → CPA росте. Server-side повертає сигнал.

Що "server-side tracking" означає насправді

Терміни замусорили вендори. Чисте визначення:

Client-side tracking = JS у браузері шле події напряму до Meta/Google.
Server-side tracking = ваш бекенд (після дії користувача) шле події через server-to-server API.

Два API які потрібні:

Meta Conversions API (CAPI) — замінює або доповнює Meta Pixel.
GA4 Measurement Protocol (MP) — замінює або доповнює client-side gtag().

Deduplication — ключовий прийом: більшість магазинів крутять client + server разом, щоб зберегти що працює на client і повернути втрачене. Обидва шлють однаковий event_id, платформа дедуплікує.

Архітектура на одній діаграмі

Браузер   ─►  Storefront (Next.js)  ─►  Cart / Checkout
                   │                          │
                   │ (client Pixel + gtag,    │
                   │  з event_id)             │ (server-side firing
                   │                          │  при order completion)
                   ▼                          ▼
                Meta Pixel                CAPI / GA4 MP
                (browser)                 (your backend)
                   │                          │
                   └──── дедуплікація ────────┘
                          через event_id

Storefront шле звичайні client Pixel/gtag події з event_id. Бекенд у момент істини (order placed, form submit) шле ту саму подію з тим самим event_id на CAPI і GA4 MP. Платформи дедуплікують.

Покроково: Meta CAPI у Next.js storefront

Мінімум для прода.

1. Отримати CAPI access token. Meta Business Manager → Events Manager → Data Sources → ваш Pixel → Settings → Generate Access Token. Зберегти як META_CAPI_TOKEN у env.

2. Захешувати PII. Email, телефон, external_id мусять бути SHA-256 hashed. Через built-in crypto:

import crypto from 'node:crypto';
const sha256 = (s: string) => crypto.createHash('sha256').update(s.trim().toLowerCase()).digest('hex');

3. Зібрати payload. Стандартна Purchase-подія:

const event = {
  event_name: 'Purchase',
  event_time: Math.floor(Date.now() / 1000),
  event_id: orderId,
  action_source: 'website',
  event_source_url: 'https://yourstore.com/checkout/success',
  user_data: {
    em: sha256(customer.email),
    ph: customer.phone ? sha256(customer.phone) : undefined,
    client_ip_address: requestIp,
    client_user_agent: requestUA,
    fbc: cookies.get('_fbc'),
    fbp: cookies.get('_fbp'),
  },
  custom_data: {
    currency: order.currency,
    value: order.total,
    contents: order.items.map(i => ({ id: i.sku, quantity: i.quantity, item_price: i.price })),
    content_ids: order.items.map(i => i.sku),
    content_type: 'product',
  },
};

4. POST на Graph API.

await fetch(`https://graph.facebook.com/v18.0/${PIXEL_ID}/events?access_token=${META_CAPI_TOKEN}`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: [event] }),
});

5. Випустити дзеркальну client-side з тим самим `event_id`.

fbq('track', 'Purchase', { value: total, currency }, { eventID: orderId });

Все. Meta бачить обидві події, дедуплікує за eventID === event_id — і ви повернули iOS / ad-blocker сигнал.

GA4 Measurement Protocol — той самий патерн

Простіше. Потрібен API secret (Admin → Data Streams → Measurement Protocol API secrets) і measurement_id.

await fetch(`https://www.google-analytics.com/mp/collect?measurement_id=${MID}&api_secret=${SECRET}`, {
  method: 'POST',
  body: JSON.stringify({
    client_id: clientIdFromCookie,
    events: [{
      name: 'purchase',
      params: {
        transaction_id: orderId,
        value: order.total,
        currency: order.currency,
        items: order.items.map(i => ({
          item_id: i.sku, item_name: i.name,
          price: i.price, quantity: i.quantity,
        })),
      },
    }],
  }),
});

Для дедуплікації з client gtag — однаковий transaction_id. GA4 дедуплікує purchase-події по ньому автоматично.

EU-комплаєнс — три речі

1. Consent Mode v2. EU-користувачі мусять погодитись на ad-storage і analytics-storage до того, як ви шлете PII. Імплементуйте Google Consent Mode, перевіряйте state на client і server. Без згоди — шліть тільки анонімізовані події (без email, телефону, fbc/fbp).

2. IP на server-side. Можна використовувати для матчингу — але не зберігати поза API-call. Не логуйте сирий IP.

3. Інтеграція з cookie-баннером. Той самий банер, що керує client Pixel, мусить керувати і server-side firing. Передавайте consent state у бекенд.

Cost-порівняння: server-side GTM vs in-app

	GTM Server-Side (Stape/Google)	In-app (цей гайд)
Помісячно	€30–€120+	€0
Setup time	2–5 днів	1–2 дні
Server costs	включено	негативний (поверх існуючого app-серверу)
Vendor dep	так	ні
Гнучкість подій	container UI	код (гнучкіше)
Кому	магазини без dev	магазини з dev / headless

Для headless-магазину якого ви володієте — in-app очевидний вибір. Для Shopify/Woo GTM SS може мати сенс — але це ще один помісячний fee поверх стека, який повне порівняння платформ → вже показало як дорогий.

Що змінюється у дашбордах

Протягом 7–14 днів після запуску:

Meta Ads Manager — Event Match Quality з ~5/10 на 8–10/10. Reported purchases ростуть на 15–35% (це продажі які ви мали — Meta їх не бачила).
GA4 — purchase події перестають губитися на iOS / ad-blockers. Revenue сходиться зі Stripe/PayPal у межах 2–3%.
Реклама — за 30 днів CPA зазвичай покращується коли алгоритм Meta нарешті має сигнал для оптимізації. Індустріальні кейси повідомляють про відчутні зниження CPA; конкретний результат залежить від стартового Event Match Quality і ad mix.

Останній пункт — бізнес-кейс. Server-side tracking — це одноразова інженерна вартість, що компаундиться у нижчий CPA.

Вплив на швидкість

Зроблений правильно, server-side покращує швидкість, бо можна defer/прибрати client скрипти, які шлють ті ж події. Разом з техніками PageSpeed 90+ → — часто +5 Lighthouse-пунктів.

FAQ

Можна на Shopify? Так, через apps (Stape) або Shopify-власний server-side. €30+/міс і через event-систему Shopify. Архітектура працює, platform-tax лишається.

Klaviyo та інші тулзи? Klaviyo має свої client і server потоки. Той самий event_id-патерн працює: надсилайте у Klaviyo з того ж server-side flow.

Чи це для lead-gen теж? Так. Lead, Subscribe, CompleteRegistration — стандартні події Meta і GA4. Патерн ідентичний.

Apple/Google зламає це у 2027? Server-side — це саме та відповідь, яку Meta і Google рекомендують на client-side breakage. Свої API вони не зламають. Cookie-based client-tracking — ось що вмирає.

Наступний крок

Якщо рекламуєтесь і Event Match Quality нижче 7/10 — ви переплачуєте за конверсії. Analytics setup → включає server-side GA4 + Meta CAPI як flat €250 floor (окремо від ongoing ads). Нові online-store-білди — у baseline →.

Маєте питання?

Напишіть мені напряму

Конкретний білд, ціни, терміни міграції — все що не вмістилося вище — відповім особисто протягом робочого дня.

Заповнити бриф