Modello di Monitoraggio di Google Ads: Campi, Livelli, Sintassi

Un modello di monitoraggio di Google Ads è uno schema di URL, impostabile a livello di account, campagna, gruppo di annunci, annuncio o parola chiave, che Google Ads usa per costruire l'indirizzo che il clic apre realmente, inserendo il tuo URL finale tramite un parametro ValueTrack come {lpurl} più qualsiasi altra cosa tu aggiunga. È un campo separato dal suffisso dell'URL finale, che si limita ad aggiungere parametri e non può reindirizzare da nessuna parte. Uno riscrive l'intero URL; l'altro lo estende. Confondere i due è il motivo per cui in tanti account il tracciamento ha smesso silenziosamente di funzionare.

Questo articolo tratta la meccanica a livello di campo: dove si colloca il modello nella gerarchia, quale livello vince, quando usarlo al posto del suffisso, e il dettaglio di codifica che rompe gli URL di destinazione con una propria query string. Per i tag in sé, i parametri UTM spiegati è il testo introduttivo, e i parametri UTM per gli annunci Google e Meta copre perché Google Ads dovrebbe funzionare per lo più con il tagging automatico piuttosto che con UTM manuali.

Cosa Fa Realmente il Modello di Monitoraggio

Niente cambia sulla landing page quando modifichi un modello di monitoraggio. Decide solo cosa succede tra il clic e il caricamento della pagina.

Google Ads legge il modello al momento della pubblicazione dell'annuncio, sostituisce {lpurl} con il tuo vero URL finale, compila gli eventuali parametri ValueTrack, e solo dopo invia il browser all'indirizzo assemblato. Un modello che inizia con un dominio di redirect manda prima il browser lì; un modello che è solo {lpurl} più una query string lo manda direttamente alla tua pagina con parametri aggiuntivi allegati.

Questo è il senso stesso del campo. Cento annunci possono condividere un unico URL finale e un unico modello, e una sola modifica al modello cambia cosa portano tutti e cento i clic. Le definizioni dei campi sono riportate testualmente nella documentazione di Google su URL finali e modelli di monitoraggio. Se il modello è solo un tassello di un flusso di tagging più ampio, tracciare le campagne UTM dall'inizio alla fine copre il resto della pipeline.

Dove Vive il Modello: Account, Campagna, Gruppo di Annunci, Annuncio, Parola Chiave

Il campo esiste a cinque livelli, e Google Ads non li unisce.

Imposta un modello di monitoraggio a livello di account, campagna, gruppo di annunci, annuncio o parola chiave, e quando ne è impostato più di uno, Google Ads usa quello più specifico e ignora gli altri, senza sommarli. Ordine, dal più al meno specifico: parola chiave, annuncio, gruppo di annunci, campagna, account. Un modello a livello di parola chiave sovrascrive tutto ciò che sta sopra; quello a livello di account si applica solo dove non esiste nulla di più specifico.

È qui che gli account deragliano senza che nessuno se ne accorga. Qualcuno imposta un modello pulito a livello di account per un nuovo strumento, e funziona ovunque tranne che in tre gruppi di annunci che ne avevano già uno lasciato da un vecchio fornitore. Quei tre continuano a eseguire il vecchio redirect indefinitamente, perché l'impostazione più specifica vince sempre. Una volta ho passato un pomeriggio intero su un account che instradava ancora silenziosamente i clic attraverso un dominio di call tracking chiuso da oltre un anno, perché un gruppo di annunci aveva un modello che nessuno ricordava di aver impostato. Fai un audit dall'alto verso il basso: account, poi campagna, gruppo di annunci, annuncio, parola chiave, controllando ognuno per un valore residuo prima di dare per scontato che la modifica a livello di account abbia raggiunto tutto.

Modello di Monitoraggio vs Suffisso dell'URL Finale

Questi due si confondono perché entrambi aggiungono testo a un URL. Ma ciò che possono aggiungere non è la stessa cosa.

