Cloudflare Zaraz dla WooCommerce: zdarzenia e-commerce, zgody i testy

Cloudflare Zaraz może przekazywać obsługiwane zdarzenia e-commerce do narzędzi analitycznych i reklamowych, ale WooCommerce nadal potrzebuje wiarygodnego źródła danych o produktach, koszyku, checkoucie i zamówieniach. Wdrożenie produkcyjne zależy od wybranej ścieżki integracji, jasnych reguł zgód i testów, które porównują śledzenie z prawdziwymi zamówieniami w sklepie.

Co Cloudflare Zaraz zmienia w śledzeniu WooCommerce?

Zaraz kieruje obsługiwane akcje narzędzi zewnętrznych przez Cloudflare. WooCommerce lub integracja nadal muszą emitować zdarzenia i dane sprzedażowe, a każde narzędzie docelowe, wtyczka i ścieżka checkoutu wymagają osobnego sprawdzenia zgodności.

Zaraz udostępnia Web API dla e-commerce z nazwanymi zdarzeniami na całej ścieżce zakupowej, od aktywności związanej z produktem i koszykiem po zrealizowane i zwrócone zamówienia. Dokumentacja Cloudflare wymienia 19 obsługiwanych nazw zdarzeń, wymaga włączenia śledzenia e-commerce na koncie i w każdym narzędziu odbierającym oraz ostrzega, że duże ładunki zamówień mogą przekroczyć limity narzędzia docelowego.

WooCommerce pozostaje źródłem stanu sprzedaży. Wie, jaki produkt wybrał klient, co jest w koszyku i czy zamówienie osiągnęło stan, który Twoja firma uznaje za zakup. Zaraz przekazuje zdarzenia do skonfigurowanych narzędzi.

Zdarzenie może pojawić się w Zaraz, a mimo to nie dotrzeć do narzędzia docelowego: jego akcja jest wyłączona, ładunek nie odpowiada temu, czego oczekuje narzędzie, narzędzie nie obsługuje tego zdarzenia automatycznie albo zablokował je brak zgody.

Przeniesienie akcji śledzących do Zaraz może zmniejszyć liczbę skryptów zewnętrznych uruchamianych bezpośrednio w przeglądarce. Kilka narzędzi, w tym narzędzie Facebooka w Zaraz, wysyła żądania z brzegu sieci Cloudflare zamiast ładować skrypt dostawcy. Loader Zaraz nadal się uruchamia, a niektóre narzędzia wciąż działają w przeglądarce, więc zmierz strony produktu, koszyka i checkoutu przed zmianą i po niej. Optymalizacja szybkości WordPressa w IMADO może obejmować taki pomiar, gdy zmiany w śledzeniu są częścią szerszego przeglądu wydajności.

Jak mapować zdarzenia WooCommerce na zdarzenia e-commerce w Zaraz?

Stosuj jeden udokumentowany kontrakt zdarzeń dla produktu, koszyka, checkoutu i zamówienia, ze spójnymi ID produktów, ID zamówień, walutą, ilościami i wartościami. Wysyłaj Order Completed dopiero wtedy, gdy spełniony jest warunek zakupu przyjęty w sklepie.

Minimalne wywołanie Order Completed z polami opisanymi w dokumentacji Zaraz wygląda tak:

zaraz.ecommerce('Order Completed', {
  order_id: '10482',
  total: 349.00,
  revenue: 300.81,
  tax: 48.19,
  shipping: 0,
  currency: 'PLN',
  products: [
    { product_id: '275333', sku: 'DDS-M1', name: 'Silk scarf', variant: '63 x 63 cm', price: 349.00, quantity: 1 }
  ]
});

Ustal, czy firma raportuje zamówienie w momencie autoryzacji płatności, jej pobrania czy osiągnięcia innego stanu zamówienia. Ma to znaczenie przy przelewach bankowych, płatności przy odbiorze, przekierowaniach do bramek płatniczych i subskrypcjach, gdzie zakończenie checkoutu i rozliczenie następują w różnym czasie.

