Parametry koszyka w tagach Floodlight w GTM: jak poprawić atrybucję

Tag Floodlight Sales potrafi wyglądać na wdrożony poprawnie, dopóki ktoś nie otworzy raportu na poziomie produktu. Liczba konwersji się zgadza, wartość koszyka też, ale nie widać, co właściwie zostało kupione i który feed to obsłużył. Raport pokazuje wtedy sprzedaż bez produktów, a pytanie o najlepiej sprzedające się SKU zostaje bez odpowiedzi.

Parametry koszyka są odpowiedzią na to pytanie. To wartości, które muszą dotrzeć razem z konwersją: identyfikator sprzedawcy, kraj feedu i język feedu oraz lista pozycji. Bez nich Google nie ma jak dopasować transakcji do konkretnego produktu w Merchant Center, zwłaszcza gdy ten sam identyfikator istnieje w kilku feedach.

Czym są parametry koszyka

W żądaniu, które przeglądarka wysyła pod /conversion, parametry koszyka mają krótkie nazwy: mid, fcntr i flng. Ich wartości pochodzą z pól aw_merchant_id, aw_feed_country i aw_feed_language. Razem z nimi jedzie opis pozycji w parametrze item, czyli tablica z identyfikatorem produktu, ceną i liczbą sztuk. Ten układ opisuje pomoc Merchant Center przy konfiguracji konwersji z danymi koszyka.

W tym samym żądaniu pojawiają się jeszcze dwa parametry: dscnt (rabat) i bttype (typ zdarzenia). W praktyce nie wpisuje się ich ręcznie. Tag Floodlight Sales buduje cały adres sam, jeśli dostał dane w oczekiwanej strukturze, więc praca sprowadza się do dostarczenia danych, a nie do składania adresu z klocków.

Warto zapamiętać jedną rzecz o nazewnictwie. mid, fcntr i flng to nazwy parametrów w żądaniu, a nie nazwy pól, które wypełniasz w interfejsie. W tagu Tag Managera widzisz etykiety Merchant ID, Feed Label i Feed Language. Trzy warstwy nazw opisują jedną wartość, co jest źródłem większości nieporozumień przy wdrożeniu.

Po co to komu, jeśli GA4 już raportuje sprzedaż

Raport e-commerce w GA4 odpowiada na pytanie, ile sprzedało się na stronie. Dane koszyka w Floodlight odpowiadają na inne pytanie: ile sprzedało się dzięki kampanii i które produkty. Google przypisuje transakcję do konkretnego sprzedawcy i kampanii, a rozliczenie idzie na poziomie SKU. Jeśli szukasz różnicy między oboma obrazami sprzedaży, opisałem ją w artykule o śledzeniu e-commerce w GA4 przez GTM.

Różnica wychodzi na wierzch przy wielu feedach. Ten sam produkt może mieć osobny feed dla Polski, osobny dla rynku niemieckiego i osobny dla wersji językowej. Identyfikatory bywają identyczne, więc bez kraju i języka feedu transakcja trafia w pierwszy pasujący wpis. Kraj i język to nie ozdoba. To jedyne rozróżnienie, jakie masz.

Drugi powód jest prostszy i boli bardziej. Kampania, która sprzedaje tanio i dużo, wygląda lepiej niż kampania, która sprzedaje drogo i rzadko, dopóki patrzysz na liczbę konwersji. Dopiero lista produktów pokazuje, że droższy koszyk zwraca się lepiej przy niższym wolumenie. Uzgadnianie takich wniosków z przychodem z e-commerce po stronie analityki to osobna praca, którą opisałem przy okazji uzgadniania przychodów e-commerce w GA4.

Warunki, które trzeba spełnić przed wdrożeniem

Google nie ukrywa wymagań. Konwersja musi mierzyć zdarzenie zakupu. Identyfikatory produktów w danych koszyka muszą się zgadzać z tym, co jest w Merchant Center. Każda pozycja musi mieć cenę. Suma koszyka powinna być wyższa niż suma kosztów własnych pozycji, inaczej raport przestaje cokolwiek znaczyć.

