Własna domena first-party i mapowanie subdomeny w server-side GTM

Własna domena first-party w server-side GTM to konfiguracja, w której kontener serwerowy sGTM odpowiada z subdomeny należącej do Twojej głównej domeny (np. sst.twojadomena.pl), dzięki czemu przeglądarka traktuje żądania oraz pliki cookie jako first-party, a nie third-party. Mapowanie subdomeny realizuje się rekordem DNS (A/AAAA albo CNAME) wskazującym na host kontenera oraz ustawieniem parametru server_container_url w tagu Google po stronie web. Efektem jest dłuższa żywotność plików cookie, większa odporność na ITP i blokery oraz pełna kontrola nad danymi przekazywanymi do platform reklamowych.

Kiedy audytuję konto, na którym tagowanie po stronie serwera niby działa, a konwersje z Safari i tak wyciekają, w większości przypadków winna jest domena. Kontener serwerowy stoi na obcym hoście dostawcy, przeglądarka widzi go jako third-party i cała przewaga tagowania po stronie serwera zamienia się w kosmetykę. Domena first-party to nie detal konfiguracyjny. To warunek, żeby cała inwestycja w kontener serwerowy miała sens.

Skrót artykułu

Co warto wiedzieć

Wnioski, które przesądzają o tym, czy kontener serwerowy realnie odzyskuje dane pomiarowe.

• Kontekst first-party w server-side GTM wyznacza domena odpowiedzi, nie właściciel serwera

  Przeglądarka klasyfikuje cookie po domenie rejestrowalnej adresu, z którego przyszedł nagłówek Set-Cookie. Kontener stojący na subdomenie witryny daje kontekst first-party, ten sam kontener pod adresem dostawcy pozostaje third-party.

• Kontener sGTM na obcym hoście dostawcy zostawia cookie w reżimie third-party

  Transport wskazujący adres dostawcy zamiast własnej subdomeny to częsty błąd konfiguracji. Konfiguracja wygląda poprawnie, a konwersje z Safari i tak wyciekają z raportów.

• Rekord CNAME dla kontenera serwerowego nie może stać na domenie głównej (apex)

  Standard DNS nie dopuszcza rekordu CNAME na domenie rejestrowalnej, dlatego pomiar serwerowy stawia się na subdomenie w rodzaju sst. Przy własnym serwerze albo Google Cloud subdomenę kierujesz rekordem A lub AAAA na stały adres IP.

• Bez parametru server_container_url tagi web omijają kontener serwerowy i wysyłają dane do Google

  Parametr server_container_url w ustawieniach tagu Google kieruje żądania na subdomenę kontenera. Ustawienie go tylko w części tagów rozjeżdża dane, bo jedne zdarzenia idą przez serwer, a inne prosto do platformy.

• Chrome ogranicza czas życia każdego pliku cookie do 400 dni

  Google podaje limit 400 dni jako maksymalny czas życia cookie w Chrome, obowiązujący od wersji 104 z sierpnia 2022 roku. Safari skraca cookie zapisywane skryptem do 7 dni, więc realny pułap first-party to około 395 dni.

Dlaczego własna subdomena first-party wydłuża życie plików cookie?

Własna subdomena wydłuża życie cookie, bo pozwala serwerowi ustawić plik nagłówkiem HTTP Set-Cookie w kontekście first-party, a nie skryptem JavaScript. Mechanizm ITP w Safari skraca żywotność cookie ustawianych przez JavaScript do 7 dni, a przy wejściu z linku z parametrami śledzącymi nawet do 24 godzin. Cookie ustawione przez serwer z Twojej domeny tego limitu nie łapie.

Różnica jest fundamentalna. Przeglądarka nie patrzy na to, „czyj” jest serwer w sensie własności biznesowej. Patrzy na domenę rejestrowalną adresu, z którego przyszła odpowiedź. Jeśli to Twoja domena, cookie jest first-party i żyje długo. Jeśli to obcy host, cookie jest third-party i ląduje w koszu reguł prywatności.

