Consent Mode v2 + CMP (EEA): pilnas gidas 2025

Publikavimo data: 2025-09-30

Turinys

• Suprantamai trumpai
• Teisinis kontekstas: kodėl to reikia
• Kas yra Consent Mode v2 ir kaip jis veikia
• Ekosistema: CMP ↔ GTM ↔ GA4/Ads ↔ sGTM
• Signalai ir būsenos (analytics/ad/ad_user_data/ad_personalization)
• Diegimas per GTM (web): žingsnis po žingsnio
• CMP pasirinkimas ir TCF 2.2
• Palyginimas: CMP funkcijų kontrolinis sąrašas
• Server-side GTM: sutikimų perdavimas į serverį
• Feed ir duomenų žymėjimas (1P signalai)
• 1P auditorijos ir privatumas
• GA4, Google Ads ir modeliuojamos konversijos
• Banerių UX: priėmimo/atsisakymo dizainas ir A/B testai
• B2C ir B2B pavyzdžiai: architektūros šablonai
• QA ir diagnostika: įrankiai ir tipinės klaidos
• Ataskaitų naratyvas vadovybei
• Starto planas 30 d. + „Acceptance criteria“
• Mini case (skaičiais)
• DUK (7)
• Terminų žodynėlis
• Kur rasti daugiau informacijos

Suprantamai trumpai

Consent Mode v2 leidžia teisėtai matuoti, kai naudotojas neleido slapukų: GA4 ir Google Ads gauna cookieless pings, o trūkstami duomenys modeliuojami. CMP tvarko sutikimus (EEE/UK/CH — default=denied), GTM užtikrina teisingą įvykių tvarką (Consent Initialization → CMP → tag’ai), o sGTM praleidžia arba atmeta žymas pagal būseną. Praktikoje siekiame: Eligible for bidding = Yes Ads’e, EC match rate ≥ 50 %, stabilų modeled share ir aiškų A/B banerių poveikį CVR.

↩ Grįžti į turinį

Teisinis kontekstas: kodėl to reikia

EEE GDPR ir ePrivacy reikalauja aiškaus sutikimo nereikalingiems slapukams ir reklamos personalizavimui. UK GDPR ir Šveicarijos taisyklės artimos, bet banerių tekstų ir „reject all“ pateikimo niuansai gali skirtis. Cookie walls (priverstiniai sutikimai) paprastai neatitinka teisės — atsisakymas turi būti toks pat lengvas kaip priėmimas. CMP užtikrina atitiktį, o Consent Mode saugo KPI, nes leidžia modeliuoti konversijas be identifikatorių.

↩ Grįžti į turinį

Kas yra Consent Mode v2 ir kaip jis veikia

Kai sutikimo nėra, gtag/GTM siunčia anoniminius ping’us be slapukų. GA4 ir Ads remiasi agreguotais signalais ir statistiniais modeliais. Kai sutikimas duotas, įsijungia pilnas režimas: slapukai, identifikatoriai, Enhanced Conversions (EC). v2 versijoje pridėti ad_user_data (leidžia siųsti hash’intus PII Ads’ams) ir ad_personalization (leidžia remarketingą). Regionams taikykite EEE/UK/CH default=denied, kituose — pagal jūsų privatumo politiką.

↩ Grįžti į turinį

Ekosistema: CMP ↔ GTM ↔ GA4/Ads ↔ sGTM

• CMP (TCF 2.2 + AC) renka sutikimus, generuoja TCF string.
• GTM (web) pradeda nuo Consent Initialization, laukia CMP atnaujinimo, tada leidžia GA4/Ads tag’ams.
• GA4 / Google Ads vartoja sutikimo būsenas; be jų — modeled.
• sGTM gauna naršyklės būseną (pvz., X-Consent-State) ir praleidžia/atmeta tag’us, neįjungia remarketingo, jei ad_personalization=denied.

↩ Grįžti į turinį

Signalai ir būsenos (analytics/ad/ad_user_data/ad_personalization)

Signalai:
analytics_storage (GA4), ad_storage (Ads), ad_user_data (leidimas EC/PII), ad_personalization (remarketingas).
Būsenos: granted / denied. Rekomendacija: iki pasirinkimo — default=denied EEE/UK/CH.
Papildomai: TCF 2.2 string, Additional Consent (AC) Google tiekėjams.

↩ Grįžti į turinį

Diegimas per GTM (web): žingsnis po žingsnio

1. Consent Initialization tag (visose EEE/UK/CH):
   default=denied visiems 4 signalams.