Produkty z wariantami wymagają przemyślanej reguły ID

Wielu klientów otwiera produkt z wariantami i nigdy nie wybiera wariantu. Feedy produktowe też się różnią: feed Google Merchant Center często wymienia warianty, a katalogi Meta grupują warianty pod produktem nadrzędnym. Praktyczna reguła to jedno wyświetlenie produktu na jedno załadowanie strony: wyślij ID wariantu, gdy istnieje wariant domyślny lub wybrany, a w przeciwnym razie wyślij do Meta ID produktu nadrzędnego z contenttype: productgroup. Nie wysyłaj kolejnego wyświetlenia za każdym razem, gdy klient zmienia wariant.

Utrzymuj spójne pola kwot i identyfikatory produktów

Używaj stałego ID zamówienia, aby uzgadniać zakupy między WooCommerce a analityką, i wykorzystuj je jako ID zdarzenia, żeby narzędzia docelowe mogły deduplikować ponowne wysyłki. Przekazuj walutę jawnie. Zapisz, czy wartość zakupu obejmuje podatek i wysyłkę oraz jak traktowane są rabaty, a potem mapuj te pola tak samo dla każdego narzędzia. Jeśli jedno narzędzie dostaje kwotę brutto, a inne wartość netto towarów, raporty będą się różnić, nawet gdy oba strumienie działają.

Traktuj bloki checkoutu i przekierowania płatności jako osobne przypadki testowe

Kliknięcie „Złóż zamówienie” rozpoczyna checkout. Walidacja może się nie powieść, operator może odrzucić płatność, a przekierowanie może wrócić bez udanego zamówienia. Wysyłaj przychód z zakupu dopiero wtedy, gdy WooCommerce lub proces płatności go potwierdzi.

Klasyczny checkout, Checkout Block, koszyki AJAX, przyciski szybkich płatności i zewnętrzne strony płatności udostępniają różne zdarzenia i ścieżki powrotu. Nasłuchuj punktów rozszerzeń tego checkoutu, którego faktycznie używasz, i weryfikuj wynik z końcowym rekordem zamówienia.

Wtyczka WooCommerce czy własne podpięcie zdarzeń Zaraz?

Użyj utrzymywanej integracji, gdy obsługuje Twój checkout, konfigurację zgód, narzędzia docelowe i kontrakt zdarzeń. Wybierz własne podpięcie, gdy checkout lub reguły zamówień wymagają kontroli, której wtyczka nie daje.

Zanim wdrożysz wtyczkę, potwierdź, że:

• Obsługuje Twoją wersję WooCommerce, typ checkoutu, metody płatności i typy produktów.
• Wysyła nazwy zdarzeń i pola, których wymagają Twoje narzędzia docelowe.
• Jej integracja zgód działa z Twoją platformą do zarządzania zgodami.
• Możesz przeglądać, eksportować i przywracać konfigurację Zaraz.
• Zespół wie, który system odpowiada za każde zdarzenie i gdzie szukać przyczyn problemów.

Przed zaimportowaniem wygenerowanej konfiguracji Zaraz przejrzyj wyzwalacze, akcje i ustawienia narzędzi, które zmienia, przetestuj ją w kontrolowanym środowisku i potwierdź ścieżkę wycofania zmian. Audyt strony WordPress może przed decyzją obejrzeć istniejący zestaw wtyczek, śledzenie i proces checkoutu.

Własne podpięcie zwykle pasuje do niestandardowych checkoutów, subskrypcji, opóźnionego potwierdzania płatności, reguł wielowalutowych, stanów zamówień sterowanych przez ERP lub połączenia sygnałów z przeglądarki i serwera. Pozwala inżynierom określić, kiedy zdarzenia się wywołują i jak obsługiwane są ponowne próby, zwroty i zduplikowane callbacki, ale wymaga właściciela, gdy zmieniają się WooCommerce, bramki płatnicze lub rozszerzenia.

