Vai al contenuto

Governance Google Ads: come approvare le modifiche in modo controllato

maitiq · Pubblicato

Le cinque fasi della risposta breve sono confini che l’automazione non deve oltrepassare in modo invisibile, indipendentemente da come viene presentato il sistema che esegue. Un caso tipico è banale: qualcuno abbassa a mano un obiettivo di offerta e tre mesi dopo nessuno sa più perché. maitiq risponde in modo strutturale, con una decisione memorizzata e un’implementazione registrata per ogni modifica che propone.

Perché la cronologia delle modifiche di Google non basta?

La cronologia delle modifiche elenca le modifiche apportate ad account, campagne e gruppi di annunci negli ultimi due anni. Mostra il momento, il tipo di modifica e l’identità che l’ha attivata: persona, API di Google Ads, Google Ads Editor, regola automatica o uno dei sistemi interni di Google. Si può filtrare per campagna, gruppo di annunci, tipo di modifica, utente, strumento e elemento modificato, e collegare ai dati di rendimento. Per motivi di sicurezza non registra le modifiche alla password. Google precisa inoltre che non sempre tutte le modifiche alle impostazioni a livello di account o quelle apportate dai rappresentanti di Google durante le consulenze vengono elencate.

Risponde quindi soprattutto a una domanda: che cosa è stato modificato nell’account? Non risponde a:

  • quale obiettivo di business valeva;
  • quali evidenze sostenevano la proposta;
  • chi ha approvato nel merito e con quale autorità;
  • quali rischi sono stati accettati consapevolmente;
  • quale rollback era preparato;
  • se in seguito la modifica ha prodotto lo stato atteso.

A questo si aggiunge un limite di lettura che molti team notano solo quando costruiscono un proprio archivio: la vista a due anni dell’interfaccia non è una cronologia interrogabile tramite API. Tramite l’API di Google Ads, la risorsa change_event fornisce i nuovi valori dei campi per le creazioni e, per gli aggiornamenti, i valori vecchi e nuovi, insieme al tipo di client e, se visibile nella cronologia delle modifiche del client web, all’utente che ha apportato la modifica, ma richiede una finestra di date entro gli ultimi 30 giorni e al massimo 10’000 righe per query; Google precisa che non ogni riga della cronologia deve esservi inclusa. La risorsa change_status risale a 90 giorni, ma per ogni risorsa restituisce solo la modifica più recente e nessun valore di campo. Questi limiti di 30 e 90 giorni valgono per queste due risorse, non per tutti i dati disponibili tramite API. Chi ha bisogno di una traccia affidabile su più trimestri deve memorizzarla continuamente da sé. Una traccia interna non sostituisce la cronologia della piattaforma: documenta le decisioni e le azioni di maitiq, non la motivazione di ogni modifica manuale nell’intero account Google.

Quali cinque fasi richiede una modifica?

1. Evidenza. La fonte viene descritta senza modifiche: periodo, account, campagna, entità interessata, indicatori, disponibilità dei dati e limiti. I dati mancanti restano mancanti.

2. Proposta. La proposta indica l’azione esatta: valore precedente e nuovo dove un simile confronto di valori ha senso – una creazione non ha un valore numerico precedente –, oltre a obiettivo, motivazione, osservazione controllabile attesa e possibili effetti collaterali. Un’analisi non è ancora un’azione.

3. Decisione. Una persona autorizzata accetta, rifiuta o lascia aperto; quando il pilota automatico limitato è esplicitamente attivato, può accettare entro i limiti che lei ha definito. Identità e momento vengono memorizzati, e un motivo dove viene registrato. Un’accettazione non è l’implementazione tecnica.

4. Implementazione autorizzata separatamente. Solo un’identità autorizzata a tale scopo esegue esattamente la modifica approvata. Un’autorizzazione propria non implica necessariamente un secondo clic di approvazione: quando si esclude una parola chiave di un concorrente, la decisione esplicita è essa stessa l’autorizzazione per quella singola operazione, e l’esecuzione viene comunque verificata rispetto a decisione, ambito e obiettivo. La richiesta e la risposta di Google vengono registrate, insieme a una prova prima/dopo dove l’operazione consente una rilettura indipendente.

