Consent Mode v2 w GTM: przewodnik 2026

Consent Mode v2 jest obowiązkowy dla reklamodawców Google w EU od marca 2024. Niepoprawne wdrożenie oznacza: (a) zablokowane kampanie Google Ads, (b) brak attribution w GA4 dla 30-70% users, (c) ryzyko kar RODO do 4% rocznego obrotu firmy. W tym tekście: pełny przewodnik wdrożenia – 6 typów consent, integracja z GTM, 3 scenariusze wdrożenia, Advanced Consent Mode vs Basic, najczęstsze pułapki i jak mierzyć skuteczność.

Tekst jest częścią analityki marketingowej 2026. Fundament GTM: architektura kontenera GTM. Serwerowy kontekst: server-side GTM. Pełna analityka: GA4 dla zaawansowanych.

W skrócie

Consent Mode v2 = granular consent system z 6 typami zgody: analytics_storage, ad_storage, ad_user_data, ad_personalization, functionality_storage, security_storage.
Obowiązkowy dla reklamodawców Google w EU od marca 2024. Niepoprawna implementacja = zablokowane kampanie, brak attribution.
2 tryby: Basic (consent denied = zero events) i Advanced (consent denied = cookieless pings z modeled data w GA4).
Advanced rekomendowany – zachowuje 50-80% attribution mimo denied consent dzięki konwersja modeling.
Integracja z CMP (Cookiebot, OneTrust, Iubenda) + GTM – standard implementacja 4-8 godzin doświadczonego developera.

Czym jest Consent Mode v2

Consent Mode v2 to mechanizm Google pozwalający dostosować zachowanie tagów Google (GA4, Google Ads, Floodlight) w zależności od consent użytkownika. Zamiast „user nie dał consent → tag w ogóle nie fires”, wprowadza warstwę pośrednią: „user nie dał consent → tag fires z ograniczonymi uprawnieniami, consent state przekazywany do Google, Google modeluje brakujące dane”.

Różnica vs starsze podejście

Pre-2021: consent = on/off dla wszystkich tagów.
Consent Mode v1 (2021): 2 typy consent (analytics, ad).
Consent Mode v2 (2024): 6 typów, granular. Obowiązkowy dla Google Ads w EU.

Dlaczego obowiązkowy

DMA (Digital Markets Act) w EU wymaga od Google transparentnego użycia danych w reklamie. Google implementacja: reklamodawcy muszą wdrożyć Consent Mode v2 żeby Google mógł legalnie używać danych z ich stron do targeting / personalizacji reklam. Brak CMv2 = Google Ads „slowdown” lub całkowita blokada kampanii.

6 typów consent

Consent type	Co kontroluje	Default w EU
`analytics_storage`	Cookies i storage dla analytics (GA4, Google Analytics)	denied
`ad_storage`	Cookies dla advertising (Google Ads, Floodlight)	denied
`ad_user_data`	Wysyłanie user data (email, phone) do Google w advertising context	denied
`ad_personalization`	Personalizacja reklam (remarketing, targeting)	denied
`functionality_storage`	Cookies essential dla funkcji strony (koszyk, preferencje)	granted (essential)
`security_storage`	Fraud prevention, security cookies	granted (essential)

Wpływ na tagi

GA4 tag: wymaga analytics_storage = granted. Denied → cookieless pings (ping bez cookie, Google modeluje).
Google Ads konwersja: wymaga ad_storage = granted. Denied → konwersja modeled w AdWords.
Google Ads remarketing: wymaga ad_storage + ad_personalization = granted.
Meta Pixel: Google Consent Mode nie steruje — wymaga własnej integracji z CMP.

Basic vs Advanced mode

Basic Consent Mode

Consent denied → tag całkowicie NIE fires (klasyczne zachowanie).
Prostsza implementacja, ale tracisz 30-70% danych.
Dla małych firm bez heavy reliance na attribution.

Advanced Consent Mode (recommended)

Consent denied → tag fires, ale wysyła ograniczony ping bez cookies.
Google używa modelowania (konwersja modeling) żeby odtworzyć atrybucję z tych pings.
Zachowuje 50-80% attribution mimo denied consent.
Wymaga minimum wolumenu danych (ok. 1000 konwersja/mies) żeby model był accurate.

Różnica w praktyce

