Data strength w Google Ads a WooCommerce: jak wdrożyć first-party data i server-side GTM

Jesienią 2026 roku Google postawił dane first-party w centrum pomiaru Google Ads. 10 września ogłosił metrykę Data Strength Uplift i rozbudowę Data Managera (blog Google Ads and Commerce), a strona pomocy Data Strength Best Practices zamieniła się w przewodnik wdrożeniowy krok po kroku. Kierunek jest jednoznaczny: piksel JavaScript wklejony w nagłówek witryny już nie wystarcza. W świecie zaostrzonych regulacji prywatnościowych, ograniczeń przeglądarek takich jak Safari ITP oraz powszechnego stosowania wtyczek blokujących reklamy, skuteczność kampanii Google Ads w e-commerce zależy bezpośrednio od jakości przesyłanych danych własnych (first-party data) oraz infrastruktury pomiarowej po stronie serwera.

Dla właścicieli sklepów opartych na WooCommerce i inżynierów WordPress oznacza to konieczność porzucenia powierzchownych rozwiązań wtyczkowych na rzecz solidnej architektury danych. Sklep, który przekazuje niepełne lub zniekształcone dane o transakcjach, płaci za to realnie: algorytmy inteligentnego licytowania stawek (Smart Bidding) tracą orientację, a koszt pozyskania zamówienia rośnie.

W tym artykule wyjaśniamy, co obejmuje Data Strength, jakich sygnałów oczekuje Google, jak zbudować rozszerzone konwersje (Enhanced Conversions) i jak wdrożyć Google tag gateway oraz Server-Side Google Tag Manager (sGTM) we własnej domenie sklepu.

#Co to jest data strength w Google Ads i dlaczego decyduje o kosztach kampanii

Data Strength to zbiorcza nazwa, którą Google nadaje konfiguracji pomiaru opartej na danych first-party. Strona pomocy dzieli ją na cztery kroki: podłączenie źródeł danych, maksymalizację sygnałów, aktywację AI Google (Smart Bidding, AI Max for Search, Demand Gen, Performance Max) oraz udowodnienie zwrotu z inwestycji eksperymentami inkrementalności i modelem marketing mix Meridian. Te dane zasilają modele uczenia maszynowego licytujące w kampaniach Performance Max, Demand Gen i w sieci wyszukiwania, więc luki w danych stają się lukami w licytacji.

W Google Ads dwa miejsca zamieniają to na liczby. Nowa metryka Data Strength Uplift według ogłoszenia Google liczy dodatkowe konwersje odzyskane dzięki konfiguracji danych first-party. Oceny jakości pochodzą z diagnostyki: diagnostyka danych offline oznacza importowane dane jako Excellent (co najmniej 90% zdarzeń poprawnie sformatowanych), Good (około 70 do 90%), Needs attention (poniżej 70%) lub No recent data (brak zdarzeń w ostatnich 28 dniach). Rozszerzone konwersje mają osobny raport diagnostyczny.

W sklepie WooCommerce konfiguracja opisana przez Google sprowadza się do czterech warunków technicznych:

1. Kompletność atrybutów transakcji: Każde zdarzenie zakupu musi zawierać precyzyjną wartość, kod waluty ISO 4217 oraz unikalny identyfikator zamówienia (Transaction ID), który zapobiega duplikowaniu konwersji.
2. Gęstość zhaszowanych danych first-party: Przesyłanie znormalizowanego i zhaszowanego adresu e-mail, numeru telefonu oraz adresu pocztowego klienta, które pozwalają powiązać transakcję z zalogowanym kontem Google.
3. Prawidłowa implementacja Consent Mode v2: Przekazywanie parametrów ad_user_data oraz ad_personalization zgodnie z deklaracją użytkownika w banerze zgody. Strona pomocy Google nie wymienia zgody jako kroku Data Strength, ale w UE bez niej nie wolno wysłać żadnego identyfikatora.
4. Stabilność strumienia danych: Eliminacja luk pomiarowych wywołanych awariami skryptów, przerwami w działaniu bramek płatności czy blokadami sieciowymi.

