Branża: Sklep elektroniczny
Klient: Botland (Bralin, Polska)
Strona: www.botland.com.pl

Punkt wyjścia

Botland to sklep internetowy specjalizujący się w sprzedaży elektroniki i komponentów. Dla zespołu kluczowe było wiarygodne mierzenie sprzedaży w Google Analytics 4 oraz poprawna atrybucja transakcji do sesji i źródeł ruchu, tak aby decyzje marketingowe mogły opierać się na rzetelnych danych.

W trakcie współpracy okazało się, że obecny sposób rejestrowania transakcji znacząco obniża jakość danych analitycznych, szczególnie w kontekście atrybucji.

Wyzwania

Analiza wykazała, że transakcje były rejestrowane w sposób mieszany:

• część zdarzeń była wywoływana na stronie podziękowania („thank you page”),
• część transakcji była dodatkowo dosyłana z backendu za pomocą Measurement Protocol.

Taka implementacja powodowała, że znaczna część zdarzeń sprzedażowych nie była poprawnie łączona z kontekstem sesji użytkownika. W praktyce około 50% transakcji traciło informację o źródle wizyty.

W danych GA4 przekładało się to na wysoki udział transakcji oznaczonych jako „(not set)”, który sięgał 21% wszystkich konwersji. Przy takiej skali problemu jakość atrybucji była niewystarczająca do wiarygodnej oceny skuteczności kanałów i kampanii, co utrudniało podejmowanie decyzji budżetowych oraz optymalizację działań marketingowych.

Nasze podejście

Aby poprawić jakość danych, zdecydowaliśmy się na zmianę momentu rejestrowania zdarzenia „purchase”. Zamiast wysyłania go na stronie „thank you page”, zdarzenie zaczęło być rejestrowane w momencie przejścia użytkownika do bramki płatniczej.

Takie podejście pozwoliło:

• zwiększyć liczbę transakcji rejestrowanych bezpośrednio przez GA4,
• poprawnie przypisać transakcje do sesji oraz źródła ruchu,
• znacząco ograniczyć skalę problemu transakcji bez przypisanego źródła („not set”).

Efekty

Wdrożone zmiany przyniosły wyraźną poprawę jakości danych:

• udział transakcji wysyłanych z przeglądarki wzrósł z 68% do 98%,
• liczba transakcji rejestrowanych z warstwy frontendu wzrosła o 30%,
• odsetek transakcji oznaczonych jako „(not set)” spadł z 21% do 10%, czyli o 11 punktów procentowych,
• poprawiła się wiarygodność atrybucji i oceny skuteczności kanałów oraz kampanii.

Co istotne, poprawa jakości danych nie odbyła się kosztem kompletności pomiaru. Całkowite pokrycie transakcji w GA4 utrzymało się na poziomie 75%, a rozkład pokrycia według metod płatności pozostał bez zmian. Oznacza to lepsze dane bez kompromisów w zakresie zasięgu rejestrowanych transakcji.

Opinia na temat współpracy Botland.com.pl z Conversion

Dzięki wprowadzonym zmianom Botland zyskał stabilne i spójne dane sprzedażowe w GA4. Poprawiona atrybucja pozwala obecnie na znacznie bardziej wiarygodną ocenę skuteczności kanałów marketingowych oraz podejmowanie decyzji budżetowych w oparciu o „czyste” dane.

Podsumowanie

Współpraca z Botland pokazuje, jak duży wpływ na jakość danych analitycznych ma sposób implementacji zdarzeń sprzedażowych. Zmiana momentu rejestrowania transakcji pozwoliła znacząco poprawić atrybucję i wiarygodność raportów, przy jednoczesnym zachowaniu tego samego poziomu pokrycia transakcji w GA4.

The post Botland.com.pl – 30% więcej transakcji z frontendu i spadek „(not set)” z 21% do 10% first appeared on Conversion.

Wyzwanie to szczególnie dotyka właścicieli sklepów internetowych z zewnętrznymi płatnościami. Użytkownik często nie wraca już na stronę podziękowania za transakcję, na której rejestrowana jest konwersja złożenia zamówienia. Najczęściej w takiej sytuacji stosuje się wirtualne odsłony, wraz z którymi wysyłany jest kod transakcji e-commerce.

Czy jeżeli chcemy śledzić akcje, które powodują przekierowanie nas do innej witryny (załadowanie nowej treści w tym samym oknie przeglądarki), możemy być pewni, że każde kliknięcie zostanie odnotowane przez Google Analytics? Odpowiedź wbrew pozorom nie jest taka oczywista. W obu powyższych przypadkach standardowe wysłanie zdarzenia (hitu) Google Analytics to błąd, który może skutkować niekompletnym śledzeniem przez nas zdarzeń, wirtualnych odsłon, transakcji itp.