Po stronie konta potrzebujesz aktywności Floodlight typu sprzedażowego w Campaign Manager 360 lub Display & Video 360, dostępu do identyfikatorów pozycji z Merchant Center oraz możliwości zmiany kodu strony. Bez aktywności sprzedażowej nie ma do czego dopiąć koszyka, a bez dostępu do kodu nie ma jak przekazać danych z przeglądarki.

Jest też ograniczenie, o którym lepiej wiedzieć zawczasu. Automatyczne rabaty, funkcja Merchant Center, nie obsługują konwersji Floodlight ani Search Ads 360. Jeśli planujesz opierać rabaty na danych koszyka, ten kanał wypada z gry i trzeba go obsłużyć osobno. Lepiej ustalić to przed wdrożeniem niż po pierwszym raporcie.

Wdrożenie w GTM: tag, dane, Conversion Linker

Droga przez Google Tag Manager sprowadza się do trzech rzeczy. Pierwsza to tag Floodlight Sales utworzony w Search Ads 360 albo Campaign Manager 360 i dodany do kontenera. Druga to dane produktowe. Trzecia to warunek, o którym zapomina się najczęściej: tag Conversion Linker musi odpalać się na wszystkich stronach.

Dane produktowe mają dwie postacie i wybór między nimi zależy od tego, co już masz na stronie. Jeśli sklep pcha do warstwy danych tablicę ecommerce.purchase.products, w tagu wystarczy zaznaczyć w sekcji Product Reporting opcję dostarczania danych na poziomie sprzedaży i wybrać źródło Data Layer. Google Tag Manager podstawi to, co znalazł w tablicy, bez dodatkowej pracy.

Jeśli dane nie są dostępne w warstwie, zostaje zmienna JavaScript. W tym samym miejscu w tagu wybierasz źródło JavaScript variable i podłączasz cztery pola: Product Data, Merchant ID, Feed Label oraz Feed Language. Każde z nich może być osobną zmienną albo polem jednego obiektu, pod warunkiem że po podstawieniu trafią tam właściwe wartości. Pole Feed Label jest opcjonalne, ale przy kilku feedach pomaga rozróżnić, który zestaw produktów obsłużył transakcję.

Struktura tablicy jest krótka: id, price, quantity, a opcjonalnie country, language, merchant_feed_label, merchant_feed_language i merchant_id. Każda pozycja koszyka to osobny element tablicy, także gdy sprzedajesz ten sam produkt w dwóch wariantach. Cena dotyczy jednej sztuki i nie zawiera podatku, wysyłki ani rabatów na poziomie całej transakcji.

Zanim dotkniesz tagu, warto sprawdzić, czy warstwa danych w ogóle pracuje. Najczęstszy scenariusz to tablica, która ma inne nazwy pól niż dokumentacja, na przykład item_id zamiast id. Tag nie zgłosi wtedy błędu, tylko wyśle konwersję bez produktów, a w panelu podglądu wszystko będzie wyglądać poprawnie.

Jak sprawdzić, że parametry wychodzą z przeglądarki

Test jest ten sam, który Google opisuje dla konwersji z danymi koszyka. Złóż zamówienie testowe i podejrzyj ruch w narzędziach deweloperskich przeglądarki. W panelu Network filtrujesz po /conversion i oglądasz parametry żądania. Powinny tam być mid, fcntr, flng, dscnt, bttype oraz item z pozycjami.

Osobny przypadek to obrazkowy tag Floodlight, ten w elemencie noscript. Część wdrożeń pomija go, uznając za relikt. To błąd, bo Google zaleca dopisanie parametrów koszyka również tam: przeglądarki bez JavaScriptu raportują konwersję tylko przez ten znacznik. Po uzupełnieniu dane dochodzą z obu ścieżek.

Druga kontrola jest po stronie Campaign Manager 360. W Report Builderze tworzysz nowy raport, filtrujesz go do jednej konfiguracji Floodlight, dodajesz pola konwersji, w tym identyfikator aktywności i u-variables, a potem kolumnę z przesłanymi danymi koszyka. Ta kolumna pokazuje dokładnie to, co dotarło, bez zgadywania po liczbach w interfejsie.

