Best practice per tag e gestori tag

Katie Hempenius

Barry Pollard

Data di pubblicazione: 29 luglio 2021

I tag sono snippet di codice di terze parti che vengono inseriti in un sito, in genere con un Tag Manager. I tag vengono utilizzati più comunemente per il marketing e l'analisi.

Nota: sebbene i tag e gli script di terze parti siano spesso fondamentalmente la stessa cosa, la terminologia separata riflette i diversi modi in cui vengono utilizzati questi script. I tag sono in genere di proprietà dei reparti marketing e vengono aggiunti con i gestori dei tag, mentre gli script di terze parti si riferiscono comunemente alle risorse aggiunte tramite modifiche al codice apportate dai reparti di ingegneria.

L'impatto sul rendimento dei tag e dei gestori tag varia notevolmente da un sito all'altro. I Tag Manager possono essere paragonati a una busta: il Tag Manager fornisce un contenitore, ma il contenuto e il modo in cui lo utilizzi dipendono principalmente da te.

Qui discutiamo le tecniche per ottimizzare i tag e i Tag Manager per le prestazioni e i Core Web Vitals. Sebbene questo documento faccia riferimento a Google Tag Manager, molte delle idee discusse sono applicabili ad altri gestori di tag.

Impatto sui Core Web Vitals

I gestori dei tag possono spesso influire indirettamente sui Core Web Vitals utilizzando le risorse necessarie per caricare rapidamente la pagina e mantenerla reattiva. La larghezza di banda può essere utilizzata per scaricare il codice JavaScript di Tag Manager per i tuoi siti o per le chiamate successive che effettua. Il tempo di CPU sul thread principale può essere impiegato per valutare ed eseguire il codice JavaScript contenuto in Tag Manager e nei tag.

La metrica Largest Contentful Paint (LCP) è vulnerabile alla contesa della larghezza di banda durante il tempo di caricamento della pagina critico. Inoltre, il blocco del thread principale può ritardare il tempo di rendering dell'LCP.

Il Cumulative Layout Shift (CLS) può essere influenzato dal ritardo nel caricamento delle risorse critiche prima del primo rendering o dall'inserimento di contenuti nella pagina da parte dei Tag Manager.

Interaction to Next Paint (INP) è suscettibile alla contesa della CPU sul thread principale e abbiamo notato una correlazione tra le dimensioni dei gestori tag e punteggi INP peggiori.

Scegli il tipo di tag giusto

L'impatto dei tag sul rendimento varia in base al tipo di tag. In generale, i tag immagine ("pixel") sono i più efficienti, seguiti dai modelli personalizzati e, infine, dai tag HTML personalizzati. I tag dei fornitori variano a seconda della funzionalità che consentono.

Tieni presente che il modo in cui utilizzi un tag influisce notevolmente sul suo impatto sulle prestazioni. I "pixel" sono molto efficienti soprattutto perché la natura di questo tipo di tag impone restrizioni rigide sulle modalità di utilizzo. I tag HTML personalizzati non sono necessariamente sempre dannosi per le prestazioni, ma a causa del livello di libertà che offrono agli utenti, possono essere facilmente utilizzati in modo improprio, con un impatto negativo sulle prestazioni.

Quando pensi ai tag, tieni presente la scalabilità: l'impatto sul rendimento di un singolo tag potrebbe essere trascurabile, ma può diventare significativo quando vengono utilizzati decine o centinaia di tag sulla stessa pagina.

Non tutti gli script devono essere caricati con un Tag Manager

In genere, i Tag Manager non sono il modo migliore per caricare risorse che implementano aspetti visivi o funzionali immediati dell'esperienza utente, come avvisi sui cookie, immagini hero o funzionalità del sito. L'utilizzo di un Tag Manager per caricare queste risorse in genere ne ritarda la pubblicazione. Questo è negativo per l'esperienza utente e può anche aumentare metriche come LCP e CLS.

Inoltre, alcuni utenti bloccano i Tag Manager. L'utilizzo di un Tag Manager per implementare le funzionalità UX potrebbe causare il malfunzionamento del sito web per alcuni utenti.

Nota: Le richieste di risorse con un Tag Manager vengono in genere caricate più tardi rispetto alle richieste di risorse dirette. Se un Tag Manager viene utilizzato principalmente per fornire risorse non essenziali, questo ritardo può essere utilizzato in modo costruttivo fornendo un meccanismo per ritardare le richieste non essenziali.

