Google Ads data strength og WooCommerce: førstepartsdata og server-side GTM

Høsten 2026 satte Google førstepartsdata i sentrum for målingen i Google Ads. 10. september kunngjorde selskapet målingen Data Strength Uplift og en utvidet Data Manager (Google Ads and Commerce-bloggen), og hjelpesiden Data Strength Best Practices leses nå som en trinnvis implementeringsveiledning. Retningen er tydelig: En JavaScript-piksel limt inn i toppen av nettstedet er ikke lenger nok. Med skjerpede personvernkrav, nettleserbarrierer som Safari ITP og utstrakt bruk av annonseblokkering avhenger lønnsomheten i e-handel nå direkte av kvaliteten på egne førstepartsdata og målesystemer på tjenersiden som ikke stoppes av nettleseren.

For eiere av WooCommerce-nettbutikker og WordPress-arkitekter krever dette at man forlater enkle utvidelser til fordel for grundig datastrukturering. En butikk som sender ufullstendige ordredata til Google Ads, betaler for det: Googles algoritmer for automatisert budgivning (Smart Bidding) mister oversikten, og kostnaden per ordre stiger.

I denne veiledningen forklarer vi hva Data Strength omfatter, hvilke signaler Google ber om, hvilke tekniske krav som stilles til utvidede konverteringer (Enhanced Conversions), og hvordan du setter opp Google tag gateway og Server-Side Google Tag Manager (sGTM) på butikkens eget domene.

#Hva betyr Google Ads data strength og hvorfor avgjør verdien annonsekostnadene

Data Strength er Googles samlebetegnelse på måleoppsettet basert på førstepartsdata som forsyner Google Ads. Hjelpesiden deler det i fire trinn: koble til datakildene, maksimere signalene, aktivere Google AI (Smart Bidding, AI Max for Search, Demand Gen, Performance Max) og dokumentere avkastningen med inkrementalitetseksperimenter og markedsmiksmodellen Meridian. Dataene er en direkte inngangsverdi for maskinlæringsmodellene som byr i Performance Max, Demand Gen og søkekampanjer, så hull i dataene blir hull i budgivningen.

To steder i Google Ads setter tall på dette. Den nye målingen Data Strength Uplift beregner ifølge Googles kunngjøring de ekstra konverteringene som oppsettet for førstepartsdata henter tilbake. Kvalitetsnivåene kommer fra diagnostikken: diagnostikk for offlinedata merker importerte data som Excellent (minst 90% av hendelsene korrekt formatert), Good (omtrent 70 til 90%), Needs attention (under 70%) eller No recent data (ingen hendelser de siste 28 dagene). Utvidede konverteringer har en egen diagnoserapport.

I en WooCommerce-butikk handler oppsettet Google beskriver om fire tekniske betingelser:

1. Fullstendige transaksjonsdata: Hver enkelt kjøpshendelse må inneholde nøyaktig ordreverdi, valutakode etter ISO 4217 og en unik transaksjons-ID (Transaction ID) for å unngå duplikater.
2. Høy andel hashede førstepartsdata: Levering av normaliserte og hashede e-postadresser, telefonnumre og adresser, slik at Google kan knytte kjøpet til påloggede Google-kontoer.
3. Korrekt integrasjon av Consent Mode v2: Overføring av parametrene ad_user_data og ad_personalization i samsvar med kundens valg i samtykkebanneret. Googles hjelpeside lister ikke samtykke som et Data Strength-trinn, men i EØS kan ingen identifikator sendes uten det.
4. Stabil dataflyt: Fjerning av tekniske avbrudd forårsaket av skriptblokkeringer, eksterne betalingsvinduer eller nettverksfeil.

Når data mangler, må Smart Bidding arbeide med usikkerhet. Systemet ser færre konverteringer enn butikken faktisk registrerer, verdsetter dermed klikk på et svakere grunnlag, og avkastningen på annonsekronene (ROAS) og kostnaden per konvertering går i feil retning.

#Hvilke signaler Googles veiledning for data strength ber om

Trinnet “maksimer signalene” på siden Data Strength Best Practices lister identifikatorene Google vil ha med hver konvertering:

