In breve: L'automazione del PPC non è diventata possibile all'improvviso. È diventata abbordabile. L'AI non ha aggiunto capacità; ha fatto crollare il periodo di ammortamento di quelle che avevamo dal 2019, trasformando progetti da sei mesi in progetti da due settimane. Vincono i super-senior che finalmente possono costruire i flussi che prima non si ripagavano mai, come ripulire migliaia di query spazzatura con un modello che gira su un PC normale.
Una volta ho visto il nostro architetto di sistema, un uomo con venticinque anni di ingegneria alle spalle, passare due giorni interi a leggere la documentazione della Google Ads API prima che una sola query restituisse dei dati. Due giorni, una query. È il miglior ingegnere che conosca, e gli ci sono voluti comunque due giorni. Era semplicemente il biglietto d’ingresso che la piattaforma faceva pagare a chiunque volesse il potere vero.
Ho passato circa vent’anni nel PPC, dodici dei quali a scrivere codice contro quell’API. Tra il 2015 e il 2017 ho gestito ppc-scripts.eu, un piccolo blog sui Google Ads Scripts, quando automatizzare il PPC non era ancora di moda. Poi ho smesso di scrivere. Non perché le idee si fossero esaurite. Il divario tra «questo è possibile» e «questo vale la pena farlo per un cliente» è rimasto ostinatamente ampio per un decennio, e i modi di descrivere strumenti che nessuno può permettersi prima o poi finiscono.
Questa primavera ho consegnato un’analisi di espansione di mercato, sedici prodotti con i prezzi in cinque paesi e mappe di calore, in circa sei ore. Fatta a mano sono più o meno 400 ore di lavoro. Costruita come software su misura alla vecchia maniera, sono due mesi di sviluppo e una fattura da 16.000 a 20.000 € che nessun cliente ha mai voluto pagare. Stesso deliverable, e il prezzo è crollato. L’analisi non è diventata più intelligente questa primavera. Si è rotta l’economia del costruirla.
Quasi tutto ciò che hai letto sull’AI che uccide lo specialista PPC prende il meccanismo al contrario. L’AI non ha cambiato cosa puoi fare nella ricerca a pagamento. Quasi tutto era possibile da sempre, e quasi tutto esisteva già nel 2019. Ciò che ha cambiato è chi può permetterselo. Questo articolo è la prova, raccontata dall’interno degli strumenti con cui costruisco davvero. Due ere che hanno reso l’automazione troppo costosa per valerne la pena, il momento in cui i conti si sono ribaltati, e un lavoro reale, ripulire le query di ricerca spazzatura con un modello open source in locale, scomposto passo per passo.
- L'AI non ha aggiunto quasi nessuna capacità nuova al PPC. Ha fatto crollare il periodo di ammortamento di quelle che avevamo dal 2019, e questo da solo riscrive cosa vale la pena costruire.
- La valuta decisiva non sono più le righe di codice. Ciò che scarseggia ora sono le idee più la conoscenza del dominio, sapere cosa costruire e quali dati incrociare.
- Il mestiere si sta spaccando in due. Chi lascia passare gli strumenti si congela; chi conosce la Google Ads API fino al midollo e combina i dati con l'immaginazione si stacca.
- L'esempio scomposto qui dentro mostra un modello open source in locale che ripulisce migliaia di query spazzatura in pochi minuti, un lavoro che prima era rigorosamente manuale.
L’era degli Scripts: qualche giorno per uno script «semplice»
Il limite non è mai stato la tecnologia, e voglio mostrartelo 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», diciamo mettere in pausa le parole chiave oltre una soglia di CPA o segnalare URL finali rotti, era questione di qualche giorno di scrittura e debug una volta gestiti i casi limite, le quote e i fallimenti silenziosi.
Poi arrivava la parte che nessuno aveva messo a budget. Eseguirlo su più account significava una copia dello script per account, 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.
Persino il layer facile di automazione era frenato dal costo di manutenzione, non dalle capacità. Tienilo a mente. È lo schema di tutto ciò che segue.
L’era dell’API: due giorni per la prima query, due anni per un tool
La Google Ads API, all’epoca l’AdWords API, era il vero potere e il vero muro. I due giorni che il mio collega ha passato nella documentazione non erano una critica a lui. Era la superficie a cui si iscriveva chiunque.
Ci siamo buttati comunque a capofitto e abbiamo costruito PPC Robot, uno strumento di reportistica e operazioni profondamente personalizzabile. Tecnicamente bellissimo, genuinamente potente. È costato anche due sviluppatori, a tempo pieno, per due anni, e lo sviluppo necessario per tenerlo in vita si aggirava intorno ai 100.000 € l’anno. Non si è mai ripagato. Copriva una frazione di ciò che serviva davvero ai nostri specialisti PPC, 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:
Cosa ha prodotto davvero quel motore
- Controllo URL finali 404 / rotti su più account rilasciato
- Generatore di campagne Shopping dal feed rilasciato
- Segmentazione Shopping / Performance Max rilasciato
- Pipeline BigQuery + reportistica in Sheets / Excel rilasciato
- Controlli stato account Merchant Center rilasciato
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 keyword, uno strumento di espansione, la traduzione degli annunci, un generatore Shopping, si misurava in mesi di due senior, e nessun cliente avrebbe pagato quanto costa.
Il limite non è mai stato la tecnologia. Era il periodo di ammortamento.
Il primo lavoro che si è liberato: le query di ricerca spazzatura
«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 sono cose che eseguo, non ipotesi, e per il primo ti faccio vedere il flusso intero.
Ripulire un account dalle query di ricerca irrilevanti ha grande valore ed è di una noia mortale, e fino a poco fa non c’era un modo onesto di automatizzarlo. Le regole intercettano un token esatto, ma decidere se «storia nike air max» merita un clic pagato richiede comprensione del testo. Così il lavoro restava un’analisi semi-manuale di migliaia di query, scrutando gli schemi a occhio, aggiungendo le esclusioni a mano. Immagina un negozio di scarpe da corsa che paga clic su «riparazione scarpe da corsa», «storia nike air max» e «scarpe da corsa gratis», niente di ciò che vende o ripara. Moltiplicalo per migliaia di righe, ogni settimana, su ogni account. È il lavoro che nessuno vuole e di cui tutti hanno bisogno.
Ecco cosa è cambiato. Uno script Python tira giù le query dalla Google Ads API e le passa a un modello open source, il Gemma 4 di Google, che quasi ogni PC attuale può eseguire. Legge migliaia di query in pochi minuti. E quando lo ancori nel contesto del cliente, la sitemap, la struttura del sito e del database, la tassonomia dei breadcrumb, il product feed, smette di indovinare e comincia a ragionare. Esclude bene e dà un nome agli schemi dietro la spazzatura, più in fretta di qualsiasi scrematura umana. Ecco quel flusso in cinque passaggi concreti.
PULL · ottieni le query di ricerca grezze
Tira giù il report dei termini di ricerca dalla Google Ads API. Query, clic, costo, conversioni. Perché per prima cosa: questa è l’evidenza, i soldi reali già spesi su ciascun termine. Vuoi il costo agganciato a ogni riga, così il modello può distinguere la spazzatura costosa da quella innocua. Ottieni: una tabella piatta di ogni termine che l’account ha pagato nella finestra.
GROUND · costruisci un pacchetto di contesto sul sito
Metti insieme ciò che il sito davvero è, in una forma che il modello possa leggere. La sitemap XML, la tassonomia dei breadcrumb, il product feed (id, titolo, categoria) e la struttura di database e categorie. Perché qui si gioca tutto: un modello senza contesto tira a indovinare; un modello che sa che non hai una categoria «riparazione» o «noleggio» ragiona. Ottieni: un pacchetto di contesto che trasforma il modello da indovino a qualcosa che conosce il tuo catalogo.
ASK · classifica le query e dai un nome agli schemi
Dai in pasto a Gemma 4 i termini più il pacchetto di contesto. Classifica ogni query come pertinente o non pertinente a ciò che vendiamo e, la parte importante, restituisci gli schemi dietro quelle non pertinenti (un token, un intento, una categoria non corrispondente). Perché gli schemi e non le righe: segnalare 200 query spazzatura ti fa risparmiare un pomeriggio; dare un nome alla categoria di spazzatura esclude le prossime mille che non hai nemmeno ancora visto. Ottieni: una lista di query non pertinenti e, sopra di essa, la manciata di regole che l’ha generata.
REVIEW · valida le regole, non le righe
Un umano legge gli schemi, da cinque a dieci, non 5.000 singole righe. Perché qui si risparmia tempo: il giudizio si applica una volta per regola invece di una volta per query, e una regola sbagliata è evidente in un modo in cui una singola riga etichettata male non lo è mai. Ottieni: una lista breve e affidabile di schemi di esclusione su cui un umano ha davvero dato il via libera.
PUSH · aggiungi le esclusioni al livello giusto
Rimanda indietro le esclusioni approvate tramite l’API al livello corretto, gruppo di annunci, campagna o lista condivisa, a seconda di quanto è ampio lo schema. Perché il livello conta: un token spazzatura valido per tutto il sito («gratis», «wikipedia») va su una lista condivisa, non sepolto in un solo gruppo di annunci. Ottieni: l’account ripulito e una lista di esclusioni riutilizzabile che continua a funzionare la settimana dopo.
Per capire perché funziona, guarda cosa restituisce davvero il passaggio ASK per il nostro negozio di scarpe da corsa. Le righe sono illustrative, la forma è esattamente ciò che torna indietro, e 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. Un umano legge quella riga, conferma che è giusta, e la regola continua a intercettare spazzatura tipo «scarpe da corsa spedizione gratis resi» che non hai ancora visto. Quello è il momento in cui una commissione settimanale di una noia mortale diventa una revisione di dieci minuti.
Il titolo detto sottovoce è che basta un modello open source eseguito in locale. Non ti serve un’API di frontiera perché questo si ripaghi, e i tuoi dati non escono di casa. È l’economia che si muove, non la capacità.
Il secondo lavoro: la ricerca keyword
Questo 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, in cima, reportistica su trend, volumi e gap.
Un progetto di ricerca keyword, prima e ora
- Il vecchio metodo (estrai, pulisci, classifica, riporta) 50–100 ore
- Quanto il cliente pagava per questo ≈ 2.000–4.000 €
- Lo stesso progetto oggi, con una buona skill una manciata di ore
- E l'output è più accurato
Non è solo più economico. È migliore, più preciso, con le ore spese sulla validazione e sul giudizio invece che sull’idraulica. Più economico e migliore è esattamente la combinazione che doveva essere 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.
La parte che ancora mi sorprende è la cadenza. Una ricerca così prima era un progetto annuale che il cliente approvava una volta. La stessa pipeline ora può girare ogni giorno, guardando la domanda muoversi invece di fotografarla una volta l’anno.
L’economia, prima e dopo
Questa è l’intera tesi in una tabella. Stessi lavori, stessa asticella di qualità; si è mosso solo il costo di farli. Cifre documentate dove le ho, ordine di grandezza da vent’anni di agenzia per il resto.
| Il lavoro | Il vecchio metodo | Oggi |
|---|---|---|
| Analisi di espansione di mercato (prezzi multi-mercato) | ~400 ore a mano · o 2 mesi di sviluppo, 16.000–20.000 € | 6 ore |
| Ricerca keyword (un progetto) | 50–100 ore · 2.000–4.000 € fatturati | una manciata di ore · più accurato |
| Triage delle query da escludere | analisi semi-manuale, migliaia di righe a mano | script + modello locale che dà un nome agli schemi |
| Rilasciare una nuova funzionalità di automazione | mesi (2 dev × 2 anni per un intero tool) | settimane |
| Tenere in vita un motore di reportistica | ~100.000 € / anno, mai ripagato | quasi zero con un modello locale |
Leggi la tabella dall’alto in basso e lo schema si ripete in ogni riga. La colonna delle capacità non si è mossa; tutto questo sapevamo già farlo nel 2019. La colonna del prezzo è sprofondata. E il periodo di ammortamento è ciò che decide se un’idea intelligente viene mai costruita.
L’AI non ha tanto sbloccato nuove capacità PPC quanto fatto crollare il periodo di ammortamento di quelle vecchie. Quando un progetto da sei mesi diventa un progetto da due settimane, l’intero backlog di «ci piacerebbe, ma non si ripagherebbe mai» si svuota all’improvviso.
Come si presenta quando ci punti davvero
Lynt è un’agenzia orientata alla tecnologia dal primo giorno. Abbiamo in squadra un architetto di sistema, un ingegnere della sicurezza, un data analyst che costruisce la BI e uno sviluppatore a tempo pieno, cosa che un’agenzia normale semplicemente non ha. Per anni è stato difficile puntare quel muscolo sui problemi PPC, per tutte le ragioni di ammortamento di cui sopra. Ora si accumula.
Boostera, il nostro strumento, ha richiesto due anni di sviluppo. Arricchisce i feed di Google Merchant Center con l’AI, così le campagne Shopping girano su dati di prodotto migliori di quelli che dà il feed grezzo. Intorno c’è l’idraulica che la nuova economia finalmente giustifica. Scraping dei prezzi dei concorrenti per mercato, del tipo che ha alimentato le tabelle dei prezzi nel blueprint di espansione. Pipeline di ricerca keyword che girano a calendario invece di una volta l’anno. Reportistica di business a livello di cliente in BigQuery con le previsioni sopra. Server MCP su ogni servizio che tocchiamo, così un agente AI può attingere a ciascuno di essi nel mezzo di un compito.
Due anni fa avrei dovuto difendere ognuno di quei progetti dalla stessa domanda, se si ripagherà mai. Oggi la domanda quasi non si pone. Quando costruire diventa economico, l’infrastruttura smette di essere un lusso e comincia a essere il fossato.
Cosa significa davvero per il settore
L’opinione popolare dice che l’AI sta facendo finire lo specialista PPC. Prenderla al contrario ha vere conseguenze sulla carriera di chi sta leggendo, quindi pianto una bandiera.
«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 davvero è una spaccatura più netta dentro il mestiere. Da un lato ci sono quelli che trattano l’interfaccia della piattaforma come se fosse l’intero lavoro e lasciano passare gli strumenti nuovi. Nessuno li licenzia domani. Si congelano mentre il lavoro si sposta. Dall’altro ci sono quelli che conoscono la Google Ads API fino al midollo, uniscono fonti di dati che nessun altro unisce e si costruiscono dashboard specializzate invece di aspettare che un vendor rilasci la funzionalità. Dodici anni a scrivere codice contro quell’API mi hanno insegnato dove vive davvero il vantaggio del secondo gruppo. Il codice è diventato economico. Ciò che resta scarso è l’immaginazione e la conoscenza del dominio, sapere quali dati combinare e perché.
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 erano da quattro a sei mesi di due sviluppatori senior ora esce in settimane, così l’investimento finalmente ha senso. Il cliente ottiene un servizio drasticamente migliore a un prezzo simile.
Perché torno a scrivere
Ho smesso di bloggare nel 2017 perché il divario tra un’idea e un’esecuzione economicamente sensata era troppo ampio per essere interessante. Quel divario si è appena chiuso. Quindi questo blog riprende da dove ppc-scripts.eu si era fermato, e resta concreto. Casi d’uso con numeri reali, i flussi esatti, gli output veri, parti caotiche e limiti inclusi. I primi approfondimenti sono già online.
Da qualche parte nel tuo backlog c’è l’automazione che hai accantonato anni fa perché non si sarebbe mai ripagata. Tirala fuori e rifai i conti. Se si sono ribaltati come i miei, sai già cosa costruire adesso. E se vuoi confrontare gli appunti, sai dove trovarmi.
FAQ
Stai dicendo che le agenzie dovrebbero licenziare i loro specialisti PPC?
Esattamente il contrario. Gli specialisti che capiscono la strategia e gli strumenti ora valgono di più, perché possono finalmente realizzare le idee che prima erano antieconomiche. A perdere valore è il puro premere bottoni nell’interfaccia della piattaforma.
La cifra dei 100.000 €/anno e dei due sviluppatori per due anni è esatta?
No, prendila come ordine di grandezza. Il punto non è l’importo preciso in euro. Un singolo motore di reportistica interno costava una cifra a sei zeri l’anno e non si è mai ripagato. È di questa economia che parla tutto l’articolo.
Mi serve un costoso modello di frontiera per farlo?
Non per lavori come il triage delle query da escludere. Un modello open source capace come Gemma 4, eseguito in locale con un buon contesto del sito, fa il lavoro. Così sia i dati sia i costi restano sotto il tuo controllo.
Riguarda solo le query di ricerca?
No, è solo il lavoro più facile da guardare mentre gira. La stessa economia si è spostata per l’analisi di espansione di mercato (sei ore invece di ~400), per lo scraping dei prezzi dei concorrenti per mercato, per la ricerca keyword che gira ogni giorno invece di una volta l’anno e per l’arricchimento dei feed con Boostera. Scegli la commissione che hai accantonato e rifai i suoi conti.
Quindi è solo hype con una mano di vernice fresca?
Se lo fosse, non avrei ricominciato a scrivere. Il cambiamento è circoscritto e reale, un periodo di ammortamento crollato su capacità che avevamo già. È un cambiamento di business, non di magia, ed è per questo che il backlog si svuota all’improvviso.
Cosa ci sarà davvero su questo blog?
Casi d’uso concreti con i numeri, i flussi che ci stanno dietro e gli output, limiti e modalità di fallimento inclusi. Meno manifesto, più «ecco la cosa esatta che abbiamo eseguito e cosa ha restituito».