Fai attenzione ai tag HTML personalizzati

I tag HTML personalizzati esistono da molti anni e sono ampiamente utilizzati nella maggior parte dei siti. I tag HTML personalizzati ti consentono di inserire il tuo codice con poche limitazioni, in quanto, nonostante il nome, l'utilizzo principale di questo tag è l'aggiunta di elementi <script> personalizzati a una pagina.

I tag HTML personalizzati possono essere utilizzati in molti modi diversi e il loro impatto sul rendimento varia in modo significativo. Quando misuri il rendimento del tuo sito, tieni presente che la maggior parte degli strumenti attribuisce l'impatto sul rendimento di un tag HTML personalizzato al gestore tag che lo ha inserito, anziché al tag stesso.

I tag HTML personalizzati possono inserire un elemento nella pagina circostante. L'inserimento di elementi nella pagina può essere una fonte di problemi di prestazioni e, in alcuni casi, causare anche variazioni del layout.

• Nella maggior parte dei casi, se un elemento viene inserito nella pagina, il browser deve ricalcolare le dimensioni e la posizione di ogni elemento della pagina. Questo processo è noto come layout. L'impatto sulle prestazioni di un singolo layout è minimo, ma quando si verifica in modo eccessivo può diventare una fonte di problemi di prestazioni. L'impatto di questo fenomeno è maggiore sui dispositivi di fascia bassa e sulle pagine con un numero elevato di elementi DOM.
• Se un elemento di pagina visibile viene inserito nel DOM dopo che l'area circostante è già stata sottoposta a rendering, può causare una variazione del layout. Questo fenomeno non è esclusivo dei gestori tag, ma poiché i tag vengono in genere caricati più tardi rispetto ad altre parti della pagina, è comune che vengano inseriti nel DOM dopo che la pagina circostante è già stata visualizzata.

Suggerimento: se aggiungi o modifichi contenuti visibili in una pagina, tieni presente che i motori di ricerca devono essere in grado di recuperare ed elaborare il codice JavaScript utilizzato. Per Google, puoi verificare il rendering della pagina per la Ricerca. Altri motori di ricerca potrebbero avere strumenti di test simili.

Utilizza modelli personalizzati

I modelli personalizzati supportano alcune delle stesse operazioni dei tag HTML personalizzati, ma sono basati su una versione di JavaScript in modalità sandbox che fornisce API per casi d'uso comuni come l'inserimento di script e pixel. Come suggerisce il nome, consentono a un utente esperto di creare un modello tenendo conto delle prestazioni. Gli utenti meno tecnici possono quindi utilizzare il modello. Spesso questa è un'opzione più sicura rispetto a fornire l'accesso completo all'HTML personalizzato.

A causa delle maggiori limitazioni imposte ai modelli personalizzati, è molto meno probabile che questi tag presentino problemi di prestazioni o sicurezza. Per questi stessi motivi, i modelli personalizzati non funzionano per tutti i casi d'uso.

Inserisci correttamente gli script

L'utilizzo di un Tag Manager per inserire uno script è un caso d'uso molto comune. Il modo consigliato per farlo è utilizzare un modello personalizzato e l'API injectScript.

Per informazioni sull'utilizzo dell'API injectScript per convertire un tag HTML personalizzato esistente, consulta Converti un tag esistente.

Se devi utilizzare un tag HTML personalizzato, ricorda:

• Le librerie e gli script di terze parti di grandi dimensioni devono essere caricati con un tag di script (ad esempio <script src="external-scripts.js">) che scarica un file esterno, anziché copiare e incollare direttamente i contenuti dello script nel tag. Sebbene la rinuncia all'utilizzo del tag <script> elimini un round trip separato per scaricare i contenuti dello script, questa pratica aumenta le dimensioni del contenitore e impedisce al browser di memorizzare lo script nella cache separatamente.
• Molti fornitori consigliano di inserire il loro tag <script> nella parte superiore di <head>. Tuttavia, per gli script caricati con Tag Manager, questo spesso non è necessario. Nella maggior parte dei casi, il browser ha già terminato l'analisi di <head> quando viene eseguito Tag Manager.

Utilizza i pixel

A volte, gli script di terze parti possono essere sostituiti con pixel di immagini o iframe. Rispetto alle controparti basate su script, i pixel potrebbero supportare meno funzionalità, quindi sono spesso considerati un'implementazione meno preferita. Tuttavia, se utilizzati all'interno di Tag Manager, i pixel possono essere più dinamici, in quanto possono attivarsi in base a trigger e trasmettere variabili diverse.