Basic + 50% denied consent → attribution spadek 50%.
Advanced + 50% denied consent → attribution spadek 10-20% (modeling kompensuje).
Advanced wymaga url_passthrough i ads_data_redaction parametrów w tag GA4.

Integracja z Consent Management Platform

Najpopularniejsze CMP w PL (2026)

Cookiebot (Cybot): most popular global, native integracja z Google CM v2, ~15-199 EUR/mies.
OneTrust: enterprise-grade, drogi (~400+ EUR/mies), full suite dla dużych firm.
Iubenda: popular w PL, dobra cena (~25-100 EUR/mies), polska pomoc.
Cookiefirst: mid-market, prosta integracja, ~9-79 EUR/mies.
TrustArc: enterprise, similar do OneTrust.
Klaro!: open source, self-hosted, darmowe.

Wymagania od CMP

Google-certified CMP partner (lista na Google support).
Wsparcie 6 typów consent v2.
Prawidłowy sequence calls: gtag('consent', 'default', ...) przed gtag('consent', 'update', ...).
Persistency cookie z consent state.

Jak działa integracja

Strona ładuje CMP banner.
CMP wysyła gtag call „consent default” z domyślnymi wartościami (zwykle denied dla EU).
User akceptuje/odrzuca w banner.
CMP wysyła gtag call „consent update” z new values.
GTM tags reagują: fires z/bez cookies w zależności od consent.
CMP zapisuje consent state w cookie (6-12 miesięcy).
W kolejnych wizytach CMP od razu wysyła update bez banner.

Implementacja w GTM krok po kroku

Krok 1: Wybór CMP

Decyzja na podstawie: (a) wielkości firmy (mała — Cookiebot/Iubenda, średnia – Cookiebot Pro, duża — OneTrust), (b) budżetu, (c) integracji z existing stack (jeśli używasz WordPress – Iubenda ma dobry plugin).

Krok 2: Instalacja CMP

Kopiuj CMP script tag i paste w <head> strony (przed GTM snippet).
Konfiguruj CMP: categorie cookies (analytics, marketing, functional), language, geo-targeting (EU-only banner?).
Test: otwórz stronę w incognito, zobacz banner.

Krok 3: Default consent state w GTM

Dodaj tag „Consent Mode – Default” w GTM:

Tag type: Consent Mode (Google tag).
Command: default.
Wszystkie 6 typów: denied (dla EU regionu).
wait_for_update: 500ms.
Trigger: Consent Initialization – All Pages.

Krok 4: Update consent na podstawie CMP

CMP powinien emitować events do dataLayer przy acceptance:

// Przykład dla Cookiebot:
window.addEventListener('CookiebotOnAccept', () => {
  gtag('consent', 'update', {
    analytics_storage: 'granted',
    ad_storage: 'granted',
    ad_user_data: 'granted',
    ad_personalization: 'granted'
  });
});

Krok 5: Tags z consent świadomość

W każdym tagu Google w GTM: Advanced Settings → Consent Settings.
Wybierz required consent: dla GA4 wybierz analytics_storage.
Dla Google Ads wybierz ad_storage + ad_user_data.
Tag sam zdecyduje, jak się zachowa przy denied.

Krok 6: Advanced Mode parameters

Aby aktywować Advanced Consent Mode (nie Basic):

W tag GA4 Configuration: dodaj parametr url_passthrough = true.
W tag GA4: dodaj ads_data_redaction = true.
Weryfikacja: otwórz stronę z denied consent, sprawdź w DevTools Network czy request do GA4 ma gcs=G100 (cookieless ping).

Testing i weryfikacja

Test 1: Default state

Otwórz stronę w incognito (bez cookies).
DevTools Console: window.google_tag_data.ics.entries.
Sprawdź: wszystkie 4 ad consent = denied, analytics_storage = denied.

Test 2: Acceptance flow

Kliknij „Accept All” w banner CMP.
Re-check: wszystko = granted.
Refresh page: consent persistuje, banner nie pokazuje się ponownie.

Test 3: Denial flow

Kliknij „Reject All” lub „Only Necessary”.
Check: analytics_storage, ad_storage = denied.
Navigate na stronie, sprawdź DevTools Network: requesty do GA4 z gcs=G100.

Test 4: Partial consent