Un modello di monitoraggio può sostituire l'intero URL: anteporre un dominio di redirect, inserire parametri ovunque, purché {lpurl} o una variante compaia da qualche parte. Un suffisso dell'URL finale fa una sola cosa, aggiunge un insieme fisso di parametri alla fine dell'URL finale, dopo tutto ciò che c'è già, e non può puntare da nessuna parte se non alla tua stessa pagina. Le indicazioni di Google sull'aggiunta di un suffisso dell'URL finale sono esplicite nel dire che il suffisso serve per i parametri, non per i redirect.

La regola è breve: se devi solo allegare parametri, usa il suffisso. Se devi instradare prima il clic attraverso un dominio di terze parti, un redirect di call tracking o un pixel di verifica, usa il modello, perché il suffisso non può reindirizzare da nessuna parte. Usa il suffisso come default e passa al modello solo quando un redirect è realmente necessario.

Parametri ValueTrack e Personalizzati Utili da Conoscere

I parametri ValueTrack sono macro che Google Ads compila al momento del clic. Una manciata di essi copre quasi ogni esigenza pratica.

{lpurl} è quello che ogni modello richiede, il tuo URL finale. {campaignid} e {creative} (l'ID dell'annuncio) identificano quale campagna e quale annuncio hanno servito il clic. {device} restituisce mobile, tablet o desktop; {network} riporta Ricerca, Display o partner di ricerca. {keyword} e {matchtype} si popolano solo sulle campagne di ricerca, con la parola chiave che ha attivato l'annuncio e il tipo di corrispondenza, generica, a frase o esatta. Per l'elenco completo, incluse alcune voci specifiche per le campagne Shopping e app, vedi il riferimento ValueTrack di Google.

Assemblato in un modello pronto da incollare nel campo a livello di campagna:

{lpurl}?utm_source=google&utm_medium=cpc&utm_campaign={campaignid}&utm_content={creative}&utm_term={keyword}&device={device}&network={network}

Inserisci solo i parametri su cui interroghi davvero i dati; aggiungerli tutti quelli offerti da Google lascia solo colonne vuote sul traffico Display o Shopping, dove metà di essi non si popola mai. Tutto ciò che sta fuori dalle macro proprie di Google, un ID campagna interno, un codice regione, richiede invece un parametro personalizzato: un nome e un valore che definisci tu stesso, richiamato come {_region}, fino a otto per entità, nome limitato a 16 caratteri e valore a 200. La guida di Google ai parametri personalizzati riporta i limiti esatti.

Costruire quella stringa a mano su decine di campagne è esattamente il tipo di compito che degenera nel momento in cui due persone ci mettono mano. Il generatore di UTM di Elido genera la parte taggata da un modulo invece che da un campo di testo vuoto, così i nomi dei parametri restano coerenti ancor prima di raggiungere il modello.

La Trappola di Codifica: lpurl vs Unescapedlpurl

Questo dettaglio rompe modelli che sembravano a posto in fase di test.

{lpurl} esegue l'escape di alcuni caratteri, punti interrogativi, segni di uguale, virgolette, spazi, ogni volta che compare in una posizione diversa dalla primissima del modello. {unescapedlpurl} non esegue mai l'escape, indipendentemente dalla posizione. Conta solo quando il tuo URL finale ha già una propria query string: un ? sottoposto a escape dentro un wrapper di redirect diventa %3F, e un sistema a valle che legge l'indirizzo alla lettera ottiene un parametro rotto invece che funzionante.

Metti {lpurl} per primo, come in {lpurl}?utm_source=google, e l'escape non si attiva mai, quindi le due macro si comportano in modo identico. Mettilo dopo un prefisso di redirect, come in https://track.example.com/go?dest={lpurl}, e il ? e il = propri della destinazione vengono sottoposti a escape dentro l'URL esterno, il che di solito è corretto, dato che il redirect ha bisogno di un unico valore pulito da inoltrare. Scambia i due e il servizio di redirect legge spazzatura invece della tua pagina. Ogni volta che un modello instrada attraverso un dominio di redirect, verifica con la procedura di test qui sotto invece di dare per scontato che la scelta della macro non conti.