I pixel sono il tipo di tag più efficiente e sicuro perché non viene eseguito alcun codice JavaScript dopo l'attivazione. I pixel hanno una dimensione delle risorse molto ridotta (meno di 1 KB) e non causano variazioni del layout.

Per saperne di più sul supporto dei pixel, rivolgiti al tuo fornitore di terze parti. Inoltre, puoi provare a ispezionare il codice per trovare un tag <noscript>. Se un fornitore supporta i pixel, spesso li include nel tag <noscript>.

Alternative ai pixel

I pixel sono diventati popolari soprattutto perché un tempo erano uno dei modi più economici e affidabili per effettuare una richiesta HTTP in situazioni in cui la risposta del server non è pertinente ( ad esempio, quando si inviano dati ai fornitori di analisi). Le API navigator.sendBeacon() e fetch() keepalive sono progettate per soddisfare lo stesso caso d'uso, ma sono probabilmente più affidabili dei pixel.

Nota: le API sendBeacon() e fetch() keepalive continuano a funzionare quando il browser scarica la pagina. Ad esempio, entrambe queste API possono essere utilizzate per monitorare i clic sui link in uscita. Al contrario, tecniche come i pixel e XMLHttpRequest probabilmente non funzionerebbero in questi casi.

Non c'è nulla di male nel continuare a utilizzare i pixel, che sono ben supportati e hanno un impatto minimo sul rendimento. Tuttavia, se stai creando i tuoi beacon, vale la pena considerare l'utilizzo di una di queste API.

sendBeacon()

L'API navigator.sendBeacon() è progettata per l'invio di piccole quantità di dati ai server web in situazioni in cui la risposta del server non è importante.

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() ha un'API limitata: supporta solo l'invio di richieste POST e non supporta l'impostazione di intestazioni personalizzate. È supportato da tutti i browser moderni.

API Fetch keepalive

keepalive è un flag che consente di utilizzare l'API Fetch per effettuare richieste non bloccanti, come i report Eventi e i dati e analisi. Viene utilizzato includendo keepalive: true nei parametri passati a fetch().

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

Se fetch() keepalive e sendBeacon() sembrano molto simili, è perché lo sono. Infatti, nei browser Chromium, sendBeacon() è ora basato su fetch() keepalive.

Quando scegli tra fetch() keepalive e sendBeacon(), è importante considerare le funzionalità e il supporto del browser di cui hai bisogno. L'API fetch() è molto più flessibile, ma keepalive ha un supporto del browser inferiore rispetto a sendBeacon().

Scopri cosa fanno i tag

I tag vengono spesso creati seguendo le indicazioni fornite da un fornitore di terze parti. Se non è chiaro cosa fa il codice di un fornitore, chiedi a qualcuno che lo sa. Ottenere un secondo parere può aiutare a identificare se un tag ha il potenziale per creare problemi di prestazioni o sicurezza.

Ti consigliamo di etichettare i tag con un proprietario in Tag Manager. È facile dimenticare chi è il proprietario di un tag, il che porta alla paura di rimuoverlo nel caso in cui si rompa qualcosa.

Trigger

In generale, l'ottimizzazione degli attivatori dei tag consiste nell'assicurarsi di non attivare i tag più del necessario e nello scegliere un attivatore che bilanci le esigenze aziendali con i costi di rendimento.

Gli attivatori sono codice JavaScript che aumenta le dimensioni e il costo di esecuzione di Tag Manager. Sebbene la maggior parte dei trigger sia di piccole dimensioni, l'effetto cumulativo può essere significativo. Ad esempio, la presenza di più eventi di clic o attivatori timer può aumentare notevolmente il carico di lavoro di Tag Manager.

Scegli un evento di attivazione appropriato

L'impatto sul rendimento di un tag può variare. In generale, prima viene attivato un tag, maggiore è l'impatto sulle prestazioni. Le risorse sono in genere limitate durante il caricamento iniziale della pagina, pertanto il caricamento o l'esecuzione di una determinata risorsa (o tag) sottrae risorse ad altro.

Sebbene sia importante scegliere attivatori appropriati per tutti i tag, è particolarmente importante per i tag che caricano risorse di grandi dimensioni o eseguono script lunghi.