W banner CMP: customize → zaakceptuj tylko analytics.
Check: analytics_storage = granted, ad_* = denied.
GA4 pełny śledzenie, Google Ads tylko cookieless.

Test 5: Tag Assistant validation

Otwórz Google Tag Assistant.
Weryfikacja: Consent state pokazywany poprawnie, tagi fires zgodnie z consent.
Lookfor warnings „Consent state unclear” — wskazuje konfigurational issue.

Konwersja modeling — jak działa

Advanced Consent Mode pozwala Google modelować brakujące konwersje. Gdy user ma denied consent, GA4 nadal otrzymuje ping (cookieless), ale bez user identifier. Google ML model przewiduje, ilu „modelowanych” users pewnie skonwertowało na podstawie patternów z users z granted consent.

Wymagania dla Konwersja Modeling

Minimum ~1000 ad konwersje miesięcznie.
Consent rate > 35% (wystarczająca próba granted users do trenowania modelu).
Aktywny GA4 z demographic / interest data.
Google Ads konta połączone z GA4.

Jak widać modelowane konwersje

W Google Ads: Attribution report → modeled konwersje.
W GA4: Konwersje report → behavioral modeling.
Typowo: 5-30% konwersji to modeled (zależy od consent rate).

Accuracy konwersja modeling

Google raportuje 85-95% accuracy dla modelowania przy właściwej implementacji. W praktyce: zależy od niszy i wolumenu. Dla e-commerce z 10k konwersje/mies – bardzo accurate. Dla B2B z 100 konwersje/mies – mało reliable, lepiej użyć Basic Mode + inne techniki atribucji.

Pułapki i błędy

Pułapka 1: Missing default consent

Jeśli nie wywołasz gtag('consent', 'default', ...) przed tagami, Google traktuje jako „all granted” — narusza RODO. Zawsze Consent Mode – Default tag PIERWSZY w Consent Initialization trigger.

Pułapka 2: Race condition z CMP

Tag GA4 fires PRZED CMP successfully loadem → wysyła request bez consent update. Rozwiązanie: wait_for_update parameter w default consent (zwykle 500ms), pozwala CMP async load.

Pułapka 3: CMP nie Google-certified

Niecertified CMP może nie poprawnie emitować gtag signals. Google Ads kampanie degradują. Zawsze weryfikuj CMP w oficjalnej liście Google certified partners.

Pułapka 4: Consent w cookie banner nie match’uje consent state

User klika „Accept All” ale internally tylko niektóre consent = granted. Bug w CMP config. Debug: DevTools Console → gtag consent state po acceptance.

Pułapka 5: URL Parameters Stripping

Bez url_passthrough = true, GA4 usuwa UTM parameters przy cookieless pings → kampanie pokazują się jako „direct”. Zawsze enable url_passthrough.

Pułapka 6: Meta Pixel nie respektuje CM v2

Google Consent Mode nie steruje Meta Pixel. Dla Meta wymagana oddzielna integracja z CMP (fbq consent API). Pominięcie = Meta Pixel fires mimo denied consent → legal risk.

Ryzyka prawne i compliance

RODO / GDPR enforcement

Kary: do 4% rocznego obrotu firmy lub 20 mln EUR (whichever higher).
Polska: UODO aktywnie audytuje, szczególnie e-commerce i finance.
Komplaints od użytkowników typowy trigger audytu.

Dobre praktyki compliance

Record of Processing Activities (RoPA) z sekcją Consent Mode.
Consent withdrawal mechanism (easy opt-out).
Data retention policies per consent type.
DPA (Data Processing Agreement) z każdym vendor (Google, Meta, CMP provider).
Regular audytów wewnętrznych (quarterly).

Dokumentacja dla audytu

Screenshots banner CMP z datami.
Consent analytics (acceptance rate per category).
Technical documentation implementacji (GTM setup, CMP config).
Privacy Policy z explicit mention Consent Mode v2.

Ryzyko niedopełnienia

Google Ads kampanie: slowdown, shadow ban, eventualne zablokowanie.
Analytics data: niereliable, niewiarygodne dla business decisions.
Legal: kary finansowe + reputational damage.
Operational: trudność migracji z incorrect setup w przyszłości.

3 case studies wdrożeń Consent Mode v2

Case A: E-commerce fashion – wzrost attribution po Advanced