2. Region rules: aptikite regioną ir taikykite default tik EEE/UK/CH.
3. CMP hook’ai: onAcceptAll() → visiems signalams granted; onRejectAll() → denied.
4. Consent checks: įjunkite „Require additional consent“ GA4/Ads tag’ams.
5. Eiliškumas: Consent Initialization → CMP update → GA4/Ads.
6. Debug: GA4 DebugView, Tag Assistant.

↩ Grįžti į turinį

CMP pasirinkimas ir TCF 2.2

Rinkitės Google-certified CMP su TCF 2.2 ir AC palaikymu, kelių kalbų, region targeting, A/B testais ir GTM šablonu. Patikrinkite GVL atnaujinimų dažnį, logų/eksporto galimybes, SDK programėlėms ir API. UX’e svarbiausia — simetriški „Priimti viską“ / „Atmesti viską“, aiškūs tikslai (analitika/reklama/reklamos duomenys/personalizavimas) ir paprasta kalba.

↩ Grįžti į turinį

Palyginimas: CMP funkcijų kontrolinis sąrašas

Komentaras (≈220 ž.): Praktikoje didžiausi skirtumai išryškėja tarp CMP, kurie turi tik teisinius minimumus, ir tų, kurie suteikia eksperimentavimo galimybes. Jei neturite A/B, būsite „įkalinti“ statiniame banerio variante ir negalėsite įrodyti, kad, pvz., apatinė juosta („bottom bar“) pakelia CVR, o modalas padidina teisinį aiškumą (didesnis atmetimas, bet daugiau pasitikėjimo). Region targeting kritiškas tarptautinėms svetainėms — default=denied turi galioti tik EEE/UK/CH. GTM šablonai ir hook’ai ženkliai mažina klaidų tikimybę, o logai/API leidžia integruoti sutikimų rodiklius į BI bei pasiruošti auditams. Jei turite programėles ar sGTM, reikalaukite oficialių SDK ir server-side gairių.

↩ Grįžti į turinį

Server-side GTM: sutikimų perdavimas į serverį

Perduokite būseną antraštėje (X-Consent-State) arba query parametru (consent_state=...). sGTM Client perskaito, Tag taisyklės pritaiko. Jei ad_user_data=denied — neperduokite EC (hash’intų el. paštų/telefonų). Jei ad_personalization=denied — nekurkite remarketingo auditorijų. Log’inkite atmetimus BigQuery/Cloud Logging.

↩ Grįžti į turinį

Feed ir duomenų žymėjimas (1P signalai)

Suderinkite web → sGTM → Ads/GA4 žemėlapį: įvykių ID (transaction_id/lead_id), vertė, valiuta, produktai, ir sutikimo būsena. Telefoną formatuokite E.164, el. paštą lowercase/trim. „Offline Conversions“ per Google Ads API naudokite tik su aiškiu teisiniu pagrindu ir ad_user_data=granted.

↩ Grįžti į turinį

1P auditorijos ir privatumas

1P (first-party) auditorijos remiasi jūsų duomenimis (CRM, el. prekyba, el. paštas). Jos veiksmingos tik su sutikimu: rinkite pasirinkimus formose („Noriu gauti personalizuotą reklamą“), aiškiai įtraukite į Privacy Policy, leiskite pakeisti nustatymus futeryje. Remarketingas be ad_personalization=granted — negalimas.

↩ Grįžti į turinį

GA4, Google Ads ir modeliuojamos konversijos

GA4 rodo observed + modeled; DDA (duomenimis pagrįsta atribucija) geriau suvaldo dalinius signalus. Google Ads optimizuoja pagal pasirinktą konversijų šaltinį — venkite dublikatų (Ads tag + GA4 importas tam pačiam įvykiui). Siekite: EC match rate ≥ 50 %, Eligible for bidding = Yes, stabilaus modeled share. Eksperimentuokite ON/OFF arba geo, kad įvertintumėte architektūros įtaką.

↩ Grįžti į turinį

Banerių UX: priėmimo/atsisakymo dizainas ir A/B testai

Naudokite paprastą kalbą, simetriškus mygtukus („Priimti viską“ / „Atmesti viską“), aiškų „Tinkinti“. Testuokite modalą prieš apatinę juostą: modalas dažnai mažina accept%, bet didina aiškumą; juosta gali kelti CVR. Lokalizuokite kalbą (LT/EN/PL) — dažnai pagerėja accept% ir sumažėja atmetimų.

↩ Grįžti į turinį

B2C ir B2B pavyzdžiai: architektūros šablonai

