Przygotowanie strategii e-commerce pod wycofanie Universal Analytics w nadchodzących latach.

Równoległe zbieranie danych od dziś

Baner wejsciowyParallax

Przygotowanie strategii e-commerce pod wycofanie Universal Analytics w nadchodzących latach.

Równoległe zbieranie danych od dziś

Autor nie posiada zdjęcia
Tomasz Piasecki
30 grudnia 2021

Zacznę od uczciwego zastrzeżenia: Google nie ogłosiło daty wyłączenia dotychczasowego Analytics i nie wiem, kiedy to nastąpi. Nie piszę więc o terminie, a o kierunku — i ten kierunek jest wyraźny od ponad roku.

Nowa wersja Analytics, oparta na zdarzeniach zamiast na sesjach, jest rozwijana intensywnie i to tam trafiają wszystkie nowe funkcje. Do starej wersji nie dochodzi nic. Integracje z pozostałymi produktami Google budowane są pod nowy model. Dokumentacja i materiały szkoleniowe przesuwają się w tę stronę. W historii produktów Google taki układ oznaczał zawsze to samo.

Dla sklepu internetowego jest to zmiana poważniejsza niż dla zwykłego serwisu, bo dotyczy pomiaru sprzedaży — czyli danych, na których stoją decyzje o budżetach. Poniżej opisuję, co zrobić teraz, żeby nie robić tego w pośpiechu później.

Dlaczego dla sklepu to trudniejsze niż dla innych

Zwykły serwis mierzy odsłony i kilka celów. Sklep mierzy całą ścieżkę zakupową i przychód, a to oznacza znacznie więcej punktów, w których coś może się rozjechać.

Trzy powody, dla których migracja w e-commerce wymaga więcej pracy.

Po pierwsze, zmienia się cała struktura danych o sprzedaży. W starym modelu istniało rozbudowane, ustandaryzowane raportowanie handlowe z własnym zestawem pól. W nowym opiera się to na zdarzeniach o określonych nazwach i parametrach, które trzeba przesłać samodzielnie z warstwy danych. To nie jest przełączenie opcji, a nowe wdrożenie techniczne.

Po drugie, historia danych nie przenosi się. Nie ma narzędzia importującego przeszłość do nowej wersji. Oznacza to, że im później zaczniesz zbierać dane równolegle, tym mniej porównań rok do roku będziesz mieć w momencie, gdy stara wersja przestanie działać.

Po trzecie, raporty wyglądają inaczej i część przyzwyczajeń trzeba porzucić. Wskaźniki liczone są odmiennie, a niektórych znanych metryk po prostu nie ma w tej samej formie. Osoby, które przez lata patrzyły na jeden zestaw liczb, potrzebują czasu na przestawienie się — i to jest koszt organizacyjny, nie techniczny.

Krok pierwszy: równoległe zbieranie danych

To jedyna rzecz, którą uważam za pilną, i można ją zrobić w kilka godzin.

Zakładam nową usługę i konfiguruję ją tak, żeby zbierała dane obok istniejącej. Oba systemy działają jednocześnie, żaden nie zastępuje drugiego. Nie wyłączam niczego i nie zmieniam raportowania — celem jest wyłącznie to, żeby dane zaczęły się gromadzić.

Dlaczego to takie ważne? Bo dane historyczne są jedyną rzeczą, której nie da się nadrobić później. Wszystko inne — konfigurację, raporty, szkolenie zespołu — można zrobić w dowolnym momencie. Roku danych porównawczych nie odtworzysz.

Praktycznie: uruchomienie samego pomiaru odsłon jest banalne. Uruchomienie pomiaru zdarzeń handlowych wymaga pracy w warstwie danych i to jest ta część, która zajmuje czas. Dlatego dzielę to na dwa etapy: najpierw najprostszy pomiar, żeby dane w ogóle płynęły, potem sukcesywne dokładanie zdarzeń zakupowych.

Krok drugi: uporządkowanie warstwy danych

Cała nowa struktura pomiaru w sklepie stoi na tym, co strona publikuje o zdarzeniach. Jeśli warstwa danych jest niekompletna albo wypełniana niekonsekwentnie, migracja będzie polegała na przepisywaniu obejść.

Zakres, który powinien być publikowany, obejmuje kolejne etapy: wyświetlenie listy produktów, kliknięcie w produkt, wyświetlenie karty produktu, dodanie do koszyka, rozpoczęcie zamówienia, dodanie danych płatności i zakup. Każde z tych zdarzeń wraz z pozycjami i wartościami.