• Sposób ustawienia: cookie z nagłówka Set-Cookie (serwer) jest trwalsze niż cookie z document.cookie (JavaScript), bo ITP celuje głównie w to drugie.
• Kontekst domeny: first-party (Twoja subdomena) wygrywa z third-party (host dostawcy) pod względem czasu życia i odporności na blokery.
• Atrybut Secure i HttpOnly: cookie serwerowe może być HttpOnly, więc skrypty przeglądarki go nie odczytają, co dodatkowo utrudnia jego wyczyszczenie przez mechanizmy prywatności.
• Sufit 400 dni: nawet najlepsza konfiguracja nie przekroczy limitu Chrome, więc uczciwa obietnica to „do około 395 dni”, nie „wieczne rozpoznanie”.

ŻYWOTNOŚĆ COOKIE

Co zmienia mapowanie na własną subdomenę

Ta sama warstwa pomiaru, inny kontekst domeny - i zupełnie inna trwałość rozpoznania użytkownika.

PrzedCookie z JS w Safari: 7 dni

PoCookie z serwera: do 395 dni

PrzedWejście z reklamy: 24 h

PoStabilne rozpoznanie powrotu

PrzedObcy host = third-party

PoWłasna subdomena = first-party

Czym różni się kontekst first-party od third-party w kontenerze serwerowym?

Kontekst first-party oznacza, że kontener serwerowy odpowiada z subdomeny Twojej witryny, więc przeglądarka traktuje jego cookie jak własne cookie strony. Kontekst third-party oznacza, że kontener odpowiada z obcej domeny (najczęściej hosta dostawcy), przez co cookie podlega tym samym ograniczeniom, co skrypty śledzące innych firm. Ta sama technologia, dwa różne światy prywatności.

To jest sedno różnicy między client-side vs server-side, której wiele wdrożeń nie domyka. Przeniesienie tagów na serwer bez własnej domeny to połowiczny ruch. Zyskujesz kontrolę nad przetwarzaniem, ale tracisz najważniejszą korzyść pomiarową, czyli trwałe rozpoznanie użytkownika w first-party. Uważam, że wdrożenie sGTM na obcym hoście bez planu migracji na subdomenę to strata połowy potencjału projektu.

KONTEKST DOMENY

Obcy host dostawcy vs własna subdomena

Ten sam kontener serwerowy sGTM, dwa różne adresy odpowiedzi - i różnica, którą widać w danych.

AObcy host (third-party)

• →Adres w rodzaju xxxx.stape.io - inna domena rejestrowalna niż witryna.
• →Cookie objęte skróceniem ITP i częściej blokowane przez rozszerzenia prywatności.
• →Szybki start, zero konfiguracji DNS - kosztem trwałości pomiaru.
• Najlepsze dla:
• testu, proof of concept, pierwszego dnia wdrożenia.

BWłasna subdomena (first-party)

• →Adres sst.twojadomena.pl - ta sama domena rejestrowalna co witryna.
• →Cookie ustawiane serwerowo, żyjące do 395 dni i odporniejsze na blokery.
• →Wymaga rekordu DNS i certyfikatu SSL - za to daje pełną wartość pomiarową.
• Najlepsze dla:
• każdego produkcyjnego wdrożenia nastawionego na dane.

Werdykt: Obcy host na start i do testów, własna subdomena na produkcję - inaczej płacisz za serwer i nie odbierasz korzyści.

Jeśli chcesz sprawdzić, czy Twój kontener serwerowy faktycznie działa w first-party, to jeden z pierwszych punktów, które weryfikuję podczas audytu pomiaru. Zajmuje kilka minut, a rozstrzyga o połowie wartości wdrożenia.

Jak zmapować subdomenę: rekord A/AAAA czy CNAME?

