Cztery miejsca, w których można podać zysk

Warto najpierw zobaczyć to jako mapę, bo mechanizmy nie wykluczają się i często stosuje się dwa naraz.

• Tag konwersji na stronie podziękowania — wartość wyliczona w momencie złożenia zamówienia. Najszybsza informacja, najczęściej używana, ale oparta na danych dostępnych w koszyku.

• Reguły wartości konwersji — modyfikator działający po stronie Google, zależny od lokalizacji, urządzenia lub listy odbiorców. Nie wymaga zmian w kodzie i dlatego jest niedoceniany.

• Korekty wartości konwersji — zmiana wartości już zaraportowanej konwersji, wysyłana później. Jedyny sposób, żeby uwzględnić anulowania i zwroty.

• Import konwersji z systemu sprzedaży — wartość dostarczana z pliku albo interfejsu programowania, powiązana identyfikatorem kliknięcia. Najbliżej prawdy, najbardziej pracochłonny.

Kolejność, w jakiej je wdrażam, zależy od tego, gdzie w firmie leży wiedza o zysku. Jeśli koszt zakupu jest znany w koszyku — zaczynam od tagu. Jeśli dopiero w systemie magazynowym — od importu. Reguły traktuję jako uzupełnienie, nigdy jako podstawę.

Wartość liczona w tagu zakupu

To najczęstszy wariant. Zamiast wartości zamówienia do tagu trafia wartość wyliczona z kosztów zakupu pozycji koszyka.

Technicznie robię to tak, żeby sklep publikował wyliczoną wartość w warstwie danych na stronie podziękowania, a menedżer tagów tylko ją odczytywał. Nie liczę marży w samym menedżerze tagów, nawet jeśli teoretycznie da się to zrobić skryptem — logika biznesowa w kontenerze tagów jest miejscem, w którym po roku nikt nie potrafi odtworzyć, skąd bierze się liczba.

Kilka szczegółów, które psują takie wdrożenia. Pole z wartością musi być liczbą, bez waluty i bez spacji w separatorze tysięcy. Separatorem dziesiętnym musi być kropka. Waluta musi być podana osobno i zgodna z walutą konta konwersji. I musi być odporna na przypadek, gdy koszt zakupu któregoś towaru jest nieznany — wtedy decyduję z góry, czy pomijam tę pozycję, czy przyjmuję domyślny wskaźnik.

Osobno pilnuję identyfikatora transakcji. Bez niego nie da się później skorygować wartości ani zestawić danych z systemem sprzedaży, a poza tym to jedyne skuteczne zabezpieczenie przed policzeniem tej samej sprzedaży dwa razy po odświeżeniu strony.

Reguły wartości konwersji

Mechanizm, który działa po stronie Google i nie wymaga ani jednej linii kodu. Ustawia się warunek — kraj, urządzenie albo lista odbiorców — i mnożnik lub wartość stałą, którą Google zastosuje do konwersji spełniających warunek.

Używam tego wtedy, gdy zysk różni się w sposób, którego sklep nie widzi w koszyku. Najlepszy przykład: zamówienie z zagranicy z droższą wysyłką albo z formą płatności o wyższej prowizji. Drugi przykład: nowy klient wart więcej niż powracający, bo powracający kupiłby i tak.

Ograniczenia trzeba znać. Zestaw dostępnych warunków jest zamknięty i nie obejmuje rodzaju produktu, więc reguły nie zastąpią wyliczania marży w koszyku. Nakładają się na wartość przekazaną z tagu, a nie zamiast niej, więc łatwo o podwójne skorygowanie tego samego czynnika. Wpływają też na to, co widać w raportach, więc po ich włączeniu wartości przestają zgadzać się z systemem sklepu i trzeba to komuś wytłumaczyć.

Zawsze zapisuję, jakie reguły są aktywne i po co. Reguła ustawiona rok temu przez kogoś innego to jedna z tych rzeczy, których się nie szuka, dopóki nie zabraknie pomysłów, dlaczego liczby nie zgadzają się o kilkanaście procent.

Korekty wartości i zwroty

Tu leży najbardziej niedoceniana część układanki. Konwersja zaraportowana w chwili zamówienia nie wie, że towar wróci za trzy tygodnie. Bez korekt algorytm uczy się na sprzedaży, która nigdy nie doszła do skutku.

Google Ads pozwala wysłać korektę do już zaraportowanej konwersji: zmienić jej wartość albo ją wycofać. Warunek jest jeden i twardy — konwersja musiała zostać zaraportowana z identyfikatorem transakcji, bo to on łączy jedno z drugim.

W praktyce wygląda to tak: system sprzedaży raz na dobę albo raz na tydzień eksportuje listę anulowań i zwrotów z identyfikatorami, a plik trafia do Google Ads przez import albo automatycznie przez interfejs programowania. Obowiązuje okno czasowe na wysłanie korekty, więc proces musi być regularny — plik wysyłany, gdy ktoś sobie o nim przypomni, przestaje działać dokładnie wtedy, gdy jest najbardziej potrzebny.