• B2C e-komercija: CMP (TCF 2.2) → GTM (default=denied) → GA4/Ads su Consent checks → sGTM su consent header → EC tik granted atveju → A/B banerių testai → Ads Diagnostics.
• B2B lead’ai: Formose atskiri sutikimai (analitika/reklama), Offline Conversions per Google Ads API tik ad_user_data=granted, CRM laukų normalizavimas, gclid/gbraid/wbraid perlaikymas teisėtai.

↩ Grįžti į turinį

QA ir diagnostika: įrankiai ir tipinės klaidos

Triage (greita diagnostika)

1. Ads Diagnostics → „Eligible for bidding?“ Jei No → tikrinkite Consent Initialization, region rules, CMP hook’us.
2. GA4 DebugView → ar matosi consent parametrai/įvykiai? Jei ne — neveikia hook’ai.
3. EC match rate < 40 % → normalizavimas (lowercase/trim/E.164), ad_user_data būsena.
4. Deduplikacija → jei Ads tag + GA4 importas to paties įvykio — palikite vieną šaltinį.

Dažniausi incidentai ir sprendimai
A) Ads „Limited by consent“ → sutvarkykite hook’us, įjunkite Consent checks, pažymėkite anotaciją.
B) EC match rate < 30 % → normalizavimas, test purchase su DebugView/Tag Assistant.
C) sGTM negerbia sutikimo → perduokite X-Consent-State, įdiekite taisykles, log’inkite atmetimus.
D) Dublikuotos konversijos → vienas optimizacijos šaltinis, dedupe pagal ID.

↩ Grįžti į turinį

Ataskaitų naratyvas vadovybei

Hipotezė: Consent v2 + EC stabilizuoja modeled share ir Ads sprendimus.
Eksperimentas: „Prieš/po“ su anotacijomis ir pastoviu media miksu 2–4 sav.
Matavimas: GA4 Model comparison (DDA vs. Last), Assisted, modeled share, Ads Diagnostics statusai.
Rezultatas: ROAS/CPA gerėja, kelio ilgis trumpėja, „Eligible for bidding“ → Yes.
Sprendimas: Palikti architektūrą nuolat, tobulinti EC/1P signalus, plėsti video/UGC.

↩ Grįžti į turinį

Starto planas 30 d. + „Acceptance criteria“

1 savaitė — Architektūra ir atitiktis
Google-certified CMP (TCF 2.2 + AC), banerio tekstai ir kalbos; GTM default=denied EEE/UK/CH; atnaujintos politikos.

2 savaitė — Implementavimas ir signalai
CMP ↔ GTM (Template + hook’ai), GA4/Ads su Consent checks, sGTM perdavimas, EC validacija (match rate).

3 savaitė — Diagnostika ir UX
GA4 DebugView, Ads Diagnostics; banerio A/B (modal vs. bar, tekstai); anotacijos.

4 savaitė — Ataskaita ir sprendimai
„Prieš/po“: modeled share, ROAS/CPA, Assisted, kelio ilgis; sprendimas dėl nuolatinės architektūros.

Acceptance criteria

• CMP įdiegtas (TCF 2.2 + AC), A/B startuotas;
• GTM Consent Initialization + region rules veikia;
• EC match rate ≥ 50 %, Eligible for bidding = Yes;
• Ataskaita su modeled share, ROAS/CPA, Assisted, anotacijomis.

↩ Grįžti į turinį

Mini case (skaičiais)

Situacija: LT e-komercija, ~2000 užsakymų/mėn., daug srauto iš PMax ir social.
Veiksmas: įdiegtas CMP (TCF 2.2), GTM default=denied EEE/UK/CH, EC tik ad_user_data=granted, sGTM su X-Consent-State, A/B: modal vs. bar.
Rezultatas (4 sav.): accept% −8 p. p. (modal), modeled share +6 p. p., EC match rate 34 % → 56 %, Ads Eligible → Yes, ROAS +11 %, CVR +4 %.
Išvada: mažesnis accept% kompensuotas EC+modeled; bar versija vėliau viršijo modalą pagal CVR.

↩ Grįžti į turinį

DUK (7)

1) Ar galiu rodyti remarketingą be sutikimo?
Ne. Remarketingas priklauso nuo ad_personalization. Jei būsena denied, auditorijos nekuriamos, net jei fiksuojate įvykius be slapukų. Praktikoje tai reiškia, kad matysite dalį modeled konversijų, bet asmeninio pritaikymo veiksmų atlikti negalėsite. Sprendimas — sąžiningas banerio dizainas (aiškūs mygtukai, paprasta kalba), region targeting ir tinkamas „Customize“ sluoksnis, kad naudotojas galėtų pasirinkti atskiras kategorijas, įskaitant personalizavimą.