Na czym polega wyzwanie?

Otóż wysłanie zdarzenia tuż przed załadowaniem innej strony rodzi bardzo duże zagrożenie, że hit z informacjami do Google Analytics po prostu nie dotrze, ponieważ szybciej wczyta się kolejna strona, aniżeli przeglądarka odbierze potwierdzenie odebrania przez Google Analytics wysłanego żądania. Jeżeli spojrzymy na kod przy debuggowaniu będzie to wyglądało w sposób następujący:

Korzystając z dodatku HttpFox dla Firefox widać, że żądanie zdarzenia wywołane tuż przed przejściem do witryny zewnętrznej ma status „(Aborted)”, co oznacza, że przeglądarka nie otrzymała odpowiedzi od Google Analytics, że narzędzie prawidłowo odebrało wysłane zdarzenie. Nie oznacza to, że to zdarzenie nie zostało zarejestrowane, ale niestety nie mamy również pewności, że wszystko jest ok.

Oczywiście nie jest powiedziane, że w rzeczywistości on nie dotarł, ale jest bardzo dużo prawdopodobieństwo, że przy części takich żądań nie zostaną one po prostu zarejestrowane w naszych statystykach.

Jakie jest rozwiązanie tego problem?

Najlepszym rozwiązaniem w przypadku zewnętrznych płatności jest zastosowanie statycznej strony przejściowej, w treści której wczytywane będą wszystkie niezbędne do zarejestrowania transakcji kody. Bardzo fajnie robi to np. portal Twoje Soczewki.

Na www.twojesoczewki.com przed przejściem do zewnętrznej płatności użytkownik na stronie przejściowej (tzw. splash page) informowany jest, że za chwilę będzie przeniesiony do zewnętrznej płatności. Dzięki kilku sekundowemu załadowaniu takiej strony mamy pewność, że kody śledzące prawidłowo się załadowały, a przy okazji nie traci na tym znacząco user experience.

Kiedy jednak nie mamy możliwości wdrożenia strony przejściowej alternatywą może być wykorzystanie funkcji hitcallback. Jej specyfikację może znaleźć na stronie pomocy Google Analytics. Prezentujemy i omawiamy ją również poniżej:

Idea funkcji polega na tym, że pozwala ona wykonać inną funkcję (w przykładzie powyżej jest to po prostu wyświetlenie okna alertu z tekstem „analytics.js done sending data”) dopiero w momencie, kiedy wszystkie wcześniejsze żądania zostały poprawnie wysłane i odebrane przez Google Analytics.

Co prawda funkcja ta została stworzona dla kodu Universal Analytics, to nie trzeba było długo czekać, aby została przystosowana dla standardowego kodu śledzącego Google Analytics. Poniżej prezentowaną postać funkcji zaczerpnęliśmy od Joel Peterson’a.

Prezentowany fragment jest dodatkowo wyposażony w „bezpiecznik”, który sprawdza czy serwisie istnieje w ogóle kod śledzący Google Analytics. Gdyby go nie było, to mogłoby dojść do sytuacji, w której hitcallback nie pozwoli wykonać żadnej funkcji (przekierowania), ponieważ Google Analytics nie daje w ogóle znaku życia.

Powyższe rozwiązanie działa w ten sposób, że przekierowuje użytkownika we wskazane miejsce someOtherPage.html pod dwoma warunkami:

1. jeżeli istnieje obiekt _gat tzn. prawidłowo wczytany jest Google Analytics
2. oraz Google Analytics odberało wszystkie wysłane żądania (w przykładzie jest to zdarzenie o paramaterach Category, Action, Label)

Jeżeli natomiast na stronie nieprawidłowo został wczytany obiekt _gat (np. Google Analytics nie działa lub został zablokowany przez przeglądarkę), to tak czy inaczej nastąpi przekierowanie do strony someOtherPage.html.

O czym pamiętać przy stosowanie hitcallback?

Często w serwisach mamy wiele elementów, które nie wywołują załadowania, a które chcielibyśmy śledzić. Ba, nawet dla ułatwienia sobie analizy oznaczamy elementy, które tak naprawdę powodują przeładowanie strony, ale dla ułatwienia analizy, osadzamy na takich akcjach zdarzenia. Pamiętajmy tylko o tym, aby nie przesadzić przy stosowaniu funkcji hitcallback. W razie jakiegoś problemu z Google Analytics (co jest raczej bardzo mało prawdopodobne) możemy zatrzymać serwis np. jeżeli zaczniemy śledzić zdarzeniami jego nawigację, to użytkownicy nie będą mogli z niej skorzystać, ponieważ Google Analytics nie odbierze zdarzeń osadzonych na korzystaniu z niej.

The post Jak poprawnie śledzić zdarzenia Google Analytics z wykorzystaniem funkcji hitcallback? first appeared on Conversion.