Sklep z 180k sesji/mies, 8% Meta Ads share, 45% Google Ads share. Przed Consent Mode v2 miał klasyczny cookie banner z accept all (bez granular options) – technicznie non-compliant RODO, ale działający. Po wdrożeniu Cookiebot + Advanced Consent Mode v2: consent rate accept all = 42% (reszta: 38% accept necessary tylko, 20% close banner). Mimo tego: GA4 widzi 83% historical volume (modeling kompensuje). Google Ads konwersja: +18% w porównaniu do 6 miesięcy wcześniej (modeled konwersje). Czas wdrożenia: 12 godzin developera + 6 godzin legal review. Roczny koszt CMP: ~600 EUR (Cookiebot Pro).

Case B: B2B SaaS – niski wolumen, Basic Mode

Firma B2B z 15k sesji/mies i 80 konwersje/mies. Za mało wolumenu dla konwersja modeling (wymaga > 1000/mies). Decyzja: Basic Consent Mode, ale zoptymalizowany UX banner dla wyższego acceptance rate. Wdrożenie: Iubenda + dopracowany copy banner („Accept to help us improve our free content”). Consent rate wzrósł z 32% do 58%. Attribution loss tylko proporcjonalny do denied rate — akceptowalny, gdy wiemy, że modeling nie poprawi sytuacji. Alternatywna strategia: server-side śledzenie + First Party cookies, częściowo niezależne od consent (zgodne z RODO gdy użyte dla essential functionality).

Case C: Medyczny marketplace – strict compliance

Portal zdrowotny, category regulowana, wysokie ryzyko audytu UODO. Wybór: OneTrust enterprise + Advanced Consent Mode v2. Pełna integracja z sGTM (server-side hashing PII, redukcja IP leak). Consent rate: tylko 28% accept all (wymagany RODO strict approach — nie możemy „zachęcać” do acceptance). Attribution minimalna, ale compliance absolute. Dokumentacja: RoPA, DPA z każdym vendor, quarterly audyt przez external DPO, logi wszystkich consent events przez 5 lat (retention policy). Koszt: ~8k EUR/rok OneTrust + 15k PLN external DPO.

Integracja z innymi platformami reklamowymi

Meta Ads

Jak wspomniałem wcześniej, Google Consent Mode nie steruje Meta Pixel. Meta wprowadziła własny „Consent API” (odpowiednik CMv2):

Sygnały do Meta Pixel: fbq('consent', 'grant') i fbq('consent', 'revoke').
Meta Events Manager: Advanced Matching + Data Processing Options (LDU – Limited Data Use).
iOS 14.5+: dodatkowo Apple App Śledzenie Transparency – signal niezależny od Meta Consent API.
Advanced integracja przez server-side Meta CAPI: consent state jako parametr eventów.

LinkedIn Ads

LinkedIn Wniosek Tag ma własne consent flag: _linkedin_data_partner_ids.
LinkedIn Konwersje API: consent passed as event parameter.
Zintegrowane w większości CMP (Cookiebot, OneTrust, Iubenda).

TikTok Ads

TikTok Pixel Consent mode: ttq.instance().consent('granted'/'revoked').
TikTok Events API supports consent signals.
Mniej dojrzałe compliance tooling vs Google/Meta.

Microsoft Ads / Bing

Microsoft UET tag z Enhanced Konwersje — wymaga consent dla PII matching.
Mniej granular niż Google, podobne do pre-v2 podejścia.

Unified Consent Strategy

Mature organizations budują „Consent Broker” – layer, który odbiera consent z CMP i rozdziela do wszystkich platform reklamowych. Zwykle sGTM lub własny Node.js middleware. Plusy: jedno źródło prawdy, konsystencja, łatwiejsza audyt. Minusy: wymaga dev work.

Monitoring consent rate

Metryki do śledzenia

Overall consent rate: % userów z ad_storage = granted. Target: > 35% dla modelingu, > 50% dla dobrego attribution.
Consent rate per category: czasem analytics accepted, ad denied – różne benchmarki.
Banner interaction rate: % userów klikających jakąkolwiek akcję vs ignorujących banner.
Time to consent: średni czas od banner show do acceptance/denial.

Optymalizacja consent rate

A/B test banner copy – pozytywne framing (+10-20% acceptance).
Show value exchange („Accept to get personalized content”).
UX polish: prominent Accept button, subtle Reject.
Legal review przed A/B test (nie wszystkie UX optymalizacje są zgodne z RODO guidelines).