Gdy danych brakuje, algorytm Smart Bidding operuje w warunkach niedoboru informacji. Widzi mniej konwersji, niż sklep faktycznie rejestruje, więc wycenia kliknięcia na słabszych podstawach, a ROAS i koszt konwersji (CPA) idą w złą stronę.

#Jakich sygnałów wymaga przewodnik data strength od Google

Krok “maksymalizuj sygnały” na stronie Data Strength Best Practices wymienia identyfikatory, których Google oczekuje przy każdej konwersji:

• Dane klienta: zhaszowany e-mail lub telefon, które rozszerzone konwersje dopasowują do danych zalogowanych użytkowników Google, odzyskując konwersje niewidoczne dla tagu.
• Adres IP: wysyłany przy imporcie przez Data Managera. Google podaje do 3% więcej zaobserwowanych konwersji w wyszukiwarce i ponad 10% na YouTube w symulacji offline.
• Transaction ID: numer zamówienia lub leada, który łączy kliknięcie na froncie ze sprzedażą w systemie zaplecza.
• GCLID: identyfikator kliknięcia, który mówi Google, która kampania przyniosła sprzedaż.
• Atrybuty sesji: ID kampanii, pełny adres strony docelowej, znacznik czasu sesji, przeglądarka i system operacyjny.
• GBRAID i WBRAID: parametry URL odzyskujące atrybucję konwersji z iOS i z przeglądania prywatnego.

Wynikają z tego dwie zasady. Google zaleca przekazywanie co najmniej 3 identyfikatorów przy każdym zdarzeniu, z priorytetem dla GCLID i IP obok zhaszowanych danych klienta, oraz wysyłanie wszystkich zdarzeń konwersji, a nie wybranej części.

W WooCommerce większość tych danych już siedzi w zamówieniu. $order->get_order_number() to identyfikator transakcji, $order->get_customer_ip_address() zwraca IP zapisane przy składaniu zamówienia, a pola rozliczeniowe niosą dane klienta. GCLID, GBRAID i WBRAID pojawiają się wyłącznie jako parametry adresu strony docelowej, więc sklep, który chce wysyłać konwersje z serwera, musi je przechwycić przy pierwszej odsłonie i zapisać razem z zamówieniem.

Google podpiera stronę własnymi liczbami, każdą z podaną podstawą:

To wewnętrzne pomiary Google, a nie niezależne badania. Traktuj je jako kierunek efektu i zmierz własny sklep przed wdrożeniem i po nim.

#Dlaczego tradycyjne piksele w przeglądarce gubią konwersje

Przez ponad dwie dekady analityka e-commerce opierała się na kodzie uruchamianym w przeglądarce klienta (client-side tracking). Użytkownik finalizował zamówienie, skrypt pobierał parametry z modelu DOM strony podziękowania i wysyłał zapytanie HTTP do serwerów reklamowych. W 2026 roku ten model stał się wysoce zawodny.

#Jak blokady reklam i Safari ITP skracają żywotność plików cookies

Trzy zjawiska techniczne powodują systematyczną utratę danych w śledzeniu po stronie przeglądarki:

Gdy użytkownik płaci za pośrednictwem zewnętrznej bramki płatności i nie powraca na stronę z podziękowaniem za zamówienie, klasyczny tag JavaScript nigdy nie zostaje wykonany. Sklep rejestruje wpłatę w panelu administracyjnym WooCommerce, ale konto Google Ads pozostaje ślepe na tę konwersję.

#Dlaczego Smart Bidding w Google Ads potrzebuje danych first-party

Modele licytacji w Google Ads opierają się na przewidywaniu prawdopodobieństwa zakupu. Im więcej wiarygodnych punktów styku model potrafi połączyć z konkretnym profilem konsumenta, tym precyzyjniej wycenia wartość kliknięcia.

