Guida maitiq
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 modifica | Responsible (esegue) | Accountable (ne risponde) | Consulted (coinvolto) | Informed (informato) |
|---|---|---|---|---|
| Testo dell’annuncio/link all’interno di una pagina di destinazione approvata | Implementazione | SEA | – | Business |
| Parola chiave negativa con portata limitata | SEA | SEA | Misurazione | Business |
| Budget giornaliero di una campagna | SEA | Business | Finanza | Controllo |
| Strategia di offerta o valore target | SEA | Business | Misurazione | Finanza |
| Azione di conversione primaria o modalità di conteggio | Misurazione | Business | SEA, protezione dei dati | Controllo |
| Automazione a livello di account (ad esempio Auto-Apply) | SEA | Business | Controllo, finanza | tutti i ruoli |
| Accesso, diritti o profilo di pagamento | Protezione dei dati e sicurezza | Business | Finanza | tutti 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:
| Dimensione | Domanda guida | Soglia propria | Effetto |
|---|---|---|---|
| Esposizione ai costi | Quanto budget pubblicitario può essere coinvolto fino alla prossima revisione? | Livello di approvazione | |
| Portata | Quante 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 misurazione | Cambiano la modalità di conteggio, l’attribuzione o un flusso di dati di conversione? | Livello di approvazione | |
| Effetto legale/marchio | Sono coinvolti consenso, dati personali, claim o marchio? | Consulted obbligatorio | |
| Effetto sui diritti | Cambiano accesso, collegamento o profilo di pagamento? | livello massimo | |
| Tempo fino allo stop | Con 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:
| Campo | Contenuto |
|---|---|
| ID proposta | ID univoco e citabile |
| Account, campagna, entità | riferimento esatto e stabile invece del nome visualizzato |
| valore precedente, valore nuovo | dove un confronto di valori ha senso – una creazione non ha un valore numerico precedente –, con unità, valuta e fuso orario |
| Evidenza | fonte, finestra, maturità dei dati e lacune note |
| Derivazione | regola o calcolo tracciabile |
| Livello di rilevanza | livello secondo la matrice propria |
| osservazione attesa | affermazione verificabile, nessuna garanzia di risultato |
| Criterio di stop | segnale che termina la modifica |
| Decisione | persona o pilota automatico attivato, momento, esito; motivo se registrato |
| Implementazione | identità che implementa, richiesta, risposta di Google; prova prima/dopo dove è possibile una rilettura indipendente |
| Verifica | termine, 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 obbligatoria | Esempio di precisione | Errore senza l’indicazione |
|---|---|---|
| Account | Customer ID esatto, non un gruppo di account | modifica nell’account sbagliato |
| Azione | esattamente un tipo di azione, ad esempio modificare il budget giornaliero | estensione non rilevata |
| Entità | campagne/liste ammesse ed escluse | effetto collaterale su una campagna protetta |
| Valore | intervallo ammesso per modifica, in assoluto e in percentuale | modifica rilevante introdotta gradualmente |
| Frequenza | numero massimo per giorno/settimana | molti piccoli passi, somma elevata |
| Limite cumulativo | somma totale su tutte le modifiche nel periodo | i singoli limiti si sommano senza essere notati |
| Scadenza | data finale fissa, non «fino a revoca» | autorizzazione permanente dimenticata |
| Persona responsabile | persona designata, non una casella di team | nessuno è responsabile |
| Potere di stop | chi può fermare che cosa e in quale misura, con effetto immediato | escalation 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.