Server side tracking: vad flyttas till servern?
Server side tracking innebär att mätdata behandlas på en server innan de skickas vidare till analys- och annonsverktyg. Det ger möjlighet att kontrollera vilka uppgifter varje mottagare får. Installationen behöver också hosting, övervakning och någon som ansvarar för driften.
Webbläsaren samlar vanligtvis fortfarande in händelser, men skickar dem först till er mätserver. Där väljer ni vilka uppgifter som ska kontrolleras, ändras eller skickas vidare.
Så förändras vägen till mottagaren
Vid traditionell webbmätning skickar webbläsarens taggar data direkt till flera mottagare. Med en servercontainer kan delar av trafiken gå till en server som ni kontrollerar. Där tolkar så kallade klienter inkommande anrop och gör dem till händelser som serverns taggar kan behandla.
| Del | Fråga att besluta om |
|---|---|
| Webbplats | Vilka händelser och värden ska lämna webbläsaren? |
| Servercontainer | Vad ska kontrolleras, tas bort eller omformas? |
| Mottagare | Vilken leverantör behöver vilken information? |
| Drift | Vem ansvarar för kapacitet, fel och förändringar? |
Bestäm vilka uppgifter servern ska kontrollera och vilka den ska skicka vidare. Om allt bara vidarebefordras är nyttan begränsad.
Ett exempel med köp
En butik skickar en köphändelse med order-ID, valuta och värde till mätservern. Servern kan kontrollera att nödvändiga fält finns och sedan skicka avsedda uppgifter till olika mottagare. Ett internt fält som bara behövs i ordersystemet kan tas bort innan vidarebefordran.
Men var uppstår köphändelsen? Om den bygger på att kunden öppnar en tacksida kan händelsen fortfarande utebli när kunden stänger fliken. Om samma order dessutom skickas från butikens backend behövs en plan för att undvika dubbla köp. Bestäm därför var köpet ska registreras och hur dubbla anrop hanteras.
Utgå från en datalayer med tydligt definierade uppgifter och kontrollera hela flödet mot testordern. Se även till att återbetalningar och ändrade ordervärden hanteras på ett sätt som passar rapportens syfte.
Arbetsgång: skicka GA4 via en servercontainer
Det här upplägget utgår från en befintlig webbmätning med Google-tagg. Arbetsgången gäller GA4. Övriga annonsintegrationer behöver konfigureras separat. Du behöver åtkomst till webbens GTM-behållare, en serverbehållare, hosting, domäninställningar och mottagande GA4-egendom. Utse också vem som äger driften.
Skapa servermiljön innan trafiken flyttas
Skapa en GTM-behållare av typen Server och följ Googles aktuella guide för vald driftmiljö. I Cloud Run-upplägget ingår en förhandsgranskningsserver och en server för mättrafiken. Cloud-projekt, fakturering och behörigheter måste vara klara. Anpassa kapaciteten efter webbplatsens trafik och följ upp kostnader och fel.
Bestäm en egen insamlingsadress, till exempel https://analytics.example.com, och konfigurera den mot mätservern enligt driftsguiden. Adressen här är fiktiv. Kontrollera DNS, HTTPS och tillgänglighet innan någon ändrar webbmätningens destination.
Styr webbtaggens anrop till rätt adress
I webbbehållarens befintliga Google-tagg öppnar du konfigurationsinställningarna och lägger till server_container_url med serverns faktiska HTTPS-adress som värde. Det är en konfigurationsparameter, inte ett fält som ska kopieras in bland varje händelses affärsuppgifter. Har ni flera Google-taggar behöver det vara tydligt vilka flöden som ska flyttas.
Behåll det korrekta GA4-ID:t. Serveradressen ersätter inte egendomens mät-ID. Starta förhandsgranskningen i både webb- och serverbehållaren och kontrollera ett vanligt sidbesök innan du testar ett mer komplicerat köp. Om anrop blockeras granskar utvecklaren även webbplatsens säkerhetspolicy och serveradressens tillgänglighet.
Ta emot anrop och skicka dem vidare
I serverbehållaren granskar du klienten för GA4. Klienten ska känna igen inkommande anrop och göra dem till händelser. Kontrollera både att anropet tas emot och att rätt tagg skickar händelsen vidare. Skapa eller granska en serverbaserad tagg av typen Google Analytics: GA4. För det här GA4-flödet skapar du en anpassad utlösare, väljer vissa händelser och sätter villkoret Client Name lika med den mottagande klientens faktiska namn, exempelvis GA4. Klientnamn och klienttyp är inte samma sak. Koppla utlösaren till taggen och kontrollera vilken GA4-destination händelserna får. Avgränsa ytterligare om bara vissa händelser ska skickas.
Bestäm vilka fält som ska behållas och kontrollera resultatet i förhandsgranskningen. Om ni vill begränsa datadelningen behöver ni också välja bort fält som mottagaren inte behöver. Dokumentera varje annan mottagare separat, inklusive samtyckesbeteende och eventuell deduplicering.
Verifiera från källa till mottagare
Gör en testorder med känt ID, valuta och värde. Följ först webbanropet till er serveradress, sedan serverklientens händelse och till sist den utgående taggen. Verifiera mottagningen i GA4 och stäm av mot ordern. Kontrollera också att samma order inte samtidigt skickas en andra väg direkt till GA4 eller från backend utan avsedd deduplicering.
| Felbild | Kontrollpunkt |
|---|---|
| Inget anrop når servern | Webbtaggens adress, publicerad version, DNS/HTTPS och blockering i webbläsaren. |
| Anropet kommer in men ingen händelse skapas | Vilken klient som tar hand om anropet och vilket format källan skickar. |
| Händelsen finns men ingen tagg körs | Serverns utlösare och regler för data/samtycke. |
| Utgående tagg körs men rätt resultat saknas | Mottagarens ID, svar och händelsens parametrar. |
| Två köp för en order | Parallella insamlingsvägar och transaktions-ID. |
Testa även avbrutna köp, omladdning och nekat samtycke. Publicera därefter kontrollerade versioner av berörda behållare och följ samma testfall i produktion. Skriv ner hur ändringen återställs, vem som ansvarar för driften och vilka kostnader och fel som ska följas upp. Om underlaget förändras behöver rapporteringen ange när serverflödet togs i bruk.
Vad kan motivera investeringen?
- Ni behöver styra vilka fält varje mottagare får.
- Flera integrationer behöver en gemensam struktur.
- Ni vill minska delar av tredjepartskoden i webbläsaren.
- Ni har resurser att förvalta mätningen och driften.
Väg nyttan mot kostnaden för installation, hosting och löpande felsökning. För en liten webbplats med ett enda kontaktformulär kan enklare åtgärder ge större nytta först. Ett felaktigt formulärmål blir inte mer relevant för affären bara för att det går genom en server.
Samtycke och ansvar följer med
Serverbaserad mätning upphäver inte besökarens val och är ingen generell metod för att komma runt integritetsskydd. Samtyckessignaler och regler för uppgifternas användning måste följa dataflödet. Kontrollera därför Consent Mode och övriga leverantörers hantering separat.
Gör en enkel driftbeskrivning före lansering: serveradress, ansvarig, kostnadsuppföljning, övervakning och hur ni återställer vid fel. Behåll testfall för köp, förfrågan, nekat samtycke och dubbla anrop. De behövs igen när webbplatsen, taggarna eller mottagarnas krav förändras.
Bestäm också hur bortfall ska upptäckas. Om en mottagare slutar få data behöver någon kunna se om felet ligger på webbplatsen, i mätservern eller hos mottagaren. Sätt en rutin för uppföljning av volym och fel innan installationen betraktas som färdig.
Källor och dokumentation
”*” anger obligatoriska fält
