googletagmamager

Google Tag Manager, calul troian pentru echipele de marketing

Google Tag Manager este un TMS (Tag Management System): permite echipelor de marketing să adauge trackere la un site web sau o aplicație, fără a fi nevoie să treacă prin dezvoltatori. Prin intermediul unei interfețe web, aceste echipe pot decide:

  • Următoarele care urmează să fie declanșate (analitice, testare A/B, atribuire etc.).
  • Condiții de declanșare (categorii de pagini, caracteristici utilizator etc.).
  • Datele care urmează să fie transmise acestor instrumente terțe (caracteristicile utilizatorului, date de navigare, variabile prezente pe pagină etc.).

Nu este singurul (putem cita de exemplu Segment , francezul TagCommander sau Matomo Tag Manager ) dar Google Tag Manager este ultra dominant:

gtm

Google Tag Manager este prezent pe 31,9% din primele 10 milioane de site-uri Alexa, conform W3Techs , dar mai ales Google Tag Manager are o cotă de piață de 99,4% pe TMS (!)

Cum a reușit Google să se impună din nou? Ca și în cazul Google Analytics, versiunea standard a Google Tag Manager este gratuită (soluțiile de piață sunt în general plătite), este foarte bine integrată cu alte soluții Google și este bine făcută.

Trackere care nu mai sunt apelate din browser

În august anul trecut, Google a anunțat o nouă versiune a Google Tag Manager , numită Server-Side Tagging. Iată o diagramă de la Google pentru a explica cum funcționează Google Tag Manager în versiunea de etichetare pe partea clientului (versiunea „istoric”):

gtm2

Managerul de etichete Google va permite declanșarea diferitelor instrumente de urmărire terță parte (pe diagramă: Google Analytics, Google Ads și un instrument de analiză), direct în browser.

În noua versiune Server-Side , instrumentele de urmărire terță parte nu mai sunt rulate din browser, ci de pe un server „ Proxy ” numit „Container server” din diagrama de mai jos (și găzduit de Google):

gtm3

Biblioteca javascript (numită „Container web Tag Manager” în diagramă) este întotdeauna rulată pe browser pentru a colecta interacțiunile și datele dumneavoastră personale, dar execuția diferitelor trasoare terță parte are loc pe partea de server.

Rețineți că această nouă versiune se aplică și aplicațiilor și colectării de date „offline” (pentru transmiterea achizițiilor din magazin, de exemplu):

gtm4

Diagrama blogului lui Simo Ahava : pe partea de server, „Clienții” sunt acolo pentru a traduce cererile HTTP primite în „evenimente”, „Tag-urile” reacționează la aceste evenimente pentru a trimite „hituri” companiilor de marketing terțe.

Această logică de declanșare a instrumentelor de urmărire terță parte pe partea serverului schimbă jocul. Simo Ahava a detaliat diferitele impacturi într -un articol excelent , din partea mea voi rezuma avantajele și mă voi concentra pe problemele legate de confidențialitatea dvs. (operarea pe partea de server vă poate permite să ocoliți alegerile dvs. și să vă scurgeți datele personale, fără a fi demascat ).

Experiență de utilizator mai bună

Pe majoritatea site-urilor web, numărul de biblioteci javascript încărcate de terți (pentru analize, publicitate, testare A/B etc.) este impresionant. Încărcarea și rularea acestor biblioteci este adesea cauza principală a unei experiențe proaste a utilizatorului: încetinirea site-ului și lipsa de interactivitate.

Consecințe pentru site-urile web care oferă o experiență de utilizator proastă: utilizatorii de internet mai puțin mulțumiți, care vor abandona direct navigarea sau nu se vor mai întoarce.

Iată un exemplu cu Le Bon Coin, care numește un număr nenumărat de biblioteci javascript :

gtm5

O mică parte din scripturile javascript numite pe pagina principală a Le Bon Coin, aceasta vă scurge datele personale către multe terțe părți .

În cel mai bun caz, site-ul web va instala o singură bibliotecă javascript (evenimentele pot fi foarte diferite între instrumente care nu au aceleași scopuri, site-ul web va folosi uneori mai mult de o singură bibliotecă). Acesta ar putea fi cel al Google Tag Manager dar nu neapărat: este posibil să-ți creezi propria bibliotecă sau să folosești alte biblioteci de pe piață precum Snowplow , Matomo , AT Internet etc.

