Porozmawiajmy Zobacz usługi
Usługi

Dane o sprzedaży, którym możesz zaufać przy decyzjach o budżecie

Sprawdzamy Twój pomiar, wdrażamy GA4 i pomiar po stronie serwera oraz porządkujemy zgody marketingowe, żebyś w jednym miejscu widział sprzedaż zgodną z tym, co realnie jest w bazie zamówień. Dzięki temu decyzje o budżecie reklamowym opierasz na pewnych liczbach.

Analityka techniczna

Uzgadniamy statystyki z bazą zamówień, żeby budżet reklamowy opierał się na pewnych liczbach

Często bywa tak, że panel sklepu pokazuje jedną liczbę zamówień, GA4 drugą, a platforma reklamowa trzecią. Wtedy trudno ocenić, którą przyjąć za punkt odniesienia, a decyzje o budżecie zapadają na wyczucie. Zwykle wystarczy uporządkować sposób, w jaki zdarzenia są zbierane i wysyłane, żeby te liczby znów się schodziły.

Pomiar prowadzimy jako część Twojego systemu, dzięki czemu dane pochodzą wprost ze źródła sprzedaży. Zdarzenia zakupowe wysyłamy dwiema drogami, z przeglądarki i z serwera, ze wspólnym identyfikatorem zdarzenia, żeby ten sam zakup policzył się tylko raz. Dane osobowe zabezpieczamy przed wysyłką (tzw. hashowanie, czyli zamiana na nieodwracalny skrót), a całość działa zgodnie ze zgodami, których udzielił użytkownik.

W efekcie dostajesz liczbę, którą można postawić obok raportu sprzedaży bez tłumaczenia, skąd wzięła się różnica. Dzięki temu rozmowa o rentowności kampanii i o tym, który kanał realnie przynosi zamówienia, opiera się na danych, którym ufasz.

Zgodność z bazą

Liczba i wartość zamówień w raporcie zgadza się z systemem

Pomiar z serwera

Zdarzenie powstaje przy zapisie zamówienia w bazie, dzięki czemu liczy się każdy zakup

Jeden zakup w raporcie

Wspólny identyfikator zdarzenia pilnuje, żeby ten sam zakup policzył się raz

Zgody i Consent Mode

Pomiar działa zgodnie ze zgodą, której udzielił użytkownik

Podstawy

Pomiar z przeglądarki i z serwera — jak połączenie obu źródeł daje pełny obraz sprzedaży

To jedno rozróżnienie wyjaśnia większość różnic w statystykach. Warto je poznać, zanim zapadnie decyzja o kolejnym narzędziu, bo zwykle prowadzi wprost do rozwiązania.

Pomiar z przeglądarki liczy zakup, gdy uda się cały łańcuch zdarzeń

Klasyczny pomiar to skrypt uruchamiany w przeglądarce klienta. Żeby zakup został policzony, musi zajść cały łańcuch zdarzeń: skrypt musi się załadować, klient musi wrócić ze strony banku na stronę podziękowania i zostać na niej dość długo, żeby dane zdążyły wyjść. Gdy któreś ogniwo zawiedzie — rozszerzenie blokujące skrypty, zamknięta karta, zerwane połączenie na telefonie — zamówienie zostaje w bazie, a w statystykach może go zabraknąć.

Pomiar po stronie serwera domyka tę lukę. Zdarzenie powstaje w momencie, w którym zamówienie zapisuje się w bazie albo zmienia status na opłacone, więc dane pochodzą wprost ze źródła sprzedaży. Ma to szczególne znaczenie przy płatnościach potwierdzanych powiadomieniem z bramki (tzw. notyfikacja, czyli sygnał od operatora płatności), bo zamówienie bywa opłacane długo po tym, jak klient zamknął sklep.

Pomiar z przeglądarki zostaje przy tym w grze, bo daje kontekst, którego serwer sam nie ma: skąd przyszedł ruch i co użytkownik oglądał po drodze. Dobrze ustawiona konfiguracja łączy oba źródła i pilnuje, żeby ten sam zakup policzył się tylko raz — dzięki temu masz komplet danych i jeden wynik.

