Nasz klient działa w modelu globalnego marketplace’u e-commerce. Sprzedaje klucze do gier i oprogramowania klientom indywidualnym na wielu rynkach, współpracując jednocześnie z wieloma partnerami.
Przy takiej skali dane marketingowe są jednym z kluczowych elementów zarządzania biznesem. To na ich podstawie zespół podejmuje decyzje o budżetach reklamowych, kanałach, retargetingu i ocenie skuteczności działań performance.
Problem polegał na tym, że część tych danych mogła nie pokazywać rzeczywistości.
Szczególnie dotyczyło to użytkowników korzystających z urządzeń Apple’a iOS odpowiadał za ponad 50% całego ruchu mobilnego na stronie klienta.
Klient korzystał z danych w GA4 do oceny skuteczności marketingu. Jednak w przypadku Safari i przeglądarek na iOS pojawiał się istotny problem technologiczny.
Mechanizmy ochrony prywatności, w tym Intelligent Tracking Prevention, ograniczają żywotność cookies analitycznych. W praktyce oznacza to, że użytkownik, który odwiedził stronę, a następnie wrócił po kilku lub kilkunastu dniach, mógł zostać rozpoznany jako zupełnie nowa osoba.
Dla biznesu to nie jest techniczny detal. Jeśli system nie rozpoznaje użytkowników powracających, zaczyna zniekształcać podstawowe wnioski o marketingu.
Nowych użytkowników wydaje się być więcej, niż jest w rzeczywistości. Retencja wygląda gorzej, niż powinna. Ścieżki konwersji na iOS i Safari stają się mniej wiarygodne. Kanały, które skutecznie przyciągają użytkowników z powrotem, mogą być niedoceniane. A działania nastawione na pozyskanie nowych klientów mogą wyglądać na skuteczniejsze, niż są w rzeczywistości.
W efekcie decyzje o budżetach, retargetingu i ocenie kanałów były podejmowane na danych, które w przypadku istotnej części ruchu mobilnego mogły być zaburzone.
Celem projektu było poprawienie jakości identyfikacji użytkowników na Safari i iOS. Nie chodziło o „wyprodukowanie” lepszych wyników w raportach. Chodziło o to, żeby klient mógł zobaczyć to, co faktycznie działo się na stronie: że część osób wracała po kilku, kilkunastu lub ponad dwudziestu dniach – tylko wcześniej system analityczny nie zawsze potrafił ich poprawnie rozpoznać.
Wdrożyliśmy rozwiązanie oparte na Cloudflare reverse proxy oraz server-side Google Tag Managerze.
W uproszczeniu: skonfigurowaliśmy środowisko tak, aby żądania narzędzi marketingowych były traktowane jako 1st party, czyli jako bliżej powiązane z domeną klienta. Dzięki temu ograniczenia przeglądarek miały mniejszy wpływ na trwałość identyfikatorów analitycznych.
Architektura rozwiązania wyglądała następująco:
strona klienta → Cloudflare i konfiguracja DNS → server-side GTM na Cloud Run → GA4
Do analizy wykorzystaliśmy eksport danych z GA4 do BigQuery. Dzięki temu mogliśmy porównać sytuację przed i po wdrożeniu nie tylko na poziomie ogólnych metryk, ale przede wszystkim na poziomie zachowania użytkowników.
Sprawdzaliśmy między innymi:
Wyniki analizy zostały przedstawione w Google Sheets, w formie pozwalającej zespołowi klienta łatwo porównać dane przed i po wdrożeniu.
Reverse proxy nie jest typem wdrożenia, którego efekt można łatwo ocenić po jednym wykresie w standardowym panelu GA4.
Jeśli po wdrożeniu rośnie liczba sesji, użytkowników albo zdarzeń, nie oznacza to automatycznie, że odpowiada za to reverse proxy. Ruch może wzrosnąć z wielu powodów: kampanii reklamowych, sezonowości, promocji, zmian w budżetach czy naturalnych wahań popytu.
Dlatego kluczowe było zejście głębiej – do danych w BigQuery – i sprawdzenie konkretnego zachowania: czy użytkownicy wracający po okresie dłuższym niż 7 dni są lepiej rozpoznawani jako te same osoby.
To właśnie tam było widać realny efekt projektu.
Przed wdrożeniem, gdy użytkownik korzystający z Safari lub iOS odwiedził stronę, a następnie wrócił na przykład po 10 dniach, GA4 często nie rozpoznawało go jako tej samej osoby. Cookie zdążyło wygasnąć, więc użytkownik dostawał nowy identyfikator.
W analizowanym okresie przed wdrożeniem zarejestrowano tylko 33 rozpoznane powroty użytkowników po 8 lub więcej dniach.
Po wdrożeniu reverse proxy takich powrotów było już 451.
To bardzo ważne: nie oznacza to, że nagle pojawiło się kilkanaście razy więcej powracających użytkowników.
Oznacza to, że ci użytkownicy najprawdopodobniej wracali już wcześniej, ale GA4 ich nie rozpoznawało. Po wdrożeniu system zaczął widzieć zachowania, które wcześniej były ukryte przez ograniczenia technologiczne przeglądarki.
Dzięki temu klient uzyskał bardziej wiarygodny obraz retencji, powracalności i ścieżek użytkowników na urządzeniach Apple.
Po wdrożeniu klient może podejmować decyzje marketingowe na podstawie danych, które lepiej pokazują realne zachowania użytkowników. Zespół marketingu ma większą pewność, że osoba wracająca po 10, 15 czy 23 dniach na Safari lub iOS nie zostanie automatycznie potraktowana jako nowy użytkownik.
To przekłada się na lepszą ocenę:
Najważniejsza zmiana nie polegała więc na poprawieniu jednego wskaźnika w raporcie. Najważniejsze było odzyskanie zaufania do danych, na podstawie których podejmowane są decyzje marketingowe.
W globalnym e-commerce nawet niewielkie zniekształcenie danych może prowadzić do dużych konsekwencji biznesowych. Szczególnie wtedy, gdy dotyczy kanałów i urządzeń odpowiadających za znaczącą część ruchu.
W tym przypadku problemem nie było to, że użytkownicy nie wracali.
Problemem było to, że analityka nie zawsze była w stanie ich rozpoznać.
Dzięki wdrożeniu Cloudflare reverse proxy i server-side GTM klient zaczął widzieć znacznie więcej realnych powrotów użytkowników na Safari i iOS. Liczba rozpoznanych powrotów po 8+ dniach wzrosła z 33 do 451.
To dało zespołowi marketingu solidniejszą podstawę do oceny retencji, kanałów, remarketingu i alokacji budżetów.
Bo w analityce marketingowej nie chodzi tylko o to, żeby mieć dane.
Chodzi o to, żeby dane pokazywały rzeczywistość, a nie ograniczenia technologii.
Tagi:
Historie sukcesów
Ostatnie wpisy na blogu