Apoi instruiește această bibliotecă să trimită „hit-urile” cu parametrii necesari în timpul interacțiunilor cheie. Apoi „clientul” containerului de server va trebui să traducă aceste „hituri” în evenimente, acestea vor fi citite de „Tag-uri” care vor trimite „hituri” companiilor de marketing terțe. Rețineți că, dacă biblioteca javascript instalată pe site este furnizată de Google, „clientul” este deja preconfigurat în Google Tag Manager. Dacă site-ul web folosește o altă bibliotecă, va trebui să-și creeze propriul „client” în Google Tag Manager ( de exemplu cu AT Internet ), în timp ce așteaptă să aibă „clienți” preconfigurați pentru principalele biblioteci de urmărire javascript.

Avantaj prin urmare: pe site este instalată o singură bibliotecă de urmărire javascript și un singur „flux” de date din browser, utilizatorul ar trebui să vadă diferența.

Control mai bun asupra datelor transmise terților

Având un „proxy” pe partea serverului face posibilă controlul datelor transmise către terți (ceea ce este mult mai dificil atunci când trackerele sunt executate direct de browserul utilizatorului):

  • În mod implicit și spre deosebire de versiunea „partea client”, adresa IP și User-Agent (nume browser, versiune, sistem de operare, limbă etc.) ale utilizatorului nu se scurg (ceea ce evită identificarea utilizatorului prin „ amprentare ”). Editorul care utilizează versiunea de etichetare pe server a Managerului de etichete Google poate decide să transmită aceste informații către terți, dar acest lucru nu este automat.
  • Se întâmplă adesea ca informațiile personale să fie scurse către terți prin intermediul parametrilor URL (citiți, de exemplu, articolul „ Google Tag Manager Server-Side – How To Manage Custom Vendor Tags ”), Etichetarea Server-Side face posibilă evitarea acestui lucru.
  • În general, editorul deține controlul asupra datelor cu caracter personal și asupra cookie-urilor trimise de „proxy-ul” său către terți (citiți documentația tehnică Google , rețineți de exemplu metodele get_cookies și set_cookies). Prin urmare, poate „curăța” informațiile și trimite către terți doar ceea ce este strict necesar.

gtm6

Exemplu cu un acces AT Internet „văzut” de către serverul „proxy”, site-ul web poate decide să nu transmită adresa IP a utilizatorului și User-Agent către AT Internet.

Un site web mai sigur

Configurarea unei politici de securitate a conținutului (CSP) permite unui editor să se protejeze mai bine împotriva diferitelor tipuri de amenințări, inclusiv atacuri XSS ( Cross-Site Scripting) și injecții de conținut. Prin adăugarea unui antet la răspunsurile de pe serverul web, site-ul poate indica browserelor ce resurse (scripturi, css etc.) sunt permise.

Iată un exemplu de CSP documentat de Google :

Politica de securitate a conținutului: script-src „self” https://apis.google.com.

Aceasta înseamnă: browserul are voie doar să execute scripturi care vin direct de pe site-ul consultat (‘ self ‘) sau de pe apis.google.com . Și iată cum va reacționa browserul dvs. dacă un script rău intenționat încearcă să ruleze de pe site-ul vizitat:

gtm7

Scriptul evil.js nu este găzduit pe site-ul vizitat și nici pe apis.google.com: execuția lui este blocată de browser.

Prin reducerea semnificativă a domeniilor terță parte permise să execute cod javascript, CSP-ul devine mai robust.

În timp ce etichetarea pe server are avantaje pentru utilizatorii care își dau consimțământul pentru supravegherea marketingului (viteză, securitate), aceasta pune în pericol protecția utilizatorilor fără consimțământ.

O ocolire a protecției browserului

Serverul „proxy” este găzduit în cloud-ul Google ( instanță App Engine ), dar Google recomandă să conecteze domeniul App Engine la un subdomeniu al site-ului clienților săi (fără a explica motivele):

Implementarea implicită de etichetare pe server este găzduită pe un domeniu App Engine. Vă recomandăm să modificați implementarea pentru a utiliza un subdomeniu al site-ului dvs. web.

gtm8

Legătura dintre domeniul App Engine și subdomeniul clientului, documentată de Google .

Google nu recomandă o înregistrare DNS de tip CNAME (alias), ci o înregistrare DNS de tip A sau AAAA , direct legată de adresele IP ale Google App Engine, care acționează ca o gazdă. Serverul „proxy” este, prin urmare, bine considerat de către browsere ca fiind prima parte, iar consecințele sunt, prin urmare, importante.