Sprawdza się też rozwiązanie hybrydowe: wtyczka do standardowych zdarzeń produktu i koszyka oraz mała własna integracja dla nietypowej reguły zakupu lub zwrotu. Każde zdarzenie powinno mieć jedno źródło prawdy. Nakładające się wtyczki, tagi Google Tag Managera i akcje Zaraz dla tego samego piksela mogą policzyć jeden zakup kilka razy.

Jeśli rozważasz te opcje dla sklepu z niestandardowym checkoutem lub kilkoma platformami reklamowymi, porozmawiaj z inżynierami WooCommerce w IMADO, zanim wybierzesz podejście.

Jak skonfigurować zgody dla Cloudflare Zaraz w WooCommerce?

Przypisz każde narzędzie zewnętrzne do jawnego celu zgody, a potem sprawdź, czy odmowa zgody je zatrzymuje. Dokumentacja Consent Management w Cloudflare mówi, że każde narzędzie ma jeden cel, a narzędzie bez przypisanego celu domyślnie pomija sprawdzanie zgody, więc nowo dodane narzędzie może ominąć tę blokadę, jeśli nikt go nie zmapuje.

Włącz inwentaryzację zgód do listy kontrolnej wdrożenia: każde narzędzie, jego cel, miejsce docelowe, zdarzenia, które otrzymuje, i stan zgody, którego potrzebuje.

Przetestuj co najmniej te stany:

• Brak wyboru: opcjonalne narzędzia nie wysyłają niczego przed udzieleniem zgody.
• Odmowa zgody: żądania do danego narzędzia ustają.
• Udzielona zgoda: oczekiwane zdarzenia docierają do narzędzia.
• Zmiana preferencji: po przeładowaniu narzędzie stosuje nowy wybór.
• Powracająca sesja: zapisane preferencje działają bez nowej akcji w koszyku czy zamówieniu.

Szczególnie sprawdź pierwsze załadowanie strony. API zgód Zaraz zwykle staje się dostępne dopiero po uruchomieniu skryptów samej strony, więc integracja, która sprawdza zgodę od razu, może potraktować odwiedzającego ze zgodą jak osobę bez zgody i porzucić zdarzenie. Poczekaj na API, zanim podejmiesz decyzję:

function onConsentReady(callback) {
  if (window.zaraz && zaraz.consent && zaraz.consent.APIReady) callback();
  else document.addEventListener('zarazConsentAPIReady', callback, { once: true });
}

Jeśli narzędzia Google działają w trybie zaawansowanym Consent Mode v2, mogą wysyłać pingi bez plików cookie nawet przy odmowie zgody. Zdecyduj, czy to zgodne z Twoją polityką, i przetestuj to osobno.

Działanie sklepu nie może zależeć od śledzenia: koszyk, konto i płatność muszą działać, gdy klient odrzuci cele opcjonalne. Wysyłaj tylko pola, których potrzebuje dane narzędzie, i nie umieszczaj danych osobowych we wspólnych ładunkach zdarzeń. Zaraz egzekwuje skonfigurowane preferencje; to właściciel strony decyduje, które cele i teksty pasują do każdego rynku, więc niech przejrzy je osoba odpowiedzialna za prywatność lub kwestie prawne.

Jak testować zdarzenia e-commerce Cloudflare Zaraz przed uruchomieniem?

Zweryfikuj zamówienie testowe od WooCommerce przez Zaraz do każdego narzędzia docelowego w trybie Preview lub na stagingu, a następnie porównaj zdarzenia i wartości z zamówieniem w WooCommerce. Strona bez błędów JavaScript nie dowodzi, że zakup został policzony raz ani że zgody działały.

Prześledź jedną sesję testową i zapisz oczekiwane zdarzenie na każdym etapie: wyświetlenie produktu, dodanie do koszyka, wyświetlenie koszyka, rozpoczęcie checkoutu, wynik płatności, zakup i zwrot. Sprawdź osobno zdarzenie źródłowe, wyzwalacz i akcję w Zaraz oraz narzędzie odbierające; awaria na jednej warstwie wygląda w końcowym dashboardzie jak ogólna luka w danych.

Macierz testów powinna obejmować:

