Wzbogacanie zdarzeń po stronie serwera: marża, LTV i dane z CRM w konwersjach

Dlaczego marży i LTV nie wysyła się z przeglądarki

Wszystko, co trafia do warstwy danych, jest jawne. Każdy, kto otworzy narzędzia deweloperskie na stronie podziękowania, zobaczy pełną treść zdarzenia purchase, łącznie z polami, które dodasz „tylko dla Google Ads”.

Dla sklepu oznacza to ryzyko biznesowe: konkurent może w kilka minut zebrać marże na Twoich bestsellerach. Drugi problem to aktualność. Koszt zakupu towaru zmienia się wraz z dostawami i kursami walut, a system ERP rzadko jest połączony z szablonem strony. Serwer tagowania może natomiast bezpiecznie odczytać aktualne dane z bazy i dopisać je do zdarzenia, zanim trafi ono do platform reklamowych. Dlatego specyfikacja przeglądarkowa, opisana w tekście o warstwie danych dla e-commerce GA4, powinna zawierać ceny i przychody, ale nie koszty.

Najczęstszy cel wzbogacania to przejście z optymalizacji pod ROAS na optymalizację pod POAS, czyli zysk z wydatków na reklamę. Różnice między wskaźnikami i wzory znajdziesz w artykule o ROAS, POAS i MER.

Skąd brać dane do wzbogacania zdarzeń

Kontener serwerowy może odczytać dane z kilku typów źródeł. Wybór zależy od tego, jak szybko dane się zmieniają i jak szybko musi przyjść odpowiedź.

W praktyce najczęściej spotyka się połączenie dwóch pierwszych: koszty produktów synchronizowane nocą z ERP do Firestore i status klienta pobierany z CRM. Firestore działa w Google Cloud, więc jeśli serwer tagowania uruchamiasz w Cloud Run w tym samym projekcie, konfiguracja uprawnień jest najprostsza – porównanie opcji infrastruktury znajdziesz w tekście o hostingu server-side GTM.

Jak działa wzbogacanie w server-side GTM

Wzbogacanie odbywa się między klientem a tagami. Klient GA4 zamienia żądanie na dane zdarzenia, zmienne pobierają dodatkowe informacje, transformacja dopisuje je do zdarzenia, a tagi wysyłają całość dalej.

purchase z przeglądarki (transaction_id, value, items)
  -> Klient GA4: dane zdarzenia
  -> Zmienna: koszt produktów z Firestore (products/ITEM_ID)
  -> Zmienna: profit = value - suma kosztów
  -> Transformacja uzupełniająca zdarzenie: profit, customer_segment
  -> Tag GA4 (parametr profit) | Google Ads (wartość = profit) | Meta CAPI

Kontener serwerowy ma trzy typy transformacji: dopuszczające wybrane parametry, wykluczające parametry i uzupełniające zdarzenie. Ta ostatnia pozwala dopisać nowe pola dla wybranych zdarzeń i tagów, dzięki czemu nie musisz powtarzać tej samej logiki w każdym tagu. Jeśli dopiero uruchamiasz serwer, zacznij od poradnika server-side tagging w praktyce.

Konfiguracja krok po kroku: marża w konwersji zakupu

Poniższa procedura dopisuje do zdarzenia purchase zysk brutto ze sprzedaży, liczony jako przychód minus koszt zakupu produktów. To najczęstszy pierwszy projekt wzbogacania.

1. Przygotuj dane. Utwórz w Firestore kolekcję products, w której identyfikator dokumentu to item_id, a pole cost zawiera koszt zakupu jednej sztuki w tej samej konwencji (brutto lub netto) co ceny w warstwie danych.
2. Zautomatyzuj synchronizację. Programista eksportuje koszty z ERP do Firestore, np. raz na dobę i po każdej dostawie.
3. Nadaj uprawnienia. Konto usługi, na którym działa serwer tagowania, musi mieć prawo odczytu z Firestore w danym projekcie.
4. Utwórz zmienną. Napisz szablon zmiennej, który pobiera koszty produktów z zamówienia i zwraca zysk, jak w przykładzie poniżej. Przy prostszym scenariuszu wystarczy wbudowana zmienna wyszukiwania Firestore.
5. Dodaj transformację. Utwórz transformację uzupełniającą zdarzenie dla purchase, która dopisze parametr profit z wartością zmiennej.
6. Skonfiguruj tagi. W tagu GA4 przekaż profit jako parametr, a w osobnej akcji konwersji Google Ads ustaw go jako wartość konwersji.
7. Przetestuj. W podglądzie kontenera serwerowego porównaj wyliczony zysk z danymi zamówienia w panelu sklepu dla kilku transakcji.

Przykładowy kod szablonu zmiennej jest poglądowy – przed użyciem sprawdź opis API w dokumentacji kontenera serwerowego i przetestuj go w podglądzie.

const Firestore = require('Firestore');
const Promise = require('Promise');
const getEventData = require('getEventData');
const makeNumber = require('makeNumber');

const items = getEventData('items') || [];
const revenue = makeNumber(getEventData('value')) || 0;
const reads = [];

for (let i = 0; i < items.length; i++) {
  const item = items[i];
  reads.push(Firestore.read('products/' + item.item_id, { projectId: data.projectId })
    .then(function (doc) {
      return makeNumber(doc.data.cost) * (makeNumber(item.quantity) || 1);
    }));
}