5. Verifica. Il controllo tecnico accerta lo stato nella misura in cui è comprovabile: riporta le evidenze disponibili – ad esempio la risposta dell’API e l’audit – e, dove l’operazione consente una rilettura indipendente, la prova prima/dopo. La verifica mancante resta aperta invece di valere come confermata; non viene promessa una conferma indipendente immediata per ogni scrittura. L’osservazione successiva degli effetti avviene dopo una finestra di osservazione definita e valuta come si è evoluto lo stato rilevante. La correlazione non viene presentata come effetto.

Ogni fase richiede una gestione degli errori. Se mancano evidenze pertinenti, la decisione può restare bloccata; i valori di stato consigliati sono «dati insufficienti per decidere», «nuova approvazione necessaria» per una decisione scaduta, «non eseguita» per una verifica preliminare bloccata, «non chiarito» per un esito remoto sconosciuto e «non risolta» per una verifica aperta. Una non applicabilità giustificata non diventa automaticamente «dati insufficienti per decidere». Questi valori di stato sono una raccomandazione per il suo registro, non cinque valori di stato integrati nel prodotto: non ogni operazione ha uno stato prima/dopo riletto in modo indipendente, uno stato di scadenza o un motivo in testo libero memorizzato. Un tentativo fallito non deve apparire né come modifica riuscita né come «nessuna modifica necessaria».

Chi decide che cosa? La base RACI

Separi i ruoli, non solo le persone: responsabilità di business (obiettivo, budget, rischio), responsabilità SEA (verifica specialistica), responsabilità della misurazione (limiti di conversione e attribuzione), implementazione (esecuzione), controllo (verifica indipendente), protezione dei dati e sicurezza (accesso, consenso, ID di clic) e finanza (budget pubblicitario e limiti di autorizzazione).

Classe di modificaResponsible (esegue)Accountable (ne risponde)Consulted (coinvolto)Informed (informato)
Testo dell’annuncio/link all’interno di una pagina di destinazione approvataImplementazioneSEA–Business
Parola chiave negativa con portata limitataSEASEAMisurazioneBusiness
Budget giornaliero di una campagnaSEABusinessFinanzaControllo
Strategia di offerta o valore targetSEABusinessMisurazioneFinanza
Azione di conversione primaria o modalità di conteggioMisurazioneBusinessSEA, protezione dei datiControllo
Automazione a livello di account (ad esempio Auto-Apply)SEABusinessControllo, finanzatutti i ruoli
Accesso, diritti o profilo di pagamentoProtezione dei dati e sicurezzaBusinessFinanzatutti i ruoli

Per ogni riga esattamente un ruolo è Accountable, mai un software. Nei team più piccoli una persona copre più ruoli; gli eventi restano separati: prima la decisione, poi l’esecuzione entro l’autorizzazione valida. Aggiunga per ogni riga sostituzione e via di escalation, altrimenti un’assenza blocca il processo. Questa matrice è un modello da copiare per il suo registro dei ruoli, non un campo modificabile di questa pagina. Ecco come si colloca maitiq: il workflow non è Accountable in nessuna riga – fornisce evidenza e proposta; una persona designata del suo team decide, oppure decide il pilota automatico limitato esplicitamente attivato entro i limiti che lei ha definito; la responsabilità di concedere questa policy resta alla persona designata. Nel servizio gestito un Client Success Manager, il suo referente dedicato, accompagna il lavoro, e l’implementazione avviene entro l’autorizzazione concessa a tale scopo, come passo registrato.

Come maitiq integra la governance

L’esecuzione del workflow raccoglie evidenza e genera proposte con l’intervento, la motivazione e la base dati – valore precedente e nuovo, dove esiste un simile confronto tra valori. La generazione di proposte non modifica nulla nell’account. Una persona autorizzata accetta, rifiuta o lascia aperto; quando il pilota automatico limitato è esplicitamente attivato, può accettare proposte entro i limiti che lei ha definito e avviare, nello stesso ciclo di workflow, un’esecuzione separata e verificata separatamente. La decisione viene memorizzata con identità e momento; l’implementazione resta vincolata ai diritti di esecuzione verificati separatamente e viene registrata. Ciò che supera questi limiti non viene accettato automaticamente.

Quali modifiche sono rilevanti?