Wybór między rekordem A/AAAA a CNAME zależy od tego, co daje Ci host kontenera. Rekord A (IPv4) lub AAAA (IPv6) stosujesz, gdy dostajesz stały adres IP - typowo przy własnym serwerze VPS lub Google Cloud z zarezerwowanym adresem. Rekord CNAME stosujesz, gdy dostawca podaje nazwę hosta docelowego, co jest standardem przy stape.io.

• Rekord A / AAAA: subdomena wskazuje na adres IP. Używaj przy własnym serwerze, load balancerze lub gdy dostawca podaje IP zamiast nazwy. AAAA to wariant dla IPv6.
• Rekord CNAME: subdomena wskazuje na nazwę hosta (np. custom.stape.io). Wygodny, bo gdy dostawca zmieni infrastrukturę, jego IP zmienia się po jego stronie, a Twój rekord zostaje.
• Zakaz CNAME na apex: na domenie głównej (twojadomena.pl bez subdomeny) CNAME jest niedozwolony przez standard DNS. Dlatego pomiar serwerowy zawsze stawiamy na subdomenie.
• SSL obowiązkowo: subdomena musi mieć ważny certyfikat, bo transport pomiarowy idzie po HTTPS. Większość hostów kontenera wystawia certyfikat automatycznie po poprawnym rekordzie.

1. Wybierz nazwę subdomeny - krótka i neutralna, np. sst, s, data albo metrics. Unikaj nazw jednoznacznie kojarzonych z trackingiem, bo bywają celem list blokujących.
2. Dodaj rekord w panelu DNS - CNAME na host dostawcy albo A/AAAA na podany adres IP. Ustaw rozsądny TTL (np. 3600 s).
3. Poczekaj na propagację - od kilku minut do kilku godzin. Zweryfikuj rozwiązywanie nazwy narzędziem typu dig lub nslookup.
4. Potwierdź wystawienie certyfikatu SSL - wejdź na https na subdomenie i sprawdź, że nie ma ostrzeżenia o certyfikacie.
5. Powiąż subdomenę z kontenerem - w panelu hosta lub w mapowaniu domeny wskaż tę subdomenę jako adres kontenera serwerowego.

KONFIGURACJA DNS

Rekord dla subdomeny sst.twojadomena.pl

Przykładowy wpis w panelu DNS przy hostingu kontenera na stape.io (CNAME).

panel-dns - Rekordy strefy

1typ=„CNAME”

2host=„sst”

3wartosc_docelowa=„custom.stape.io”<-host z panelu dostawcy

4TTL=„3600”

5host = „@” (apex)<-CNAME na domenie głównej niedozwolony

Objaśnienie: przy Google Cloud zamiast CNAME wskazujesz zwykle rekordy A/AAAA na adresy podane w mapowaniu domeny. Kluczowe jest to, żeby subdomena należała do tej samej domeny co witryna - to warunek kontekstu first-party.

Jak ustawić server_container_url, żeby ruch web trafiał na Twój serwer?

Parametr server_container_url ustawiasz w konfiguracji tagu Google po stronie web, wpisując pełny adres swojej subdomeny z HTTPS. Dopiero ten parametr przekierowuje żądania pomiarowe z przeglądarki do kontenera serwerowego, zamiast wysyłać je bezpośrednio do Google. Bez niego kontener stoi pusty i nie ma czego przetwarzać.

W praktyce oznacza to jedno pole w tagu konfiguracyjnym GA4 w kontenerze web. Wpisujesz tam https://sst.twojadomena.pl i publikujesz kontener. Od tej chwili tag GA4 wysyła dane na Twoją subdomenę, a kontener serwerowy decyduje, co i gdzie przekazać dalej.

