Server-side tracking: är det värt det för svenska företag?

Server-side tracking marknadsförs oftast som ett sätt att kringgå ad-blockers och Safaris Intelligent Tracking Prevention. Det är sant, men det är inte längre huvudskälet svenska bolag bör bry sig. Efter IMY:s tillsynsärenden mot Tele2 och CDON sommaren 2023 blev server-side tracking en central del av hur svenska företag faktiskt kan efterleva GDPR när de använder Google Analytics.

Den här artikeln är en ärlig genomgång: vad server-side tracking faktiskt löser, vad det inte löser, och ett verkligt exempel på när investeringen betalade sig.

Client-side vs. server-side: vad är skillnaden?

I en klassisk (client-side) uppsättning kör Google Tag Manager direkt i besökarens webbläsare. Varje tagg — Google Analytics, Google Ads, Meta Pixel — skickar data direkt från besökarens dator till respektive plattform. Webbläsaren ser och kan blockera varje enskild anrop, vilket är exakt vad ad-blockers och webbläsares spårningsskydd gör.

I en server-side uppsättning skickar webbplatsen istället data till en server som du kontrollerar, som i sin tur vidarebefordrar den till Google, Meta och andra plattformar. Besökarens webbläsare pratar bara med din egen server — vilket både är svårare att blockera och ger dig en kontrollpunkt för vad som faktiskt skickas vidare, och vart.

Varför det blev en GDPR-fråga, inte bara en prestandafråga

Den kontrollpunkten är precis det som gjorde skillnad i IMY:s tillsynsärenden. Vi går igenom hela regelverket och de fyra inblandade bolagen i vår guide till Consent Mode v2 för svenska företag — men kortversionen: Tele2 och CDON bötfälldes för att persondata via Google Analytics skickades okontrollerat till USA. Dagens Industri och Coop undgick böter genom att implementera server-side Google Tag Manager hos en EU-baserad värd, med IP-anonymisering och hashning av cookie-ID:n innan data lämnade servern.

Poängen är inte att server-side tracking automatiskt gör dig GDPR-compliant. Poängen är att det ger dig en plats att faktiskt göra någonting åt tredjelandsöverföringen — anonymisera, filtrera, hasha — innan data lämnar EU. Utan den kontrollpunkten skickas allt rakt igenom, okontrollerat, direkt från besökarens webbläsare.

Ett verkligt exempel: Aleris

Aleris, verksam inom hälso- och sjukvård, behövde en GDPR-kompatibel mätuppsättning som fungerade lika över flera affärsområden och produkter — en bransch där kraven på hur persondata hanteras är extra höga. Vi implementerade GA4 med server-side tracking, realtidsspårning av användarresor och en automatiserad rapporteringsstruktur.

Resultatet: realtidsövervakning implementerad, alla affärsområden täckta av samma mätramverk, och automatiserad rapportering som ersatte manuellt hopplock av data från flera system. Server-side tracking var en förutsättning för att kunna hantera persondata korrekt givet branschens känslighet — inte en optimering på marginalen. Läs hela caset: Aleris.

När är det värt investeringen — och när inte?

Server-side tracking kräver egen serverinfrastruktur (eller en hanterad tjänst), löpande underhåll av taggkonfigurationen och oftast utvecklarstöd för att sätta upp korrekt. Det är inte gratis, och det är inte alltid rätt första steg.

Det är sannolikt värt det om: ni hanterar känsliga persondata (hälsa, finans, HR), ni har betydande annonsspend där dataförlust från ad-blockers redan syns i era konverteringssiffror, eller ni redan har fått en anmärkning eller förfrågan från IMY eller en enskild registrerad.

Det är sannolikt inte första prioritet om: er nuvarande Consent Mode-implementation inte ens är på plats — då är det där ni ska börja, inte i serverinfrastruktur — eller om er datavolym är för liten för att komplexiteten ska motiveras. Ett tomt eller felkonfigurerat Consent Mode-setup som körs server-side är fortfarande ett felkonfigurerat setup, bara dyrare att underhålla.

Grundläggande krav för att komma igång

• En server-side GTM-container, antingen självhostad på Google Cloud, AWS eller en EU-baserad leverantör, eller via en hanterad tjänst.
• En egen subdomän (t.ex. data.dittdomän.se) som pekar mot server-containern, så att förstapartscookies kan sättas korrekt.
• En genomgång av vilka taggar som faktiskt behöver flyttas server-side — inte allt behöver det, och att flytta i onödan ökar bara underhållsbördan.
• Fortsatt korrekt Consent Mode-implementation. Server-side tracking ersätter inte samtyckeshantering; det är ett komplement, inte en genväg.

Vanliga frågor

Ersätter server-side tracking behovet av Consent Mode?

Nej. De löser olika problem. Consent Mode styr om data får samlas in baserat på besökarens samtycke. Server-side tracking styr hur och var den insamlade datan bearbetas innan den når tredje part. Du behöver båda för en komplett, GDPR-anpassad mätuppsättning.

Är server-side tracking bara för stora företag?

Nej, men komplexiteten och kostnaden gör att det oftast blir mest relevant för företag med antingen betydande annonsspend, känsliga datakategorier (som vård eller finans), eller båda. Mindre bolag med enklare datahantering bör oftast prioritera en korrekt Consent Mode-implementation först.

Hur lång tid tar en server-side tracking-implementation?

Det beror på hur många taggar som ska flyttas och hur komplex er nuvarande GTM-uppsättning är. En grundläggande implementation med GA4 och en handfull annonsplattformar tar normalt några veckor, inklusive testning och verifiering av datakvalitet innan full drift.

Måste vi hosta servern själva?

Nej. De flesta väljer en hanterad lösning eller sätter upp containern på Google Cloud eller motsvarande. Det viktiga ur ett GDPR-perspektiv är var servern är fysiskt placerad och vilket bolag som juridiskt sett hanterar datan, inte om ni själva sköter driften.

Fundera på om server-side tracking är rätt investering för er? Läs mer om vår mätningstjänst eller boka ett kostnadsfritt samtal — vi går igenom er nuvarande uppsättning och ger ett ärligt svar, även om det svaret är att ni inte behöver det än.