Bez danych first-party model widzi jedynie anonimowe kliknięcie i anonimową sesję. Po przekazaniu zhaszowanego adresu e-mail Google dopasowuje konwersję do zalogowanego konta Google i może przypisać ją do interakcji z reklamą, która ją poprzedziła (Pomoc Google Ads). Więcej przypisanych konwersji to więcej przykładów, na których model licytacji uczy się, które kliknięcia kończą się zamówieniem.

#Jak działają rozszerzone konwersje (Enhanced Conversions) w sklepie WooCommerce

Rozszerzone konwersje to mechanizm uzupełniający standardowy tag transakcji o zhaszowane identyfikatory klienta zgromadzone w formularzu zamówienia. Od kwietnia 2026 roku rozszerzone konwersje dla witryn i dla leadów to jedno ustawienie włącz/wyłącz w Google Ads, a dotychczasowi użytkownicy zostali przeniesieni automatycznie.

#Jakie dane klienta należy haszować algorytmem SHA-256 przed wysyłką

Przewodnik Google po rozszerzonych konwersjach wymaga normalizacji danych osobowych i haszowania ich algorytmem SHA-256 w zapisie szesnastkowym, a każdą wartość należy przekazać jako ciąg znaków:

• Adres e-mail: Usunięcie spacji na początku i końcu ciągu znaków, zamiana wszystkich liter na małe (lowercase), a następnie wygenerowanie skrótu SHA-256. Dla adresu [email protected] ciąg wejściowy to [email protected]. W adresach gmail.com i googlemail.com trzeba dodatkowo usunąć kropki przed znakiem @.
• Numer telefonu: Usunięcie spacji, myślników i nawiasów, sformatowanie do standardu E.164, czyli od 11 do 15 cyfr ze znakiem plus i kodem kraju (np. +48600100200), po czym zastosowanie SHA-256.
• Imię i nazwisko: Małe litery, brak spacji wiodących, usunięcie znaków interpunkcyjnych.
• Kod pocztowy i kraj: Kod pocztowy bez zbędnych znaków, kraj w formacie dwuliterowego kodu ISO 3166-1 alpha-2 (np. PL). Dopasowanie po adresie wymaga łącznie imienia, nazwiska, kodu pocztowego i kraju.

#Gotowy kod PHP dla zdarzenia woocommerce_thankyou i dataLayer

Poniższy fragment kodu należy umieścić w pliku functions.php motywu potomnego lub we własnej wtyczce. Wypełnia on warstwę danych (dataLayer) na stronie potwierdzenia zamówienia skrótami SHA-256 wygenerowanymi bezpośrednio w PHP:

<?php
/**
 * Wdrożenie warstwy danych dla Google Ads Enhanced Conversions w WooCommerce
 */
add_action('woocommerce_thankyou', 'wppoland_inject_enhanced_conversions_datalayer', 20);