2) Ar modeliuojamos konversijos yra „tikros“?
Tai statistiniai įverčiai, paremti agreguotais signalais ir panašių sesijų elgsena. Jos nepakeičia realių identifikuotų įvykių, bet užpildo spragas, kad sprendimai nebūtų „akli“. Vadovybei rekomenduokite žiūrėti modelių palyginimą (GA4) ir daryti incrementality eksperimentus (geo arba laikai), kad patvirtintumėte architektūros įtaką ROAS/CPA. Dokumentuokite starto datą su anotacijomis, kad matytųsi pokyčių kontekstas.

3) Ar reikia server-side GTM?
Ne visada. sGTM suteikia stabilumą, mažina klientinės pusės „triukšmą“, leidžia centralizuotai valdyti PII ir atmest žymas pagal sutikimus. Jei srautas didelis, daug integracijų ir reikia logų, sGTM bus privalumas. Mažesnėms svetainėms galima pradėti be sGTM, tačiau iškart suplanuoti, kaip perduosite sutikimo būseną ateityje (pvz., X-Consent-State).

4) Ką daryti skirtingose rinkose (EEE vs. ne EEE)?
EEE/UK/CH taikykite default=denied, o kitur — pagal privatumo politiką, laikydamiesi vietinių taisyklių. „Reject all“ turi būti lygiai toks pat lengvas kaip „Accept all“. Jei esate globalūs, rinkitės CMP su region targeting ir kalbomis (LT/EN/PL ir kt.). Testuokite su VPN: ar banerio elgsena skiriasi pagal šalį, ar teisingai taikomos taisyklės ir ar fiksuojamas TCF string.

5) Ar Enhanced Conversions veiks be sutikimo?
Ne. EC priklauso nuo ad_user_data. Jei ši būsena denied, hash’inti el. paštai/telefonai neturi būti siunčiami. Prieš diegiant EC, sutvarkykite normalizavimą (lowercase, trim, E.164) ir įrašykite tai Privacy Policy. GA4/Ads diagnostikoje stebėkite match rate: <40 % rodo duomenų kokybės ar sutikimų problemą.

6) Kaip greitai patikrinti, ar viskas veikia?
Naudokite GA4 DebugView (ar ateina consent parametrai?), Tag Assistant (ar tvarka: Consent Init → CMP → tag’ai?), Ads Diagnostics („Eligible for bidding?“). Darykite test purchase/lead su aiškiai žinoma sutikimo būsena, užrašykite rezultatą ir palyginkite su EC match rate. Jei turite sGTM, įsiveskite žurnalus (leidimų/atmestų įvykių skaitiklius) ir kelkite į BigQuery.

7) Ar „Atmesti viską“ mažins ROAS?
Trumpuoju laikotarpiu — taip, nes mažiau identifikatorių. Tačiau modeled share + EC/Offline Conversions dažnai kompensuoja kritimą. Fokusas — UX (aiškus tekstas, lokalizacija), A/B testai (modal vs. bar) ir duomenų kokybė (EC normalizavimas). Rodikliai vadovybei: modeled share %, EC match rate, Eligible for bidding, ROAS/CPA ir kelio ilgis.

↩ Grįžti į turinį

Terminų žodynėlis

AC (Additional Consent) — papildomas leidimų mechanizmas Google tiekėjams.
DDA (Data-Driven Attribution) — duomenimis pagrįstas atribucijos modelis GA4.
E.164 — tarptautinis telefono numerių formatas.
EC (Enhanced Conversions) — hash’intų PII (el. paštas/telefonas) siuntimas Ads’ams su sutikimu.
EEE — Europos ekonominė erdvė.
GVL (Global Vendor List) — IAB tiekėjų sąrašas TCF ekosistemoje.
sGTM — server-side „Google Tag Manager“.
TCF 2.2 — IAB „Transparency & Consent Framework“ versija.
Modeled share — modeliuojamų konversijų dalis GA4 ataskaitose.
Eligible for bidding — Ads diagnostikos statusas, rodantis, kad konversijos tinkamos siūlymams.

↩ Grįžti į turinį

Atsakomybės apribojimas

Šis gidas yra edukacinis. Teisiniai reikalavimai ir platformų politikos keičiasi; sprendimai gali skirtis pagal jurisdikciją, industriją, duomenų praktiką ir techninę architektūrą. Prieš diegiant, atlikite teisinę peržiūrą, kontrolinius testus ir GA4 anotacijas.