Floodlight w serwerowym Tag Managerze: zgoda, atrybucja i praktyczna kontrola

Floodlight mierzy konwersje reklamowe w Campaign Manager 360, czyli zarejestrowane działania, takie jak zakupy lub wysłane zapytania. Przeniesienie tagu do kontenera serwerowego zmienia drogę przesyłania danych, ale nie usuwa potrzeby przekazywania i respektowania decyzji dotyczących zgody. Znaczenie mają dwie osobne zmiany Google: żądania między serwerami opisane w lipcu 2025 oraz poprawa atrybucji opisana w czerwcu 2026.

Dwie daty, dwie różne zmiany

Informacja o wydaniu Tag Managera z 28 lipca 2025 zapowiada żądania Floodlight między serwerami bez zgody, służące modelowaniu konwersji, czyli szacowaniu konwersji, których nie zaobserwowano bezpośrednio. Wpis z 22 czerwca 2026 dotyczy brakującego kontekstu przeglądarki: obecność GCLID pozwala łączyć dane serwerowe z równoległymi sygnałami przeglądarki. GCLID to identyfikator kliknięcia reklamy Google. Drugi wpis opisuje atrybucję, czyli przypisanie konwersji do kontaktu z reklamą.

Żaden wpis nie gwarantuje powszechnego usuwania duplikatów ani nie podaje zmierzonego udziału odzyskanych konwersji.

Sygnały zgody mogą dotrzeć do serwera

W opisanej przez Google konfiguracji platforma zarządzania zgodami przekazuje decyzje do tagu Google. Tag dodaje parametry zgody do żądań kierowanych do kontenera serwerowego; klient GA4, czyli moduł odbierający dane w kontenerze serwerowym, odbiera żądania, a zgodne tagi Google uwzględniają sygnały. Consent Mode nie ogranicza się więc do przeglądarki. Własne nadajniki i tagi wymagają osobnej kontroli: ustawienie przeglądarki nie steruje automatycznie niezależnym żądaniem backendu.

Dokumentacja zawiera jednak istotną rozbieżność. Podczas sprawdzenia 24 października 2026 instrukcja serwerowego Consent Mode nadal opisywała blokowanie żądań HTTP Floodlight przy ad_storage: denied. Tymczasem informacja z lipca 2025 zapowiada żądania bez zgody. Z tych zapisów nie wynika jedna wiarygodna reguła dla każdego aktualnego kontenera. Potrzebne jest sprawdzenie wdrożonej wersji tagu i rzeczywistego ruchu wychodzącego.

Pamięć, dane reklamowe i personalizacja

• ad_storage dotyczy przechowywania danych do celów reklamowych.
• ad_user_data dotyczy wysyłania danych użytkowników do Google w celach reklamowych.
• ad_personalization dotyczy reklam spersonalizowanych.
• analytics_storage dotyczy przechowywania danych do celów analitycznych.

Odmowa zapisu nie oznacza, że każde żądanie jest puste lub anonimowe. Ogólna dokumentacja Consent Mode opisuje pingi bez plików cookie zawierające na przykład czas i informacje o stronie odsyłającej. Informacje o kliknięciu reklamy zależą również od produktu i ustawień usuwania danych. Istotna jest rzeczywista zawartość transmisji; sam brak reklamowego pliku cookie nie stanowi wystarczającego dowodu.

Atrybucja nie oznacza deduplikacji

Dodatkowy kontekst kliknięcia może poprawić przypisanie konwersji. Zapobieganie podwójnemu liczeniu zakupu to osobne zadanie. Instrukcja serwerowego Floodlight zaleca usunięcie równoważnych tagów Floodlight z kontenera internetowego po udanej migracji, aby uniknąć duplikatów. Ta sama instrukcja wymaga tagu Conversion Linker w kontenerze serwerowym.

Osobnym przykładem są konwersje z wielu źródeł w Campaign Manager 360: tag internetowy i import offline przez Data Manager API potrzebują zgodnych, unikalnych identyfikatorów transakcji. Ten mechanizm nie wynika z czerwcowej informacji o GCLID. Przed uruchomieniem równoległej transmisji potrzebny jest spis nadajników, aktywności konwersji, metod zliczania i identyfikatorów zamówień.

Praktyczne testy dla każdego stanu zgody

1. Przed wyborem: otwarcie nowej sesji testowej i zapis domyślnego stanu zgody przed uruchomieniem tagów pomiarowych.
2. Po akceptacji: kontrola aktualizacji w Tag Assistant, żądania odebranego przez serwer, obsługującego klienta, uruchomionych tagów i celów transmisji.
3. Po odmowie: powtórzenie testu przy odmowie przechowywania danych reklamowych. Osobne przypadki dla odmowy danych reklamowych i personalizacji pozwalają wykryć błędne mapowanie, ukryte przy jednoczesnej odmowie wszystkich zgód.
4. Po wycofaniu zgody: kontrola kolejnych zdarzeń i odsłon. Wcześniejszy stan akceptacji nie powinien pozostawać niezauważenie aktywny.
5. Poza przeglądarką: test własnych nadajników backendowych, brakujących pól zgody i ustawień regionalnych. Własna logika nie powinna automatycznie traktować brakujących sygnałów jako zgody.

Dla każdego przypadku protokół powinien zawierać wersje kontenera i tagu, wartości zgód, czas zdarzenia, wynik reguły uruchamiania i faktycznie wysłane pola. Podgląd serwera i panel sieciowy przeglądarki pokazują różne fragmenty drogi; odpowiedzi serwera mogą też uruchamiać żądania przeglądarki. Eksporty diagnostyczne nie wymagają rzeczywistych danych klientów ani kluczy dostępu. Uruchomiony tag lub poprawna odpowiedź HTTP nie potwierdza prawidłowej atrybucji, legalności przetwarzania ani braku duplikatów w późniejszych raportach.

Ocena prawna obejmuje całą drogę danych

Transmisja między serwerami nie tworzy wyjątku prawnego. W Niemczech zapis lub odczyt informacji na urządzeniu podlega § 25 TDDDG z ustawowymi wyjątkami. Dalsze przetwarzanie danych osobowych wymaga również oceny na gruncie ochrony danych. Znaczenie mają między innymi cel, pola danych, odbiorcy, podstawa prawna i okres przechowywania. Techniczny sygnał granted nie dowodzi uzyskania ważnej zgody.