I tag possono essere attivati in base alle visualizzazioni di pagina (in genere Page load, su DOM Ready, su Window Loaded) o in base a un evento personalizzato. Per evitare di influire sul caricamento pagina, attiva i tag non essenziali dopo Window Loaded.

Utilizza gli eventi personalizzati

Utilizza gli eventi personalizzati per attivare i trigger in risposta agli eventi della pagina non coperti dai trigger integrati di Google Tag Manager. Ad esempio, molti tag utilizzano attivatori di visualizzazione di pagina. Tuttavia, il tempo che intercorre tra DOM Ready e Window Loaded può essere lungo, il che rende difficile ottimizzare il momento in cui un tag viene attivato. Gli eventi personalizzati possono essere una soluzione a questo problema.

Innanzitutto, crea un trigger evento personalizzato e aggiorna i tag per utilizzarlo.

Per attivare l'attivatore, esegui il push dell'evento corrispondente al livello dati.

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

Utilizza condizioni di attivazione specifiche

Definisci condizioni di attivazione specifiche per evitare di attivare i tag quando non è necessario. Uno dei modi più semplici ed efficaci per farlo è assicurarsi che un tag venga attivato solo nelle pagine in cui viene effettivamente utilizzato.

Le variabili integrate possono essere incorporate nelle condizioni di attivazione per limitare l'attivazione dei tag.

Attenzione: anche le condizioni di attivazione o le eccezioni complesse possono richiedere tempo di elaborazione. Evita di utilizzare troppe condizioni e condizioni complesse.

Carica il Tag Manager in un momento appropriato

Puoi migliorare il rendimento modificando il momento in cui viene caricato Tag Manager. Gli attivatori, indipendentemente dalla loro configurazione, non possono attivarsi fino a quando non viene caricato un Tag Manager. Sperimenta con il momento in cui carichi il Tag Manager, in quanto questo può avere un impatto uguale o maggiore. Questa decisione influisce su tutti i tag di una pagina.

Caricando Tag Manager in un secondo momento, puoi evitare futuri problemi di prestazioni, in quanto impedisci il caricamento involontario di un tag troppo presto.

Variabili

Utilizza le variabili per leggere i dati dalla pagina. Sono utili negli attivatori e nei tag stessi.

Come gli attivatori, le variabili aggiungono codice JavaScript a Tag Manager e, di conseguenza, possono causare problemi di prestazioni. Le variabili possono essere relativamente piccole, ad esempio un codice per leggere parti dell'URL, i cookie, il livello dati o il DOM. Possono anche includere codice JavaScript personalizzato con funzionalità (e dimensioni) illimitate.

Riduci al minimo l'utilizzo delle variabili, poiché vengono valutate continuamente da Tag Manager. Rimuovi le vecchie variabili che non vengono più utilizzate per ridurre sia le dimensioni dello script di Tag Manager sia il tempo di elaborazione che utilizza.

Gestione dei tag

L'utilizzo efficiente dei tag riduce il rischio di problemi di prestazioni.

Utilizza il livello dati

Il livello dati è un array JavaScript di oggetti che contengono informazioni sulla pagina. Questi oggetti contengono tutte le informazioni che vuoi trasmettere a Google Tag Manager.

Il livello dati può essere utilizzato anche per attivare i tag.

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

Sebbene Google Tag Manager possa essere utilizzato senza il livello dati, è vivamente consigliato. Il livello dati raggruppa i dati a cui possono accedere gli script di terze parti in un unico posto, offrendo così una migliore visibilità sul loro utilizzo. Tra le altre cose, questo può contribuire a ridurre i calcoli ridondanti delle variabili e l'esecuzione degli script.

Utilizzando un livello dati, puoi controllare a quali dati accedono i tag, anziché concedere l'accesso completo alle variabili JavaScript o al DOM.

I vantaggi in termini di prestazioni del livello dati potrebbero non essere intuitivi, dato che l'aggiornamento del livello dati comporta la rivalutazione di tutte le variabili del contenitore da parte di Google Tag Manager e la potenziale attivazione di tag, il che comporta l'esecuzione di JavaScript. Sebbene sia possibile utilizzare in modo improprio il livello dati, in generale, se il livello dati sembra essere la causa di problemi di prestazioni, è probabile che il contenitore stesso presenti problemi di prestazioni. Il livello dati rende questi problemi più evidenti.