function wppoland_inject_enhanced_conversions_datalayer($order_id) {
    if (!$order_id) {
        return;
    }

    $order = wc_get_order($order_id);
    if (!$order || $order->has_status('failed')) {
        return;
    }

    // Normalizacja i haszowanie adresu e-mail
    $raw_email = strtolower(trim($order->get_billing_email()));
    // gmail.com i googlemail.com: usuń kropki przed znakiem @
    if (preg_match('/^([^@]+)@(gmail|googlemail)\.com$/', $raw_email, $m)) {
        $raw_email = str_replace('.', '', $m[1]) . '@' . $m[2] . '.com';
    }
    $hashed_email = hash('sha256', $raw_email);

    // Normalizacja i haszowanie numeru telefonu (format E.164)
    $raw_phone = preg_replace('/[^0-9+]/', '', $order->get_billing_phone());
    if (strpos($raw_phone, '+') !== 0 && strlen($raw_phone) === 9) {
        $raw_phone = '+48' . $raw_phone; // Domyślny prefix dla numerów w Polsce
    }
    $hashed_phone = hash('sha256', $raw_phone);

    // Przygotowanie danych adresowych
    $raw_first_name = strtolower(trim($order->get_billing_first_name()));
    $raw_last_name  = strtolower(trim($order->get_billing_last_name()));
    $hashed_first_name = hash('sha256', $raw_first_name);
    $hashed_last_name  = hash('sha256', $raw_last_name);

    $postal_code = trim($order->get_billing_postcode());
    $country_code = strtoupper(trim($order->get_billing_country()));

    // Pobranie pozycji zamówienia
    $items = [];
    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        if ($product) {
            $items[] = [
                'item_id'   => (string) $product->get_id(),
                'item_name' => $item->get_name(),
                'price'     => (float) $order->get_item_total($item, false, false),
                'quantity'  => (int) $item->get_quantity(),
            ];
        }
    }

    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
        event: 'purchase',
        ecommerce: {
            transaction_id: '<?php echo esc_js($order->get_order_number()); ?>',
            value: <?php echo (float) $order->get_total(); ?>,
            tax: <?php echo (float) $order->get_total_tax(); ?>,
            shipping: <?php echo (float) $order->get_shipping_total(); ?>,
            currency: '<?php echo esc_js($order->get_currency()); ?>',
            items: <?php echo json_encode($items); ?>
        },
        user_data: {
            sha256_email_address: '<?php echo esc_js($hashed_email); ?>',
            sha256_phone_number: '<?php echo esc_js($hashed_phone); ?>',
            address: {
                sha256_first_name: '<?php echo esc_js($hashed_first_name); ?>',
                sha256_last_name: '<?php echo esc_js($hashed_last_name); ?>',
                postal_code: '<?php echo esc_js($postal_code); ?>',
                country: '<?php echo esc_js($country_code); ?>'
            }
        }
    });
    </script>
    <?php
}

Dzięki wygenerowaniu skrótów SHA-256 bezpośrednio na serwerze PHP dane osobowe klienta w postaci jawnej nigdy nie pojawiają się w obiekcie JavaScript przeglądarki, co stanowi istotną zaletę z punktu widzenia bezpieczeństwa i zgodności z normami ochrony danych.

#Jak sprawdzić, czy rozszerzone konwersje działają w WooCommerce

Google podaje trzy sposoby weryfikacji, wszystkie w tym samym artykule pomocy:

1. Zapytanie sieciowe na stronie podziękowania: złóż zamówienie testowe, otwórz Chrome DevTools, przejdź do karty Network i znajdź zapytanie konwersji. Powinno zawierać parametr em: e-mail pojawia się jako tv.1~em ze skrótem, telefon jako tv.1~pn. Prefiks bez skrótu oznacza, że pole było puste w chwili uruchomienia tagu, co w WooCommerce zwykle wskazuje na tag odpalany przed wpisem do dataLayer.
2. Raport diagnostyczny: Google Ads pokazuje diagnostykę rozszerzonych konwersji około 48 godzin po wdrożeniu.
3. Efekt: wpływ na raportowane konwersje widać po około 30 dniach.

Dwa ustawienia blokują zbieranie danych bez żadnego komunikatu. Dane nie są zbierane, dopóki nie zaakceptujesz warunków dotyczących danych klientów w Google Ads lub Google Analytics, a w tagu Google musi być włączona opcja Allow user-provided data capabilities. Gdy dane dostarcza jednocześnie fragment kodu i automatyczne wykrywanie, Google stosuje zawsze dane z fragmentu kodu.

#Jak wdrożyć Server-Side Google Tag Manager na własnej subdomenie

Nawet najlepiej przygotowana warstwa danych w przeglądarce nie pomoże, jeśli zapytanie sieciowe zostanie zablokowane przez wtyczkę filtrującą lub zaporę sieciową. Odpowiedzią na ten problem jest kontener Server-Side Google Tag Manager (sGTM).

