Jak awaria wygląda z perspektywy konta

Rozpoznanie objawów pozwala skrócić czas reakcji z tygodnia do jednego dnia, więc warto je znać.

Najbardziej podręcznikowy przypadek to nagły spadek liczby konwersji do zera przy niezmienionej liczbie kliknięć. Łatwy do wyłapania, o ile ktoś patrzy. Groźniejsze są awarie częściowe: pomiar działa na komputerach, a nie działa na telefonach, bo błąd pojawia się tylko w jednym szablonie. Albo działa, ale przestał przekazywać wartość zamówienia i wszystkie transakcje mają wartość zerową, co dla strategii nastawionej na zwrot z nakładów jest równoznaczne z brakiem danych.

Osobna kategoria to awarie odwrotne, czyli zliczanie nadmiarowe. Zdublowany kod na stronie podziękowania albo zdarzenie uruchamiane przy każdym odświeżeniu potrafi zawyżyć wyniki dwukrotnie. Skutek jest bardziej podstępny niż przy braku danych — kampania wygląda świetnie, więc dostaje więcej budżetu.

Wniosek praktyczny jest prosty: nie wystarczy pilnować, czy konwersje są. Trzeba pilnować, czy ich liczba i wartość mają sens w odniesieniu do czegoś niezależnego od tagu.

Drugie, niezależne źródło prawdy

To fundament całej reszty. Jeżeli jedynym miejscem, w którym wiesz, ile było zamówień, jest panel reklamowy, nie masz jak stwierdzić, że coś nie działa.

Niezależnym źródłem jest system, w którym powstaje sprzedaż: baza zamówień sklepu, system obsługi zgłoszeń, tabela leadów w bazie danych, arkusz z rejestrem telefonów. Nie potrzebuję tu zgodności do jednej transakcji, bo różnice wynikające z modelu atrybucji i okien konwersji są normalne. Potrzebuję rzędu wielkości i trendu.

W praktyce wystarczy prosty rytuał: raz w tygodniu zestawiam liczbę zamówień z systemu sklepowego z liczbą konwersji w koncie reklamowym i patrzę na proporcję. Ta proporcja jest zwykle dość stabilna. Kiedy z dnia na dzień spada o połowę, wiem, że mam do czynienia z pomiarem, a nie z rynkiem.

Warto ten wskaźnik gdzieś zapisywać. Pamięć jest złym narzędziem porównawczym, szczególnie po dwóch miesiącach.

Zapis identyfikatora kliknięcia po stronie zamówienia

Jeśli miałbym wskazać jedno zabezpieczenie warte wdrożenia przed wszystkimi innymi, byłoby to zapisywanie identyfikatora kliknięcia razem z zamówieniem.

Mechanizm jest niezależny od tego, czy tag konwersji zdąży się wykonać. Użytkownik wchodzi z reklamy, w adresie znajduje się parametr identyfikujący kliknięcie, skrypt sklepu odkłada go w ciasteczku pierwszej strony, a w momencie złożenia zamówienia zapisuje w rekordzie zamówienia obok numeru, wartości i daty. Od tej chwili masz w swojej bazie trwały ślad powiązania sprzedaży z reklamą, którego nie zabierze żadna awaria kodu po stronie przeglądarki.

Ten sam mechanizm obsługuje sprzedaż, która finalizuje się poza stroną — telefonicznie, mailowo, po rozmowie z handlowcem. Wdrażam go standardowo w sklepach i w firmach usługowych z długim procesem decyzyjnym.

Ważne ograniczenie techniczne: wgrywane później konwersje muszą dotyczyć kliknięć nie starszych niż 90 dni, a samo zdarzenie musi mieścić się w oknie konwersji. To i tak dużo więcej, niż potrzebujesz do naprawienia tygodniowej luki, ale przy bardzo długim procesie sprzedaży trzeba to mieć z tyłu głowy.

Pomiar po stronie serwera jako warstwa zapasowa

Przeniesienie części pomiaru z przeglądarki na serwer nie jest cudownym lekiem, ale usuwa całą klasę awarii.

Kod działający w przeglądarce zależy od wtyczek blokujących, od tego, czy przeglądarka wykona skrypt, od kolejności wczytywania i od banera zgód. Zdarzenie wysyłane z serwera po zapisaniu zamówienia w bazie zależy tylko od Twojego serwera. Jeżeli zamówienie zostało zapisane, zdarzenie zostanie wysłane.

