W retailu i marketingu cyfrowym sama dostępność danych to za mało. Równie ważna jest możliwość szybkiego reagowania na potrzeby biznesu. Problem zaczyna się wtedy, gdy nawet drobna zmiana w analityce wymaga zaangażowania zespołu IT, publikacji nowej wersji aplikacji i czekania, aż użytkownicy ją zaktualizują.
W tym przypadku klient potrzebował uruchomić dodatkowy pomiar konwersji zakupowych dla wybranych marek promowanych w aplikacji mobilnej. Na pierwszy rzut oka była to niewielka modyfikacja. W praktyce mogła jednak oznaczać długi proces po stronie developmentu i znacznie ograniczyć tempo działania biznesu.
Dzięki temu, że wcześniej wdrożyliśmy server-side GTM, mogliśmy podejść do tego inaczej – szybciej, sprawniej i bez konieczności wprowadzania zmian w kodzie aplikacji.
Klient działa na polskim rynku w modelu retail, w segmencie Health & Beauty / FMCG. W projekcie współpracowaliśmy bezpośrednio z osobą odpowiedzialną za analitykę online w obszarze Marketingu, MarTech & Own Media.
Potrzeba biznesowa była jasna: uruchomić dodatkowe konwersje zakupowe dla transakcji obejmujących wybrane marki, tak aby dokładniej mierzyć skuteczność działań promocyjnych prowadzonych w aplikacji mobilnej. Wydawałoby się proste, a jednak.
W tym projekcie pojawiły się dwa kluczowe ograniczenia. Po pierwsze, dostępność zespołu IT była ograniczona, co utrudniało szybkie wdrażanie zmian. Po drugie, pierwsze próby przygotowania dodatkowego zdarzenia po stronie aplikacji nie dały oczekiwanego efektu — zdarzenia były niekompletne i nie zawierały wszystkich parametrów potrzebnych do dalszego wykorzystania.
To oznaczało realne ryzyko, że zmiana, która biznesowo powinna być szybka i operacyjna, utknie w procesie developmentu, testów, publikacji nowej wersji aplikacji i oczekiwania na aktualizacje po stronie użytkowników
Klient miał już wcześniej wdrożony server-side GTM dla aplikacji mobilnej, który zrealizowaliśmy w ramach naszej współpracy. Dzięki temu mieliśmy solidną bazę do kolejnych działań.
Zamiast ingerować w kod aplikacji, zaproponowaliśmy wykorzystanie istniejącej architektury server-side, która daje pełną kontrolę nad danymi jeszcze zanim trafią one na serwery Google. Dzięki temu nie trzeba było przebudowywać aplikacji — wykorzystaliśmy istniejącą warstwę pośredniczącą, by przetworzyć i rozszerzyć dane, które już były zbierane z aplikacji.
Po naszej stronie zakres prac obejmował:
Całość wdrożyliśmy bez konieczności angażowania zespołu developerskiego klienta.
W praktyce oznaczało to, że zamiast przebudowywać aplikację, wykorzystaliśmy istniejącą warstwę pośredniczącą do przetworzenia i rozszerzenia danych, które były już zbierane z aplikacji.
Klasyczny model:
Nasze podejście:
To podejście okazało się szczególnie wartościowe także dlatego, że w trakcie projektu pojawiła się potrzeba zmiany listy marek objętych dodatkową logiką. W klasycznym modelu oznaczałoby to kolejny cykl developmentu i następny release aplikacji. W naszym modelu mogliśmy zareagować znacznie szybciej.
Najważniejsza zmiana polegała na tym, że Klient zyskał możliwość uruchamiania nowych konwersji zakupowych w aplikacji bez każdorazowego angażowania developerów i bez wydawania nowej wersji aplikacji.
Biznesowo przełożyło się to na:
W środowisku retailowym, gdzie okna decyzyjne są krótkie, a działania promocyjne wymagają szybkiej reakcji, to realna przewaga operacyjna. Dzięki server-side GTM klient nie musiał wybierać między jakością danych a tempem działania.
Ten case nie był jednorazowym obejściem problemu. Potwierdził wartość wcześniej wdrożonej architektury ssGTM – zarówno po stronie webu, jak i aplikacji mobilnej.
I właśnie to jest najważniejszy wniosek z całego projektu: dobrze zaprojektowana architektura analityczna nie tylko zbiera dane. Daje biznesowi większą kontrolę, skraca czas reakcji i pozwala szybciej przekładać potrzeby marketingowe na konkretne działania.
Historie sukcesów
Ostatnie wpisy na blogu