Wzbogacanie page_view e-mailem z wcześniejszego zakupu — wyższy Event Match Quality

Meta dopasowuje konwersję do użytkownika i kampanii tym lepiej, im więcej danych identyfikujących dostanie razem ze zdarzeniem. E-mail jest tu najmocniejszym czynnikiem Event Match Quality — ale zdarzenie page_view naturalnie go nie niesie. Użytkownik wraca na stronę po tygodniu, przegląda ofertę, a Meta Conversions API dostaje gołe odsłony bez żadnego dopasowania.

Rozwiązaniem jest lekki mini-CDP w server-side GTM oparty na Stape Store: przy zakupie zapisujesz profil klienta, a na późniejszym page_view odtwarzasz z niego e-mail i wysyłasz wzbogacone zdarzenie do Mety. Poniżej dokładnie ten łańcuch krok po kroku.

Jak to działa — cztery elementy, dwa momenty

Cały mechanizm to czteroelementowy łańcuch, który działa w dwóch rozdzielonych w czasie momentach: przy zakupie zapisuję, przy odsłonie odczytuję.

PRZY ZAKUPIE — zapis profilu

event purchase
→
Stape Store Writer
→
📦 profil w Store
klucz: x-stape-user-id

PRZY ODSŁONIE — odczyt i wysyłka

event page_view
→
Stape Store Lookup
wyciąga e-mail
→
Meta — PageView
CAPI, wzbogacony

Profil zapisany przy zakupie jest źródłem e-maila przy odsłonie. Oba momenty spina ten sam klucz dokumentu — identyfikator urządzenia z nagłówka x-stape-user-id.

#	Element	Typ w GTM	Rola
1	`x-stape-user-id`	zmienna: nagłówek żądania	dostarcza identyfikator urządzenia
2	Stape Store Writer	tag (trigger `purchase`)	zapisuje profil przy zakupie
3	Stape Store Lookup	zmienna	odczytuje e-mail z profilu
4	Meta — PageView	tag (Meta CAPI)	wysyła wzbogacony `page_view`

Dlaczego Stape Store — i kiedy lepszy Firestore albo Supabase

Stape Store to naturalny wybór, gdy hostujesz sGTM na Stape i zależy ci na zerowym narzucie: szablony Writer i Lookup są natywne, bez osobnej infrastruktury i service accountów. Ale ten sam łańcuch zbudujesz też na Firestore (Google) albo Supabase (Postgres) — różnią się modelem kosztu, kontrolą nad danymi i tym, czy dane mają żyć poza taggingiem.

Backend	Model kosztu	Free tier	Próg płatny	Setup w sGTM
Stape Store	w cenie planu Stape (per żądanie)	10 tys. żądań/mies.	~$20/mies. (500 tys. żądań)	natywny — zero infra
Firestore	per operacja	50 tys. odczytów/dzień, 1 GB	$0,03 / 100 tys. odczytów, $0,09 / 100 tys. zapisów	GCP + service account
Supabase	flat (plan Pro)	500 MB, nielimit. API	$25/mies. za projekt	projekt + klucze API

Ceny: stan na czerwiec 2026; modele cenowe się zmieniają — zweryfikuj u dostawcy.

Czym kierować się przy wyborze:

Stape Store — gdy już hostujesz sGTM na Stape, chcesz najprostszy setup i najniższą latencję (magazyn współdzieli infrastrukturę z kontenerem), a dane mają służyć tylko wzbogacaniu w tagach. Najszybszy time-to-value.
Firestore — gdy jesteś w ekosystemie Google i chcesz eksportować profile do BigQuery pod analitykę. Uwaga na koszt: każdy page_view robi odczyt, a Firestore liczy per operację — przy dużym ruchu rachunek za odczyty rośnie.
Supabase — gdy zależy Ci na przewidywalnym, flat koszcie i relacyjnym Postgresie, który odpytasz SQL-em także poza taggingiem. Kontrola nad bazą za stałą cenę.

Praktyczny wniosek dla tego use case: skoro odczyt leci na każdym page_view, najbardziej przewidywalne kosztowo są Stape Store (w cenie planu) i Supabase (flat). Firestore wybierz świadomie — gdy realnie potrzebujesz jego skali albo eksportu do BigQuery.

Zasada, na której wszystko stoi: klucz zapisu = klucz odczytu

To jedyna rzecz, którą trzeba zrozumieć, zanim cokolwiek się skonfiguruje. Identyfikator, pod którym zapisuję dokument, musi być dokładnie tym samym, po którym go czytam. Zapiszesz profil pod jednym kluczem, a odczytasz po innym — Lookup nie znajdzie dokumentu i zwróci pusto.