return Promise.all(reads).then(function (costs) {
  let totalCost = 0;
  for (let j = 0; j < costs.length; j++) { totalCost += costs[j]; }
  return revenue - totalCost;
}, function () {
  return undefined;
});

Zwrócenie wartości undefined przy braku kosztu choćby jednego produktu jest celowe: lepiej nie wysłać zysku niż wysłać zawyżony. Takie zdarzenia możesz obsłużyć regułą zapasową, np. przychód pomnożony przez średnią marżę kategorii, i liczyć ich udział – jeśli rośnie, synchronizacja z ERP przestała działać. Odczyty kosztów zmieniają się rzadko, więc warto je buforować między żądaniami; więcej o pisaniu własnych szablonów znajdziesz w artykule o szablonach niestandardowych w GTM.

Prostszy wariant to sytuacja, w której backend sklepu w chwili utworzenia zamówienia zapisuje marżę w dokumencie orders/ID_ZAMOWIENIA. Wtedy wbudowana zmienna wyszukiwania Firestore odczytuje jedno pole po transaction_id. Warunek: zapis musi nastąpić, zanim zdarzenie zakupu dotrze na serwer.

Gdzie wysłać wzbogacone dane: GA4, Google Ads i Meta

Każda platforma inaczej wykorzystuje dodatkową wartość. W GA4 to dane do raportów, w Google Ads – sygnał dla strategii stawek, a w Meta trzeba uważać na deduplikację z pikselem.

W Google Ads zmiana wartości z przychodu na zysk wymaga nowego celu. Załóżmy, że średnia marża brutto w sklepie wynosi 30%. Jeśli dotychczasowy docelowy ROAS na przychodzie wynosił 600%, równoważny cel liczony na zysku to ok. 180%. Ustawienie starego celu na nowej wartości drastycznie ograniczyłoby wyświetlanie reklam. Jak dobrać strategię, opisujemy w tekście o docelowym ROAS i maksymalizacji wartości konwersji, a natywne funkcje Google Ads do optymalizacji pod marżę, takie jak Product Value Optimization i cele cyklu życia klienta – w artykule o optymalizacji pod marżę i wartość klienta.

W Meta piksel i Conversions API wysyłają zwykle to samo zdarzenie z tym samym event_id, a Meta zachowuje jedno z nich po deduplikacji. Jeśli piksel wyśle przychód, a serwer zysk, wynik będzie nieprzewidywalny. Bezpieczniej przekazać zysk w dodatkowym polu zdarzenia albo wysyłać zakup z wartością zysku wyłącznie przez Conversions API – to drugie wymaga jednak dobrego dopasowania danych klienta, co opisujemy w tekście o Event Match Quality. Konfigurację samego tagu zawiera poradnik o Meta Conversions API przez server-side GTM.

LTV i dane z CRM: status i wartość klienta

Drugim typem wzbogacania jest informacja o kliencie: czy kupuje pierwszy raz, do jakiego segmentu należy i ile jest wart w dłuższym okresie. Te dane zwykle pochodzą z CRM lub modelu analitycznego.

Status nowego klienta ustalisz, wyszukując w Firestore zahaszowany adres e-mail z zamówienia w kolekcji dotychczasowych klientów. Wynik przekażesz do tagu konwersji Google Ads jako informację o nowym kliencie, co pozwala raportować i optymalizować pozyskanie nowych klientów. Prognozowaną wartość klienta, czyli LTV, najlepiej liczyć w hurtowni danych, a wyniki eksportować okresowo do Firestore, bo kontener serwerowy nie wykonuje zapytań do BigQuery.

Część danych z CRM powstaje długo po wizycie na stronie, np. status zakwalifikowanego leada czy zwrot zamówienia. Takich informacji nie dopiszesz do zdarzenia z przeglądarki – trzeba je przesłać do platform osobno. W Google Ads służą do tego import konwersji offline i Data Manager, którego zmiany z 2026 roku opisujemy w tekście o Customer Match i Data Manager.

Ryzyka: RODO, zgody, opóźnienia i spójność danych

Wzbogacanie zwiększa wartość danych, ale też odpowiedzialność za nie. Najważniejsze ryzyka dotyczą zgód, zakresu przetwarzania i jakości wyliczeń.

Zgody. Wzbogacanie na serwerze nie zmienia zasad wynikających ze zgód użytkownika. Jeśli użytkownik nie zgodził się na przetwarzanie danych w celach reklamowych, dane z CRM nie powinny trafiać do platform reklamowych tylko dlatego, że łączy je serwer.

Zakres danych. Łączenie zdarzeń z historią zakupów i prognozą wartości klienta to przetwarzanie danych osobowych, które może być profilowaniem. Potrzebujesz podstawy prawnej, aktualnej polityki prywatności i minimalizacji danych przekazywanych dostawcom. Ogólne zasady opisujemy w artykule o RODO w reklamie online, a w konkretnym przypadku warto skonsultować się z prawnikiem.

Opóźnienia. Każde zapytanie do bazy lub API wydłuża przetwarzanie zdarzenia. Ustaw rozsądne limity czasu, korzystaj z pamięci podręcznej i obserwuj czasy odpowiedzi w podglądzie.

Spójność. Zysk w GA4 to szacunek: zwykle nie uwzględnia zwrotów, kosztów dostawy ani prowizji bramek płatności. Zapisz definicję w dokumentacji, żeby nikt nie porównywał go wprost z wynikiem finansowym. Wzbogacone zdarzenia są częścią strategii danych first-party, a kolejne poradniki z tego obszaru znajdziesz w podtemacie server-side tagging.