#Dlaczego server-side GTM we własnej domenie trudniej zablokować

W tradycyjnej architekturze przeglądarka wysyła dane bezpośrednio do serwerów firm trzecich (np. google-analytics.com lub googleadservices.com). Narzędzia blokujące reklamy posiadają gotowe listy tych domen i przerywają połączenia na poziomie sieciowym przeglądarki.

W architekturze Server-Side GTM punkt zbierania danych działa we własnej domenie sklepu, na przykład na subdomenie:

https://metrics.twoj-sklep.pl

Przewodnik Google po własnej domenie opisuje trzy warianty:

Z perspektywy przeglądarki zapytania w obu pierwszych wariantach trafiają do domeny sklepu (first-party context), więc listy blokujące domeny Google ich nie obejmują. Przy subdomenie jest jedno zastrzeżenie: od Safari 14 WebKit wykrywa maskowanie CNAME podmiotów trzecich i ogranicza ważność ciasteczek ustawionych w takich odpowiedziach do 7 dni (blog WebKit). Subdomena będąca rekordem CNAME do domeny dostawcy hostingu może podpaść pod tę regułę, co jest kolejnym argumentem za wariantem z tym samym originem.

Kontener sGTM następnie:

1. Odbiera jedno zagregowane zapytanie ze strony klienta.
2. Weryfikuje i oczyszcza dane z niepożądanych parametrów.
3. Ustawia ciasteczka w odpowiedzi HTTP we własnej domenie sklepu, zamiast przez JavaScript.
4. Równolegle rozsyła zdarzenia do Google Ads, Meta Conversions API (CAPI), Google Analytics 4 oraz innych partnerów analitycznych.

#Ile kosztuje utrzymanie server-side GTM na Cloud Run

Przewodnik Google po konfiguracji Cloud Run podaje parametry, które warto znać, zanim sklep zdecyduje się na sGTM:

• Każdy serwer tagowania to instancja Cloud Run z 1 vCPU i 0,5 GB pamięci, rozliczana w modelu z procesorem przydzielonym na stałe. Google szacuje koszt jednego serwera na około 45 USD miesięcznie.
• Google zaleca minimum 2 instancje w produkcji, aby ograniczyć ryzyko utraty danych podczas awarii.
• Autoskalowanie między 2 a 10 serwerami powinno obsłużyć od 35 do 350 zapytań na sekundę, zależnie od liczby tagów.
• Wartość max-instances wyznacza najgorszy scenariusz kosztowy, więc ustaw ją świadomie i dodaj alert rozliczeniowy.
• Serwer podglądu, obsługujący tryb podglądu Tag Managera, uruchamia się osobno.
• Przy globalnej grupie odbiorców Google sugeruje wdrożenie w kilku regionach za load balancerem.

Jako alternatywy udokumentowane są App Engine i ręczna konfiguracja na dowolnej platformie. W małym sklepie WooCommerce dwie instancje działające przez cały miesiąc to stały koszt, który trzeba zestawić z liczbą odzyskanych konwersji.

#Jak odciążyć przeglądarkę klienta przenosząc tagi analityczne na serwer

W klasycznym sklepie e-commerce strona produktu ładuje kilkanaście bibliotek JavaScript: piksel Mety, tag Google Ads, skrypt TikToka, Hotjara i systemy rekomendacji. Każdy z tych skryptów zużywa zasoby procesora na urządzeniu mobilnym klienta, degradując wskaźniki Core Web Vitals, w szczególności wskaźnik Interaction to Next Paint (INP).

Przeniesienie tagowania na serwer redukuje liczbę bibliotek klienckich do jednego, zunifikowanego skryptu zbierającego. Przeglądarka wysyła lekki strumień zdarzeń, a mapowanie parametrów i komunikacja z zewnętrznymi interfejsami API odbywają się na serwerze tagowania, a nie w telefonie klienta. Google wymienia poprawę wydajności strony wśród korzyści tagowania po stronie serwera (Google for Developers).