Il livello di rilevanza dipende dall’account. Non esistono categorie Google universali né soglie in CHF o in percentuale valide in generale. La matrice è un modello da copiare per il suo registro, non un campo modificabile di questa pagina. Calibri la matrice con i suoi valori:

DimensioneDomanda guidaSoglia propriaEffetto
Esposizione ai costiQuanto budget pubblicitario può essere coinvolto fino alla prossima revisione?Livello di approvazione
PortataQuante campagne, gruppi di annunci o account sono coinvolti?Obbligo di revisione
ReversibilitàIl ritorno al valore precedente è tecnicamente possibile, e in quale finestra?Piano di rollback
Effetto sulla misurazioneCambiano la modalità di conteggio, l’attribuzione o un flusso di dati di conversione?Livello di approvazione
Effetto legale/marchioSono coinvolti consenso, dati personali, claim o marchio?Consulted obbligatorio
Effetto sui dirittiCambiano accesso, collegamento o profilo di pagamento?livello massimo
Tempo fino allo stopCon quale rapidità qualcuno può fermare di fatto la modifica?Finestra di implementazione

Un importo piccolo può essere critico se tocca il flusso di dati della conversione primaria o diritti a livello di account; una modifica di budget grande e immediatamente reversibile può avere un livello di rilevanza medio. Definisca per ogni livello il livello di approvazione, la finestra di implementazione, il monitoraggio e il rollback. Le modifiche critiche non partono in fasce non presidiate.

Che cosa contiene una proposta di modifica?

Il solo testo libero rende più difficile la deduplicazione, la revisione e il reporting. Utilizzi riferimenti stabili alle entità e valori di stato strutturati; il seguente elenco di campi è un modello per il suo formato di proposta, non un input di prodotto:

CampoContenuto
ID propostaID univoco e citabile
Account, campagna, entitàriferimento esatto e stabile invece del nome visualizzato
valore precedente, valore nuovodove un confronto di valori ha senso – una creazione non ha un valore numerico precedente –, con unità, valuta e fuso orario
Evidenzafonte, finestra, maturità dei dati e lacune note
Derivazioneregola o calcolo tracciabile
Livello di rilevanzalivello secondo la matrice propria
osservazione attesaaffermazione verificabile, nessuna garanzia di risultato
Criterio di stopsegnale che termina la modifica
Decisionepersona o pilota automatico attivato, momento, esito; motivo se registrato
Implementazioneidentità che implementa, richiesta, risposta di Google; prova prima/dopo dove è possibile una rilettura indipendente
Verificatermine, prova tecnica, aspetti ancora da verificare

Com’è fatta un’approvazione permanente completa?

Un’approvazione permanente sostituisce la decisione singola per modifiche ricorrenti e a basso rischio. «Ottimizzare secondo le best practice» non è un permesso controllabile. Come modello organizzativo è completa solo con nove indicazioni – un modello da copiare per il suo registro delle autorizzazioni, non nove impostazioni di prodotto:

Indicazione obbligatoriaEsempio di precisioneErrore senza l’indicazione
AccountCustomer ID esatto, non un gruppo di accountmodifica nell’account sbagliato
Azioneesattamente un tipo di azione, ad esempio modificare il budget giornalieroestensione non rilevata
Entitàcampagne/liste ammesse ed escluseeffetto collaterale su una campagna protetta
Valoreintervallo ammesso per modifica, in assoluto e in percentualemodifica rilevante introdotta gradualmente
Frequenzanumero massimo per giorno/settimanamolti piccoli passi, somma elevata
Limite cumulativosomma totale su tutte le modifiche nel periodoi singoli limiti si sommano senza essere notati
Scadenzadata finale fissa, non «fino a revoca»autorizzazione permanente dimenticata
Persona responsabilepersona designata, non una casella di teamnessuno è responsabile
Potere di stopchi può fermare che cosa e in quale misura, con effetto immediatoescalation senza capacità di intervento

Ogni deroga riporta alla decisione singola. Alla data di scadenza verifichi attivamente se rinnovare; una continuazione silenziosa non è una decisione. Il pilota automatico limitato di maitiq segue un insieme di limiti propri, diversi e configurabili: per ogni modifica un importo e una percentuale, più un tetto massimo per la somma dei valori di budget dopo la modifica sul livello di raggruppamento scelto. Sono limiti meno numerosi o diversi rispetto a una policy organizzativa completa, non una protezione più severa. Limiti di frequenza, data di scadenza e persona responsabile designata sono campi del suo registro, non impostazioni di prodotto; senza la policy attivata la funzione resta spenta.