Come Questo Interagisce con il Tagging Automatico e gclid

Il tagging automatico e il modello di monitoraggio risolvono problemi diversi, e non entrano in conflitto sull'URL come invece succede tra UTM manuali e tagging automatico.

Il tagging automatico aggiunge gclid dopo che il modello ha già assemblato l'indirizzo, dato che gclid viene aggiunto al momento dell'invio, non incorporato nella stringa del modello. Un modello che aggiunge parametri ValueTrack o personalizzati viene eseguito per primo, e gclid arriva sopra, quindi i due convivono senza conflitti. La modalità di guasto è diversa dall'errore da UTM manuali descritto in i parametri UTM per gli annunci Google e Meta: qui succede solo se un modello codifica in modo statico una destinazione fissa invece di lasciar passare il clic, nel qual caso il clic non raggiunge mai il vero percorso di invio e gclid viene eliminato insieme a tutto il resto. Finché {lpurl} o {unescapedlpurl} è effettivamente presente nel modello, gclid continua a funzionare sotto di esso, e l'analytics dei tuoi link è dove i parametri risultanti e gclid compaiono come dati riportabili.

Il Monitoraggio Parallelo Ha Rotto i Tracker di Redirect - Testa Prima di Fidarti

Se un modello ha smesso di funzionare senza preavviso, probabilmente è questo il motivo.

Prima che il monitoraggio parallelo diventasse il comportamento predefinito, un modello di redirect funzionava esattamente come suona: il clic colpiva prima il redirect, il servizio di redirect faceva il suo lavoro, poi inoltrava il browser all'URL finale. Il monitoraggio parallelo ha cambiato l'ordine. Il browser ora va dritto all'URL finale immediatamente, mentre il redirect del modello si carica in background invece che nel percorso del visitatore. Un tracker che dipendeva realmente dall'essere il primo hop, dal leggere il clic prima di inoltrarlo, dall'impostare un cookie prima che la pagina si renderizzi, ha smesso di vedere traffico reale nel momento in cui il monitoraggio parallelo è subentrato, anche se il modello sembrava ancora configurato correttamente. Come conferma la panoramica di Google sul monitoraggio in Google Ads, il monitoraggio parallelo è l'attuale comportamento predefinito, ed è anche per questo che il suffisso dell'URL finale, che non reindirizza mai, è il campo predefinito più sicuro.

Non fidarti di un modello solo perché sembra corretto nell'editor. Google Ads ha un pulsante Test accanto al campo: cliccalo e Google Ads assembla l'URL esattamente come farebbe un clic reale, sostituendo ogni parametro, e mostra l'indirizzo risultante insieme a tempo di caricamento ed errori. Leggi quella stringa carattere per carattere; un {lpurl} fuori posto o una e commerciale mancante emergono qui prima di costarti una giornata di dati rotti. Il pulsante Test controlla l'assemblaggio, non la consegna, quindi seguilo con un clic reale: carica il tuo stesso annuncio in una finestra in incognito, leggi la barra degli indirizzi una volta che la pagina si è stabilizzata, conferma che i valori ValueTrack siano popolati invece di mostrare il testo letterale {device}, e conferma che gclid sia presente se il tagging automatico è attivo. Cinque minuti qui intercettano ciò che il controllo di sintassi dell'editor non può.

Correlati sul Blog

• I parametri UTM spiegati: il testo introduttivo in parole semplici
• I parametri UTM per gli annunci Google e Meta
• Perché i parametri UTM non appaiono in GA4: cause e soluzioni
• Traccia le campagne UTM dall'inizio alla fine senza una CDP
• Le convenzioni di denominazione UTM che mantengono i report puliti