LW IT Solutions
« Blog Overview /Digital Marketing / Odnawianie plików cookie First-Party: Ochrona przed ITP...
This post in other languages:

Odnawianie plików cookie First-Party: Ochrona przed ITP dzięki Cloudflare Workers i ssGTM

Odnawianie plików cookie First-Party: Ochrona przed ITP dzięki Cloudflare Workers i ssGTM
Spis treści
  1. Odnawianie plików cookie First-Party: Ochrona przed ITP dzięki Cloudflare Workers i ssGTM
  2. 1. Projekt architektury: Pliki cookie zarządzane przez serwer
  3. 2. Odnawianie cookie przez Cloudflare Workers i ssGTM
  4. 3. Google Tag Gateway (GTG): Idealne partnerstwo na krawędzi
  5. Podsumowanie
  6. Źródła

Odnawianie plików cookie First-Party: Ochrona przed ITP dzięki Cloudflare Workers i ssGTM

Mechanizm Intelligent Tracking Prevention (ITP) w przeglądarce Safari oraz nowoczesne silniki prywatności drastycznie ograniczają żywotność plików cookie po stronie klienta. Identyfikatory ustawiane za pomocą JavaScriptu (document.cookie) są ograniczane do maksymalnie 7 dni – a w przypadku wykrycia parametrów kliknięć reklamowych w adresie URL ich ważność jest redukowana nawet do 24 godzin. Również klasyczne wdrożenia oparte na maskowaniu CNAME są identyfikowane i neutralizowane przez algorytmy obronne WebKit, gdy rekord DNS wskazuje na zewnętrzne serwerownie systemów śledzących.

Aby zachować spójność danych oraz precyzję atrybucji w długich cyklach konwersji, architektura analityczna musi zrezygnować z pamięci zarządzanej przez skrypty na rzecz prawdziwego trasowania First-Party na krawędzi sieci (Edge Routing) przy użyciu nagłówków HTTP zarządzanych przez serwer.

1. Projekt architektury: Pliki cookie zarządzane przez serwer

Ominięcie 7-dniowego limitu ITP wymaga generowania identyfikatorów bezpośrednio w warstwie brzegowej za pomocą nagłówków odpowiedzi HTTP (Set-Cookie). Ponieważ restrykcje przeglądarek odróżniają pliki cookie tworzone przez skrypty klienta od legalnych sesji generowanych przez serwer, ciasteczka skonfigurowane przez Edge Workers zachowują ważność nawet przez 365 dni, przy pełnej zgodności z regionalnymi regulacjami o prywatności.

Atrybut pliku cookieWymagana wartośćUzasadnienie techniczne
HttpOnlytrueBlokuje dostęp z poziomu JavaScriptu, uodparniając ciasteczko na limity ITP oraz ataki XSS.
SecuretrueWymaga szyfrowanej transmisji HTTPS w całych strukturach sieciowych.
SameSiteLax / StrictGwarantuje traktowanie pliku jako natywnego kontekstu First-Party.
DomainDomena główna (np. example.com)Zapobiega karom za niezgodność CNAME pomiędzy subdomenami.
Diagram do artykułu: Kontekst Same-Origin, Odporność na mechanizmy obronne CNAME, Brak opóźnień sieciowych
3 elementów artykułu w skrócie: Kontekst Same-Origin, Odporność na mechanizmy obronne CNAME, Brak opóźnień sieciowych.

2. Odnawianie cookie przez Cloudflare Workers i ssGTM

Zaawansowany potok odnawiania identyfikatorów wykorzystuje Cloudflare Workers jako reverse proxy przed kontenerem Server-Side Google Tag Manager (ssGTM). W momencie przechwycenia żądania HTTP na krawędzi sieci, skrypt Worker weryfikuje obecność prawidłowego identyfikatora serwerowego. W przypadku jego braku lub bliskiego wygaśnięcia, Worker wstrzykuje do odpowiedzi odświeżony nagłówek Set-Cookie.

// Cloudflare Worker Edge Script: Server-Managed Identifier Restoration
export default {
  async fetch(request, env) {
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    
    // Odczyt lub wygenerowanie anonimowego identyfikatora First-Party
    let fpId = getCookieValue(request.headers.get("Cookie"), "fp_id");
    if (!fpId) {
      fpId = crypto.randomUUID();
    }

    // Wymuszenie nagłówka Set-Cookie z 1-rocznym okresem ważności
    newResponse.headers.append(
      "Set-Cookie",
      `fp_id=${fpId}; Max-Age=31536000; Path=/; Domain=example.com; Secure; HttpOnly; SameSite=Lax`
    );

    return newResponse;
  }
};