Trzeba przy tym pamiętać o dwóch rzeczach. Po pierwsze, pomiar serwerowy nie zwalnia z respektowania zgód — to Ty odpowiadasz za to, żeby zdarzenie nie poszło, gdy użytkownik nie wyraził zgody. Po drugie, dwie równoległe ścieżki wysyłki wymagają uzgodnienia identyfikatorów zdarzeń, bo inaczej zamiast zabezpieczenia zbudujesz maszynę do podwójnego zliczania.

W wielu firmach pełne wdrożenie serwerowe jest projektem na kwartał. Sensownym pierwszym krokiem jest objęcie nim tylko najważniejszej konwersji — zakupu albo wysłanego formularza ofertowego — i pozostawienie reszty w przeglądarce.

Alerty, które faktycznie zadziałają

Monitoring pomiaru zwykle nie istnieje, a jeśli istnieje, to w formie „ktoś zajrzy do panelu w poniedziałek”.

Kilka warstw, które warto poskładać. Prosta reguła w koncie reklamowym powiadamiająca mailem, gdy liczba konwersji w kampanii spadnie poniżej progu w danym dniu — to nie wykryje awarii częściowej, ale wykryje ciszę. Druga warstwa to własny skrypt odpytujący cyklicznie stronę podziękowania i sprawdzający obecność wywołania tagu w kodzie odpowiedzi. Trzecia to zestawienie liczby zamówień z bazy z liczbą zdarzeń w narzędziu analitycznym, wysyłane raz na dobę do skrzynki.

Najważniejsze jest jednak coś organizacyjnego, nie technicznego: wpisanie kontroli pomiaru na listę kontrolną wdrożeń. Jeśli po każdym wdrożeniu na produkcję ktoś przechodzi ścieżkę zakupową i sprawdza, czy zdarzenie się wysłało, wyłapiesz w ten sposób większość problemów tego samego dnia.

Procedura na dzień awarii

Kiedy awaria już nastąpi, kolejność działań ma znaczenie, bo część decyzji jest nieodwracalna.

• Ustal zakres i moment rozpoczęcia problemu — dokładna data i godzina będą potrzebne później do wykluczenia danych i do wgrywania konwersji.

• Napraw przyczynę i potwierdź naprawę realną transakcją testową, a nie samym podglądem konfiguracji.

• Zablokuj automatyczne decyzje podejmowane na złych danych: wstrzymaj reguły automatyczne i powstrzymaj się od ręcznych zmian celów strategii stawek na czas trwania luki.

• Poinformuj osoby, które będą raportować wyniki tego okresu. Nic nie psuje zaufania do danych bardziej niż niewyjaśniona dziura w wykresie odkryta miesiąc później.

Co zrobić z luką po naprawie

Zostaje pytanie, co z okresem, w którym pomiaru nie było. Mam do dyspozycji dwa narzędzia i używam ich razem.

Pierwsze to wgranie brakujących konwersji na podstawie zapisanych identyfikatorów kliknięć. Dostaję wtedy realne dane w koncie, z prawdziwymi datami i wartościami. Warunek jest jeden i wraca jak refren: identyfikatory muszą być zapisywane od wcześniej, bo wstecz ich nie odtworzysz.

Drugie to wykluczenie danych dla strategii ustalania stawek. Wskazuję przedział czasowy, w którym pomiar był niesprawny, a system przestaje traktować ten okres jako dowód, że kampanie nagle przestały sprzedawać. To ważniejsze, niż się wydaje: bez tego algorytm przez kolejne tygodnie tłumi ruch w miejscach, które według zafałszowanej historii nie działają. Wykluczenie ma sens tylko przy potwierdzonej awarii pomiaru i tylko na dokładnie ten okres — używanie go do maskowania słabego tygodnia sprzedażowego szkodzi Twoim własnym danym.

Na końcu zostaje wniosek, który powtarzam każdemu klientowi po takiej sytuacji: koszt awarii pomiaru nie kończy się w dniu naprawy. Rozciąga się na kilka tygodni gorszych decyzji podjętych na jej podstawie. Dlatego zabezpieczenia buduje się wcześniej, a nie po fakcie.