Naturalnym wyborem jest tu x-stape-user-id — hash z IP, User-Agenta i ustawień TLS, który Stape dokleja do każdego żądania. Jego zaleta: jest obecny na każdym evencie, także na page_view, gdzie nie ma jeszcze e-maila. Ograniczenie: to identyfikator per urządzenie — nie połączy tego samego człowieka między telefonem a laptopem. Dla tego konkretnego zadania (odczyt na page_view) to akceptowalny kompromis.

Konfiguracja krok po kroku

Krok 1 — zmienna z identyfikatorem

Najpierw warunek po stronie Stape: w panelu włącz Power-Up User ID (Power-Ups → User ID → Configure). Od tej chwili każde żądanie niesie nagłówek x-stape-user-id.

Potem w sGTM: Zmienne → Nowa → typ „Nagłówek żądania”, w polu nazwa wpisz x-stape-user-id. Zmienna zwraca identyfikator urządzenia, obecny na każdym żądaniu.

Krok 2 — Writer zapisujący profil przy zakupie

Tag → Nowy → szablon „Stape Store Writer” (galeria szablonów, stape-io):

Document ID: wartość zmiennej z kroku 1 — to klucz dokumentu.
Zaznacz Add Event Data (zapisze całe dane zdarzenia, w tym user_data.email), Merge document keys (scala z istniejącym dokumentem, nie nadpisuje) i Add Timestamp.
Trigger: zdarzenie purchase.

Zakup to moment, w którym masz najwięcej danych o kliencie — dlatego to właśnie tu warto zapisać profil.

Krok 3 — Lookup odczytujący e-mail

Zmienne → Nowa → typ „Stape Store Lookup”:

Lookup Type: Document ID.
Document ID: ta sama zmienna co w kroku 2 (x-stape-user-id).
Key Path: user_data.email.

Zmienna pobiera dokument zapisany przez Writer i wyciąga z niego adres.

Krok 4 — tag Meta PageView z wzbogaceniem

Tag → Facebook Conversion API:

Event Name: PageView (metoda Override, typ Standard), Action Source: Website.
Pixel ID i API Access Token ze zmiennych konfiguracyjnych.
User Data → Email: wartość zmiennej Lookup z kroku 3 — to główny czynnik Event Match Quality.
Event ID do deduplikacji z pikselem przeglądarkowym, Test ID do walidacji w Test Events.
Trigger: page_view.

Tag sam hashuje dane, które tego wymagają (zhashowane wcześniej również przyjmie).

Cicha awaria, która zaniża Event Match Quality

Najłatwiej pomylić się przy kluczu dokumentu. Jeśli zapiszesz profil pod jednym identyfikatorem, a czytasz po innym, Lookup zwróci pusto — a tag Meta i tak odpali się na zielono, tylko bez e-maila.

To jest cicha awaria i jej najgorsza cecha: w debuggerze sGTM wszystko wygląda poprawnie. Braku wzbogacenia nie zobaczysz w podglądzie — zobaczysz go dopiero jako spadek Event Match Quality w Menedżerze Zdarzeń Meta, czyli z opóźnieniem i w innym narzędziu. Dlatego po każdej zmianie klucza — pełna weryfikacja.

Weryfikacja

Kolejność testu. Dokument musi istnieć przed odczytem i pochodzić z tego samego urządzenia: najpierw purchase (powstaje profil), potem page_view na tym samym urządzeniu. Pole User Data → Email w tagu Meta powinno się wypełnić.
Ścieżka klucza. Otwórz dokument w zakładce Store i potwierdź, że e-mail leży dokładnie pod user_data.email. Jeśli jest pod inną ścieżką (user_data.email_address) albo jako hash — dostosuj Key Path. Inaczej klucz będzie dobry, a Lookup i tak zwróci pusto.
Debugger. Cały łańcuch podejrzysz w trybie podglądu sGTM — na poziomie eventu sprawdzasz wartość Lookup i dane wysłane do Mety.

Prywatność — zanim trafi na produkcję

Zapis user_data do Stape Store to utrwalanie danych osobowych poza sesją — inny próg niż przekazanie pojedynczego hitu do platformy:

Trigger Writera warunkuj zgodą marketingową, nie samym zdarzeniem zakupu.
Na dokumentach profilowych ustaw TTL — bezterminowa retencja PII to niepotrzebne ryzyko.
Kluczowanie po x-stape-user-id, a nie po surowym e-mailu, sprawia, że adres nie jest jednocześnie nazwą dokumentu — drobna, ale sensowna higiena.

Ten sam magazyn obsługuje trudniejszy scenariusz — przywracanie fbc/fbp dla zakupu offline, gdzie zdarzenie przychodzi webhookiem bez przeglądarki. Szerszy kontekst odzyskiwania sygnałów po stronie serwera opisuję w case study o server-side taggingu.