În special, cookie-urile depuse de serverul „proxy” nu sunt cookie-uri de la terți, nici cookie-uri create prin javascript, nici cookie-uri depuse de un domeniu CNAME. Prin urmare, sunt autorizați, fără restricții:

  • Safari prin Intelligent Tracking Prevention (ITP) limitează durata de viață a cookie-urilor create în javascript la 7 zile (exemplu: cookie-uri primare create de Google Analytics). Datorită serverului „proxy”, plotterele terțe depășesc acum această limitare.
  • Always Safari via ITP limitează acum cookie-urile plasate prin intermediul unui domeniu CNAME la 7 zile . Datorită serverului „proxy”, trasoarele terțe nu sunt afectate de această limitare.
  • Brave , din partea sa , blochează cererile CNAME către urmăritorii cunoscuți . Din nou, datorită serverului „proxy”, trasorii terți evită această blocare.

O ocolire a blocatorilor de reclame

Blocatorul de anunțuri (uBlock Origin pe Firefox de exemplu), blocarea conținutului ( Firefox Focus sau Adguard pe iOS, de exemplu) sau blocarea DNS ( NextDNS de exemplu) funcționează pe dispozitivul dvs. Astfel, poate detecta instrumente de urmărire terțe și le poate bloca înainte ca datele dvs. personale să se scurgă.

Nimic din toate acestea cu versiunea Server-Side Tagging a Google Tag Manager: scurgerile de date personale au loc de la serverul proxy al clientului (găzduit în cloudul Google) către terți. Nu mai ai mana sa eviti aceste scurgeri.

Ai putea să-ți spui: doar blochează primul apel, cel al browserului tău către biblioteca javascript însărcinată cu colectarea datelor și comunicarea către serverul „proxy”. Cu excepția faptului că această bibliotecă javascript poate fi foarte bine accesibilă pe domeniul site-ului web (și nu pe un domeniu Google de exemplu). De asemenea, Google își sfătuiește deja clienții să-și schimbe scripturile gtag.js pentru a intra în domeniul serverului proxy. Această manipulare face deja blocarea prin nume de domeniu inoperabilă.

Dacă gtag.js este un script javascript al cărui nume este cunoscut principalilor agenți de blocare a reclamelor, aceștia vor avea dificultăți în funcționarea atunci când numele bibliotecii javascript a fost schimbat sau când site-urile și-au creat propriile biblioteci.

uBlock Origin, eficient împotriva cloakingului CNAME pe Firefox , neputincios împotriva etichetării pe server?

Cum pot reacționa adblockerii? Subiectul nu este evident, iată câteva idei, dar nu sunt sigur că sunt fezabile:

  • Detectează automat aceste apeluri „prima parte” către serverul „proxy” prin intermediul parametrilor URL trimiși. Cu excepția faptului că acești parametri URL se vor schimba de la un site la altul, în funcție de biblioteca utilizată, de pagina vizualizată etc.
  • Detectați biblioteca javascript responsabilă pentru apelurile către serverul „proxy” pentru a bloca execuția acesteia. Cu excepția faptului că nu ar trebui să detectați pur și simplu biblioteca javascript oferită de Google, ci potențial toate bibliotecile de urmărire javascript, chiar și bibliotecile de acasă.
  • Blocați adresele IP ale acestor servere proxy. Doar că va fi necesar să găsiți manual miile de adrese IP din spatele acestor servere „proxy”, să le actualizați… Sau să decideți blocarea tuturor adreselor IP ale Google App Engine , cu riscul de a bloca multe aplicații. avand nimic de-a face cu urmarirea. Ca să nu mai vorbim că Google ar putea decide să deschidă serverul „proxy” către alte gazde.
  • Nu rulați niciodată javascript în browser, de exemplu cu extensia NoScript , configurată drastic. Opțiune eficientă, cu excepția faptului că multe site-uri nu vor mai funcționa.

Scăpați de datele dumneavoastră personale în cea mai totală opacitate

În timp ce astăzi multe site-uri web vă scurg datele personale, adesea fără consimțământul dvs., este încă posibil să auditați site-urile, să dovediți încălcarea consimțământului și să documentați scurgerile. CNIL ar putea, de exemplu, să-și facă treaba și să sancționeze greșelile. Nimic din toate acestea, cu etichetarea pe server, un site poate acum foarte ușor:

  • Dați o aparență de consimțământ, permițându-vă să răspundeți la un banner de consimțământ.
  • În timp ce vă scurgeți datele personale către mai mulți terți, fără ca un auditor extern să poată realiza acest lucru (va vedea pur și simplu apelul „prima parte” către server „proxy”, fără a ști dacă datele personale sunt folosite, partajate sau vândute in spate).