1. Utwórz zmienną ustawień konfiguracji tagu Google (Google tag: Configuration settings) w kontenerze web (client-side) w Google Tag Managerze.
2. Dodaj parametr server_container_url w tej zmiennej, wpisz pełny adres subdomeny z https i przypisz zmienną do tagu Google.
3. Powtórz to dla pozostałych tagów, które mają iść przez serwer - nie zostawiaj części pomiaru na starej ścieżce.
4. Opublikuj kontener web i sprawdź w trybie podglądu, że żądania kierują się na subdomenę.

Najczęstszy błąd na tym etapie to ustawienie transportu tylko w części tagów. Wtedy jedne konwersje idą przez serwer, inne bezpośrednio, a dane robią się niespójne. To dokładnie ten rodzaj rozjazdu, który analizuję, gdy raporty nie zgadzają się między sobą.

Jak zweryfikować, że kontener działa w kontekście first-party?

Kontekst first-party potwierdzasz, sprawdzając w narzędziach deweloperskich przeglądarki, że cookie pomiarowe ma w atrybucie Domain Twoją domenę, a żądania sieciowe kierują się na Twoją subdomenę, nie na obcy host. Jeśli w zakładce Application widzisz cookie ustawione dla .twojadomena.pl z długą datą wygaśnięcia, konfiguracja jest poprawna.

• Zakładka Network: żądania pomiarowe trafiają na sst.twojadomena.pl, a nie na adres dostawcy. To pierwszy i najważniejszy test.
• Zakładka Application → Cookies: cookie (np. FPID lub _ga) ma Domain ustawiony na Twoją domenę i datę wygaśnięcia liczoną w miesiącach, nie w dniach.
• Atrybuty cookie: obecność Secure i SameSite=Lax potwierdza poprawne ustawienie serwerowe.
• Tryb podglądu kontenera serwerowego: pokazuje przychodzące żądania i potwierdza, że transport działa end to end.

WERYFIKACJA FIRST-PARTY

Jak wygląda poprawne cookie w narzędziach przeglądarki

Widok z zakładki Application - cookie first-party obok cookie z obcego hosta.

Application → Cookies

Ustawione przez serwer (Set-Cookie)FPID | Domain: .twojadomena.plSecure, HttpOnly, SameSite=Lax

Atrybuty cookie:

Expiresdo 395 dni

Kontekstfirst-party

Ustawione z obcego hostacookie | Domain: obcy-host.ioTHIRD-PARTY: 7 DNI / ITP

Domena zgodna z witryną

Cookie z Domain ustawionym na Twoją domenę potwierdza kontekst first-party i długi czas życia.

Żądania na subdomenę

W zakładce Network ruch pomiarowy idzie na Twoją subdomenę, nie na adres dostawcy.

Najczęstsze błędy mapowania subdomeny first-party

Najczęstszy błąd to pozostawienie kontenera na obcym hoście dostawcy i wpisanie tego obcego adresu jako server_container_url. Wtedy formalnie masz tagowanie po stronie serwera, ale całe cookie i tak jest third-party, więc tracisz odporność na ITP. To pułapka, która wygląda jak działająca konfiguracja, a po cichu odbiera połowę korzyści.

• Obca domena serwera = third-party: transport na xxxx.stape.io zamiast na własną subdomenę. Najczęstsza i najkosztowniejsza pomyłka.
• Subdomena na innej domenie rejestrowalnej: jeśli witryna to sklep.pl, a pomiar stoi na sklep-data.pl, to wciąż third-party - musi być ta sama domena.
• CNAME na apex: próba postawienia rekordu CNAME na domenie głównej. Standard DNS na to nie pozwala - użyj subdomeny.
• Brak lub błędny certyfikat SSL: transport po HTTPS nie zadziała bez ważnego certyfikatu na subdomenie.
• Rekord CAA blokujący certyfikat: restrykcyjny wpis CAA potrafi uniemożliwić wystawienie certyfikatu dla nowej subdomeny.
• Proxy CDN przed kontenerem: warstwa pośrednia (np. źle skonfigurowany Cloudflare) potrafi usuwać nagłówki cookie lub rozjeżdżać adresy.
• Transport tylko w części tagów: jedne zdarzenia idą przez serwer, inne bezpośrednio - dane przestają się zgadzać.

