Budujemy i łączymy
Automatyzujemy
GA4 i tracking serwerowy
Sprawdzamy Twój pomiar, wdrażamy GA4 i pomiar po stronie serwera oraz porządkujemy zgody marketingowe.
Porządkujemy pomiar, ż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.
Przegląd
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.
Liczba i wartość zamówień w raporcie zgadza się z systemem.
Zdarzenie powstaje przy zapisie zamówienia w bazie, dzięki czemu liczy się każdy zakup.
Wspólny identyfikator zdarzenia pilnuje, żeby ten sam zakup policzył się raz.
Pomiar działa zgodnie ze zgodą, której udzielił użytkownik.
Od przeglądu obecnego stanu, przez pomiar po stronie serwera, po raporty, które realnie wspierają Twoje decyzje o budżecie.
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ć.
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ć.
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.
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.
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.
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.
Podstawy
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.
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
Audyt
Te sytuacje powtarzają się w większości wdrożeń, które przejmujemy — dlatego wiemy, gdzie szukać, i szybko doprowadzamy dane do porządku.
W szczegółach
Deduplikacja zdarzeń
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.
Wydajność
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ę.
Jak pracujemy
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ąć.
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.
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.
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ć.
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
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.
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ć.
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ą.
Audyt pomiaru
Raport pokazuje przychód, którego nie widać w księgowości. Trudno cokolwiek wyłączyć, bo nie wiadomo, co jeszcze przestanie się mierzyć.
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.
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.
Zgody
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.
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.
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.
FAQ
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.
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ć.
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.
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.
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.
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. Opinię prawną wydaje prawnik, a my dostarczamy dokumentację techniczną, na której może się oprzeć.
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.