#Czym Google tag gateway różni się od server-side GTM

Google tag gateway for advertisers to lżejsza opcja, którą Google wymienia w pierwszym kroku przewodnika Data Strength. Pozwala wdrożyć tag Google na własnej infrastrukturze, serwowany z domeny witryny (Google for Developers). Gateway działa na CDN, load balancerze lub serwerze WWW, który już masz. Serwuje tag Google i jego zapytania pomiarowe z Twojej domeny, ale nie przetwarza ani nie rozsyła zdarzeń tak jak kontener sGTM.

W przypadku Cloudflare konfiguracja odbywa się w samym tagu Google (Pomoc Google Ads):

1. W ustawieniach tagu Google otwórz Admin i wybierz Google tag gateway.
2. Zaloguj się do Cloudflare. Konto potrzebuje roli Super Administrator, Administrator lub Zaraz Admin.
3. Wybierz domeny witryny do aktywacji i kliknij Complete setup. Domeny powinny następnie mieć status Active.

Gateway korzysta ze ścieżki pomiarowej w Twojej domenie, domyślnie złożonej z czterech losowych znaków, którą można zmienić (na przykład na /metrics). Google zaleca wcześniejszy przegląd ustawień zgód, bo włączenie gateway wpływa na sposób uruchamiania tagu Google.

Oba rozwiązania się uzupełniają. Google tag gateway przenosi tagi Google do Twojej domeny przy minimalnej infrastrukturze. Server-side GTM dodaje warstwę przetwarzania, która zasila też Meta CAPI, GA4 i inne punkty docelowe. Google zaleca wdrożenie obu dla najtrwalszej konfiguracji tagowania.

#Jak połączyć Consent Mode v2 z RODO i bezpiecznym zbieraniem danych

Wdrożenie zbierania danych first-party na terenie Unii Europejskiej wymaga zgodności z dyrektywą ePrivacy oraz ogólnym rozporządzeniem o ochronie danych (RODO). Google Consent Mode v2 stanowi techniczny most pomiędzy decyzją użytkownika w banerze zgody (CMP) a zachowaniem tagów analitycznych. Dokumentacja Google mówi wprost, że za uzyskanie zgody odpowiada właściciel witryny.

Consent Mode v2 operuje czterema typami zgód:

// Domyślna konfiguracja przed uzyskaniem zgody użytkownika
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

• ad_storage: Kontroluje zapisywanie plików cookies do celów reklamowych.
• analytics_storage: Kontroluje pliki cookies statystyczne.
• ad_user_data: Decyduje, czy zhaszowane dane osobowe (first-party data) mogą zostać przesłane do Google w celach atrybucji.
• ad_personalization: Warunkuje wykorzystanie danych do remarketingu i personalizacji reklam.

W trybie basic tagi Google nie ładują się, dopóki użytkownik nie zareaguje na baner zgody, a przy odmowie nic nie jest wysyłane. W trybie zaawansowanym (Advanced Mode) tagi ładują się z domyślną odmową, a gdy użytkownik odrzuca pliki cookies, wysyłają sygnały bez ciasteczek (tzw. cookieless pings). Zawierają one informacje o zdarzeniu, ale są pozbawione trwałych identyfikatorów, i Google modeluje na ich podstawie konwersje, gdy tag przekroczy próg ilości zebranych danych (Google for Developers).

#Jak krok po kroku zbudować data strength w WooCommerce

Budowa Data Strength w sklepie WooCommerce najlepiej sprawdza się jako stała sekwencja kroków. Poniższy diagram przedstawia kompletny przepływ wdrożeniowy:

