Czy to możliwe, że system e-commerce modeluje dane sprzedaży?

Raporty, które nie mają sensu

Kilkanaście tysięcy kliknięć. Kilkutysięczny budżet reklamowy. W analityce jedna konwersja w całym okresie.

Panel sklepu pokazywał sprzedaż. Narzędzia Google widziały jej znikomy ułamek, rzędu jednego procenta.

W takiej sytuacji nasuwa się rekomendacja, którą składa się niemal odruchowo: kampania nie zarabia, więc trzeba ją wyłączyć albo przebudować. Zanim ją złożyłam chciałabym zrozumieć, skąd bierze się tak duża rozbieżność. Odpowiedź była w punkcie w którym nikt by jej nie szukał.

Pierwsza czerwona lampka nie jest oczywista

Nie zaczęłam od raportu konwersji, bo to objaw, a nie trop.

Zaczęłam od tego, że niemal wszyscy odwiedzający byli oznaczani jako nowi użytkownicy. Blisko dziewięćdziesiąt dziewięć procent.

To jest metryka diagnostyczna, choć rzadko się jej tak używa. Udział nowych użytkowników opisuje nie tylko zachowanie klientów, ale też zdolność systemu do ich rozpoznawania. Jeśli sklep ma powracających kupujących, a analityka widzi wyłącznie nowych, to znaczy, że coś przerywa ciągłość identyfikacji między jedną wizytą a drugą.

A jeśli coś przerywa identyfikację, to bardzo prawdopodobne, że przerywa też pomiar wszystkiego innego. Konwersja jest przecież zdarzeniem, które trzeba przypisać do sesji, a sesję do użytkownika.

Nienaturalny udział nowych użytkowników jest sygnałem tańszym i szybszym do sprawdzenia niż audyt całej konfiguracji. Warto go włączyć do rutynowego przeglądu raportów.

Jak działa zgoda, w dwóch akapitach

Baner cookies nie jest ozdobą prawną ani formalnością. Jest przełącznikiem, który steruje tym, co narzędzia pomiarowe mogą zrobić z aktywnością użytkownika.

Mechanizm ma dwa etapy. Najpierw ustawiany jest stan domyślny, obowiązujący, zanim użytkownik cokolwiek kliknie. Potem, po decyzji użytkownika, wysyłana jest aktualizacja tego stanu i dopiero ona informuje narzędzia Google, że zgoda została udzielona.

Jeśli implementacja wysyła wyłącznie stan domyślny, a aktualizacji nie wysyła, to z punktu widzenia narzędzi Google użytkownik nigdy nie kliknął „Akceptuję". Panel administracyjny pokazuje przy tym zgodę ze statusem „przyznana", bo tam zapis rzeczywiście się zapisał. Google go po prostu nie dostał.

To jest cała przyczyna. Rozdźwięk między tym, co zapisuje sklep, a tym, co wysyła do narzędzi pomiarowych.

Widać to wprost w narzędziu diagnostycznym Google, które rozpisuje oba etapy na osobne kolumny.

Zdarzenie zakupu. Kolumna „Wartość domyślna tagu" jest wypełniona, więc stan początkowy został ustawiony poprawnie. Kolumna „Aktualizacja na stronie" jest pusta dla wszystkich kategorii, więc sygnał po decyzji użytkownika nigdy nie dotarł. W efekcie „Bieżący stan" pozostał odmową, mimo że zgoda została udzielona i zapisana w panelu sklepu. Identyfikator strumienia danych został zamazany.

Zwróć uwagę, na jakim zdarzeniu to widać. Nie na wejściu na stronę główną, tylko na zakupie, czyli na tej jednej rzeczy, którą kampania ma dowieźć.

Dlaczego moduł zgód mógł tego nie objąć

Warto wiedzieć, skąd bierze się ta luka, bo to pozwala szukać jej u siebie zanim zrobi szkodę.

Moduły zgód wbudowane w platformy sklepowe obsługują zwykle integracje włączane w panelu sklepu. Jeśli tagi pomiarowe jadą przez zewnętrzny kontener, moduł może o nim po prostu nie wiedzieć i nie wysyłać do niego aktualizacji. Zarządza tym, co zna, i robi to poprawnie. Reszta zostaje poza jego zasięgiem.

Dla właściciela sklepu oba przypadki wyglądają identycznie. Baner działa, zgoda się zapisuje, panel pokazuje „przyznano". Różnica jest niewidoczna z poziomu interfejsu i ujawnia się dopiero w tym, co faktycznie leci do narzędzi pomiarowych.

Stąd pytanie, które warto zadać sobie niezależnie od tego, na jakiej platformie stoi sklep: czy mój moduł zgód w ogóle wie o istnieniu mojego kontenera tagów?

Parametr, w którym widać prawdę

Stan zgody jest przekazywany w każdym żądaniu do Google jako parametr gcs. Przyjmuje cztery wartości, a ich odczytanie zajmuje kilkanaście sekund.