• Nową sesję bez wyboru zgody, potem odmowę i udzielenie zgody, w tym akceptację na stronie wejścia.
• Produkt z wariantami z wybranym wariantem i bez niego, zmianę ilości i usunięcie pozycji.
• Kupony, rabaty, wysyłkę, podatek i każdą raportowaną walutę.
• Każdy typ płatności: odrzuconą, oczekującą, z przekierowaniem i udaną.
• Udane zamówienie, a po nim odświeżenie strony potwierdzenia.
• Zwrot częściowy lub pełny, jeśli raportujesz zwroty.
• Każdą ścieżkę checkoutu w sklepie: Checkout Block, AJAX, subskrypcję, szybką płatność.

Zapisz ID każdego zamówienia testowego i znajdź to samo ID w narzędziu docelowym. Pomagają w tym narzędzia testowe po stronie dostawców: Test Events w Meta pokazuje, czy zdarzenie serwerowe zawierało dane użytkownika i ID produktów. Przed publikacją usuń z narzędzia kod zdarzeń testowych, bo zdarzenia wysłane z kodem testowym nie liczą się w raportach produkcyjnych.

Używaj Zaraz Monitoring, aby oddzielić liczbę zdarzeń od wyzwalaczy, akcji i statusów żądań po stronie serwera. Jeśli Zaraz policzył zdarzenie, ale narzędzie docelowe go nie otrzymało, sprawdź konfigurację narzędzia i odpowiedź. Jeśli Zaraz nigdy go nie policzył, sprawdź integrację WooCommerce i moment wywołania zdarzenia. Przed publikacją zapisz zaakceptowane wyniki i wersję konfiguracji.

Co psuje się na produkcji?

Najbardziej szkodliwe problemy to fałszywe i zduplikowane zakupy, obchodzenie zgód oraz zdarzenia, które po cichu znikają. Te wzorce widzimy najczęściej, gdy sklepy WooCommerce przenoszą śledzenie do Zaraz.

Zdarzenia e-commerce są wspólne dla wszystkich narzędzi z włączonym e-commerce.

Wywołanie zaraz.ecommerce() trafia do każdego narzędzia z włączonym śledzeniem e-commerce, z tym samym ładunkiem, a pól nie da się filtrować per narzędzie. Nigdy nie umieszczaj adresów e-mail ani numerów telefonów w zdarzeniach e-commerce. Dla danych specyficznych dla jednego narzędzia wyślij osobne zdarzenie zaraz.track() z właściwością routingu, podepnij je tylko pod wyzwalacz tego narzędzia i użyj reguły takiej jak {{ client._zarazTrack }} równe viewitem w połączeniu z Twoją flagą routingu.

Pełny cache stron zachowuje starą konfigurację śledzenia.

Konfiguracja i wersje skryptów wypisane w HTML zostają po wdrożeniu w cache Cloudflare i serwera. Zbuforowane strony produktów i kategorii nadal wysyłają zdarzenia w starym kształcie, a niebuforowane strony koszyka i checkoutu w nowym. Przy każdym wdrożeniu zmian w śledzeniu czyść cache stron, zminifikowanych zasobów i Cloudflare.

Narzędzia po stronie serwera nadal potrzebują czystych danych identyfikacyjnych.

Narzędzie Facebooka w Zaraz wysyła zdarzenia przez Conversions API i samo haszuje e-mail, telefon oraz inne pola użytkownika. Wysyłaj znormalizowane surowe wartości: e-mail małymi literami, telefon z kodem kraju, kod pocztowy bez spacji i myślników. Wartości zahaszowane wcześniej zostaną zahaszowane dwukrotnie i przestaną się dopasowywać. Stałe zewnętrzne ID, na przykład hash adresu e-mail klienta przechowywany w first-party ciasteczku HttpOnly, pozwala dopasować powracających klientów bez przechowywania danych osobowych w przeglądarce.

Zmiana narzędzi resetuje identyfikatory klientów.

