Twoja nieruchomość GA4 zgłasza 4,180 zakupów w zeszłym miesiącu. W tabeli zamówień widnieje 4,690. Zapytany, która wartość jest prawidłowa, szczerze odpowiada: żadna, dopóki nie będziesz w stanie określić, gdzie podziało się brakujące 510 zamówień. To nie jest problem z porządkiem. Każdy wynik eksperymentu i każdy wynik priorytetyzacji, który generujesz, jest obliczany na podstawie liczby, która jest błędna o nieznaną wartość i w nieznanym kierunku.
Google traktuje duży, niemierzalny fragment jako normalny: modelowanie zachowań dla trybu zgody nie włącza się, dopóki właściwość nie zarejestruje co najmniej 1,000 wydarzeń dziennie analytics_storage='denied' przez co najmniej 7 dniPoniżej tego przedziału brakujące dane pozostają niedostępne.
To narzędzie jest przeznaczone dla każdego, kto odpowiada za analitykę lub współczynnik konwersji (CRO) w zespole e-commerce. Na koniec otrzymasz tabelę uzgodnień, rozkład luki na nazwane przyczyny wraz z testem dla każdej z nich oraz wartość tolerancji, którą możesz obronić.
Co tak naprawdę mierzy uzgodnienie zakupu
Uzgodnienie nie polega na „doprowadzeniu liczb do zgodności”. Nigdy się one nie zgodzą, a zespół, który go do tego zmusza, zazwyczaj popełnił coś gorszego niż pozostawienie luki w spokoju. Uzgodnienie odpowiada na trzy pytania: jak duża jest luka, jakie mechanizmy ją generują i ile jest możliwe do odzyskania i jakim kosztem. Przeprowadzamy je przed jakimkolwiek eksperymentem, ponieważ test mierzony na podstawie zdarzenia konwersji, które po cichu zmniejsza nieznaną część zamówień, nie jest eksperymentem.
Krok 1: wybierz dwie tabele, które można połączyć według identyfikatora zamówienia
Potrzebny jest jeden wiersz na zamówienie, z obu systemów, dla tego samego zakresu kalendarza, z kluczem istniejącym po obu stronach.
- backend: Identyfikator zamówienia, znacznik czasu utworzenia w strefie czasowej raportowania danej nieruchomości, wartość zamówienia na tej samej podstawie podatku i wysyłki, którą skonfigurowałeś w GA4, metoda płatności, urządzenie, kraj, status.
- GA4: eksport BigQuery, a nie interfejs użytkownika. Zapytanie
purchasewydarzenia zecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, kategoria urządzenia i źródło ruchu.
Używaj BigQuery świadomie. Modelowane dane z trybu zgody pojawiają się w standardowych raportach GA4 i niektórych eksploracjach, ale Google twierdzi, że… nie W eksporcie BigQuery, odbiorcach, eksploratorze użytkowników, eksploracjach kohort lub retencji, a także metrykach predykcyjnych. Porównaj interfejs użytkownika z tabelą zamówień, a porównasz szacunek z faktem.
Następnie pełne sprzężenie zewnętrzne na identyfikatorze zamówienia. Masz teraz trzy kontenery: w obu tylko back-end i tylko GA4. Trzeci jest mniejszy, ale najbardziej diagnostyczny.
Krok 2: wyraź lukę na trzy sposoby, a nie jeden
Pojedynczy miesięczny procent ukrywa wszystko. Oblicz wszystkie trzy:
- Różnica między liczbą zamówień: (zamówienia końcowe pomniejszone o dopasowane zakupy GA4) / zamówienia końcowe. To izoluje straty z tytułu śledzenia.
- Różnica w przychodach: To samo obliczenie wartości. Jeśli luka w liczbie wynosi 3%, a luka w przychodach 11%, nie masz problemu ze śledzeniem, tylko z definicją wartości (podatek, wysyłka, rabaty, waluta, karty podarunkowe).
- Dzienna wariancja luki: Narysuj dzienną lukę w liczbie zamówień. Płaska linia oznacza przyczynę strukturalną, taką jak zgoda lub blokady. Skoki oznaczają wdrożenia, wzrosty liczby kampanii lub incydenty związane z dostawcą płatności.
Krok 3: rozłóż lukę na nazwane przyczyny
Przeanalizuj tę tabelę. Każda przyczyna ma test, który może ją potwierdzić lub wyeliminować w mniej niż godzinę.
| Spowodować | Jak to przetestować | Podpis w danych |
|---|---|---|
| Zgoda odmówiona, tag nigdy nie zostanie uruchomiony | Porównaj dziennik stanu zgody CMP z sesjami GA4 w tym samym okresie | Stabilny dzienny odsetek; skoncentrowany w ruchu w UE i Turcji |
| Blokery reklam i trackerów | Zlicz żądania dotyczące logów serwera dla adresu URL potwierdzenia i porównaj je ze zdarzeniami zakupu GA4 na tym adresie URL | Obsługuje komputery stacjonarne, przeglądarkę Firefox i przeglądarki zapewniające prywatność; stabilny z czasem |
| Strona potwierdzenia nigdy się nie ładuje | Zliczaj zamówienia złożone wyłącznie za pośrednictwem zaplecza, których adres URL potwierdzenia nigdy nie został zażądany w dziennikach serwera | Skoncentrowany na metodach płatności typu bank-redirect i 3DS |
| Zduplikowane zdarzenia zakupu | Liczba zdarzeń zakupu GA4 na transaction_id | W niektóre dni GA4 przekracza możliwości zaplecza; strony wymagają częstego odświeżania i klikania przycisku „Wstecz” |
| Zerwany link międzydomenowy | Sprawdź, czy _gl przetrwa podróż powrotną od dostawcy płatności | Zakupy trafiają do nowych sesji przypisanych do domeny płatności jako polecenie |
| Resetowanie okresu ważności plików cookie | Segmentacja wskaźnika nowych użytkowników według przeglądarki | Zwiększona liczba nowych użytkowników i ruch bezpośredni w Safari i iOS |
| Modelowane kontra surowe | Porównaj sumy GA4 UI z BigQuery dla tego samego zakresu dat | Dwie liczby Google'a nie zgadzają się, zanim jeszcze otworzysz tabelę zamówień |
| Definicja wartości | Przelicz przychody końcowe z uwzględnieniem i bez uwzględnienia podatku, kosztów wysyłki i rabatów | Liczba się zgadza, przychody nie |
| Granica strefy czasowej | Ponowne zsumowanie do pełnych tygodni | Luka zmniejsza się do zera przy tygodniowej granularności |
Dwoje zasługuje na szczególną opiekę. transaction_id deduplikacja działa tylko w strumieniach internetowych, a nie w strumieniach aplikacji, a Google ostrzega, że wysłanie pustego ciągu powoduje deduplikację usługi Analytics każdy wydarzenie zakupowe transaction_id=''Ten jeden błąd może zniweczyć większość dnia. Co więcej, lista niechcianych poleceń jest ograniczona do 50 domen na strumień danych, co jest uciążliwe, jeśli korzystasz z kilku programów do pobierania, portfeli i stron bankowych.
[POTRZEBNE DANE WEWNĘTRZNE: zaobserwowany rozkład tych dziewięciu przyczyn w ramach działań pojednawczych Switas, aby czytelnicy mogli zobaczyć, które z nich zwykle dominują.]
Krok 4: ustaw tolerancję, której możesz bronić
Google nie publikuje żadnych dopuszczalnych wartości rozbieżności, a często cytowane stwierdzenie „5% jest w porządku” nie pojawia się w żadnej dokumentacji Google, jaką udało nam się znaleźć. Ustaw własną, opierając się na rozkładzie, a nie wyłącznie na liczbie.
| Miesięczna luka w liczbie zamówień | Czytający | Działania |
|---|---|---|
| Do 2% | Granice stref czasowych i normalna deduplikacja | Rejestruj przyczyny i sprawdzaj ponownie co kwartał |
| % 2 do 5% | Dopuszczalne tylko wtedy, gdy każdy punkt jest przypisany do określonej przyczyny | Udokumentuj, a następnie przejdź do eksperymentu |
| % 5 do 10% | Co najmniej jedna przyczyna strukturalna jest nieustalona | Napraw przed zaufaniem liczbom konwersji bezwzględnej |
| Powyżej 10% | Nie nadaje się do eksperymentów | Zaprzestań używania zakupów GA4 jako głównego wskaźnika eksperymentu do czasu wprowadzenia poprawek |
To nasze progi operacyjne, a nie standard branżowy. Sedno sprawy jest takie: niewyjaśnione 3% jest gorsze niż wyjaśnione 8%.
Krok 5: napraw w kolejności, która zapewnia najwięcej zamówień na godzinę pracy
- Definicja wartości i strefa czasowa. Konfiguracja, nie inżynieria, zwykle zajmuje to popołudnie.
- Duplikaty i puste identyfikatory transakcji. Jedna poprawka dataLayer.
- Odnośniki międzydomenowe i niechciane odnośniki. Skonfiguruj oba, a następnie ponownie przetestuj ścieżkę zwrotu płatności na żywo, a nie na etapie przejściowym.
- Zdarzenie zakupu po stronie serwera. Wyślij zakup z systemu zamówień za pomocą protokołu pomiarowego, korzystając z
client_idWygenerowano Twój tag internetowy. Google wymaga, aby te zdarzenia nastąpiły w ciągu 48 godzin od pierwotnego znacznika czasu zdarzenia po stronie klienta, w przeciwnym razie atrybucja może nie zostać przetworzona zgodnie z oczekiwaniami. To właśnie przywraca zamówienia utracone z powodu blokad i stron potwierdzenia, które nigdy nie zostały wyrenderowane. - Architektura zgody. Najwolniejszy i najbardziej polityczny. Pozostałą część traktuj jako znaną, udokumentowaną lukę.
Co się zmienia, jeśli sprzedajesz w Turcji lub UE
Na wyniki wpływają dwa regionalne fakty.
W Turcji również obowiązuje zasada opt-in, jednak bez zabezpieczenia Google. Turecki urząd ochrony danych nałożył na operatora strony internetowej grzywnę w wysokości 300 000 TL w decyzji 2022/1358 (z dnia 23 grudnia 2022 r.) za stosowanie plików cookie do celów reklamowych i marketingowych bez podstawy prawnej i wymaganie aktywnej zgody na pliki cookie niebędące niezbędne. Wiele tureckich stron odpowiedziało banerem, który całkowicie blokuje tag Google, zamiast takiego, który wysyła sygnały zgody. To rozróżnienie jest kosztowne: modelowanie wymaga analytics_storage='denied' zdarzeń. Baner, który nic nie wyświetla, nie daje Google żadnego narzędzia do modelowania, więc dane znikają, a nie są szacowane.
Tureckie przepływy 3DS zwracają nabywcy za pośrednictwem poczty POST. Dzięki iyzico sprzedawca renderuje zdekodowaną stronę 3DS i po potwierdzeniu OTP iyzico przekierowuje do sprzedawcy callbackUrl w status, paymentId oraz mdStatus. Zwrot sterowany metodą POST to dokładnie to, co Google nazywa przerwaniem pomiaru międzydomenowego, ponieważ przekierowania mogą usuwać _gl przed załadunkiem towaru do miejsca docelowego. Jeśli różnica w płatnościach kartą jest bliska zeru, a w przypadku płatności gotówką przy odbiorze jest bliska zeru, to właśnie dlatego.
Dwa często powtarzane twierdzenia, których nie mogliśmy zweryfikować
„Safari ogranicza okres przechowywania plików cookie pierwszej strony do 7 dni”. Nieprecyzyjne. W dokumentacji WebKita napisano, że ITP usuwa pliki cookie JavaScript i inne pliki pamięci masowej z możliwością zapisu przez skrypty po 7 dniach. brak interakcji użytkownikai oddzielnie ogranicza czas przechowywania plików cookie JavaScript do 24 godzin, jeśli strona docelowa została otwarta za pomocą dekoracji linku z domeny ogłoszeniowej. Testy Simo Ahavy wykazały, że zegar działa na podstawie dni korzystania z przeglądarki, a nie dni kalendarzowych, więc powracający klient może przechowywać identyfikator znacznie dłużej niż tydzień.
„Rozbieżność 5% jest dopuszczalna”. Nie znaleźliśmy żadnego źródła w Google, które by potwierdzało tę liczbę. Krąży ona na blogach sprzedawców i w odpowiedziach na forach. Potraktuj ją jako legendę, a nie jako punkt odniesienia.
Gdzie ta metoda zawodzi
Nie obejmuje strumieni aplikacji, gdzie transaction_id Deduplikacja nie ma zastosowania, podobnie jak modele subskrypcji i częściowej dostawy, gdzie „zamówienie” nie jest pojedynczym zdarzeniem. Nie może odzyskać tożsamości użytkownika, który odmówił zgody, a jedynie oszacować wolumen. Nie rozwiązuje problemu atrybucji kanału, co stanowi odrębny i trudniejszy problem. Zakłada również, że tabela zamówień jest czysta: jeśli anulowane i zablokowane z powodu oszustwa zamówienia są liczone niespójnie po obu stronach, będziesz szukać luki, która istnieje tylko w zapytaniu.
PYTANIA I ODPOWIEDZI
Jak często powinniśmy to uruchamiać? Raz w całości, a następnie dzienny wykres luk. Ponownie uruchom pełną dekompozycję po każdej zmianie płatności, CMP, dostawcy płatności lub menedżera tagów.
Dlaczego nie używać interfejsu GA4 zamiast BigQuery? Interfejs może obejmować modelowanych użytkowników i sesje, których eksport nie uwzględnia, przez co dwie liczby Google różnią się od siebie. Porównanie z szacunkami uniemożliwia rozłożenie różnicy.
Czy tagowanie po stronie serwera całkowicie zlikwiduje tę lukę? Nie. Odzyskuje zamówienia utracone z powodu blokad i stron z potwierdzeniem, które nigdy się nie wyświetliły. Nie odzyskuje użytkowników, którzy odmówili zgody.
GA4 jest wyższe niż nasz back-end. Czy to możliwe? Tak. Zwykle duplikują się zdarzenia zakupowe z odświeżania strony, puste lub ponownie użyte transaction_idlub wydawanie rozkazów strzelania do obiektu produkcyjnego.
Czy tryb zgody rozwiązuje problem braku zgody w Turcji? Częściowo. Odrzucone sygnały umożliwiają modelowanie, z zastrzeżeniem progów wolumenowych Google. Nie zastępuje to legalnego baneru zgodnie z przepisami tureckimi.
Co uznaje się za dobrą przerwę? Taki, w którym każdy punkt procentowy ma swoją nazwę. Udokumentowane 8% pokonuje niewyjaśnione 3%.
Czy powinniśmy ponownie przedstawić raporty historyczne po naprawieniu tego problemu? Nie. Dodaj adnotację do daty korekty i traktuj okresy jako oddzielne serie. Ponowne podanie śledzonych konwersji niszczy ślad audytu.
Czy możemy przeprowadzić testy A/B, gdy różnica wynosi ponad 10%? Przeprowadź je na podstawie względnych wskaźników mierzonych wewnątrz narzędzia testowego, ale nie raportuj bezwzględnego wpływu na przychody z GA4, dopóki luka nie zostanie rozłożona.
Uruchom to uzgadnianie w swoim sklepie w tym miesiącu lub pozwól naszemu zespołowi analityków przeprowadzić z Tobą analizę i podam Ci rozkład, tolerancję i kolejność ustalania.
Źródła
- [GA4] Modelowanie behawioralne dla trybu zgody, Pomoc Google Analytics
- [GA4] Minimalizuj duplikaty kluczowych zdarzeń za pomocą identyfikatorów transakcji, Pomoc Google Analytics
- [GA4] Niechciane polecenia, pomoc Google Analytics
- [GA4] Pomiar międzydomenowy, Pomoc Google Analytics
- Wysyłaj zdarzenia protokołu Measurement Protocol do Google Analytics, Google for Developers
- Parametry trybu zgody, dokumentacja platformy Google Tag Platform
- Zapobieganie śledzeniu w WebKit
- Usunięto limit wygaśnięcia plików cookie JavaScript w przeglądarkach WebKit, Simo Ahava
- KVKK Kurul karari 2022/1358, 23 grudnia 2022 r
- Implementacja 3DS, dokumentacja deweloperska iyzico