Zasada diagnostyczna jest prosta. Przed kliknięciem w banerze wartość powinna wynosić G100. Po kliknięciu „Akceptuję" powinna zmienić się na G111. Jeśli po akceptacji nadal widzisz G100, sygnał aktualizacji nie dociera do narzędzi Google, choćby panel sklepu twierdził co innego.

Wartości G101 i G110 są normalne przy zgodzie częściowej, gdy użytkownik zaakceptuje tylko wybrane kategorie.

Tak wygląda ten odczyt w praktyce. Poniżej dwa zrzuty tego samego żądania, wykonane w odstępie kilku sekund, w panelu Payload narzędzi deweloperskich przeglądarki.

Stan przed podjęciem decyzji w banerze. Parametr gcs ma wartość G100, czyli obie zgody odmówione. Parametr npa wynosi 1, co oznacza reklamy niespersonalizowane. Identyfikatory strumienia danych, kontenera i użytkownika zostały zamazane.

Jeśli u Ciebie drugi zrzut wygląda jak pierwszy, masz odpowiedź na pytanie, dlaczego raporty nie zgadzają się z panelem sklepu.

Osobny przypadek: jeśli parametru gcs nie ma w żądaniu w ogóle, Consent Mode nie jest wdrożony. Jego obecność jest potwierdzeniem, że mechanizm w ogóle działa.

Consent Mode w wersji drugiej dodał dwa kolejne sygnały, dotyczące przekazywania danych użytkownika i personalizacji reklam. Odpowiada za nie parametr gcd, ale do wstępnej diagnozy wystarczy gcs.

Modelowanie, czyli dlaczego problem sam się maskuje

Kiedy zgoda jest odmówiona, Google nie przestaje raportować konwersji. Zaczyna je modelować, czyli szacować na podstawie ruchu, dla którego pomiar był możliwy.

Z perspektywy osoby patrzącej na raport nie widać różnicy. Konwersje są, wykresy powstają, kolumny się sumują. Zmienia się tylko to, że część z nich dociera do systemu jako wynik modelu, a nie jako zdarzenie zmierzone.

Przy skali błędu takiej jak w tym sklepie modelowanie nie miało jednak z czego szacować. Zbyt mała próbka danych zmierzonych daje wynik, który w raporcie wygląda jak brak sprzedaży.

I tu jest sedno problemu. Nie ma w Google Ads kontrolki, która zapala się na czerwono, kiedy cały ruch wysyłany jest jako odmowa. Interfejs pokazuje niską konwersję, a niska konwersja ma wiele wygodnych wyjaśnień: nieskuteczna reklama, słaba oferta, zbyt wysoka cena, sezonowość.

Zanim ktokolwiek dotrze do parametru gcs, znacznie taniej jest zmienić kreację albo dołożyć do budżetu.

Odpowiedź dostawcy

Zgłosiłam problem dostawcy platformy. W odpowiedzi przeczytałam, że w ich środowisku błędu nie udało się odtworzyć, mechanizm działa prawidłowo, a przyczyną może być środowisko przeprowadzenia testu.

Taka odpowiedź jest typowa, a dalsza wymiana argumentów rzadko coś w takiej sytuacji zmienia. Nie dlatego, że jest nieuczciwa. Dlatego, że opisuje inny stan faktyczny niż ten, który obserwowałam, a spór o to, czyj opis jest trafniejszy, nie prowadzi do niczego.

Wyjście z takiej sytuacji jest jedno.

Dowód zamiast sporu

Agencja techniczna obsługująca sklep dodała brakujący element odpowiadający za przekazanie zgody na kolejnych podstronach. Bez zmiany plików cookies i bez ingerencji w pozostałe ustawienia.

To jest istotne metodologicznie. Zmieniona została jedna zmienna, a efekt był binarny: zakupy natychmiast zaczęły pojawiać się w raportach. Nie ma tu miejsca na interpretację ani na alternatywne wyjaśnienie.

Po przedstawieniu tego dowodu dostawca poprawił moduł u źródła.

Ostatni krok był odrębny i zarazem najważniejszy. Po wdrożeniu poprawki natywnej tymczasowe obejście zostało usunięte, a sygnał sprawdzony ponownie, na produkcji. Poprawka działająca równolegle z obejściem nie jest jeszcze potwierdzona. Weryfikacja, czy natywne rozwiązanie działa samodzielnie, stanowi osobne zadanie, które w większości wdrożeń zostaje pominięte.

Rzecz, która nie daje mi spokoju

Błąd nie siedział w konfiguracji tego sklepu.

Siedział w standardowym module platformy. W tym samym, z którego korzystają wszystkie sklepy zbudowane na tym rozwiązaniu.

Brak zgłoszeń od innych użytkowników systemu nie oznaczał, że problem nie występuje. Oznaczał, że nikt go nie nazwał. W panelu wszystko wygląda spójnie, dane w sklepie się zgadzają, a rozbieżność między panelem a analityką narzędzi Google rzadko bywa przedmiotem osobnego sprawdzenia. Pewien poziom rozbieżności jest zresztą normalny, więc sama jej obecność nikogo nie alarmuje.