Rimuovi i tag duplicati e inutilizzati

I tag duplicati possono verificarsi quando un tag è incluso nel markup HTML di una pagina, oltre a essere inserito tramite un Tag Manager.

I tag inutilizzati devono essere messi in pausa o rimossi anziché bloccati tramite l'utilizzo di un trigger di blocco. Se metti in pausa o rimuovi un tag, il codice viene rimosso dal contenitore, mentre se lo blocchi, il codice non viene rimosso.

Una volta rimossi i tag inutilizzati, esamina gli attivatori e le variabili per determinare se possono essere rimossi anche questi.

I tag in pausa influiscono sulle dimensioni del contenitore, ma il payload totale è inferiore rispetto a quando i tag sono attivi.

Utilizza le liste consentite e bloccate

Utilizza le liste consentite e bloccate per configurare limitazioni molto granulari sui tag, sugli attivatori e sulle variabili consentiti in una pagina. Questo può essere utilizzato per contribuire ad applicare le best practice per le prestazioni e altre policy.

Le liste consentite e bloccate vengono configurate tramite il livello dati.

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

Ad esempio, potresti impedire l'utilizzo di tag HTML personalizzati, variabili JavaScript o l'accesso diretto al DOM. Ciò significa che è possibile utilizzare solo pixel e tag predefiniti, con i dati del livello dati. Sebbene sia restrittivo, può portare a un'implementazione di Tag Manager più efficiente e sicura.

Valuta la possibilità di utilizzare il tagging lato server

Vale la pena prendere in considerazione il passaggio al tagging lato server, in particolare per i siti più grandi che vogliono un maggiore controllo sui propri dati. Il tagging lato server rimuove il codice del fornitore dal client e, di conseguenza, trasferisce l'elaborazione dal client al server.

Ad esempio, quando utilizzi il tagging lato client, l'invio di dati a più account Analytics comporta che il client avvii richieste separate per ogni endpoint. Con il tagging lato server, il client invia una singola richiesta al contenitore lato server e, da lì, questi dati vengono inoltrati a diversi account Analytics.

Tieni presente che il tagging lato server funziona solo con alcuni tag. La compatibilità dei tag varia in base al fornitore.

Per saperne di più, consulta Introduzione al tagging lato server.

Container

In genere, i gestori tag consentono più istanze, spesso definite contenitori, all'interno della loro configurazione. In un account Tag Manager è possibile controllare più contenitori.

Utilizza un solo contenitore per pagina

La presenza di più contenitori su una singola pagina può creare problemi di prestazioni significativi, in quanto introduce overhead aggiuntivo ed esecuzione di script. Come minimo, duplica il codice del tag principale stesso che, poiché viene fornito come parte del codice JavaScript del contenitore, non può essere riutilizzato tra i contenitori.

È raro che più contenitori vengano utilizzati in modo efficace. Tuttavia, se controllata bene, questa strategia può funzionare. Ad esempio:

• Includere un container più leggero per il "caricamento iniziale" e un container più pesante per il "caricamento successivo", anziché un unico container di grandi dimensioni.
• Utilizzare un contenitore con restrizioni per gli utenti meno tecnici e un contenitore con meno restrizioni, ma più controllato, per i tag più complessi.

Se devi utilizzare più contenitori per pagina, segui le indicazioni di Google Tag Manager per la configurazione di più contenitori.

Se necessario, utilizza container separati

Se utilizzi un gestore tag per più proprietà, ad esempio un'app web e un'app mobile, il numero di contenitori che utilizzi può influire positivamente o negativamente sulla produttività del tuo flusso di lavoro. Inoltre, può influire sul rendimento.

Un singolo contenitore può essere utilizzato in modo efficace su più siti se questi sono simili per utilizzo e struttura. Ad esempio, anche se le app web e mobile di un brand potrebbero avere funzioni simili, è probabile che siano strutturate in modo diverso e, di conseguenza, che vengano gestite in modo più efficace tramite contenitori separati.

Il riutilizzo eccessivo di un singolo contenitore può aumentarne la complessità e le dimensioni, costringendo a una logica complessa per la gestione di tag e attivatori.

Tieni d'occhio le dimensioni del contenitore

Le dimensioni di un contenitore sono determinate dai relativi tag, attivatori e variabili. Anche se un contenitore di piccole dimensioni può comunque influire negativamente sulle prestazioni della pagina, un contenitore di grandi dimensioni lo farà quasi sicuramente.

