COSSY / RAPORTY
← Wszystkie raporty
Audyt techniczny · Tracking & Performance

COSSY — Meta / GTM / Stape / Shopify

Stan na 26.08.2026 · Shopify · Meta Pixel · CAPI · Web GTM · sGTM · Stape · Google

Podsumowanie wykonawcze

Tracking nie jest całkowicie niedziałający. Problem polega na tym, że równolegle funkcjonują co najmniej dwie niezależne ścieżki Meta, a kluczowy sygnał Purchase nie ma potwierdzonego, stabilnego odpowiednika server-side. W obecnym stanie dane mogą być dublowane, niespójne i nie nadają się do bezpiecznego skalowania kampanii optymalizowanych na zakup.

Meta Browser
2 równoległe źródła
Purchase Server / CAPI
Niepotwierdzony
Priorytet
Naprawa architektury przed skalowaniem
Najważniejszy wniosek: nie chodzi o naprawę pojedynczego tagu. Najpierw trzeba doprowadzić tracking do jednej kontrolowanej architektury, a dopiero potem weryfikować poszczególne kanały.

Obecna architektura

Shopify
├─ Native Meta / Partner Integration
│  ├─ PageView       eid = sh-...
│  ├─ ViewContent    eid = sh-...
│  └─ Purchase       Browser / Partner integration
│
└─ Customer Events / Stape bridge
   ↓
Web GTM
   ├─ [Stape] Meta-*        → Meta Browser
   ├─ [Stape] GA4-*         → Google
   └─ [Stape] DT-*          → sst.cossy.com
                                ↓
                              sGTM
                                ├─ Meta CAPI
                                ├─ Google Ads / GA4
                                ├─ Klaviyo
                                └─ osobna gałąź purchase_webhook

Główne ryzyko: dwa niezależne browser pipelines dla Meta pracują na tym samym Pixel ID, ale generują różne event_id.

Najważniejsze ustalenia

1

Potwierdzony duplikat Meta browser events

Na jednej stronie produktu rejestrowane są dwa ViewContent dla tego samego Pixel ID, ale z różnymi identyfikatorami zdarzenia. To nie jest poprawna para Browser + Server do deduplikacji, tylko dwa niezależne zdarzenia browser-side.

Meta ViewContent request
Stape / GTM — ViewContent z osobnym event_id
Meta browser event sh id
Shopify / Partner — event z identyfikatorem sh-*
2

Web GTM / Stape działa, ale nie w pełni spójnie

Preview Web GTM potwierdza uruchamianie tagów Meta, GA4 i Data Tag. Konfiguracja ViewContent posiada własny Unique Event ID, dane ecommerce i wymaganie ad_storage.

Web GTM preview
Web GTM — uruchomione tagi dla ViewContent
ViewContent config
Konfiguracja Stape Meta ViewContent
ViewContent properties
Parametry, user data i event_id
3

PageView jest skonfigurowany niespójnie

Tag uruchamia się w GTM, ale podczas testu nie potwierdzono odpowiadającego mu requestu w Network. Konfiguracja różni się także od działającego ViewContent.

PageView config top
Stape Meta PageView — konfiguracja
PageView config
PageView — brak pełnej zgodności z ViewContent

Purchase / Meta CAPI

Browser Purchase
Potwierdzony

Shopify / Partner integration

Server Purchase
Niepotwierdzony

Brak stabilnego odpowiednika w testach

sGTM
Dwie ścieżki Purchase

purchase + purchase_webhook

Inne zdarzenia Stape server-side docierają do sGTM i Meta CAPI, więc problem nie wygląda na awarię całego SST. Najbardziej prawdopodobny obszar błędu znajduje się wcześniej: generowanie lub transport Purchase z Shopify/Web GTM albo osobne źródło webhook.

purchase_webhook
→ [Webhook] Meta - Purchase
→ [Webhook] GA4 - Purchase
→ [Webhook] GADS - Purchase
→ [Webhook] Klaviyo - Placed Order
→ Store transaction id

W Shopify Admin nie było widocznej ręcznej subskrypcji webhook. Nie wyklucza to subskrypcji zarządzanej przez aplikację — źródło wymaga osobnej weryfikacji.

Meta Catalog / Product Feed

Natywna integracja Facebook & Instagram jest jednocześnie źródłem trackingu oraz powiązaniem z obecnym katalogiem Meta. Dlatego jej wyłączenie nie powinno być wykonywane „w ciemno”. Najpierw trzeba rozdzielić funkcję feed/catalog od źródła browser tracking i upewnić się, że katalog pozostanie zasilany po zmianach.

Dodatkowe problemy

ObszarProblemZnaczenie
Meta PixelDuplicate Pixel IDPotwierdza wielokrotną inicjalizację
Meta paramsNieprawidłowy format currency w części requestówRyzyko błędnej jakości eventów
GTMRóżne trigger patterns dla podobnych zdarzeńTrudne utrzymanie i testowanie
Template / exceptionPUT_YOUR_VALUE_HEREŚlad niedokończonej konfiguracji
DiagnostykaTag fired bez potwierdzonego requestuFiring w GTM nie gwarantuje dostarczenia danych

Rekomendowana architektura docelowa

Jeżeli celem jest pełna kontrola nad browser + server trackingiem, właściwym kierunkiem jest jedna spójna ścieżka oparta o Customer Events / Web GTM / sGTM, bez równoległego browser trackingu Meta z Shopify Partner Integration.

Shopify Customer Events
        ↓
Web GTM
        ├─ Meta Browser
        ├─ GA4 / Google Ads
        └─ Stape Data Tag
                ↓
              sGTM
                ├─ Meta CAPI
                ├─ Google
                └─ pozostałe destinations

Warunki: jeden event_id dla każdej pary Browser/Server, spójny Consent Mode, osobno odtworzony i przetestowany Purchase oraz bezpieczne zachowanie Meta Catalog / Product Feed.

Plan działań

PriorytetDziałanieRezultat
P0Przywrócić i potwierdzić pełną ścieżkę Purchase → Web GTM → sGTM → Meta CAPI.Stabilny sygnał zakupu
P0Ustalić źródło purchase_webhook i zdecydować, czy druga server-side ścieżka jest potrzebna.Jednoznaczna architektura Purchase
P1Rozdzielić zależność Meta Catalog / Product Feed od źródła trackingu.Możliwość bezpiecznego wyłączenia duplikatów
P1Wyłączyć zbędny Meta browser pipeline.Brak dublowania browser events
P1Ujednolicić event_id i consent handling.Poprawna deduplikacja Browser/Server
P2Przetestować cały funnel w Web GTM, sGTM, Network i Meta Test Events.Potwierdzona jakość danych przed skalowaniem kampanii