To częsty scenariusz. Samo przełączenie transportu z obcego hosta na własną subdomenę może przywrócić widoczność części konwersji z Safari, które wcześniej gubiły się w raportach. To nie magia, tylko poprawiona domena. Jeśli rozpoznajesz u siebie któryś z tych błędów, to typowy moment, w którym warto spojrzeć na konfigurację z zewnątrz.

Co domena first-party oznacza dla RODO i zgód użytkowników?

Domena first-party daje Ci większą kontrolę nad danymi, ale nie zwalnia z obowiązku zbierania zgody. RODO nadal wymaga podstawy prawnej do przetwarzania, a Consent Mode nadal musi przekazywać sygnały zgody do kontenera serwerowego. First-party to lepsze narzędzie do minimalizacji danych, nie furtka omijająca zgodę.

Przewaga jest realna, ale leży gdzie indziej. Skoro dane najpierw trafiają na Twój serwer, to na nim możesz filtrować i anonimizować parametry, zanim cokolwiek pojedzie do platform reklamowych. To praktyczna realizacja zasady minimalizacji danych. Pełną architekturę zgód i pomiaru serwerowego dla Google Ads rozwijam w materiale o server-side tagging.

• Kontrola przed wysyłką: serwer może usunąć lub zahashować dane osobowe, zanim trafią do Google czy innej platformy.
• Region przetwarzania: kontener serwerowy warto trzymać w regionie UE, co ułatwia zgodność z RODO.
• Consent Mode dalej obowiązuje: bez sygnału zgody z CMP kontener nie powinien wykonywać pomiaru wymagającego zgody - first-party tego nie zmienia.
• Minimalizacja danych: przekazuj dalej tylko to, co potrzebne do pomiaru, a nie cały ładunek parametrów z przeglądarki.

Podsumowanie

Własna domena first-party to element, który decyduje o tym, czy kontener serwerowy realnie odzyskuje dane, czy tylko udaje, że to robi. Sam serwer nie wystarcza. Dopiero subdomena należąca do Twojej domeny, poprawny rekord DNS, ustawiony server_container_url i ważny certyfikat SSL składają się na kontekst first-party, w którym cookie żyje miesiącami, a nie dniami.

Przestań traktować hosting kontenera jak techniczny szczegół, który można odłożyć na później. Zacznij postrzegać domenę jako fundament całego pomiaru serwerowego - bo to ona przesądza o wartości danych, którymi karmisz kampanie. Kolejność jest prosta: subdomena, DNS, SSL, transport, weryfikacja w narzędziach przeglądarki. Jeśli któregoś z tych elementów brakuje, wdrożenie pracuje na połowie mocy.

Na czym opieram te wnioski

Źródła i dokumentacja

Mapowanie subdomeny do kontenera serwerowego łączy trzy warstwy: mechanikę plików cookie w przeglądarce, konfigurację tagu web i wymogi zgód. Poniższe cztery źródła opisują dokładnie te warstwy - specyfikację nagłówka Set-Cookie, pomiary dostępu skryptów do cookie first-party, dokumentację parametru server_container_url oraz badanie zgód na ponad 20 tys. domen.

developer.mozilla.org

Pliki cookie w HTTP: Domain, Max-Age, HttpOnly

Dokumentacja MDN opisuje, jak atrybuty Domain, Max-Age i HttpOnly decydują o zasięgu cookie na subdomeny i o tym, czy plik jest w ogóle widoczny dla JavaScriptu. To techniczna podstawa pierwszej sekcji o tym, dlaczego cookie ustawione nagłówkiem Set-Cookie z Twojej subdomeny żyje dłużej niż plik zapisany przez document.cookie.

MDN Web Docs Otwórz

arxiv.org

CookieGuard: izolacja pierwszej strony