Sytuacja Pomiar z przeglądarki Pomiar z serwera
Rozszerzenie blokujące skrypty Zdarzenie w ogóle nie powstaje Powstaje niezależnie od przeglądarki klienta
Klient zamyka kartę zaraz po płatności Dane mogą nie zdążyć wyjść z przeglądarki Wysyłka po zapisie zamówienia w bazie
Płatność potwierdzana notyfikacją z bramki W momencie odsłony status jest jeszcze nieznany Zdarzenie po weryfikacji notyfikacji, z realnym statusem
Wartość zamówienia z rabatem Często liczona z cen katalogowych w szablonie Brana z kwoty zapisanej w zamówieniu
Dane pozwalające dopasować konwersję Wysyłane jawnie albo pomijane Hashowane przed wysyłką, po stronie serwera
Ograniczenia czasu życia identyfikatorów Skrócone przez przeglądarkę, ścieżka się urywa Identyfikator kontrolowany po stronie aplikacji
Zwrot lub anulowanie zamówienia Wartość sprzedaży bywa liczona za wysoko Korekta wysyłana po zmianie statusu

Analityka mierzy dokładnie to, na co pozwala jej konfiguracja. Gdy ustawienia są domyślne, mierzy mniej, niż mogłaby — i właśnie to porządkujemy, żeby dane były kompletne.

Wniosek z audytów pomiaru, od których zaczynamy każde wdrożenie
Zakres

Co wdrażamy

Od przeglądu obecnego stanu, przez pomiar po stronie serwera, po raporty, które realnie wspierają Twoje decyzje o budżecie.

Audyt pomiaru

Sprawdzamy, które znaczniki (tzw. tagi, czyli fragmenty kodu zbierające dane) realnie działają, które zdarzenia się powtarzają, a których brakuje. Porównujemy liczbę i wartość zamówień w narzędziach analitycznych z danymi w bazie i wskazujemy źródło każdej różnicy, żebyś wiedział, którym liczbom możesz zaufać.

GA4 i pomiar e-commerce

Ustawiamy pełną ścieżkę zakupową — od obejrzenia produktu, przez dodanie do koszyka i rozpoczęcie zamówienia, po jego złożenie — z poprawnymi identyfikatorami produktów, wariantami, walutą i wartością po rabatach. Konfigurację prowadzimy spójnie między rynkami i wersjami językowymi, żeby dane z każdego z nich dało się porównywać.

Meta Pixel i Conversions API

Pomiar prowadzimy dwiema drogami, z przeglądarki i z serwera (Conversions API to kanał, którym dane o zakupie idą wprost z Twojego zaplecza do platformy reklamowej), ze wspólnym identyfikatorem zdarzenia, żeby ten sam zakup policzył się raz. Dane osobowe zabezpieczamy przed wysyłką, obsługujemy zwroty i korekty, a pomiar działa nawet przy blokadach po stronie klienta.

Consent Mode i zgody

Stan zgód przekazujemy do narzędzi pomiarowych i respektujemy go także po stronie serwera, dzięki czemu pomiar działa zgodnie z wyborem użytkownika. Do tego dokładamy dostępny na stronie sposób zmiany decyzji o zgodach oraz politykę prywatności z prawdziwą tabelą plików cookies, żebyś był spokojny o zgodność z przepisami.

Pliki produktowe i ich sprawdzanie

Budujemy pliki z ofertą (tzw. feedy, czyli listę produktów w formacie, który czytają systemy reklamowe) pod Google Merchant Center i narzędzia marketing automation: grupujemy warianty, uzupełniamy wymagane atrybuty i sprawdzamy plik przed publikacją. Odrzucone pozycje trafiają do raportu z konkretnym powodem, dzięki czemu Twoja oferta pokazuje się w reklamach w komplecie.

Zestawienia i alerty

Przygotowujemy cykliczne raporty wprost z bazy i z narzędzi analitycznych, dostarczane mailem lub w panelu, żebyś miał jeden spójny obraz sprzedaży. Do tego stale obserwujemy napływ zdarzeń, więc jeśli pomiar przestanie działać, dowiesz się tego samego dnia i nie stracisz danych za dłuższy okres.

Audyt

Usterki pomiaru, które najczęściej znajdujemy w audycie