Le dimensioni del contenitore non devono essere la metrica più importante per ottimizzare l'utilizzo dei tag. Tuttavia, un container di grandi dimensioni è spesso un segnale di avviso che indica che un container non è gestito correttamente e potrebbe essere utilizzato in modo improprio.

Google Tag Manager limita le dimensioni del contenitore a 300 kB e avvisa quando le dimensioni del contenitore raggiungono il 70% del limite.

La maggior parte dei siti dovrebbe cercare di mantenere i propri container al di sotto del limite. Per fare un confronto, il contenitore del sito mediano è di circa 50 kB. La libreria di Google Tag Manager ha una dimensione di circa 33 kB compressi.

Assegna un nome alle versioni del contenitore

Una versione del contenitore è uno snapshot dei contenuti di un contenitore in un determinato momento. L'utilizzo di un nome significativo e l'inclusione di una breve descrizione delle modifiche significative apportate possono contribuire notevolmente a semplificare il debug di futuri problemi di prestazioni.

Tagga i workflow

È importante gestire le modifiche ai tag in modo che non abbiano un impatto negativo sulle prestazioni della pagina.

Testa prima del deployment

Testa i tag prima del deployment per individuare eventuali problemi, di rendimento e non, prima della pubblicazione.

Gli aspetti da considerare quando si testa un tag includono:

• Il tag funziona correttamente?
• Il tag causa variazioni del layout?
• Il tag carica risorse? Quanto sono grandi queste risorse?
• Il tag attiva uno script a lunga esecuzione?

Modalità di anteprima

La modalità di anteprima ti consente di testare le modifiche ai tag sul tuo sito effettivo senza doverle prima implementare per il pubblico. La modalità di anteprima include una console di debug che fornisce informazioni sui tag.

Il tempo di esecuzione di Google Tag Manager è diverso (leggermente più lento) se eseguito in modalità di anteprima a causa dell'overhead aggiuntivo richiesto per esporre le informazioni nella console di debug. Pertanto, non è consigliabile confrontare le misurazioni di Segnali web raccolte in modalità di anteprima con quelle raccolte in produzione. Tuttavia, questa discrepanza non dovrebbe influire sul comportamento di esecuzione dei tag stessi.

Test autonomi

Un approccio alternativo per testare i tag consiste nel configurare una pagina vuota contenente un contenitore con un solo tag, ovvero quello che stai testando. Questa configurazione di test è meno realistica e non rileva alcuni problemi (ad esempio, se un tag causa variazioni del layout), ma può semplificare l'isolamento e la misurazione dell'impatto del tag su aspetti come l'esecuzione degli script. Scopri come Telegraph utilizza questo approccio di isolamento per migliorare le prestazioni del codice di terze parti.

Monitora il rendimento dei tag

L'API Monitoring di Google Tag Manager può essere utilizzata per raccogliere informazioni sul tempo di esecuzione di un tag specifico. Queste informazioni vengono inviate a un endpoint di tua scelta.

Per saperne di più, consulta How to build a Google Tag Manager Monitor.

Richiedi l'approvazione per le modifiche al contenitore

Il codice proprietario viene in genere sottoposto a revisione e test prima del deployment. Tratta i tag allo stesso modo.

Un modo per farlo è aggiungere la verifica in due passaggi, che richiede l'approvazione dell'amministratore per le modifiche ai contenitori. In alternativa, se non vuoi richiedere la verifica in due passaggi, ma vuoi comunque tenere d'occhio le modifiche, puoi configurare le notifiche del contenitore per ricevere avvisi via email sugli eventi del contenitore che preferisci.

Controlla periodicamente l'utilizzo dei tag

Una delle sfide legate all'utilizzo dei tag è che tendono ad accumularsi nel tempo: i tag vengono aggiunti, ma raramente vengono rimossi. Il controllo periodico dei tag è un modo per invertire questa tendenza. La frequenza ideale per eseguire questa operazione dipende dalla frequenza con cui vengono aggiornati i tag del tuo sito.

Etichettare ogni tag in modo che il proprietario sia evidente consente di identificare più facilmente chi è responsabile di quel tag e può dire se è ancora necessario.

Quando esegui l'audit dei tag, ricordati di pulire gli attivatori e le variabili. Spesso possono anche essere la causa di problemi di prestazioni.

Per saperne di più, consulta Keeping third-party scripts under control.