Pomiar na 20 tys. witryn pokazał, że na 56 procent z nich skrypty zewnętrzne odczytują cookie, których same nie ustawiły, a na 32 procent mogą je nadpisać lub skasować. Twardy dowód pod drugą sekcję o różnicy między kontekstem first-party i third-party: sama subdomena nie izoluje danych, robi to dopiero cookie ustawiane po stronie serwera.

arXiv (badanie) Otwórz

developers.google.com

Konfiguracja strumienia GA4 z tagowaniem serwerowym

Dokumentacja Google prowadzi krok po kroku przez odczytanie Default Url kontenera serwerowego i dodanie parametru server_container_url w tagu Google w kontenerze web. Bezpośrednie odniesienie do sekcji o ustawieniu server_container_url, łącznie z nazwą pola, którą wpisujesz w ustawieniach tagu.

Google for Developers Otwórz

arxiv.org

Cookie odporne na decyzje w bannerze

Crawl ponad 20 tys. domen z listy Tranco wykazał, że około połowa witryn wysyła cookie niepodatne na wybór użytkownika, a witryny z bannerem CMP wysyłają ich 6,9 raza więcej niż te z rozwiązaniem własnym. Podstawa dla sekcji o RODO i zgodach: własna domena first-party niczego nie legalizuje, jeśli sygnał zgody nie steruje realnie zapisem plików.

arXiv (badanie) Otwórz

Najczęściej zadawane pytania

Pytania i odpowiedzi (FAQ)

Własna domena w tagowaniu serwerowym: wybór między rekordem A i CNAME oraz żywotność ciasteczka ustawionego przez serwer.

01Czy muszę mieć własną domenę, żeby uruchomić server-side tagging?

Do samego startu nie, bo kontener zadziała na hoście dostawcy. Ale bez własnej subdomeny działasz w kontekście third-party, więc tracisz odporność na ITP i długie cookie. Do produkcyjnego pomiaru własna domena first-party jest praktycznie obowiązkowa.

02Czy subdomena kontenera może kolidować z istniejącymi rekordami DNS?

Może, jeśli subdomena jest już używana - na przykład przez pocztę albo panel. Dlatego wybiera się nazwę nieużywaną i sprawdza istniejące wpisy przed zmianą. Błędny rekord potrafi zerwać pomiar i inne usługi jednocześnie, a propagacja zmian trwa do doby.

03Jak długo żyje cookie first-party ustawione przez serwer?

Znacznie dłużej niż cookie z JavaScript w Safari, które ITP tnie do 7 dni. Cookie ustawione serwerowo w kontekście first-party może żyć do około 395 dni, bo Chrome ogranicza maksymalny czas życia każdego cookie do 400 dni.

04Czy mapowanie własnej domeny ma sens przy małym ruchu?

Jeśli w ogóle decydujesz się na kontener serwerowy, to mapowanie subdomeny jest najtańszym krokiem w całym wdrożeniu - to jeden rekord DNS i certyfikat. Nie ma sensu płacić za serwer i dobrowolnie zostawać w third-party. Skala ruchu wpływa na koszt hostingu, nie na sens samej domeny.

05Czy własna domena first-party zwalnia mnie z pytania o zgodę?

Nie. First-party daje kontrolę nad danymi, ale RODO nadal wymaga zgody, a Consent Mode nadal musi przekazywać jej sygnały do kontenera. Przewaga polega na tym, że na własnym serwerze możesz filtrować i minimalizować dane przed wysyłką do platform.

06Jak sprawdzić, czy pomiar naprawdę działa w first-party?

Otwórz narzędzia deweloperskie przeglądarki. W zakładce Network żądania pomiarowe powinny iść na Twoją subdomenę, a w zakładce Application cookie powinno mieć Domain ustawiony na Twoją domenę i datę wygaśnięcia liczoną w miesiącach. Jeśli tak jest, konfiguracja first-party jest poprawna.

---