Te sytuacje powtarzają się w większości wdrożeń, które przejmujemy — dlatego wiemy, gdzie szukać, i szybko doprowadzamy dane do porządku.

  • Ten sam zakup policzony dwa razy, bo pomiar z przeglądarki i z serwera nie ma wspólnego identyfikatora zdarzenia
  • Wartość zamówienia wysyłana z cen katalogowych, bez rabatów, kodów promocyjnych i kosztu dostawy
  • Zdarzenie zakupu powstaje tylko na stronie podziękowania, do której część klientów już nie wraca
  • Ten sam zakup liczony ponownie przy każdym odświeżeniu strony podziękowania, bo brakuje klucza z numerem zamówienia
  • Inny identyfikator produktu w pliku z ofertą, inny w zdarzeniu, przez co reklamy nie mają czego dopasować do katalogu
  • Brak zdarzeń dodania do koszyka i rozpoczęcia zamówienia, przez co ścieżka zakupowa urywa się w połowie
  • Skrypty pomiarowe uruchamiane w złej kolejności względem zgody użytkownika, przez co milczą także po jej udzieleniu
  • Dane osobowe przekazywane do platform reklamowych bez zabezpieczenia, czasem widoczne w adresie strony
  • Ruch wewnętrzny, roboty sieciowe i narzędzia monitorujące wliczane do statystyk sprzedaży i skuteczności
  • Brak alertu o przerwaniu napływu zdarzeń, przez co przerwa w pomiarze wychodzi na jaw dopiero w raporcie miesięcznym
GA4 Meta Pixel Conversions API Consent Mode Google Merchant Center Platformy CDP Marketing automation Node.js PHP PostgreSQL

Zakup jedzie dwiema drogami, a w raporcie zostaje jeden — dzięki wspólnemu identyfikatorowi zdarzenia

Wysyłanie zakupu równolegle z przeglądarki i z serwera daje odporność na blokady, a wspólny identyfikator zdarzenia pilnuje, żeby to samo zamówienie policzyło się tylko raz. Nadajemy go przy tworzeniu zamówienia, zapisujemy razem z nim i używamy w obu drogach, dzięki czemu platforma reklamowa dopasowuje oba sygnały i zostawia jeden zakup — Ty widzisz w raporcie liczbę zgodną z bazą.

Tak samo dbamy o dane, które pozwalają przypisać zakup do użytkownika. Adres e-mail czy numer telefonu zabezpieczamy przed wysyłką — zamieniamy je na nieodwracalny skrót (tzw. hashowanie), żeby dopasowanie działało bez przekazywania danych czytelnych dla człowieka. Gdy brakuje zgody marketingowej, zdarzenie nie zostaje wysłane, również z serwera, więc pomiar działa zgodnie z prawem.

Do tego dbamy o porządek w danych: powtórzone powiadomienie z bramki płatniczej nie utworzy drugiego zakupu, zwrot skutkuje korektą wartości, a identyfikatory produktów są spójne między sklepem, plikiem z ofertą i zdarzeniami. Dzięki temu Twoje liczby pozostają wiarygodne przez cały czas.

event_id Hashowanie PII Webhooki Idempotencja MedusaJS Next.js WooCommerce

Szybsza strona to też pełniejsze dane — sprawdzamy wydajność i Core Web Vitals

Szybkość strony wpływa na wyniki podwójnie: gdy treść ładuje się wolno, część użytkowników wychodzi wcześniej, a skrypty pomiarowe mają mniej czasu na wysłanie zdarzeń. Dlatego audyt pomiaru prowadzimy razem z audytem wydajności — badamy Core Web Vitals, czyli mierzone przez Google wskaźniki szybkości i stabilności strony, na realnych urządzeniach i przy realnej przepustowości, żeby przyspieszenie przełożyło się na więcej dokończonych zakupów i pełniejsze dane.

Sprawdzamy, ile zewnętrznych skryptów naprawdę musi się ładować i w jakiej kolejności, czy obrazy mają właściwe formaty i wymiary oraz czy dane nie są pobierane w nadmiarze przy każdym wejściu. Weryfikujemy też wyświetlanie w Chrome, Safari i Chromium, które potrafią różnie potraktować ten sam układ, oraz działanie na wąskich ekranach, od 320 pikseli w górę, żeby sklep wyglądał tak samo na każdym telefonie.

W efekcie dostajesz listę uporządkowaną według stosunku efektu do nakładu: co poprawić najpierw, co można odłożyć, a co wymaga zmiany po stronie zaplecza — dzięki temu wiesz, od czego zacząć, żeby najszybciej zobaczyć różnicę.

Core Web Vitals Testy w kilku przeglądarkach 320 / 360 / 390 px nginx Next.js
Jak pracujemy

Od audytu do danych potwierdzonych na realnym ruchu

01

Audyt

Spisujemy działające znaczniki i zdarzenia, a dane z narzędzi analitycznych zestawiamy z liczbą oraz wartością zamówień w bazie. Do każdej różnicy podajemy jej przyczynę, żebyś wiedział, skąd się bierze i jak ją domknąć.