Wtyczka pikseli, którą zastępujesz, prawdopodobnie od lat wysyła własne zewnętrzne ID. PixelYourSite na przykład generuje losowe ID i przechowuje je w ciasteczku przeglądarki (pbid), na koncie klienta i w metadanych każdego zamówienia. Jeśli nowa konfiguracja zacznie zamiast tego wysyłać hash e-maila, Meta uzna każdego powracającego klienta za nową osobę, a jakość dopasowania i ciągłość grup odbiorców spadną. Planując migrację, sprawdź, jakie identyfikatory zapisuje obecna konfiguracja i gdzie. Potem używaj ich w stałej kolejności: ID zapisane w zamówieniu lub na koncie klienta, dotychczasowe ciasteczko, a dopiero na końcu nowy hash e-maila. Zapisuj wybrane ID w nowych zamówieniach i kontach, żeby od tej pory pozostawało stałe.

Akcje typu „catch-all” tworzą duplikaty.

Ogólna akcja „wszystkie pozostałe zdarzenia” obok dedykowanych akcji, takich jak ViewCategory, wywoła obie, chyba że ogólny wyzwalacz wyklucza każde zdarzenie, które ma własną akcję. Zaraz ogranicza wartości dopasowania do 128 znaków, więc wzorce wykluczeń muszą być zwięzłe.

Niektóre zdarzenia w ogóle nie docierają.

Blokery reklam i automatyczne ukrywanie banerów cookie usuwają część sygnałów z przeglądarki, w tym własną atrybucję zamówień WooCommerce. Spodziewaj się różnicy między liczbą zamówień a zamówień z atrybucją, zmierz ją i jako punkt odniesienia traktuj zakupy potwierdzone przez serwer.

Fałszywe zakupy biorą się z nasłuchiwania kliknięcia przycisku, kroku przed płatnością lub wizyty na stronie podziękowania bez sprawdzenia stanu zamówienia. Używaj trwałego odniesienia do zamówienia i idempotentnej reguły, żeby ponowna próba lub odświeżenie nie zarejestrowały zamówienia ponownie.

Jeśli kilka z tych problemów brzmi znajomo, przyczyną jest zwykle projekt integracji, a nie pojedyncze ustawienie. Zespół WooCommerce w IMADO może przeprowadzić audyt przepływu zdarzeń i naprawić go na stagingu, zanim błędy trafią do raportów.

Kiedy produkcyjne wdrożenie Zaraz wymaga wsparcia inżynierskiego?

Zaangażuj inżyniera WooCommerce, gdy modyfikacje checkoutu, stan płatności, narzędzia do zgód lub nakładająca się analityka utrudniają udowodnienie, że na każdą akcję w sklepie przypada dokładnie jedno poprawne zdarzenie.

Inżynier ustala kontrakt zdarzeń z marketingiem i finansami, wybiera wtyczkę lub własne podpięcie, testuje je na prawdziwym checkoucie i w cyklu życia zamówienia oraz dokumentuje, które narzędzie odpowiada za każde zdarzenie i jak blokuje je zgoda. To się opłaca, gdy pominięte lub zduplikowane zakupy wpływają na decyzje kampanijne, uzgadnianie danych lub zaufanie zespołu do raportów. Po uruchomieniu wsparcie i utrzymanie WordPressa albo plan opieki nad stroną utrzymuje testy regresji w procesie wdrożeń, gdy zmieniają się wtyczki i bramki płatnicze.

Podsumowanie

Niezawodna konfiguracja Cloudflare Zaraz dla WooCommerce zaczyna się od jawnego kontraktu zdarzeń, celu zgody dla każdego narzędzia, uwzględnienia momentu udzielenia zgody na pierwszej stronie i zamówień testowych, które zgadzają się z danymi sklepu. Wybierz wtyczkę lub własne podpięcie na podstawie checkoutu i reguł raportowania, których faktycznie używasz, a przy każdym wdrożeniu zmian w śledzeniu czyść cache i testuj ponownie.

Planujesz wdrożenie Zaraz albo naprawiasz takie, w którym liczby się nie zgadzają? Porozmawiaj z IMADO o swoim projekcie WooCommerce.