• Kundedata: hashet e-post eller telefon, som utvidede konverteringer sammenligner med Googles data om påloggede brukere for å hente tilbake konverteringer taggen ikke så.
• IP-adresse: sendes med importer via Data Manager. Google oppgir opptil 3% flere observerte konverteringer i søk og over 10% på YouTube i en offlinesimulering.
• Transaksjons-ID: ordre- eller leadnummeret som kobler et klikk i frontend til salget i backend.
• GCLID: klikkidentifikatoren som forteller Google hvilken kampanje som ga salget.
• Øktattributter: kampanje-ID, full URL til landingssiden, tidsstempel for økten, nettleser og operativsystem.
• GBRAID og WBRAID: URL-parametere som gjenoppretter tilskriving for iOS-konverteringer og privat surfing.

Det gir to regler. Google anbefaler minst 3 identifikatorer per hendelse, med GCLID og IP prioritert sammen med hashede kundedata, og å sende alle konverteringshendelser i stedet for et utvalg.

I WooCommerce ligger de fleste av disse verdiene allerede på ordren. $order->get_order_number() er transaksjons-ID-en, $order->get_customer_ip_address() gir IP-adressen som ble lagret i kassen, og fakturafeltene inneholder kundedataene. GCLID, GBRAID og WBRAID finnes bare som parametere i URL-en til landingssiden. En butikk som vil laste opp konverteringer fra tjeneren, må derfor fange dem opp ved første sidevisning og lagre dem sammen med ordren.

Google underbygger siden med egne tall, hver med oppgitt grunnlag:

Dette er Googles interne målinger, ikke uavhengige studier. Bruk dem som retningen på effekten, og mål din egen butikk før og etter.

#Hvorfor tradisjonelle nettleserpiksler mister konverteringer

I over tjue år har nettbutikker målt salg ved hjelp av kode som kjøres i kundens nettleser (client-side tracking). Når et kjøp ble fullført, leste et JavaScript-skript av verdiene på kvitteringssiden og sendte en forespørsel til annonsørens servere. I 2026 er denne metoden blitt svært upålitelig.

#Hvordan annonseblokkering og Safari ITP korter ned levetiden til informasjonskapsler

Det er særlig tre tekniske hindringer som fører til tap av data ved tradisjonell sporing i nettleseren:

Når en kunde betaler med en mobil betalingsløsning og ikke venter på omdirigeringen tilbake til butikken, blir JavaScript-koden aldri kjørt. Ordren registreres i WooCommerce-databasen, men Google Ads mottar aldri noe signal om salget.

#Hvorfor Smart Bidding i Google Ads er avhengig av førstepartsdata

Algoritmene for automatisert budgivning beregner sannsynligheten for at en bruker vil handle før det legges inn et bud i auksjonen. Jo flere etterprøvbare punkter modellen kan knytte til en reell brukerprofil, desto mer nøyaktig fastsettes verdien av et klikk.

Uten førstepartsdata ser modellen kun en anonym nettleserøkt. Med en hashet e-postadresse matcher Google konverteringen mot en pålogget Google-konto og kan tilskrive den annonseinteraksjonen som kom før (Google Ads-hjelp). Flere tilskrevne konverteringer gir budmodellen flere eksempler på hvilke klikk som ender i ordre.

#Hvordan utvidede konverteringer (Enhanced Conversions) fungerer i WooCommerce

Utvidede konverteringer supplerer vanlige målekoder med hashet kundeinformasjon som samles inn under utsjekkingen. Siden april 2026 er utvidede konverteringer for nettsteder og for leads én felles av/på-innstilling i Google Ads, og eksisterende brukere ble flyttet automatisk.

#Hvilke kundedata må hashes med SHA-256 før overføring

Googles veiledning for utvidede konverteringer krever at personopplysninger normaliseres og hashes med heksadesimal SHA-256, og at hver verdi sendes som tekststreng:

• E-postadresse: Fjerning av alle mellomrom foran og bak, endring til små bokstaver og deretter hashing med SHA-256. For [email protected] blir den normaliserte inngangsverdien [email protected]. For adresser på gmail.com og googlemail.com fjernes i tillegg punktum foran @.
• Telefonnummer: Fjerning av mellomrom, bindestreker og parenteser, formatering etter E.164-standarden med 11 til 15 sifre inkludert plusstegn og landskode (for eksempel +4790010020), fulgt av SHA-256.
• Navn: Små bokstaver uten tegnsetting eller ekstra mellomrom.
• Postnummer og land: Postnummer uten overflødige tegn og landskode i tobokstavs ISO 3166-1 alpha-2-format (som NO eller SE). Adressematching krever fornavn, etternavn, postnummer og land samlet.