Come si approvano le raccomandazioni Auto-Apply?

Auto-Apply è un’attivazione esplicita (opt-in). Il rischio non è un consenso mancante, ma un’autorizzazione non documentata o dimenticata, che può sopravvivere alla memoria del personale. Google consente di applicare automaticamente tipi di raccomandazione selezionati, esclusivamente a livello di account. Le impostazioni di Auto-Apply hanno una cronologia propria; mostra per ogni tipo quando è stato attivato per la prima volta, quante volte è stato applicato nella settimana precedente e quando è avvenuto l’ultimo utilizzo. L’ID utente che ha dato il consenso si verifica nella cronologia delle modifiche. Proprio questi campi appartengono al suo registro delle autorizzazioni, integrati con scopo di business, azioni di conversione protette, ritmo di revisione, data di scadenza e regola di stop.

Documenti i singoli tipi, non i nomi dei pacchetti: portata e rischio variano molto. I tipi disponibili cambiano: Google adegua continuamente il catalogo delle raccomandazioni applicabili automaticamente; verifichi l’elenco a ogni revisione. Ogni revisione termina con uno stato esplicito per tipo; i valori consigliati sono «mantenere», «disattivare», «test a tempo determinato», «dati insufficienti per decidere» o «escalation». Il punteggio di ottimizzazione non è un KPI aziendale: una raccomandazione può essere coerente con la logica della piattaforma e contraddire comunque il quadro di business.

È importante la distinzione: disattivare ferma le future applicazioni automatiche. Non annulla le modifiche già applicate. Per questo esiste la via separata della cronologia delle modifiche – se l’operazione interessata supporta questo annullamento. In caso contrario può essere necessario un intervento manuale di modifica inversa autorizzato separatamente, oppure l’annullamento può essere impossibile. Come tenere Auto-Apply, Smart Bidding e strumenti esterni in un registro unico, verificarli e fermarli è descritto nella guida Controllare l’automazione con limiti e controlli.

Com’è fatto un protocollo di rollback?

Un rollback non è una contromodifica spontanea, ma un’operazione preparata e registrata. Google offre a tal fine una finestra temporale: la maggior parte dei tipi di modifica degli ultimi 30 giorni può essere annullata direttamente nella riga della cronologia delle modifiche, anche nel caso di una raccomandazione applicata per errore – se l’operazione supporta questo annullamento. In caso contrario può essere necessario un intervento manuale di modifica inversa autorizzato separatamente, oppure l’annullamento può essere impossibile. Se nel frattempo un elemento collegato è stato rimosso o qualcun altro ha già ripristinato, l’interfaccia segnala che la modifica non può essere annullata. Una raccomandazione applicata solo parzialmente non può essere annullata con la funzione di annullamento di quella raccomandazione; ciò non dimostra che ogni modifica di fondo che ne è derivata sia impossibile da invertire manualmente. Non si affidi quindi mai solo a questa funzione: annoti il valore precedente prima della modifica.

Per ogni modifica rilevante annoti: segnale di stop, riferimento alla proposta e prova di implementazione, vecchio valore target con relativa prova, persona autorizzata, autorizzazione valida per la modifica inversa, via scelta (annullamento nella cronologia, modifica inversa manuale autorizzata separatamente o non possibile), momento, prova tecnica successiva, effetto residuo su costi e dati e aspetti ancora da verificare. Una pausa riduce l’esposizione, ma non garantisce che non seguano altri costi già generati o segnalati con ritardo. In caso di errori di monitoraggio il rollback comprende inoltre l’arresto di un’importazione errata e la riconciliazione dei dati.

Come si descrive un sistema in base alle autorizzazioni invece che alle etichette?

Un’etichetta come «AI-powered» non dice nulla sull’architettura di controllo. Decisiva è una sola domanda: il sistema può avviare una modifica dalle conseguenze rilevanti senza una decisione memorizzata e autorizzata? Verifichi per ogni livello – sistema d’asta di Google, impostazioni dell’account Google come Auto-Apply e strumenti esterni – entità ammesse, variazione massima, modalità proposta o diretta, approvazione umana, identità del fornitore, traccia di audit e via di stop.