+-------------------------------------------------------------------+
|            ARCHITEKTURA DATA STRENGTH W WOOCOMMERCE              |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ KROK 1: Audyt warstwy danych i zdarzenia purchase ]
                 (Sprawdź kompletność parametrów w dataLayer)
                                  |
                                  v
        [ KROK 2: Wdrożenie haszowania SHA-256 w kodzie PHP ]
               (E-mail, telefon i adres haszowane po stronie serwera)
                                  |
                                  v
       [ KROK 3: Konfiguracja Consent Mode v2 w systemie CMP ]
               (Zapewnij obsługę ad_user_data i ad_personalization)
                                  |
                                  v
      [ KROK 4: Uruchomienie tag gateway i Server-Side GTM ]
               (Ścieżka w tym samym originie lub subdomena, Cloud Run)
                                  |
                                  v
         [ KROK 5: Mapowanie Enhanced Conversions w sGTM ]
               (Przekaż zhaszowane dane do tagu Google Ads)
                                  |
                                  v
       [ KROK 6: Wysyłka zamówień bez strony podziękowania ]
               (Z serwera przez Google Ads API lub Data Manager API)

1. Weryfikacja warstwy danych: Upewnij się, że zdarzenie purchase generuje poprawny, unikalny numer zamówienia oraz wartość koszyka netto i brutto.
2. Bezpieczne haszowanie w PHP: Wdróż normalizację ciągów tekstowych i generowanie skrótów SHA-256 bezpośrednio w silniku WordPressa, zapobiegając wyciekowi jawnych danych osobowych do przeglądarki.
3. Integracja platformy CMP: Podłącz certyfikowany baner zgody (np. Cookiebot, Complianz lub OneTrust) obsługujący Consent Mode v2 z automatyczną aktualizacją stanów zgód.
4. Instalacja tag gateway i Server-Side GTM: Serwuj tag Google z własnej domeny i kieruj zdarzenia przez serwer tagowania na ścieżce w tym samym originie albo na subdomenie.
5. Konfiguracja tagu konwersji: W kontenerze serwerowym sGTM skonfiguruj tag Google Ads Conversion Tracking, włączając opcję Include user-provided data i mapując odpowiednie zmienne z warstwy danych.
6. Wysyłka brakujących zamówień z serwera: Dla zamówień opłacanych bramkami asynchronicznymi (gdzie klient nie wraca do sklepu) użyj haka woocommerce_order_status_completed, który wysyła konwersję z identyfikatorem transakcji i zapisanym GCLID do Google Ads przez Google Ads API lub Data Manager API.

#Podsumowanie wdrożeniowe dla sklepów e-commerce i specjalistów PPC

Podniesienie Data Strength w Google Ads to projekt inżynierii danych, którego wynik da się sprawdzić na koncie.

Wdrożenie czystych rozszerzonych konwersji, zabezpieczenie danych osobowych haszowaniem SHA-256 oraz przeniesienie strumienia zdarzeń do Google tag gateway i Server-Side GTM daje sklepowi:

• Konwersje, które gubi tag działający tylko w przeglądarce (zablokowane zapytania, zamknięte strony podziękowania), docierają do Google Ads, a metryka Data Strength Uplift pokazuje, ile ich jest.
• Co najmniej 3 identyfikatory przy każdym zamówieniu (ID transakcji, zhaszowany e-mail, IP, GCLID tam, gdzie został zapisany), czyli to, czego wymaga przewodnik Google.
• Mniej skryptów firm trzecich w przeglądarce klienta, co pomaga mobilnym wskaźnikom Core Web Vitals.
• Konfigurację zgód zgodną z Consent Mode v2 i europejskim prawem ochrony prywatności.

Jeśli chcesz zweryfikować zgodność sklepu z dyrektywami prawnymi i technicznymi, sprawdź nasz dedykowany audyt gotowości WooCommerce na regulacje UE.

Odporna, zgodna z prywatnością architektura pomiarowa utrzymuje działający pomiar reklam także po kolejnych zmianach w polityce przeglądarek.