#Komplett PHP-kode for woocommerce_thankyou og dataLayer

Koden nedenfor kobles til hendelsen woocommerce_thankyou i barnetemaets functions.php eller i en egen utvidelse. Den fyller et dataLayer-objekt på kvitteringssiden med SHA-256-hasher generert direkte i PHP:

<?php
/**
 * dataLayer-oppsett for Google Ads Enhanced Conversions i 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;
    }

    // Normalisering og hashing av e-postadresse
    $raw_email = strtolower(trim($order->get_billing_email()));
    // gmail.com og googlemail.com: fjern punktum foran @
    if (preg_match('/^([^@]+)@(gmail|googlemail)\.com$/', $raw_email, $m)) {
        $raw_email = str_replace('.', '', $m[1]) . '@' . $m[2] . '.com';
    }
    $hashed_email = hash('sha256', $raw_email);

    // Normalisering og hashing av telefonnummer (E.164)
    $raw_phone = preg_replace('/[^0-9+]/', '', $order->get_billing_phone());
    if (strpos($raw_phone, '+') !== 0 && strlen($raw_phone) === 8) {
        $raw_phone = '+47' . $raw_phone; // Standard landskode for Norge
    }
    $hashed_phone = hash('sha256', $raw_phone);

    // Behandling av navn og adresse
    $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()));

    // Henting av varelinjer
    $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
}

Ved å beregne SHA-256-verdiene direkte på tjeneren i PHP sendes personopplysninger aldri i klartekst til nettleserens JavaScript-miljø. Dette styrker datasikkerheten betraktelig.

#Hvordan sjekke at utvidede konverteringer virker i WooCommerce

Google oppgir tre kontroller, alle i den samme hjelpeartikkelen:

1. Nettverksforespørselen på kvitteringssiden: Legg inn en testordre, åpne Chrome DevTools, gå til fanen Network og finn konverteringsforespørselen. Den skal ha en parameter em: E-post vises som tv.1~em fulgt av en hash, telefon som tv.1~pn. Et prefiks uten hash betyr at feltet var tomt da taggen ble utløst. I WooCommerce peker det som regel på at taggen kjører før dataLayer-pushen.
2. Diagnoserapporten: Google Ads viser diagnostikken for utvidede konverteringer omtrent 48 timer etter implementeringen.
3. Effekten: Virkningen på rapporterte konverteringer blir synlig etter omtrent 30 dager.

To innstillinger stopper innsamlingen uten varsel. Data samles ikke inn før vilkårene for kundedata er godtatt i Google Ads eller Google Analytics, og i Google-taggen må valget Allow user-provided data capabilities være slått på. Når både kodesnutten og automatisk gjenkjenning leverer data, prioriterer Google ifølge veiledningen alltid kodesnutten.

#Hvordan sette opp Server-Side Google Tag Manager på eget underdomene

Selv en feilfri dataLayer-struktur i nettleseren kommer til kort hvis nettverkskallene stoppes av innholdsfiltre. Her kommer en Server-Side Google Tag Manager-container (sGTM) inn.

#Hvorfor server-side GTM på eget domene er vanskeligere å blokkere

Ved tradisjonell sporing sender nettleseren trafikk direkte til tredjepartsdomener som googleadservices.com. Annonseblokkere overvåker disse domenene og blokkerer forespørslene i nettleseren.

Med Server-Side GTM kjører målepunktet på butikkens eget domene, for eksempel på et underdomene:

https://maling.din-butikk.no

Googles veiledning for eget domene beskriver tre alternativer:

For nettleseren hører forespørsler i de to første alternativene til butikkens domene (førstepartskontekst), så blokkeringslister rettet mot Googles domener fanger dem ikke. Underdomenet har ett forbehold: Siden Safari 14 oppdager WebKit CNAME-tildekking fra tredjeparter og begrenser informasjonskapsler satt i slike svar til 7 dager (WebKit-bloggen). Et underdomene som er en CNAME til en vertsleverandørs domene, kan falle inn under regelen, og det er enda en grunn til å velge samme opphav.

sGTM-tjeneren ivaretar deretter følgende oppgaver:

1. Tar imot én samlet datapakke fra kundens nettleser.
2. Vasker bort unødvendige hoder og uønskede parametere.
3. Setter informasjonskapsler i HTTP-svaret på butikkens eget domene i stedet for via JavaScript.
4. Distribuerer hendelsene parallelt til Google Ads, Meta Conversions API (CAPI) og Google Analytics 4.

#Hva det koster å drive server-side GTM på Cloud Run

Googles veiledning for Cloud Run gir dimensjoneringstall som er verdt å kjenne før en butikk velger sGTM:

• Hver taggingtjener er en Cloud Run-instans med 1 vCPU og 0,5 GB minne, fakturert etter modellen der CPU alltid er tildelt. Google anslår omtrent 45 USD per tjener i måneden.
• Google anbefaler minst 2 instanser i produksjon for å redusere risikoen for datatap ved driftsstans.
• Autoskalering mellom 2 og 10 tjenere forventes å håndtere 35 til 350 forespørsler i sekundet, avhengig av antall tagger.
• Verdien max-instances er det verste tilfellet for hva du betaler, så sett den bevisst og legg til et budsjettvarsel.
• Forhåndsvisningstjeneren, som driver forhåndsvisningsmodusen i Tag Manager, settes opp separat.
• For et globalt publikum foreslår Google utrulling i flere regioner bak en lastbalanserer.

App Engine og manuelt oppsett på valgfri plattform er dokumentert som alternativer. For en liten WooCommerce-butikk er to instanser som går hele måneden en fast månedlig kostnad som må veies mot konverteringene de henter tilbake.

#Hvordan flytting av analysekoder til tjeneren gir raskere nettbutikk

I mange nettbutikker forsinker en rekke eksterne skript sidevisningen: Google Ads, Meta Pixel, TikTok-koder og analyseverktøy belaster prosessoren på mobile enheter og forringer Core Web Vitals, spesielt Interaction to Next Paint (INP).

Ved å flytte sporingen til tjeneren reduseres skriptmengden i nettleseren til én enkelt innsamlingskode. Nettleseren sender en lett datastrøm, mens mapping av parametere og API-kall kjøres på taggingtjeneren i stedet for på den besøkendes telefon. Google nevner bedre sideytelse blant fordelene med tagging på tjenersiden (Google for Developers).

#Hvordan Google tag gateway skiller seg fra server-side GTM

Google tag gateway for advertisers er det lettere alternativet, og Google nevner det i første trinn av Data Strength-veiledningen. Det lar deg levere en Google-tagg fra din egen infrastruktur, servert fra nettstedets domene (Google for Developers). Gatewayen kjører på et CDN, en lastbalanserer eller en webtjener du allerede har. Den serverer Google-taggen og måleforespørslene fra domenet ditt, men behandler eller videresender ikke hendelser slik en sGTM-container gjør.

Med Cloudflare gjøres oppsettet i selve Google-taggen (Google Ads-hjelp):

1. Åpne Admin i innstillingene for Google-taggen og velg Google tag gateway.
2. Logg inn i Cloudflare. Kontoen trenger rollen Super Administrator, Administrator eller Zaraz Admin.
3. Velg domenene som skal aktiveres, og klikk Complete setup. Domenene skal deretter vise statusen Active.

Gatewayen bruker en målesti på domenet ditt, som standard fire tilfeldige tegn, og den kan endres (for eksempel til /metrics). Google ber deg gå gjennom samtykkeinnstillingene først, fordi aktiveringen påvirker hvordan Google-taggen utløses.

De to løsningene utfyller hverandre. Google tag gateway flytter Googles egne tagger til domenet ditt med lite infrastruktur. Server-side GTM legger til et behandlingslag som også kan forsyne Meta CAPI, GA4 og andre mottakere. Google anbefaler å gjennomføre begge slik at taggingen fortsetter selv om én vei faller bort.

#Hvordan tilpasse Consent Mode v2 til personvernreglene i GDPR

Innsamling av førstepartsdata i EØS-området krever streng overholdelse av GDPR og ePrivacy-direktivet. Google Consent Mode v2 fungerer som bindeleddet mellom kundens valg i samtykkebanneret og oppførselen til målekodene. Googles dokumentasjon sier tydelig at nettstedseieren selv er ansvarlig for å innhente samtykke.

Consent Mode v2 arbeider med fire samtykketyper:

// Standardinnstilling før brukeren har svart på banneret
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

• ad_storage: Styrer lagring av informasjonskapsler for annonseformål.
• analytics_storage: Regulerer statistikk og analysekapsler.
• ad_user_data: Bestemmer om hashede kundedata kan overføres til Google for tilskriving.
• ad_personalization: Avgjør om dataene kan benyttes til remarketing og tilpassede annonser.

I Basic Mode lastes Google-taggene ikke før brukeren har svart på banneret, og ved avslag sendes ingenting. I avansert modus (Advanced Consent Mode) lastes taggene med avslag som standard, og når kunden avslår sporing, sender de signaler uten informasjonskapsler (cookieless pings) til Google. Disse signalene inneholder hendelsesdata uten varige identifikatorer, og Google modellerer konverteringer ut fra dem når taggen når en terskel for innsamlede data (Google for Developers).

#Hvordan bygge data strength i WooCommerce steg for steg

Å bygge Data Strength i en WooCommerce-butikk fungerer best som en fast rekkefølge. Diagrammet nedenfor oppsummerer trinnene:

+-------------------------------------------------------------------+
|              ARBEIDSFLYT FOR DATA STRENGTH                        |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ TRINN 1: Gjennomgå purchase-hendelsen i dataLayer ]
                 (Kontroller transaksjons-ID, verdi og varer)
                                  |
                                  v
        [ TRINN 2: SHA-256-hashing i PHP ved utsjekking ]
               (Hash e-post, telefon og navn på tjeneren)
                                  |
                                  v
       [ TRINN 3: Consent Mode v2 i godkjent samtykkebanner ]
               (ad_user_data oppdateres dynamisk)
                                  |
                                  v
      [ TRINN 4: Tag gateway og Server-Side GTM ]
               (Sti på samme opphav eller underdomene, Cloud Run)
                                  |
                                  v
         [ TRINN 5: Utvidede konverteringer i sGTM ]
               (Send user_data til Google Ads-taggen)
                                  |
                                  v
       [ TRINN 6: Last opp ordre uten kvitteringsside ]
               (Fra tjeneren via Google Ads API eller Data Manager API)

1. Gjennomgå kjøpshendelsen: Påse at purchase-hendelsen konsekvent leverer unike ordrenumre, korrekte beløp og valutakoder.
2. Kjør hashing på tjeneren: Vask tekstfeltene og generer SHA-256-hasher i PHP før dataene eksponeres i nettleseren.
3. Integrer godkjent samtykkebanner: Knytt til et samtykkebanner som støtter Consent Mode v2 og oppdaterer samtykkestatus dynamisk.
4. Rull ut tag gateway og Server-Side GTM: Server Google-taggen fra ditt eget domene og send hendelsene gjennom en taggingtjener på en sti med samme opphav eller et underdomene.
5. Konfigurer konverteringstagger: Aktiver utvidede konverteringer i Google Ads-taggen i sGTM og koble til de hashede kundedataene.
6. Last opp manglende ordre fra tjeneren: For betalinger der kunden ikke vender tilbake til kvitteringssiden, bruk kroken woocommerce_order_status_completed til å sende konverteringen med transaksjons-ID og lagret GCLID til Google Ads via Google Ads API eller Data Manager API.

#Oppsummering og anbefalinger for nettbutikker og PPC-spesialister

Å løfte Data Strength i Google Ads er et teknisk dataprosjekt, og resultatet kan kontrolleres i kontoen.

Ved å ta i bruk utvidede konverteringer, sikre dataene med SHA-256-hashing og sende hendelsene gjennom Google tag gateway og Server-Side GTM får butikken:

• Konverteringer som en ren nettlesertagg mister (blokkerte forespørsler, lukkede kvitteringssider), når Google Ads, og målingen Data Strength Uplift viser hvor mange det er.
• Minst 3 identifikatorer per ordre (transaksjons-ID, hashet e-post, IP, GCLID der den er lagret), slik Googles veiledning ber om.
• Færre tredjepartsskript i kundens nettleser, noe som hjelper Core Web Vitals på mobil.
• Et samtykkeoppsett som følger Consent Mode v2 og europeisk personvernlovgivning.

For å sikre at nettbutikken din oppfyller gjeldende regelverk, se vår dedikerte WooCommerce EU-beredskapsvurdering.

En serverbasert og personvernvennlig målearkitektur holder annonsemålingen i gang også når nettleserprodusentene innfører nye innstramminger.