Narzędzia monitoringu

CMP-native analytics (Cookiebot, OneTrust dashboards).
GA4 custom events z consent state.
Google Ads Consent Diagnostics report (pokazuje impact).

Zaawansowane wzorce i optymalizacje

Wzorzec 1: Geo-targeting banner

Banner CMP pokazuje się tylko dla użytkowników z EU. Dla US/Asia – no banner, full śledzenie. Implementacja: CMP supports country detection (IP geolocation). Plusy: niższy friction dla non-EU userów, attribution bez degradation. Minusy: wymaga CMP, który to wspiera (większość enterprise).

Wzorzec 2: Różne banners per language

Wielojęzyczne marki (PL, EN, DE) pokazują banner w odpowiednim języku. Zwiększa to acceptance rate o 10-15% vs uniwersalny banner. CMP obsługują to natywnie, wymaga tłumaczeń copy.

Wzorzec 3: Progressive consent

Zamiast „Accept All vs Reject” – progresywny banner: początkowo pyta o analytics (minimal friction), po acceptance → przy kolejnej wizycie dopytuje o ads. Wyższa acceptance rate per category, ale wymaga custom logic w CMP (nie wszystkie supportują).

Wzorzec 4: Contextual consent

Banner pokazywany nie na pierwszej wizycie, a dopiero przy akcji wymagającej śledzenie (np. przy checkout, gdy user już zainwestował w proces). Wyższa acceptance (70%+), ale niższy overall wolumen (user może opuścić stronę przed acceptance).

Wzorzec 5: First-party data emphasis

Zamiast polegać tylko na Google modeling, budowanie własnego first-party data ciąg procesów (email capture, account creation incentives). Users logged-in mają 95%+ consent acceptance. Strategia: premium content / discounts za account creation = high-value first-party data, niezależna od consent.

Wzorzec 6: Audit log consent events

Każda zmiana consent state logowana do dedicated endpoint (BigQuery, Snowflake). Przydatne dla: (a) compliance audytu, (b) reconstruction consent history dla konkretnego user (RODO prawo do informacji), (c) debugging issues z consent. Retention: 3-5 lat zgodnie z prawem.

Timeline wdrożenia Consent Mode v2

Tydzień 1: Audit i planowanie

Audit obecnych tagów i cookies na stronie.
Identyfikacja wszystkich „marketing” vs „essential” cookies.
Decyzja wybór CMP.
Legal review planu z DPO lub prawnikiem.

Tydzień 2: CMP setup

Instalacja CMP na stronie.
Konfiguracja categorie cookies w CMP dashboard.
Customization banner design (zgodnie z brand guidelines).
Translation banner dla obsługiwanych języków.

Tydzień 3: GTM integracja

Consent Mode default tag.
Consent Mode update integration z CMP.
Tag Consent Settings per każdy tag Google.
Advanced mode parameters (url_passthrough, ads_data_redaction).

Tydzień 4: Testing i rollout

Testing wszystkich scenariuszy (accept, reject, partial, no-interaction).
Tag Assistant validation.
Staged rollout (10% → 50% → 100% traffic).
Monitoring first 7 days: consent rate, attribution impact, errors.

Miesiąc 2-3: Optymalizacja

A/B test banner copy dla wyższego acceptance.
Dodatkowe platformy (Meta, LinkedIn) integrated with CMP.
Advanced modeling monitoring w Google Ads.
Documentation dla zespołu.

Kontynuacja: bieżący monitoring

Miesięczny raport consent rate dla marketing manager’a.
Kwartalny audit: czy nowe tagi dodane mają właściwe Consent Settings.
Roczny legal review: aktualizacje RODO, zmiany w wytycznych Google/Meta.
Upgrade CMP przy nowych wydaniach (szczególnie gdy Google dodaje nowe typy consent – historycznie co 12-18 miesięcy).
Aktualizacja RoPA przy każdej istotnej zmianie konfiguracji śledzenie’u.

Sygnały, że wdrożenie wymaga rewizji