Per maitiq la risposta è: la generazione di proposte da sola non modifica Google Ads. Una modifica nasce solo da una decisione memorizzata e da un passo di esecuzione autorizzato e registrato separatamente; con il pilota automatico limitato esplicitamente attivato, il motore può approvare proposte entro la policy e avviare, nello stesso ciclo di workflow, questa esecuzione separata. I calcoli sono deterministici; l’IA opera solo in funzione consultiva, con formato di output verificato, e non può né unire proposte né approvarle, rifiutarle o riscriverne i valori numerici. Un audit non applica mai modifiche.

Come si separano verifica ed effetto?

La verifica tecnica accerta lo stato nella misura in cui è comprovabile: riporta le evidenze disponibili e lascia aperta la verifica mancante. L’osservazione degli effetti chiede in seguito come sono cambiati gli indicatori definiti. Le due cose non devono fondersi: una modifica tecnicamente corretta può essere economicamente inadeguata, e un movimento favorevole successivo non dimostra alcuna causalità. Memorizzi separatamente stato di implementazione, prova tecnica disponibile, finestra di osservazione, maturità dei dati, modifiche parallele e incertezza residua. Quale indicatore, quale finestra e quale modello di attribuzione consente l’osservazione successiva è chiarito nelle definizioni di KPI e attribuzione.

Come si evita la burocrazia?

La governance deve accelerare le decisioni: limiti approvati in anticipo per modifiche reversibili e a basso rischio, campi di proposta standardizzati, ruoli secondo il livello di rilevanza, finestre di revisione raggruppate, raccolta automatica delle evidenze e un’eccezione di emergenza con obbligo di documentazione entro un termine stabilito autonomamente e fissato per iscritto. Il termine lo stabilisce ogni organizzazione; gli obblighi legali, contrattuali e legati agli incidenti restano invariati.

Domande frequenti

Basta la sola approvazione umana?

No. Senza entità esatta, evidenza pertinente e – dove un confronto di valori ha senso – valore precedente e nuovo, oltre alla prova di implementazione, resta poco chiaro che cosa è stato approvato. Se manca evidenza pertinente, la decisione resta bloccata; una non applicabilità giustificata non è un motivo di blocco.

La cronologia delle modifiche sostituisce la traccia di audit interna?

No. La integra. Scopo di business, autorità e verifica non vi figurano, e tramite API sono consultabili solo 30 giorni per change_event e 90 giorni per change_status. La traccia interna documenta le decisioni e le azioni di maitiq, non la motivazione di ogni modifica manuale nell’account.

Si può annullare una raccomandazione applicata?

Di regola sì, entro 30 giorni tramite la cronologia delle modifiche – se l’operazione supporta questo annullamento. Una raccomandazione applicata solo parzialmente non può essere annullata con questa funzione; ciò non esclude un intervento manuale di modifica inversa sulle modifiche che ne sono derivate. I casi con elementi collegati rimossi possono richiedere un intervento manuale autorizzato separatamente o essere impossibili da invertire.

L’IA può formulare proposte?

Sì, purché fonti e limiti siano controllati. Le decisioni numeriche e i diritti di implementazione non devono nascere da testo generato non supportato da dati. Per questo in maitiq l’IA resta consultiva e con formato di output verificato; i numeri nascono in modo deterministico, e la decisione spetta a una persona autorizzata oppure – entro la policy esplicitamente attivata – al pilota automatico limitato. La responsabilità di concedere questa policy resta a una persona designata.

L’audit di maitiq applica le proposte approvate?

No. Anche un’accettazione non è ancora l’implementazione; questa segue come passo autorizzato e registrato separatamente, dopo l’approvazione, mai nell’audit.

Fonti e inquadramento

Le fonti sono la documentazione Google: le pagine di assistenza descrivono la cronologia delle modifiche, le impostazioni di Auto-Apply e le raccomandazioni; il riferimento API descrive che cosa si può recuperare a livello programmatico. Informazioni sul modo di lavorare di maitiq sono disponibili su maitiq.com.

Faccia esaminare il suo caso concreto da maitiq.