W Google Ads dostępne jest jeszcze narzędzie diagnostyczne dla konwersji z danymi koszyka. Warto je uruchomić krótko po wdrożeniu, bo wyłapuje braki w identyfikatorach i cenie szybciej niż jakikolwiek raport. Kontrolę pokrycia tagów na stronie opisałem szerzej przy okazji diagnostyki pokrycia tagów w GTM.

Gdzie to się najczęściej psuje

Większość problemów nie leży w tagu. Leży w danych, które do niego trafiają, albo w ustawieniach konta. Osiem przypadków poniżej pokrywa znakomitą część zgłoszeń.

• Identyfikatory pozycji nie zgadzają się z Merchant Center. Dopasowanie idzie po id, nie po nazwie produktu, więc literówka w feedzie wycina transakcję z raportu.
• Brak ceny. Pozycja bez price jest niekompletna i psuje całą transakcję, nie tylko pojedynczy wiersz.
• Rozjazd między items.id a items.item_id. Przy wielu integracjach Google prosi o wpisanie tego samego identyfikatora w oba pola. Wpisany tylko w jedno daje raport, który wygląda na prawie poprawny.
• Konwersja ustawiona jako drugorzędna. Działania drugorzędne nie pojawiają się w głównej kolumnie konwersji, więc dane koszyka nie mają gdzie wejść.
• Podwójne liczenie po stronie sklepu. W systemach typu Shopify czy Wix skrypt wgrany bezpośrednio i aplikacja robiąca to samo dają dwa żądania na jedno zamówienie. Trzeba wybrać jedną drogę i usunąć drugą.
• Brak tagu Conversion Linker. Bez niego atrybucja po kliknięciu gubi się przy przejściach między domenami. Temat rozwinąłem w artykule o śledzeniu międzydomenowym w GA4.
• Niespójny podatek. Jeśli w kosztach własnych uwzględniasz VAT, ten sam VAT musi być w items.price. Mieszanie obu podejść psuje wyliczenie marży i podważa sens raportu.
• Zbyt wczesny wniosek. Google przypisuje konwersję do daty ostatniego kliknięcia, a dane potrzebują od 24 do 48 godzin na przetworzenie. Kontrola raportu godzinę po wdrożeniu prowadzi do fałszywych alarmów.

Do tego dochodzi kwestia interpretacji. Dane koszyka mówią, co się sprzedało, a nie dlaczego. Przypisanie zasługi do konkretnego kanału to odrębna decyzja, opisana w artykule o modelach atrybucji w GA4. Mieszanie jednego z drugim kończy się raportem, którego nikt nie potrafi obronić na spotkaniu.

Co zrobić w tym tygodniu

1. Sprawdź, czy aktywność Floodlight raportująca zakupy jest typu sprzedażowego i czy cel główny jest ustawiony na tak.
2. Zajrzyj do tagu Floodlight Sales w kontenerze i ustal, skąd biorą się dane produktowe: warstwa danych czy zmienna JavaScript.
3. Porównaj identyfikatory produktów z feedu z tymi, które wysyła strona. Różnice zapisz, bo one zjadają większość danych.
4. Złóż zamówienie testowe, otwórz panel Network i sprawdź, czy w żądaniu /conversion są mid, fcntr i flng razem z pozycjami koszyka.
5. Uzupełnij obrazkowy tag Floodlight, jeśli z niego korzystasz.
6. Uruchom raport w Report Builderze z kolumną przesłanych danych koszyka i porównaj wynik z tym, co widzi sklep.
7. Powtórz kontrolę po dwóch dniach, żeby oddzielić opóźnienie przetwarzania od prawdziwego błędu we wdrożeniu.

Parametry koszyka nie naprawiają atrybucji same z siebie. Domykają lukę między konwersją a produktem, a to dwie różne rzeczy. Wdrożenie, które przekazuje identyfikator sprzedawcy, kraj i język feedu oraz pełną listę pozycji, daje raport odpowiadający na pytanie o produkty. Wdrożenie bez nich daje liczbę, której nikt nie potrafi rozłożyć na części.