Dwie rzeczy, na które szczególnie uważam.

Spójność identyfikatorów produktów w całym łańcuchu: na stronie, w pliku produktowym dla Merchant Center i w systemie sprzedażowym. Rozjazd w tym miejscu psuje nie tylko raportowanie, ale też remarketing dynamiczny i wszystkie analizy per produkt.

Jedna definicja wartości, ustalona raz: czy przychód liczymy z podatkiem, czy bez, czy uwzględniamy koszt dostawy, jak traktujemy rabaty. Ta decyzja przekłada się na każdy późniejszy wskaźnik rentowności i musi być zapisana, nie zapamiętana.

Robota w tym punkcie zwraca się niezależnie od migracji, bo poprawia jakość danych już dziś. Traktuję ją więc nie jako koszt zmiany, a jako zaległość, którą warto nadrobić.

Krok trzeci: przygotowanie zespołu i raportowania

Element pomijany, a odpowiadający za większość opóźnień we wdrożeniach, które widziałem.

Nowa wersja Analytics ma inną logikę raportowania. Nie ma tam gotowego zestawu raportów odpowiadającego jeden do jednego temu, co znamy — więcej jest budowania własnych widoków. Dla osób, które przez lata korzystały z kilku ustalonych ekranów, jest to zmiana sposobu pracy, nie tylko interfejsu.

Praktyczne przygotowanie polega na trzech rzeczach. Ustaleniu listy pytań, na które raporty muszą odpowiadać — nie listy raportów, a listy pytań. Zbudowaniu w nowym narzędziu widoków odpowiadających na te pytania. I porównaniu wyników z tym, co pokazuje stare narzędzie, żeby zrozumieć, skąd biorą się różnice.

Różnice będą i to jest normalne — inny model danych daje inne liczby przy tym samym ruchu. Ważne, żeby zrozumieć ich przyczynę zawczasu, a nie tłumaczyć się z nich w momencie, gdy stare dane przestaną być dostępne.

Krok czwarty: eksport danych na przyszłość

Rzecz, o której mało kto myśli, dopóki nie jest za późno.

Jeśli stara wersja Analytics kiedyś zostanie wyłączona, dostęp do danych historycznych stanie się pytaniem otwartym. Nie zakładam najgorszego scenariusza, ale koszt zabezpieczenia się jest niewielki.

Robię więc coroczny eksport najważniejszych zestawień: przychód i transakcje w podziale na miesiące i kanały, konwersje w podziale na źródła, sprzedaż produktów, podstawowe dane o ścieżkach. To kilka arkuszy, które można trzymać niezależnie od dostępu do narzędzia.

Przy większych sklepach warto rozważyć bardziej systematyczne rozwiązanie — regularny eksport danych do własnej hurtowni. To dodatkowy koszt, ale daje niezależność od zmian w narzędziach i możliwość łączenia danych o ruchu z danymi z systemu sprzedażowego. Dla sklepu, w którym reklama jest głównym kanałem, jest to inwestycja, którą warto rozważyć niezależnie od tematu migracji.

Harmonogram, który proponuję

Zamykam propozycją rozłożenia tego w czasie, bo pilne jest tylko jedno.

  • Teraz, w pierwszych tygodniach roku — utworzenie nowej usługi i uruchomienie podstawowego pomiaru. Kilka godzin pracy.
  • Pierwszy kwartał — uporządkowanie warstwy danych i wdrożenie zdarzeń zakupowych w nowym systemie. Najwięcej pracy programistycznej.
  • Drugi kwartał — budowa raportów odpowiadających na realne pytania i porównanie liczb między systemami.
  • Druga połowa roku — przestawienie zespołu na nowe raporty przy zachowaniu starych jako punktu odniesienia.
  • Na bieżąco — coroczny eksport danych historycznych.

Taki harmonogram ma jedną zaletę: żaden jego etap nie jest wykonywany pod presją. Jeśli okaże się, że data wyłączenia zostanie kiedyś ogłoszona z krótkim wyprzedzeniem, będziesz mieć już zebrane dane i działający pomiar, a nie projekt do zrobienia w trzy miesiące. A jeśli nic się nie zmieni jeszcze długo, to i tak zyskasz lepszy pomiar niż dziś.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.