Kiedy warto wdrożyć server-side tagging i dla kogo się opłaca?
Server-side tagging warto wdrożyć wtedy, gdy realne straty w danych o konwersjach - wywołane blokadami ITP w Safari, adblockerami i skróconym życiem plików cookie - zaczynają zniekształcać decyzje algorytmów Google Ads, a skala ruchu i wydatków uzasadnia stały koszt utrzymania kontenera serwerowego. W praktyce to moment, w którym różnica między konwersjami widocznymi w przeglądarce a tymi domkniętymi realnie przekracza kilkanaście procent, a konto opiera optymalizację na Smart Bidding, konwersjach rozszerzonych lub licytacji opartej na wartości. Dla małego konta z niewielkim ruchem tagowanie po stronie serwera bywa przedwczesne; dla sklepu z dużym udziałem iOS - często spóźnione.
- Kiedy warto wdrożyć server-side tagging?
- Dla kogo server-side tagging się opłaca?
- Kto może jeszcze poczekać z tagowaniem po stronie serwera?
- Jak sprawdzić, ile konwersji naprawdę tracisz?
- Ile realnie odzyskujesz dzięki kontenerowi serwerowemu?
- Ile to kosztuje, a ile jest warte?
- Prosty test decyzyjny: czy server-side tagging opłaca się u Ciebie?
- Dlaczego Enhanced Conversions i value-based bidding przechylają szalę?
- Najczęstszy błąd przy decyzji o wdrożeniu
- Podsumowanie
- Źródła i dokumentacja
Najczęstsze pytanie, jakie słyszę po prezentacji korzyści z przeniesienia tagów na serwer, brzmi prosto: „dobrze, ale czy mi się to opłaci?”. I słusznie, bo to pytanie o próg, nie o technologię. Bo tagowanie po stronie serwera nie jest celem samym w sobie - jest inwestycją w jakość danych, która ma sens tylko wtedy, gdy tracisz dość danych, by ta inwestycja się zwróciła. W tym artykule pokazuję, jak wyznaczyć ten próg dla własnego konta, komu wdrożenie realnie się opłaca, a kto spokojnie może poczekać.
Wnioski, które decydują o tym, czy kontener serwerowy zwróci się na Twoim koncie.
-
Server-side tagging opłaca się dopiero wtedy, gdy straty danych przekraczają koszt kontenera
Konto z niewielkim ruchem, marginalnym udziałem Safari i kampaniami prowadzonymi ręcznie zwykle nie odrobi hostingu kontenera serwerowego. Próg przesuwa się jednak szybko - wystarczy wzrost ruchu albo przejście na licytację automatyczną.
-
Safari ogranicza cookie pierwszej strony ustawiane skryptem do siedmiu dni w ramach ITP
WebKit w dokumentacji ITP podaje limit 7 dni dla cookie ustawianych skryptem, a w części scenariuszy 24 godzin (stan na 2026 rok). Konta z długim cyklem zakupu gubią przez to ścieżki wielosesyjne.
-
Koszt kontenera serwerowego to wydatek infrastrukturalny, nie część budżetu reklamowego
Stape.io startuje od około 20 USD miesięcznie przy darmowym progu do 10 tys. żądań, a Google Cloud Run przy realnym ruchu zwykle od 90 do 120 USD (cenniki na 2026 rok).
-
Rozjazd między GA4 a Google Ads powyżej kilkunastu procent sygnalizuje realną utratę konwersji
Przykład ilustracyjny (liczby poglądowe): sklep z artykułami ogrodowymi ma 23% różnicy między transakcjami w GA4 a konwersjami Google Ads przy 41% ruchu z urządzeń Apple. Taki układ liczb przesądza decyzję szybciej niż jakikolwiek benchmark.
-
Konta na Smart Bidding i konwersjach rozszerzonych zyskują na kontenerze serwerowym najwięcej
Smart Bidding uczy się na sygnale konwersji, a konwersje rozszerzone na dopasowaniu danych pierwszej strony. Każdy brakujący procent zdarzeń przesuwa stawki w złą stronę, więc kompletność pomiaru wprost przekłada się na koszt pozyskania.
-
Server-side tagging nie odzyska zdarzeń zablokowanych, zanim żądanie opuści przeglądarkę użytkownika
Kontener serwerowy domyka pomiar dopiero po stronie serwera, więc blokada transportu w przeglądarce zamyka sprawę wcześniej. Wdrożenie bez policzenia realnych strat kończy się kosztem i dodatkowym punktem awarii.
Kiedy warto wdrożyć server-side tagging?
Server-side tagging warto wdrożyć, gdy tracisz mierzalny odsetek konwersji przez blokady przeglądarek, a Twoje kampanie optymalizują się automatycznie na podstawie tych danych. Prosto: gdy niedokładny sygnał zaczyna kosztować Cię pieniądze w licytacji, a nie tylko psuć raporty. Moment, w którym niedokładny sygnał zaczyna kosztować w licytacji, jest granicą, od której analityka internetowa przestaje być kwestią raportów, a staje się kwestią budżetu.
Decyzja rzadko zależy od jednego czynnika. Składa się na nią kilka sygnałów, które trzeba czytać razem. Jeden duży sklep może potrzebować serwera bardziej niż dziesięć małych razem wziętych - bo u niego każdy procent utraconych konwersji to realna kwota wpompowana w gorszą optymalizację Smart Bidding.
- Rozjazd danych: różnica między konwersjami w GA4 a Google Ads przekracza kilkanaście procent i utrzymuje się w czasie.
- Udział iOS/Safari: znacząca część ruchu pochodzi z urządzeń Apple, gdzie ITP najmocniej tnie okno atrybucji.
- Automatyczna licytacja: konto opiera się na Smart Bidding, tCPA lub tROAS - algorytm karmi się sygnałem konwersji, więc jego jakość wprost przekłada się na wynik.
- Skala wydatków: budżet i wolumen konwersji są na tyle duże, że kilkuprocentowy odzysk danych to zauważalna wartość, a nie błąd zaokrąglenia.
- Dane pierwszej strony: planujesz lub już wykorzystujesz konwersje rozszerzone albo licytację opartą na wartości - a te mechanizmy żywią się kompletnym first-party.
Jeśli rozpoznajesz u siebie co najmniej trzy z tych sygnałów naraz, jesteś już za progiem. Jeśli chcesz sprawdzić, jak ten rozjazd wygląda na Twoim koncie, dokładnie to analizuję podczas audytu pomiaru.
Czy wiesz, że…
Przeglądarka Safari w ramach ITP skraca życie plików cookie pierwszej strony ustawianych skryptem do maksymalnie 7 dni, a w części scenariuszy do 24 godzin. To dlatego konta z dużym udziałem iOS „gubią” konwersje długiego cyklu, mimo że kampanie realnie działają.
Dla kogo server-side tagging się opłaca?
Server-side tagging opłaca się najbardziej sklepom e-commerce ze stałym ruchem, kontom z dużym udziałem urządzeń Apple oraz firmom, które budują licytację na wartości konwersji. Wspólny mianownik jest jeden: dane są u nich paliwem, a nie ozdobą raportu.
Jestem przekonany, że najwięcej zyskują ci, u których jakość sygnału bezpośrednio steruje wydatkiem. Gdy algorytm rozdziela budżet między produkty i odbiorców na podstawie tego, co „widzi” jako konwersję, każda brakująca transakcja przesuwa jego decyzje w złą stronę. Poniżej profile, które najczęściej wychodzą na wdrożeniu na plus.
Sześć sytuacji, w których kontener serwerowy przestaje być gadżetem, a staje się realną dźwignią wyniku.
Sklep z powtarzalnym wolumenem transakcji, gdzie kilka procent odzyskanych zakupów to co miesiąc konkretna kwota przychodu przypisanego kampaniom.
Konta, gdzie użytkownicy Safari to znacząca część ruchu - tam ITP tnie okno atrybucji najboleśniej, a kontener first-party łagodzi straty.
Konta na tROAS i licytacji opartej na wartości, którym zależy na dokładnym, kompletnym sygnale wartości koszyka, nie tylko liczbie konwersji.
Firmy korzystające z konwersji rozszerzonych, gdzie hashowanie danych pierwszej strony po stronie serwera daje pełniejszą kontrolę nad PII.
Branże z odbiorcami technicznymi, gdzie adblockery i rozszerzenia prywatności blokują skrypty third-party częściej niż w rynku masowym.
Modele, gdzie decyzja zapada w kilku sesjach na przestrzeni dni - krótkie życie cookie w Safari najczęściej gubi właśnie takie ścieżki.
Zwróć uwagę, że w każdym z tych profili powtarza się to samo: dane sterują pieniędzmi. To dokładnie sytuacja, którą rozkładam na czynniki podczas audytu pomiaru - sprawdzam, ile realnie tracisz i czy serwer to odrobi.
Kto może jeszcze poczekać z tagowaniem po stronie serwera?
Z wdrożeniem może poczekać ten, u kogo straty w danych są niewielkie, a konto nie opiera się na automatycznej licytacji. Jeśli ruch jest mały, udział iOS marginalny, a kampanie prowadzisz ręcznie, koszt utrzymania kontenera serwerowego łatwo przewyższy wartość odzyskanych konwersji.
Uważam, że wdrażanie serwera „na zapas”, zanim pojawi się realna strata do odrobienia, to najczęstszy błąd entuzjastów technologii. SST łatwo potraktować jako domyślny standard dla każdego, tymczasem dla części kont to przedwczesny wydatek, który nie zmienia wyniku, a dokłada punkt do utrzymania i debugowania.
- Bardzo mały ruch: jeśli miesięczny wolumen zdarzeń mieści się w darmowym progu stape.io, a konwersji są dziesiątki, kilka procent odzysku to ułamek, nie dźwignia.
- Marginalny udział Safari: gdy większość ruchu to Android i Chrome na desktopie, straty z ITP są mniejsze, a client-side wciąż wystarcza.
- Kampanie prowadzone ręcznie: bez Smart Bidding algorytm nie „karze” Cię za niekompletny sygnał w takim stopniu jak przy tCPA czy tROAS.
- Brak zaplecza technicznego: jeśli nie masz kto skonfigurować i utrzymać kontenera, a budżet nie pozwala na specjalistę, lepiej najpierw uporządkować pomiar client-side.
- Świeży start: nowe konto bez historii konwersji najpierw potrzebuje poprawnego server-side tagging dopiero jako kolejnego kroku, nie pierwszego.
To nie znaczy „nigdy”. Znaczy „jeszcze nie teraz”. Próg opłacalności potrafi zostać przekroczony w kilka miesięcy, gdy ruch urośnie albo gdy przełączysz kampanie na licytację automatyczną. Dlatego decyzję warto rewidować, a nie zamykać raz na zawsze.
Jak sprawdzić, ile konwersji naprawdę tracisz?
Ile konwersji tracisz, sprawdzisz zestawiając trzy liczby: rozjazd między GA4 a Google Ads, udział ruchu z Safari/iOS oraz odsetek sesji z aktywnym adblockerem. Dopiero razem pokazują, ile sygnału ucieka, zanim client-side zdąży go zapisać.
Przykład ilustracyjny (liczby poglądowe): w sklepie z artykułami ogrodowymi różnica między liczbą transakcji w GA4 a konwersjami raportowanymi w Google Ads sięga 23%, a udział ruchu z urządzeń Apple wynosi 41%. To nie przypadek - to mapa strat. Poniższy rozkład pokazuje, jak taka struktura ruchu przekłada się na ryzyko niedomierzenia.
Im większy udział segmentów podatnych na ITP i blokowanie skryptów, tym więcej danych ucieka przy pomiarze wyłącznie po stronie przeglądarki.
Sama diagnoza jest prostsza, niż się wydaje. Nie potrzebujesz do niej serwera - potrzebujesz kilku raportów, które i tak masz pod ręką.
- Porównaj GA4 z Google Ads - zestaw liczbę konwersji tego samego typu w obu narzędziach za ten sam okres i policz różnicę procentową.
- Sprawdź udział iOS/Safari - w GA4 w raporcie technicznym odczytaj udział przeglądarki Safari i systemu iOS w sesjach.
- Oszacuj ruch blokowany - różnica między wejściami z serwera a zdarzeniami zarejestrowanymi w GA4 przybliża skalę blokowania skryptów.
- Odnieś stratę do wydatku - przelicz brakujące konwersje na wartość i zestaw ją z miesięcznym kosztem hostingu kontenera.
Czy wiesz, że…
Rozjazd między GA4 a Google Ads nie zawsze oznacza utratę danych - część różnicy wynika z odmiennych modeli atrybucji i okien konwersji obu narzędzi. Dlatego rozjazd trzeba interpretować w kontekście, a nie brać każdego punktu procentowego za stratę. Różnice między GA4 a Google Ads opisuję osobno.
Ile realnie odzyskujesz dzięki kontenerowi serwerowemu?
Realny odzysk konwersji dzięki kontenerowi serwerowemu to zwykle rząd od kilku do kilkunastu procent - zależnie od udziału iOS, długości cyklu zakupowego i tego, jak dużo danych gubił dotychczasowy pomiar client-side. Serwer nie tworzy konwersji, których nie było; odzyskuje te, które client-side gubił po drodze.
To ważne rozróżnienie, bo w sieci krąży dużo marketingowej mgły. Server-side tagging nie „mnoży” konwersji. Domyka pomiar tam, gdzie przeglądarka blokowała cookie albo skrypt. Poniższe wskaźniki pokazują, jak różne bywają efekty w zależności od profilu konta - to rzędy z moich obserwacji, nie obietnica dla każdego.
Wypełnienie koła to przybliżony odsetek odzyskanego sygnału względem strat sprzed wdrożenia. Rzędy z obserwacji, nie gwarancje.
Ostatni wskaźnik jest tu najważniejszy: server-side tagging nie odzyska danych, gdy transport zostanie zablokowany na poziomie przeglądarki, zanim żądanie w ogóle opuści urządzenie. To granica uczciwości, o której rzadko się pisze. Pełen mechanizm działania i konfigurację opisuję w przewodniku o server-side tagging dla Google Ads.
Ile to kosztuje, a ile jest warte?
Koszt server-side tagging to głównie hosting kontenera serwerowego i czas wdrożenia: stape.io od ok. 20 USD/mies. (z darmowym progiem do ok. 10 tys. żądań miesięcznie), a Google Cloud (Cloud Run) przy realnym ruchu zwykle od ok. 90-120 USD/mies. Do tego dochodzi jednorazowa konfiguracja i utrzymanie. Opłacalność to prosty rachunek: koszt miesięczny kontra wartość odzyskanych konwersji.
Rekomenduję liczyć to konkretnie, a nie „na oko”. Jeśli serwer odzyska konwersje o wartości wielokrotnie wyższej niż jego utrzymanie, decyzja jest oczywista. Jeśli koszt hostingu zjada większość odzyskanej wartości - to sygnał, że jeszcze nie czas. Poniżej składniki, które trzeba zsumować, żeby rachunek był uczciwy.
- Hosting kontenera: stape.io od ok. 20 USD/mies. lub Google Cloud zwykle od ok. 90-120 USD/mies. przy realnym ruchu - to nie budżet reklamowy, tylko infrastruktura.
- Transfer i skalowanie: przy dużym wolumenie żądań rośnie zużycie zasobów, więc koszt hostingu jest funkcją ruchu, nie stałą.
- Subdomena i SSL: mapowanie własnej subdomeny first-party i certyfikat - koszt zwykle marginalny, ale konieczny dla poprawnego kontekstu.
- Wdrożenie i utrzymanie: czas na konfigurację, walidację oraz późniejsze debugowanie kontenera; to najczęściej największa pozycja przy starcie.
- Wartość odzysku: po drugiej stronie równania - brakujące konwersje przeliczone na przychód i lepsze decyzje Smart Bidding, które karmi kompletniejszy sygnał.
Ważna uwaga porządkowa: nie myl kosztu hostingu z budżetem kampanii. Minimalny sensowny budżet reklamowy na start współpracy to zupełnie inna pozycja niż 20 czy 120 USD za kontener. To dwa różne rachunki, które trzeba prowadzić osobno.
Prosty test decyzyjny: czy server-side tagging opłaca się u Ciebie?
Najprostszy test decyzyjny to cztery pytania: czy tracisz dane, czy masz dużo iOS, czy licytujesz automatycznie i czy skala uzasadnia koszt. Trzy odpowiedzi „tak” zwykle przechylają szalę na korzyść wdrożenia. Cztery - przestaje być pytaniem „czy”, a staje się „kiedy”.
- Czy tracisz dane? Rozjazd GA4 kontra Google Ads przekracza kilkanaście procent i się utrzymuje - jeśli tak, dodaj punkt.
- Czy masz dużo iOS? Udział Safari/iOS jest znaczący w Twoim ruchu - jeśli tak, dodaj punkt.
- Czy licytujesz automatycznie? Kampanie działają na Smart Bidding, tCPA lub tROAS - jeśli tak, dodaj punkt.
- Czy skala uzasadnia koszt? Wartość odzyskanych konwersji w miesiącu przewyższa koszt hostingu kontenera - jeśli tak, dodaj punkt.
Zsumuj punkty i zważ argumenty. Poniższe zestawienie pokazuje, jak w typowym średnim koncie e-commerce rozkładają się racje za i przeciw - z wagami, bo nie każdy argument znaczy tyle samo.
Waga 5/5 to argument, który sam potrafi przesądzić decyzję; 2/5 - niuans, który dokłada się do całości.
Werdykt: Dla sredniego e-commerce z licytacja automatyczna i realnym udzialem iOS argumenty ZA zwykle przewazaja - koszt i prog techniczny sa realne, ale odrabialne.
Czy wiesz, że…
Model hybrydowy pozwala uruchomić kontener serwerowy równolegle z dotychczasowym pomiarem client-side. Dzięki temu porównujesz oba źródła na żywo, zanim zdecydujesz o pełnym przełączeniu - i test decyzyjny opierasz na własnych liczbach, nie na cudzych benchmarkach.
Dlaczego Enhanced Conversions i value-based bidding przechylają szalę?
Konwersje rozszerzone i licytacja oparta na wartości przechylają szalę na korzyść serwera, bo obie techniki żywią się kompletnymi, dokładnymi danymi pierwszej strony. Im więcej sygnału gubi client-side, tym słabiej działają - a kontener serwerowy domyka właśnie ten brakujący fragment.
W praktyce te dwa mechanizmy najczęściej rozstrzygają decyzję. Gdy konwersje rozszerzone hashują dane pierwszej strony po stronie serwera, masz pełniejszą kontrolę nad tym, jakie parametry PII w ogóle opuszczają Twoją infrastrukturę - to argument i za jakością, i za zgodnością z RODO. A value-based bidding bez kompletnego sygnału wartości koszyka po prostu licytuje w ciemno.
- Kompletność sygnału wartości: tROAS optymalizuje na wartość konwersji - brakujące transakcje zaniżają uczoną wartość i psują licytację.
- Kontrola PII na serwerze: hashowanie i filtrowanie parametrów po stronie serwera to realna minimalizacja danych zgodna z duchem RODO.
- Trwalszy identyfikator first-party: kontener na własnej subdomenie wydłuża życie cookie, co poprawia dopasowanie konwersji rozszerzonych.
Jeśli Twoje konto już opiera się na którejś z tych technik, próg opłacalności masz zwykle przekroczony - bo płacisz za zaawansowaną optymalizację, której nie karmisz pełnym paliwem. To dokładnie ten wzorzec, który wychodzi podczas audytu pomiaru.
Najczęstszy błąd przy decyzji o wdrożeniu
Najczęstszy błąd to wdrożenie server-side tagging „bo trend”, bez policzenia realnej straty i wartości odzysku. Serwer staje się wtedy kosztem i punktem awarii, a nie dźwignią - bo rozwiązuje problem, którego dane nie potwierdzają.
Częsty scenariusz: firma stawia kontener serwerowy, po czym nie waliduje go poprawnie - i kontener przez tygodnie działa z błędem transportu, gubiąc więcej danych niż stary client-side. To gorszy scenariusz niż brak serwera. Uważam, że źle utrzymany kontener jest realnym ryzykiem, nie tylko zmarnowanym wydatkiem. Poniżej pułapki, które widuję najczęściej.
- Decyzja bez liczb: wdrożenie na podstawie artykułu, a nie własnego rozjazdu danych i udziału iOS.
- Brak walidacji: uruchomienie kontenera bez trybu Preview i testu transportu - błąd, który cicho gubi konwersje.
- Podwójne liczenie: równoległy pomiar web i serwer bez deduplikacji, co zawyża konwersje i myli licytację.
- Ignorowanie zgody: traktowanie serwera jako sposobu na obejście Consent Mode - to droga do niezgodności z RODO, nie zaleta.
- Brak utrzymania: postawienie kontenera i porzucenie go bez monitoringu logów i aktualizacji tagów.
Jeśli rozpoznajesz któryś z tych wzorców u siebie - albo podejrzewasz, że Twój serwer działa, ale nie wiesz, czy poprawnie - to sygnał do audytu, nie do kolejnej wtyczki.
Podsumowanie
Server-side tagging nie jest ani modą, ani obowiązkiem - jest inwestycją w jakość danych, która ma sens tam, gdzie danych realnie brakuje. Próg opłacalności wyznaczają trzy rzeczy: skala strat, udział iOS i to, czy Twoje kampanie licytują automatycznie. Gdy te trzy sygnały grają razem, kontener serwerowy zwraca się szybko i wyraźnie.
Przestań pytać „czy wszyscy już to mają?”. Zacznij pytać „ile konwersji tracę co miesiąc i czy serwer to odrobi?”. To przesunięcie perspektywy - z technologii na rachunek - zmienia wszystko. Bo tagowanie po stronie serwera to nie zakup narzędzia, tylko decyzja o tym, na jak dokładnych danych chcesz opierać wydatek reklamowy.
Jeśli nie masz pewności, po której stronie progu jesteś, zacznij od diagnozy: porównaj GA4 z Google Ads, sprawdź udział Safari i policz wartość rozjazdu. Ta jedna godzina analizy powie Ci więcej niż dziesięć poradników. A jeśli chcesz, żebym zrobił to razem z Tobą na Twoim koncie - od tego zaczynam każdy audyt pomiaru.
Czy ten artykuł był dla Ciebie pomocny?
Oceń go w skali od 1 do 5. Dzięki temu wiem, które tematy rozwijać.
Brak ocen. Twoja będzie pierwsza.
Źródła i dokumentacja
Decyzja o kontenerze serwerowym to rachunek strat, odzysku i kosztów, dlatego zebrałem cztery źródła, które dają liczby do każdej z tych trzech części. Trzy z nich to materiały niezależne od Google, czwarte to dokumentacja infrastruktury, na której ten koszt realnie powstaje.
Pięć obszarów audytu pomiaru w Google Ads
Przegląd pięciu miejsc, w których konta gubią dane: duplikaty konwersji, brak konwersji rozszerzonych, nieszczelny consent mode oraz straty z przeglądarek i blokerów. Punkt wyjścia do sekcji o tym, jak sprawdzić, ile konwersji naprawdę tracisz, zanim policzysz rozjazd GA4 kontra Google Ads.
Pomiar omijania partycjonowania pamięci przez trackery
Badanie pomiarowe pokazuje, że nawigacyjne śledzenie występuje w nieco ponad 10% nawigacji, a link decoration stosują 214 domeny należące do co najmniej 104 organizacji. Twarda podstawa dla sekcji o realnym odzysku: dokumentuje, gdzie przeglądarki domykają obejścia, czyli czego kontener serwerowy nie naprawi.
Planowanie infrastruktury i kosztów kontenera
Dokumentacja podaje rząd ok. 50 USD miesięcznie za instancję i tłumaczy, że rachunek jest funkcją mocy obliczeniowej, pamięci i ruchu sieciowego, a widełki wyznaczają ustawienia min i max instancji. Techniczna podstawa sekcji o tym, ile to kosztuje, a ile jest warte - zwłaszcza pozycji o transferze i skalowaniu.
Czego wymaga licytacja oparta na wartości
Materiał wskazuje próg ok. 45 konwersji w 30 dniach dla danej akcji oraz konieczność przekazywania GCLID do CRM albo wdrożenia konwersji rozszerzonych, żeby wartość w ogóle wróciła do konta. Wprost karmi sekcję o tym, dlaczego konwersje rozszerzone i value-based bidding przechylają szalę na korzyść serwera.
Pytania i odpowiedzi (FAQ)
Skala ruchu, przy której tagowanie serwerowe ma sens, jego wpływ na liczbę konwersji i koszt utrzymania kontenera.
Od jakiej skali ruchu server-side tagging ma sens?
Czy server-side tagging zwiększy liczbę moich konwersji?
Ile kosztuje utrzymanie kontenera serwerowego?
Czy server-side tagging jest za drogi dla małego sklepu?
Czy tagowanie po stronie serwera zwalnia mnie z Consent Mode?
Jak sprawdzić, czy tracisz dane konwersji bez server-side tagging?