Consent rate spada poniżej 30% – CMP banner UX require redesign.
Google Ads Diagnostics pokazuje consent errors – debugging wymagany.
Attribution discrepancy między platforms i GA4 > 30% – check Advanced mode setup.
Nowy produkt lub market entry z nowymi typami cookies – re-audit wymagany.
Skarga klienta / zgłoszenie do UODO — natychmiastowy audyt techniczny i legal review.
Zmiana CMP providera – pełna rewalidacja implementacji, testing wszystkich scenariuszy.
Aktualizacja przeglądarek (Safari ITP, Firefox ETP) może wpływać na cookie persistence – monitoring po każdej major update, szczególnie przy przełomach jak Chrome deprecation third-party cookies w 2024-2025.
Zmiany regulacyjne na poziomie EU (np. nowe wytyczne EDPB dotyczące Consent Mode albo interpretacje krajowych organów jak polski UODO) – review całości dokumentacji technicznej oraz polityk prywatności w ciągu maksymalnie 30 dni roboczych od daty publikacji oficjalnych wytycznych regulatora europejskiego lub krajowego.

FAQ

Czy Consent Mode v2 zastępuje cookie banner?

Nie. Consent Mode v2 to mechanism pośredniczący między CMP a Google tags. Nadal potrzebujesz CMP (Cookiebot, OneTrust, Iubenda) dla banner. Consent Mode integruje to z Google Ads / Analytics.

Czy Consent Mode v2 jest wymagany poza EU?

Technicznie nie, ale wielu klientów z EU mimo wszystko wymaga pełnej CMv2 compliance. Dla globalnych marek lepiej wdrożyć CMv2 w całej infrastrukturze + geo-targeting banner (banner pokazuje się tylko w EU). Dla US/CA — osobne regulacje (CCPA, CPRA), podobne idee ale inne typy consent.

Ile kosztuje wdrożenie?

CMP: 15-200 EUR/mies. Developer time: 4-8 godzin (dla standard setup), 20-40 godzin (advanced + multi-domain). Legal review: 2-5k PLN. Total start-up: 4-15k PLN + 100-300 PLN/mies running cost dla mid-size firmy.

Czy można wdrożyć bez CMP?

Technicznie tak (własny banner + własna logic consent), ale nie rekomendowane. CMP dostarczają: legal compliance (aktualizowane z regulacjami), geo-targeting, A/B testing, audit trail. DIY banner to wysokie ryzyko non-compliance.

Co jeśli user nie interagował z banner?

Default consent state (zwykle denied dla EU). Tags fires w Basic mode (nie fires) lub Advanced mode (cookieless ping). Banner pozostaje na stronie — user zobaczy go ponownie, eventually wybierze. Nie można „skrywać” banner dla nie-interagujących.

Czy Meta Pixel potrzebuje osobnej integracji?

Tak. Google Consent Mode v2 nie kontroluje Meta Pixel. Dla Meta: własny consent signal przez fbq('consent', 'revoke') i fbq('consent', 'grant'). Większość CMP (Cookiebot, OneTrust) wspierają Meta natywnie.

Ile attribution tracimy przez Consent Mode v2?

W Basic mode: proporcjonalnie do denial rate (50% denied = 50% attribution loss). W Advanced mode z konwersja modeling: 10-20% loss przy 50% denied. Advanced mode wyraźnie lepszy dla firm z wolumenem > 1000 konwersje/mies.

Co dalej

Consent Mode v2 nie jest opcjonalny — to warunek legalnie działającej kampanii Google Ads w EU. Zaniedbanie = zablokowane kampanie, brak attribution, ryzyko kar. Pierwsze kroki: (1) wybierz Google-certified CMP (Cookiebot, Iubenda, OneTrust), (2) wdróż w GTM Consent Mode default + update flow, (3) aktywuj Advanced mode z url_passthrough i ads_data_redaction, (4) testuj wszystkie scenariusze (accept, reject, partial), (5) monitoruj consent rate w pierwszym miesiącu, optymalizuj banner copy.

Powiązane aspekty: architektura GTM jako fundament, server-side GTM (wzmacnia Consent Mode przez first-party śledzenie), GA4 dla zaawansowanych (pełna analityka kompatybilna z CM v2). Pełny obraz w pilarze analityka marketingowa 2026. Consent Mode v2 + sGTM + Enhanced Konwersje to „święta trójca” nowoczesnej analityki 2026 — bez nich tracisz attribution, compliance i ROI reklam.

GTM a RODO: Consent Mode v2 w praktyce