02

Plan pomiaru

Ustalamy listę zdarzeń, ich parametry i wiarygodne źródło dla każdej wartości, żeby liczby miały jasne pochodzenie. Zapisujemy, co idzie z przeglądarki, co z serwera, jak pilnujemy, żeby zakup policzył się raz, i które zdarzenia zależą od zgody marketingowej.

03

Wdrożenie

Budujemy warstwę pomiarową na osobnej kopii sklepu, na której sprawdzamy zmiany bez ryzyka dla działającej sprzedaży: zdarzenia w aplikacji, wysyłka z serwera, obsługa zgód, zabezpieczenie danych i korekty statusów. Na żywy sklep włączamy to etapami, z możliwością cofnięcia zmiany, żeby wdrożenie było bezpieczne.

04

Walidacja na realnym ruchu

Przez ustalony okres porównujemy zdarzenia z zamówieniami w bazie, kanał po kanale, i domykamy różnice, aż liczby się schodzą. Na koniec zostawiamy stałą obserwację napływu zdarzeń oraz alerty, żebyś od razu wiedział, gdyby pomiar zaczął się rozjeżdżać.

Sytuacje z audytów

Trzy sytuacje, w których doprowadzamy raport do zgodności z bazą zamówień

Każda z nich powtarza się w wielu sklepach, a poniżej jest droga, którą przywracamy w nich zgodność liczb — dzięki temu zyskujesz dane, na których można polegać przy budżecie.

Pomiar po stronie serwera

Zakup jest w panelu zamówień, a brakuje go w raporcie

Jak to wygląda

Panel zamówień pokazuje więcej zakupów niż GA4 i menedżer reklam. Różnica rośnie w kampaniach płatnych, maleje w ruchu bezpośrednim.

Co jest pod spodem

Zdarzenie zakupu wysyła przeglądarka ze strony podziękowania. Gdy skrypt jest zablokowany, karta zamknięta albo płatność potwierdza się już po wyjściu ze sklepu, zdarzenie może w ogóle nie powstać.

Jak to rozkładamy

Przenosimy pomiar zakupu na serwer i wiążemy go ze zmianą statusu zamówienia w bazie, żeby liczył się każdy zakup. Wysyłkę z przeglądarki zostawiamy dla kontekstu, a wspólny identyfikator zdarzenia pilnuje, żeby zakup policzył się raz. Dane osobowe zabezpieczamy, a zdarzenia marketingowe działają zgodnie ze zgodą.

Meta Conversions API Node.js Webhooki PostgreSQL
Audyt pomiaru

Sprzedaż w raporcie wyższa niż wpływy na koncie

Jak to wygląda

Raport pokazuje przychód, którego nie widać w księgowości. Trudno cokolwiek wyłączyć, bo nie wiadomo, co jeszcze przestanie się mierzyć.

Co jest pod spodem

Zdarzenie zakupu bywa wpięte w trzech miejscach naraz: w szablonie, w menedżerze znaczników i we wtyczce. Kolejne wdrożenia dokładały swoje źródło, a poprzednie zostawało. Do tego odświeżenie strony podziękowania liczy ten sam zakup ponownie.

Jak to rozkładamy

Spisujemy każde źródło zdarzeń i zestawiamy je z numerami zamówień z bazy, dzień po dniu. Źródła wyłączamy pojedynczo, mierząc wpływ każdego kroku, żeby nic potrzebnego nie zniknęło. Zakup dostaje klucz z numerem zamówienia, dzięki czemu powtórka już się nie liczy.

GA4 Menedżer tagów WooCommerce Audyt pomiaru
Zgody

Pomiar spadł o rząd wielkości po wymianie okna zgód

Jak to wygląda

Z dnia na dzień liczba zdarzeń spada o rząd wielkości. Sprzedaż w sklepie utrzymuje się na tym samym poziomie, więc różnica leży po stronie pomiaru.

Co jest pod spodem

Skrypty pomiarowe czekają na sygnał o rozstrzygnięciu zgody. Przy części wyborów użytkownika ten sygnał nie przychodzi, więc narzędzia milczą także wtedy, gdy zgoda została udzielona.

Jak to rozkładamy