Datele dvs. în cloudul Google

În mod implicit, serverul „proxy” înregistrează toate solicitările pe care le primește :

În mod implicit, App Engine înregistrează informații despre fiecare cerere (de exemplu, calea solicitării, parametrii de interogare etc.) pe care o primește.

Dar datele personale conținute în aceste interogări nu sunt singurele informații care se scurg către Google. Ca și în cazul cloaking-ului CNAME , cookie-urile asociate domeniului site-ului consultat sunt trimise către subdomeniul serverului „proxy”. Deci, dacă modulele cookie de sesiune sunt asociate cu domeniul site-ului (și nu cu un subdomeniu separat), acestea vor fi trimise în cloud-ul Google.

Acesta declară că datele găzduite pe cloud-ul său aparțin clientului și nu Google. Încă trebuie să ai încredere în Google.

Etichetarea pe server, probabil că va fi adoptată pe scară largă

Dacă soluțiile Server-Side există pe piață de mult timp și dacă a fost deja posibil să vă dezvoltați propriul „proxy”, lansarea soluției Google va avea probabil un impact uriaș asupra adoptării Server-Side Tagging :

  • Google Tag Manager este prezent pe un număr considerabil de site-uri web, este ultra-dominant.
  • Google prezintă această versiune ca o evoluție a instrumentelor TMS, îmbunătățind performanța și securitatea site-urilor web.

Chiar dacă un client Google Tag Manager poate continua să utilizeze versiunea Client-Side, chiar dacă versiunea Server-Side are încă limite (puține biblioteci terță parte, unele soluții vor avea dificultăți să fie acceptate etc.), chiar dacă învățarea soluția este complexă și chiar dacă dă roade (da, trebuie să plătiți factura Google App Engine pentru serverul „proxy”), putem, prin urmare, să pariăm că clienții Google Tag Manager vor migra treptat la această versiune.

Ocoliți blocatorii de anunțuri și alte protecții ale browserului, un punct de vânzare

După cum am văzut, Google nu explică motivul creării unui subdomeniu al site-ului web pentru serverul său „proxy”:

Implementarea implicită de etichetare pe server este găzduită pe un domeniu App Engine. Vă recomandăm să modificați implementarea pentru a utiliza un subdomeniu al site-ului dvs. web.

Nu are nevoie de el, ocolirile de protecție a browserului și a blocatorului de anunțuri au fost deja enumerate ca „beneficii” de multe publicații:

  • Etichetarea pe server în Managerul de etichete Google ” al lui Simo Ahava , articolul indică avantajul de a putea ocoli limitările Safari în ceea ce privește durata de viață a cookie-urilor javascript. Spre meritul său, autorul nu dorește să dea detalii despre faptul că Etichetarea pe server face posibilă ocolirea blocatorilor de anunțuri și indică faptul că colectarea datelor trebuie făcută după obținerea consimțământului.
  • Partea serverului GTM – Evoluția naturală pentru etichetarea dvs.? ” De la Converteo. Articolul enumeră avantajele de a putea ocoli limitările browserului, cum ar fi cele ale Safari și Firefox, precum și de a ocoli blocatorii de anunțuri.
  • Introducere în Google Tag Manager Server-side Tagging ”, de pe blogul Analytics mania. Și aici, soluțiile pentru limitările browserelor și a blocatorilor de anunțuri sunt enumerate ca beneficii.
  • Google introduce etichetarea pe server, vești bune? ” De Nicolas Jaimes pe JDN. Unghiul articolului este publicitatea și, prin urmare, ocolirea protecțiilor browserului este enumerată ca un beneficiu (deși pentru moment, lipsa bibliotecilor terțe înseamnă că etichetarea pe server rămâne complex de implementat).

Din păcate, este un pariu sigur că multe site-uri vor fi atrase și de aceste „beneficii”, pe lângă câștigurile de performanță, securitate și control. Incapacitatea de a audita site-urile web va fi, de asemenea, o mare pierdere pentru susținătorii confidențialității. Sperăm că browserele și blocatorii de anunțuri să găsească soluții pentru ca utilizatorii de internet preocupați de confidențialitatea lor să poată continua să se apere.

Manager de etichete Google

Cât de utilă a fost această pagină ?

Faceți click pe stele pentru evaluare!

Rata medie / 5. Voturi:

Niciun vot până acum, evaluează pagina !