Skoro poprawka trafiła do modułu, objęła wszystkie sklepy na tym szablonie. Także te, które nigdy nie dowiedziały się, że coś było nie tak.

Dlaczego nikt tego nie zgłasza

Warto nazwać mechanizm, który stoi za tą ciszą, bo nie jest to niczyja zła wola.

Sklep zwykle nie ma kompetencji, żeby odróżnić błąd platformy od własnej konfiguracji. Agencja techniczna wdraża rozwiązanie dostawcy i pracuje w jego logice, więc kwestionowanie standardowego modułu nie jest jej naturalnym odruchem. Dostawca dowiaduje się o problemach ze zgłoszeń, których w tej sprawie nie dostaje.

Kiedy jedna strona wdraża rozwiązanie drugiej, nikt nie ma strukturalnego interesu w sprawdzeniu, czy moduł działa poprawnie. Nie dlatego, że komuś zależy na ukryciu błędu. Dlatego, że w tym układzie nie ma roli, do której takie sprawdzenie należy.

Ta rola musi być obsadzona osobno, po stronie klienta.

Co sprawdzić u siebie

Cztery kroki, wszystkie do wykonania bez dostępu do kodu.

Zestaw liczbę zamówień w panelu sklepu z liczbą w analityce, za ten sam okres. To jest test, który zajmuje dziesięć minut i wykrywa większość problemów pomiarowych. Rozbieżność rzędu kilku procent bywa normalna. Rozbieżność wielokrotna nie jest.

Sprawdź udział nowych użytkowników i zestaw go z realnym profilem klienta. Jeśli wiesz, że klienci wracają, a system tego nie widzi, masz sygnał, zanim jeszcze spojrzysz na konwersje.

Odczytaj parametr gcs przed kliknięciem w banerze i po nim. W narzędziach deweloperskich przeglądarki, w zakładce sieci, filtrując żądania po nazwie collect. Przed zgodą G100, po zgodzie G111. Wszystko inne wymaga wyjaśnienia.

Zrób to na kilku podstronach, nie tylko na stronie głównej. Błąd tego typu potrafi występować wyłącznie na dalszych krokach ścieżki, a stronę główną testuje się najczęściej.

Jeśli wynik odbiega od oczekiwanego, warto od razu rozstrzygnąć, gdzie leży przyczyna. Konfiguracja po stronie sklepu jest do naprawienia samodzielnie. Błąd w standardowym module jest sprawą dla dostawcy platformy, gdzie naprawa jest bezpłatna i obejmuje wszystkich jego klientów. Zgłoszenie skierowane pod właściwy adres oszczędza pieniądze i czas.

Dwa pytania do dostawcy platformy

Zgłoszenie samo w sobie nie wystarczy, bo zwykle wraca z odpowiedzią, że po ich stronie mechanizm działa. Dlatego pytania warto postawić tak, żeby wymuszały odpowiedź „tak" albo „nie", a nie opis.

Czy moduł wysyła globalne polecenie aktualizacji zgody, widoczne dla zewnętrznych kontenerów tagów, czy zarządza wyłącznie integracjami włączonymi w panelu sklepu? To pytanie rozstrzyga zakres. Odpowiedź „zarządza integracjami z panelu" jest odpowiedzią twierdzącą na to, czy problem istnieje, tylko sformułowaną inaczej.

Czy aktualizacja jest wysyłana na każdej podstronie, czy tylko przy pierwszym kliknięciu w banerze? To pytanie wykrywa wariant trudniejszy do zauważenia. Zgoda potrafi zadziałać przy kliknięciu i przestać obowiązywać na kolejnych krokach ścieżki, więc pomiar działa dokładnie tam, gdzie go testujesz, i przestaje działać wszędzie tam, gdzie powstaje sprzedaż.

Punkt zerowy danych

Ta sprawa ma jeszcze jedną konsekwencję, o której łatwo zapomnieć po naprawie.

Data wdrożenia poprawki jest punktem zerowym wiarygodnych danych. Od niej raporty opisują rzeczywistość. Przed nią opisują coś innego i trzeba wiedzieć, jak je czytać.

To znaczy, że porównania rok do roku, benchmarki i cele oparte na wcześniejszych okresach wymagają korekty albo przynajmniej przypisu. Zespół, który tego nie wie, będzie się przez kolejny rok porównywał do liczb, które nigdy nie były prawdziwe.

Warto tę datę zapisać i przekazać wszystkim, którzy z tych raportów korzystają.

Nie napiszę, że sprzedaż wzrosła, bo nie wzrosła. Stała się w końcu mierzalna. To dwie różne rzeczy.

Interpretacja danych z ekosystemu Google nie jest prostą ścieżką i nie sądzę, żeby ktokolwiek znał ją w całości. W tej sprawie nie byłam ekspertem. Byłam osobą, która zauważyła, że jedna liczba nie ma sensu, i nie odpuściła, dopóki nie dowiedziała się dlaczego.

To jest, moim zdaniem, najbardziej niedoceniana kompetencja w analityce.