Ustalamy stan zgód przed załadowaniem narzędzi i aktualizujemy go po każdej zmianie decyzji, również w wysyłce z serwera, żeby pomiar działał zgodnie z wyborem użytkownika. Zdarzenia sprzed rozstrzygnięcia odkładamy w kolejce. Stała obserwacja napływu wyłapie kolejny taki spadek tego samego dnia, w którym wystąpi.

Consent Mode GA4 Next.js Monitoring zdarzeń
FAQ

Najczęstsze pytania o analitykę techniczną

Czy tracking serwerowy pozwala mierzyć użytkowników, którzy nie wyrazili zgody?

Nie. Zgoda dotyczy celu, w jakim przetwarzane są dane, więc obowiązuje niezależnie od tego, czy zdarzenie wychodzi z przeglądarki, czy z serwera — jeśli użytkownik odmówił zgody marketingowej, zdarzenie nie zostaje wysłane również z serwera. Pomiar po stronie serwera pomaga w innej sprawie: obejmuje sytuacje, w których zgoda została udzielona, a zdarzenie i tak nie dotarło, bo przeglądarka je zablokowała albo klient zamknął kartę przed jego wysłaniem. Dzięki temu masz komplet danych bez naruszania wyboru użytkownika.

Mamy już wdrożone GA4. Po co nam audyt?

Bo samo wdrożenie nie przesądza jeszcze, że dane są poprawne. W audycie porównujemy liczbę i wartość zamówień w narzędziach analitycznych z tym, co jest w bazie, i sprawdzamy najczęstsze źródła różnic: brakujące zdarzenia na ścieżce zakupowej, wartości liczone przed rabatem, powtórzone znaczniki z poprzednich wdrożeń, ruch wewnętrzny wliczany do sprzedaży. Dostajesz listę różnic razem z przyczyną i propozycją naprawy, dzięki czemu wiesz, którym liczbom możesz zaufać.

Czy po wdrożeniu dane będą się zgadzać co do jednego zamówienia?

Co do jednego zamówienia trudno to obiecać uczciwie. Narzędzia analityczne mają własne sposoby przypisywania sprzedaży, okna czasowe i metody liczenia wizyt, więc drobne różnice są naturalne. Celujemy w to, żeby różnica była mała, stabilna i wyjaśniona — wtedy raport da się porównywać między miesiącami i traktować jako pewną podstawę decyzji o budżecie.

Czy trzeba zmieniać sklep, żeby wdrożyć pomiar serwerowy?

Zazwyczaj nie. Warstwę pomiarową dopinamy do istniejącej aplikacji — na MedusaJS, Shopify, WooCommerce, WordPressie albo własnym zapleczu w Node.js, PHP czy Pythonie — więc Twój sklep działa dalej bez przebudowy. Potrzebujemy dostępu do momentu, w którym zamówienie powstaje lub zmienia status, oraz do powiadomień z bramki płatniczej. Jeśli takich punktów zaczepienia brakuje, dopisujemy je przy okazji, żeby wdrożenie było spokojne dla działającej sprzedaży.

Jak dowiemy się, że pomiar przestał działać?

Z alertu. Stale obserwujemy napływ kluczowych zdarzeń i porównujemy go z liczbą zamówień w bazie. Jeśli strumień się urwie albo różnica przekroczy ustalony próg, wysyłamy powiadomienie mailem lub na kanał zespołu, więc reagujesz tego samego dnia. Ma to duże znaczenie, bo przerwy w pomiarze najczęściej pojawiają się przy wdrożeniu nowej wersji sklepu, a stała obserwacja pozwala domknąć je od razu, zanim urośnie luka w danych.

Czy zajmujecie się też stroną prawną pomiaru?

W zakresie technicznym tak. Przygotowujemy politykę prywatności z prawdziwą tabelą wykorzystywanych plików cookies, listą odbiorców danych i informacją o przekazywaniu ich poza EOG, a także dostępny na stronie sposób zmiany zgód w każdym momencie. Zapisy z dokumentu zestawiamy z tym, co faktycznie robi kod, a różnice wypisujemy z nazwą skryptu, żebyś miał pewność, że deklaracja pokrywa się z działaniem. Opinii prawnej nie wydajemy — dostarczamy dokumentację techniczną, na której może się oprzeć prawnik.

Chcesz mieć pewność co do swoich liczb?

Napisz, czego używasz do pomiaru i gdzie widzisz różnicę w liczbach. Zaczniemy od audytu, który pokaże, skąd bierze się różnica i ile kosztuje jej domknięcie, żebyś podejmował decyzje o budżecie na pewnych danych.

Porozmawiajmy