Google Consent Mode v2 на практика: ред, сигнали и проверки

Повечето сайтове на малки фирми в Европа вече показват банер за бисквитки, а много от тях ползват и Google Analytics или Google Ads. Между двете стои Google Consent Mode, частта, която казва на таговете на Google какво е решил посетителят. Когато е настроен зле, нищо не изглежда счупено: банерът се появява, бутоните работят, отчетите се пълнят. Проблемите не се виждат. Таговете тръгват, преди посетителят да е избрал, завърнал се посетител, който е казал „да“, се брои като „не“, или „Отказвам всички“ така и не стига до рекламните тагове. Тук обясняваме как работи Consent Mode v2 на практика, в какъв ред трябва да става всичко и как да проверите собствения си сайт за пет минути. Това е техническо ръководство, а не правен съвет; за това какво изисква законът от малък сайт вижте ръководството ни за GDPR и бисквитките.

#Какво е Consent Mode и какво не е

Consent Mode е малък речник, който таговете на Google разбират. Сайтът ви казва на таговете за всяка цел дали съхраняването е „granted“ (разрешено) или „denied“ (отказано), а таговете променят поведението си. При отказан анализ Google Analytics не слага бисквитки. При отказана реклама Google Ads не слага рекламни бисквитки и не ползва посещението за персонализирани реклами.

Consent Mode не пита никого за нищо. Няма банер, не пази избор и не прави нищо за тагове, които не са на Google, например пиксел на Meta или скрипт за топлинни карти. Тях банерът ви трябва да задържи, докато посетителят се съгласи. Consent Mode е жицата между банера и Google; банерът си остава ваша работа.

#Седемте сигнала

Версия 2 има седем сигнала. Първите четири са най-важни:

• ad_storage: бисквитки за реклама;
• ad_user_data: дали данни за посетителя могат да се изпращат на Google за реклама;
• ad_personalization: дали посещението може да се ползва за персонализирана реклама, например ремаркетинг;
• analytics_storage: бисквитки за анализ, например продължителност на посещението;
• functionality_storage и personalization_storage: съхраняване за функции и предпочитания, например избран език;
• security_storage: съхраняване за сигурност, например срещу измами, което обикновено винаги е разрешено.

„v2“ в името се отнася до ad_user_data и ad_personalization. От март 2024 г. Google иска сайтовете, които ползват рекламните му функции за посетители от Европейското икономическо пространство, да ги изпращат; без тях тези функции спират да ползват данните. Банер, настроен преди 2024 г., често изпраща само старите два сигнала.

Прост банер с три категории се свързва с тях така: „Маркетинг“ управлява трите рекламни сигнала, „Анализ“ управлява analytics_storage, а „Предпочитания“ управлява двата сигнала за функции.

#Редът е всичко

Най-честата грешка е редът. Началното състояние трябва да бъде зададено, преди да се зареди който и да е таг на Google. Ако Google Analytics е вписан директно в заглавната част на темата, а скриптът на банера идва след него, първото извикване при всяко посещение тръгва, преди някой да е казал какво е разрешено.

Началното състояние стои вградено най-горе в <head>. То не бива да е „отказано за всички, винаги“: посетител, който вчера е приел анализа, трябва да се брои правилно още от първата си страница днес. Затова началното състояние първо чете запазения избор и чак тогава пада на „отказано“:

window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }

const stored = (() => {
  const m = document.cookie.match(/(?:^|; )consent=([^;]*)/);
  try { return m ? JSON.parse(decodeURIComponent(m[1])) : {}; } catch (e) { return {}; }
})();
const state = (on) => (on === true ? 'granted' : 'denied');

gtag('consent', 'default', {
  ad_storage: state(stored.marketing),
  ad_user_data: state(stored.marketing),
  ad_personalization: state(stored.marketing),
  analytics_storage: state(stored.analytics),
  functionality_storage: state(stored.preferences),
  personalization_storage: state(stored.preferences),
  security_storage: 'granted',
  wait_for_update: 500,
});

wait_for_update дава на банера до 500 милисекунди да изпрати промяна, преди вече чакащите тагове да продължат с началните настройки. Когато посетителят избере, банерът изпраща промяна със същите сигнали и добавя събитие, така че тригерите в Tag Manager, които зависят от съгласието, да тръгнат точно тогава:

function onChoice(choice) {
  gtag('consent', 'update', {
    ad_storage: state(choice.marketing),
    ad_user_data: state(choice.marketing),
    ad_personalization: state(choice.marketing),
    analytics_storage: state(choice.analytics),
    functionality_storage: state(choice.preferences),
    personalization_storage: state(choice.preferences),
  });
  dataLayer.push({ event: 'consent_updated' });
}

Пуснахме двете части със запазен избор „анализ да, маркетинг не“: началното състояние изпраща разрешен анализ и трите рекламни сигнала отказани, а по-късно „Приемам всички“ изпраща промяна с всички разрешени, последвана от събитието.