Wewnątrz środowiska ssGTM ten trwały identyfikator brzegowy jest mapowany na standardowe pole Client ID dla GA4 lub Google Ads, co stabilizuje wielokanałową atrybucję w długoterminowych ścieżkach użytkowników.

3. Google Tag Gateway (GTG): Idealne partnerstwo na krawędzi

Google Tag Gateway (GTG) to wyspecjalizowany mechanizm trasowania First-Party, który tuneluje ruch analityczny bezpośrednio przez główną domenę. Wdrożenie GTG na platformie Cloudflare Workers tworzy idealną synergię z procesem odnawiania ciasteczek:

  • Kontekst Same-Origin: GTG przesyła biblioteki skryptów (np. /gtg/gtm.js) oraz pakiety danych (/gtg/collect) przez dokładnie ten sam adres IP oraz numer systemu autonomicznego (ASN), co aplikacja główna.
  • Odporność na mechanizmy obronne CNAME: Ponieważ GTG działa bezpośrednio w infrastrukturze domeny głównej poprzez proxy brzegowe zamiast zewnętrznych delegacji DNS, algorytmy antyśledzące WebKit klasyfikują ten ruch jako natywną komunikację backendową.
  • Brak opóźnień sieciowych: Realizacja trasowania GTG oraz odnawiania plików cookie w tym samym procesie Cloudflare Worker odbywa się w węzłach brzegowych na całym świecie, eliminując dodatkowe uściski dłoni TLS.

Podsumowanie

Przezwyciężenie ograniczeń ITP wymaga przeniesienia zarządzania identyfikatorami ze skryptów przeglądarki do infrastruktury brzegowej. Połączenie serwerowych plików cookie HttpOnly w Cloudflare Workers z trasowaniem Same-Origin oferowanym przez Google Tag Gateway (GTG) zapewnia w pełni zgodną z prawem, bezpieczną i technicznie niezawodną architekturę pomiarową.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

Komentarze: 2

  1. Christiane Merl

    Tabela atrybutów ciasteczka jest zwięzła i kompletna,a uzasadnienie dla domeny głównej zamiast subdomeny tłumaczy, dlaczego połowa wdrożeń CNAME przestała działać.

    Pytanie o skutki uboczne: ciasteczko na domenie głównej jedzie z każdym żądaniem, także po zasoby statyczne. Czy nie psuje to buforowania na CDN?

    1. Lukas Wojcik Autor

      Psuje, jeżeli klucz bufora uwzględnia ciasteczka — a wiele konfiguracji domyślnie tak robi, żeby nie wydać treści zalogowanego użytkownika komuś innemu.

      Efekt jest cichy i kosztowny: każdy odwiedzający ma inną wartość identyfikatora, więc każdy dostaje własną kopię w buforze. Współczynnik trafień spada niemal do zera, obciążenie serwera źródłowego rośnie, a strona staje się wolniejsza bez jednego komunikatu o błędzie.

      Rozwiązanie polega na wyłączeniu tego konkretnego ciasteczka z klucza bufora — u większości dostawców to jedno pole w konfiguracji. Warto zrobić to świadomie i zapisać, bo reguła wygląda niebezpiecznie („ignoruj ciasteczko”), a jest dokładnie odwrotnie: identyfikator analityczny nie zmienia treści strony, więc nie ma powodu, żeby dzielił bufor na tyle części, ilu jest odwiedzających.

Napisanie komentarza

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.

ALL ARTICLES & CATEGORIES

CCTV

Śledź tę kategorię przez RSS

Cloud & AI

Śledź tę kategorię przez RSS

Data Privacy

Wszystkie artykuły w tej kategorii (11) Śledź tę kategorię przez RSS

Digital Analytics

Wszystkie artykuły w tej kategorii (43) Śledź tę kategorię przez RSS

Digital Marketing

Wszystkie artykuły w tej kategorii (25) Śledź tę kategorię przez RSS

IT & Networks

Wszystkie artykuły w tej kategorii (15) Śledź tę kategorię przez RSS

Raspberry Pi

Śledź tę kategorię przez RSS

Smart Home

Wszystkie artykuły w tej kategorii (11) Śledź tę kategorię przez RSS

Tworzenie stron internetowych

Śledź tę kategorię przez RSS

Wtyczki i triki WordPress

Śledź tę kategorię przez RSS