W branżach z wysokim odsetkiem zwrotów uważam korekty za element obowiązkowy, nie dodatek. Bez nich cała reszta pracy nad przekazywaniem zysku traci sens, bo dane wejściowe są systematycznie zawyżone — i zawyżone najbardziej tam, gdzie zwroty są najczęstsze.

Import konwersji z systemu sprzedaży

Wariant dla sytuacji, w których zysk znany jest dopiero po fakcie: przy zamówieniach realizowanych z opóźnieniem, sprzedaży telefonicznej, umowach podpisywanych po rozmowie albo cenach negocjowanych indywidualnie.

Zasada działania: przy wejściu użytkownika na stronę zapisuję identyfikator kliknięcia z adresu, przekazuję go do formularza i zapisuję razem z rekordem w systemie sprzedaży. Kiedy transakcja się domknie i znany jest zarobek, wysyłam do Google Ads parę — identyfikator kliknięcia i wartość.

Elementem, który najczęściej się psuje, nie jest wysyłka, a zapisanie identyfikatora. Wystarczy, że system zarządzania treścią obcina parametry z adresu, przekierowuje z zapytaniem albo formularz nie ma ukrytego pola — i po miesiącu okazuje się, że jest pełny plik rekordów z pustą kolumną.

Alternatywą, gdy identyfikator kliknięcia jest niedostępny, jest wariant oparty na zahaszowanych danych kontaktowych z systemu sprzedaży. Trzeba wtedy uważnie przejść przez podstawę prawną przetwarzania i sposób pozyskania zgody, więc traktuję to jako decyzję do podjęcia razem z klientem, a nie techniczny detal do odhaczenia.

Warto też znać ograniczenie czasowe: import ma sens w oknie, w którym Google przypisuje konwersje do kliknięć. Przy cyklach sprzedaży dłuższych niż to okno część transakcji nie zostanie przypisana i trzeba się z tym pogodzić.

Jedno działanie konwersji czy dwa

Pytanie, które pada zawsze: podmieniać wartość w istniejącym działaniu konwersji, czy stworzyć nowe, osobne?

Zwykle wybieram nowe działanie i uruchamiam je równolegle, jako konwersję dodatkową, bez oznaczania jako główna. Przez kilka tygodni zbieram dane w obu i mogę je porównać. Dopiero gdy widzę, że nowe działanie liczy się poprawnie, przełączam je na główne, a stare przenoszę do obserwacyjnych.

Zaleta jest oczywista: zachowuję ciągłość historii i mam punkt odniesienia. Wada też: konto ma na jakiś czas dwie konwersje dla tej samej sprzedaży i trzeba pilnować, żeby tylko jedna była główną, bo inaczej strategie stawek uczą się na podwójnie policzonej wartości.

Podmiana w istniejącym działaniu ma jeden przypadek zastosowania: gdy wartość była do tej pory oczywiście błędna i historia nie jest do niczego potrzebna. Wtedy szkoda czasu na równoległe zbieranie danych.

Niezależnie od wyboru, w koncie zostawiam nazwę mówiącą, co się liczy — z dopiskiem informującym, że chodzi o zysk, a nie o przychód. Za rok będzie to jedyna wskazówka dla osoby, która przejmie konto.

Jak sprawdzam, czy dane doszły

Nie kończę wdrożenia na tym, że tag się odpalił. Robię trzy testy, zawsze w tej samej kolejności.

Pierwszy: zamówienie testowe i podejrzenie żądania wychodzącego do Google. Sprawdzam, czy wartość, waluta i identyfikator transakcji są dokładnie takie, jak w systemie sklepu. Ręcznie przeliczam marżę tego jednego zamówienia i porównuję z liczbą w żądaniu.

Drugi: po dwóch dniach zestawiam sumy. Liczba konwersji i suma wartości w Google Ads za konkretny dzień, wobec liczby zamówień i sumy marży w systemie sklepu za ten sam dzień. Nie oczekuję zgodności co do groszy — atrybucja i modelowanie robią swoje — ale różnica rzędu kilkudziesięciu procent oznacza błąd, a nie atrybucję.

Trzeci: sprawdzam rozkład wartości, nie tylko sumę. Jeśli w danych są konwersje o wartości zero albo takie, które wyglądają jak pełna cena zamiast marży, to znaczy, że jakaś ścieżka zakupu omija wyliczenie. Zwykle chodzi o płatność odroczoną, zamówienie z rabatem albo zakup przez inny szablon strony podziękowania.

Na koniec zapisuję w dokumentacji konta datę wdrożenia, definicję przekazywanej wartości i miejsce, gdzie liczona jest w kodzie. Trzy zdania, które oszczędzają dzień pracy każdemu, kto po mnie przyjdzie — i mnie samemu, gdy wrócę do tego konta po pół roku.