#Основен или разширен режим

Google описва два начина да се ползва всичко това:

• Основен режим (basic): таговете на Google изобщо не се зареждат, докато посетителят не се съгласи. Нищо не се изпраща на Google преди съгласието и нищо след отказ.
• Разширен режим (advanced): таговете се зареждат веднага с отказаните начални настройки. Докато съгласието е отказано, не слагат бисквитки, но изпращат сигнали без бисквитки, които Google ползва, за да моделира конверсии и посещения.

Разширеният режим дава по-пълни отчети; основният изпраща по-малко. Кой подхожда на сайта ви, е решение за вас и за този, който ви съветва за поверителността, а не технически детайл. Технически разликата е само в това дали самият таг на Google чака съгласие като всеки друг скрипт.

Две допълнителни настройки си струва да знаете. ads_data_redaction маха рекламните идентификатори от заявките, докато ad_storage е отказано. url_passthrough пренася идентификаторите на кликовете във връзките вместо в бисквитки, което някои сайтове с реклами искат, а други не.

#Как да проверите собствения си сайт

Отворете сайта в частен прозорец, с инструментите за разработчици на браузъра в раздела Network, и минете през този списък:

1. Преди да натиснете каквото и да е, напишете dataLayer в конзолата. Първият запис трябва да е началното състояние на съгласието, преди всеки запис config или gtm.js.
2. Погледнете заявките към Google Analytics (те отиват към адрес на google-analytics.com). Всяка носи параметър gcs със състоянието: G100 означава, че рекламното и аналитичното съхраняване са отказани, G111, че и двете са разрешени.
3. Проверете бисквитките в раздела Application. Когато нищо не е прието, не бива да има бисквитка _ga и рекламни бисквитки.
4. Натиснете „Отказвам всички“ и презаредете. Началните настройки трябва още да са отказани, а пиксели и топлинни карти не бива да се зареждат.
5. Приемете само анализа, презаредете и проверете дали още първата заявка носи разрешен анализ. Това е случаят със завърналия се посетител, който повечето настройки бъркат.
6. Оттеглете съгласието от връзката за настройки на банера. Бисквитките за анализ трябва да изчезнат, а не просто да спрат да се обновяват.

#Грешки, които виждаме при малките сайтове

• Таг в темата или във втори плъгин, който се зарежда преди началните настройки.
• Само двата стари сигнала, така че рекламните функции нямат съгласие за посетителите от ЕИП.
• „Отказвам всички“ е скрит във втори слой или е бледа връзка, а „Приемам всички“ е голям бутон.
• Пиксели и вградени видеа, които се зареждат независимо от избора, защото се приема, че Consent Mode ги покрива.
• Няма начин изборът да се промени по-късно, а бисквитките остават и след оттегляне.

#Банер, който го прави така

Вградихме тези правила в Biskvitka, банер за съгласие с бисквитките за сайтове на малки фирми, като плъгин за WordPress и като обикновен JavaScript за всеки друг сайт. „Отказвам всички“ стои до „Приемам всички“ и изглежда като него, а диалог позволява на посетителите да избират по цел. Началните настройки на Consent Mode се отпечатват първи в <head> според запазения избор на посетителя, а всеки избор изпраща промяна с шестте сигнала за целите и събитие за Tag Manager. Ако въведете идентификатор на Google Analytics или Tag Manager, той се зарежда веднага след началните настройки; ако предпочитате тагът на Google да чака съгласие, можете да го задържите като всеки друг скрипт. Другите тракери, вградените видеа и карти чакат, докато категорията им бъде разрешена, бисквитките на отказаните категории се изтриват, а дневник пази всеки избор без IP адреси. На английски и български е, тестван е с пълно изпълнение на WordPress 7.1.3 и с тестове в Chrome и е обявен като „Очаквайте скоро“.

#Често задавани въпроси

Прави ли Consent Mode сайта ми съобразен със закона?

Не. Той само предава избора на посетителя на таговете на Google. Пак ви трябват банер, който пита както трябва, скриптове, които чакат съгласие, и политика за бисквитките. Проверете задълженията си с човек, който ги познава.

Трябва ли ми Consent Mode, ако не ползвам Google Ads?

Ако ползвате Google Analytics или Tag Manager, Consent Mode е начинът те да научат за избора, затова си струва да го настроите. Ако не ползвате никакви тагове на Google, той не ви върши работа.

Защо посещенията ми намаляха след банера?

Защото посетителите, които откажат, вече не се броят с бисквитки. В разширения режим Google моделира част от разликата; в основния тези посещения просто не се измерват.

Къде трябва да е началното състояние, ако ползвам Tag Manager?

Или вградено в <head> преди кода на Tag Manager, както по-горе, или в таг с тригера Consent Initialization в Tag Manager, който тръгва преди всички останали.

#Източници

• Google: преглед на consent mode, основен и разширен режим
• Google: настройка на consent mode за уебсайтове