Automatizzare il PPC è sempre stato possibile. Solo che non si ripagava mai — fino a ora.

Tutta la tesi in una frase

Automatizzare il PPC come si deve è sempre stato possibile — solo che non si ripagava mai, quindi quasi nessuno lo faceva. L’AI non ci ha dato nuovi poteri; ha fatto crollare il costo di usare quelli vecchi, e questo singolo spostamento economico rimette sul tavolo un decennio di «ci piacerebbe, ma non si ripagherebbe mai». Tutto ciò che segue è la prova, raccontata dall’interno degli strumenti con cui costruisco davvero — non da un keynote di un vendor.

Ecco cosa ti porti via concretamente da questo articolo: le tre ere che hanno reso l’automazione PPC troppo costosa per valerne la pena, il momento esatto in cui i conti sono tornati quest’anno, e un lavoro reale — ripulire le query di ricerca spazzatura con un modello open source in locale — scomposto passo per passo, mostrando a ogni fase l’output intermedio che ti ritroveresti davanti. Alla fine saprai distinguere tra «l’AI ci ha dato nuove capacità» (per lo più falso) e «l’AI ha cambiato chi può permettersi quelle vecchie» (la cosa che conta davvero), e avrai un flusso che puoi copiare.

Tra il 2015 e il 2017 ho gestito un piccolo blog sui Google Ads Scripts, poi ho smesso di scrivere. Non perché le idee si fossero esaurite — ma perché il divario tra «questo è possibile» e «questo vale la pena farlo per un cliente» è rimasto ostinatamente ampio per un decennio. Quasi tutto ciò che hai letto sull’AI che uccide lo specialista PPC sbaglia il meccanismo. L’AI non ha cambiato cosa puoi fare nella ricerca a pagamento. La maggior parte era già possibile. Ciò che ha cambiato è chi può farlo, e a quale costo — ed è una questione molto più grande dell’ennesimo interruttore di offerte automatiche. Lascia che ti spieghi come lo so.

L’era degli Scripts: qualche giorno per uno script «semplice»

Perché parto da qui: per mostrarti che il limite non è mai stato la tecnologia. Era il lavoro umano, fin dal primo strumento che ho toccato.

I Google Ads Scripts sembravano magia quando sono arrivati. JavaScript, direttamente nell’account, che cicla sulle campagne. In pratica, uno script «semplice» — mettere in pausa le parole chiave oltre una soglia di CPA, segnalare URL finali rotti — era questione di qualche giorno di scrittura e debug, una volta gestiti i casi limite, le quote, i fallimenti silenziosi.

Poi arrivava la parte che nessuno aveva messo a budget: eseguirlo su più account. Uno script per account, copiato e incollato, che andava fuori sincrono, che si rompeva in silenzio quando la convenzione di denominazione di un cliente non corrispondeva alle altre. Scalare e distribuire era un lavoro a sé. Così la maggior parte degli script in circolazione non andava oltre la reportistica — tirare giù qualche numero in uno Sheet a cadenza fissa. Qualsiasi cosa che davvero modificava l’account era troppo fragile, e troppo costosa da mantenere, per valerne la pena per la maggior parte delle agenzie.

La lezione che ti porti avanti: persino il layer di automazione «facile» era frenato dal costo di manutenzione, non dalle capacità.

L’era dell’API: due giorni per la prima query, due anni per un tool

Perché questa conta: è il punto in cui il divario di ammortamento è diventato così ampio da trasformarsi in una decisione di business, non di ingegneria.

La Google Ads API — all’epoca l’AdWords API — era il vero potere, e il vero muro. Ho visto il nostro architetto di sistema, un uomo con oltre 25 anni di ingegneria alle spalle, passare due giorni interi a leggere la documentazione prima di ottenere una sola query che restituisse dati. Non è una critica a lui. È la superficie a cui ti sei iscritto.

Ci siamo buttati comunque a capofitto e abbiamo costruito PPC Robot: uno strumento di reportistica e operazioni profondamente personalizzabile, tecnicamente bellissimo, genuinamente potente. Ha richiesto anche due sviluppatori, a tempo pieno, per due anni. Lo sviluppo necessario per tenerlo in vita si aggirava intorno ai 100.000 € l’anno — all’incirca, come ordine di grandezza — e non si è mai ripagato. Copriva una frazione di ciò che i nostri specialisti PPC servivano davvero, così alla fine l’abbiamo parcheggiato in una modalità interna limitata. Non perché fosse fatto male. Perché i conti non tornavano mai.

E sopra a quell’API abbiamo comunque rilasciato cose reali, quattro e cinque anni fa:

Guarda quella lista e nota una cosa: niente di tutto ciò è esotico per gli standard di oggi. Era tutto possibile. Solo che costava una fortuna costruirlo e una fortuna tenerlo in vita. Ogni funzionalità di rilievo — uno strumento di ricerca delle parole chiave, uno strumento di espansione, la traduzione degli annunci, un generatore Shopping — si misurava in mesi. È l’intera lezione di quell’era in una frase: il limite non è mai stato la tecnologia. Era il periodo di ammortamento.

Due cose che si sono rotte quest’anno

Perché ora divento specifico: «l’AI ha cambiato tutto» è un’affermazione che dovresti rifiutarti di accettare per fede. Quindi ecco due lavori che prima erano antieconomici e ora non lo sono — entrambi cose che sto eseguendo, non ipotesi — e per il primo ti mostro esattamente cosa produce ogni passaggio.

1. Escludere le query di ricerca sbagliate

Ripulire un account dalle query di ricerca irrilevanti ha grande valore ed è da impazzire dalla noia. Il vecchio metodo era un’analisi semi-manuale di migliaia di query, scrutando gli schemi a occhio, aggiungendo le esclusioni a mano. Immagina la scena: un negozio di scarpe da corsa sta pagando clic su «riparazione scarpe da corsa», «storia nike air max» e «scarpe da corsa gratis» — nessuna delle quali vende o ripara. Moltiplicalo per migliaia di righe, ogni settimana, su ogni account. È il lavoro che nessuno vuole e di cui tutti hanno bisogno.

L’azione che è cambiata: uno script Python tira giù le query dalla Google Ads API e le passa a un modello open source — il Gemma 4 di Google — con istruzioni adeguate e, cosa cruciale, contesto sul sito: la sitemap, la struttura del sito/DB, la tassonomia dei breadcrumb, il product feed. Il risultato: il modello non si limita a segnalare le singole query spazzatura; fa emergere gli schemi che ci stanno dietro, più velocemente e a costo inferiore di una scrematura umana. Ecco quel flusso in cinque passaggi concreti.

La vera notizia qui, detta sottovoce, non è «l’AI è intelligente». È che un modello open source eseguito in locale è sufficiente — non ti serve nemmeno un’API di frontiera perché ciò si ripaghi. È l’economia che si muove, non la capacità.

Guardalo girare: cosa sputa davvero fuori ogni passaggio

I cinque passaggi sono la ricetta; questo è il piatto. Qui sotto c’è l’artefatto concreto che ogni passaggio ti consegna per il nostro negozio di scarpe da corsa — ciò che hai letteralmente davanti prima di andare avanti. Le forme sono esattamente ciò che gli strumenti restituiscono; le righe sono illustrative, non un cliente reale. (Esempi illustrativi ovunque.)

PULL → le query di ricerca grezze, con i soldi agganciati. Ogni termine che l’account ha pagato, ordinato così che lo spreco sia visibile:

Search term                Clicks  Cost   Conv
running shoes                420    €310    12
free running shoes            88    €61      0
running shoes repair          54    €40      0
nike air max history          31    €24      0
running shoes wikipedia       19    €14      0

Quattro di queste cinque righe sono pura spesa con zero conversioni — 139 € che l’account non avrebbe mai dovuto pagare. Il problema è ovvio in cinque righe e invisibile in cinquemila.

GROUND → il pacchetto di contesto contro cui ragiona il modello. Non prosa — una mappa compatta di ciò che il sito è genuinamente:

sitemap.xml      → 1,010 URLs (categories, products, blog)
breadcrumb tax.  → Footwear > Running > Road / Trail
product feed     → 1,205 SKUs (id, title, category, price)
DB structure     → no "repair", "rental" or "history" nodes exist

È quell’ultima riga a fare il lavoro: il modello ora sa che «repair» non è una cosa che questo negozio offre, invece di tirare a indovinare.

ASK → i verdetti, e gli schemi sopra di essi. Il modello restituisce un verdetto per query — ma il premio è il blocco in fondo:

Query                     Verdict      Why
free running shoes        irrelevant   freebie intent, no purchase
running shoes repair      irrelevant   service we don't offer
nike air max history      irrelevant   informational, no buy intent
running shoes wikipedia   irrelevant   reference-seeker

→ PATTERN: tokens "free", "repair", "history", "wikipedia"
  = non-commercial modifiers absent from our taxonomy.
  Recommend excluding as a shared negative list.

Quattro righe sono diventate una regola. Quella regola intercetterà la spazzatura tipo «scarpe da corsa spedizione gratis resi» che non hai ancora visto — che è l’intero punto.

REVIEW → un umano dà il via libera alla regola. Leggi una riga — «modificatori non commerciali assenti dalla nostra tassonomia» — concordi che è giusta, e hai finito. Niente scorrere 5.000 righe. Il giudizio avviene una volta sola.

PUSH → le esclusioni atterrano al livello giusto. Poiché lo schema vale per tutto il sito, va su una lista di esclusioni condivisa, non su un singolo gruppo di annunci:

Shared negative list: "non-commercial modifiers"
  free · repair · history · wikipedia · manual · pdf
Applied to: all Search campaigns

Uno schema, una lista, ogni campagna protetta — e continua a guadagnarsi il pane la settimana dopo senza un altro passaggio umano. Quello è il momento in cui un lavoro settimanale da impazzire diventa una revisione di dieci minuti.

2. Ricerca delle parole chiave

Il secondo lavoro è quello che prima era una voce di budget a sé. La vera ricerca delle parole chiave — quella che mappa la domanda sulle tue pagine di destinazione e ti dice cosa manca sul sito — significava decine di ore di estrazione dati (AdWords API, box dei suggerimenti, OpenRefine), pulizia semi-manuale, classificazione per pagina di destinazione, e reportistica su trend / volume di ricerca / gap in cima.

Non è solo più economico. È migliore — più preciso, con le ore spese sulla validazione e sul giudizio invece che sull’idraulica. Quella combinazione, più economico e migliore, è esattamente ciò che si supponeva fosse impossibile. Ho scomposto la versione moderna dall’inizio alla fine nel blueprint per l’espansione di mercato e nell’analisi del gap di contenuti — entrambi con il vero output intermedio mostrato a ogni passaggio.

L’economia, prima e dopo

Questa è l’intera tesi in una tabella. Stessi lavori, stessa asticella di qualità — è cambiato solo il costo di farli. Cifre documentate dove le ho; il resto è ordine di grandezza dai due decenni di un’agenzia che fa questo mestiere.

Leggi la tabella dall’alto in basso e lo schema è lo stesso in ogni riga: la colonna della capacità non è cambiata — potevamo fare tutto questo nel 2019. La colonna del prezzo è crollata fino in fondo. Non è una storia di tecnologia. È una storia di periodo di ammortamento, e il periodo di ammortamento è ciò che decide se un’idea intelligente viene mai costruita.

Cosa significa davvero per il settore

Perché qui pianto una bandiera: l’opinione popolare — «l’AI sta facendo finire lo specialista PPC» — è pigra, e prenderla al contrario ha vere conseguenze sulla carriera di chi sta leggendo.

«L’era degli specialisti PPC sta finendo» è una sciocchezza. Sta succedendo il contrario. I bravi specialisti hanno passato anni frustrati dal fatto che la cosa intelligente — quella che vedevano chiaramente — «non valeva la pena costruirla». Ora possono costruirla. Automaticamente, in modo redditizio, su larga scala. Un intero scaffale di strategie PPC che prima erano antieconomiche o semplicemente assurde da tentare è improvvisamente sul tavolo.

Ciò che sta succedendo è una spaccatura più netta dentro il mestiere. Da un lato, junior senza immaginazione, visione o dimestichezza con gli strumenti — persone che trattano l’interfaccia della piattaforma come se fosse l’intero lavoro. Dall’altro, super-senior che padroneggiano gli strumenti, inventano i flussi di lavoro, pensano fuori dagli schemi della piattaforma, uniscono fonti di dati che nessun altro unisce, e si costruiscono dashboard specializzate invece di aspettare che un vendor rilasci una funzionalità.

E per uccidere l’ovvio fraintendimento: questa non è una storia di servizio più economico. Strumenti, potenza di calcolo e sviluppo costano ancora soldi. Il punto è che un progetto che prima era sei mesi di sviluppo ora è due settimane — così l’investimento finalmente ha senso. Il cliente ottiene un servizio drasticamente migliore a un prezzo simile, non uno peggiore per meno.

Perché torno a scrivere

Ho smesso di bloggare anni fa perché il divario tra l’idea e l’esecuzione economicamente sensata era troppo ampio per essere interessante. Quel divario si è appena chiuso. Quindi questo blog è tornato, e sarà concreto: casi d’uso con numeri reali, i flussi esatti, gli output reali — comprese le parti caotiche e i limiti. I primi approfondimenti sono già online; altri stanno arrivando.

Se la tua reazione a tutto questo è «potremmo finalmente fare quella cosa che abbiamo sempre voluto» — bene. È l’intero senso di questa era. Costruiamola.

1. PULL   Google Ads API → search-terms report (query, clicks, cost, conv)
2. GROUND Build a context pack the model can reason against:
            - sitemap.xml (what the site actually sells)
            - site / DB structure + breadcrumb taxonomy
            - product feed (id, title, category)
3. ASK    Prompt Gemma 4: "Given this site context, classify each query as
            relevant / irrelevant to what we sell. Return the irrelevant ones
            AND the PATTERNS behind them (token, intent, category mismatch)."
4. REVIEW Human validates the ~10 patterns, not 5,000 rows one by one.
5. PUSH   Add negatives back via the API at the right level (shared list for
            site-wide junk tokens; ad group for local noise).

FAQ