Dai 300 annunci dei competitor a un modello e ottieni quattro aggettivi: fai così invece

Hai raccolto trecento headline dei competitor da una libreria pubblica di annunci e vuoi capire cosa stanno davvero vendendo. La scorciatoia è incollarle tutte in chat e chiedere: "riassumi i punti di vendita di questi annunci". La risposta arriva in fretta: puntano sul rapporto qualità-prezzo, valorizzano l'esperienza utente, creano urgenza, mantengono un tono emotivo positivo. Quattro righe che avresti potuto scrivere senza leggere neppure un annuncio.

I dati non sono il problema. Le ad library e i creative center delle piattaforme sono pubblici, consultabili dal proprio account senza aggirare nulla. Il problema è la domanda. Hai chiesto al modello un giudizio aggregato, e lui può solo restituirti una risposta aggregata. Comprimere trecento annunci in quattro aggettivi significa perdere quasi tutta l'informazione e ritrovarsi con frasi al tempo stesso vere e inutili.

Per ottenere qualcosa di utilizzabile dall'analisi di grandi volumi di copy, bisogna prima definire cosa sia davvero "utilizzabile". "Punta sul rapporto qualità-prezzo" non lo è. "Promessa di risparmio, prova numerica e limite temporale: una combinazione presente nel 40% di questo campione e rivolta a un pubblico sensibile al prezzo" lo è, perché indica direttamente quali variabili impostare nel prossimo asset. Per arrivarci non basta una singola chiamata: bisogna dividere il lavoro in due fasi.

Perché chiedere un riassunto produce sempre una risposta vaga

Il fallimento dell'approccio one-shot è strutturale, non dipende da un prompt scritto male.

Stai chiedendo al modello di svolgere insieme due compiti di natura molto diversa: estrarre informazioni da ogni annuncio e classificare quelle informazioni. L'estrazione è deterministica: quale promessa fa l'annuncio, se porta una prova, sono risposte sostanzialmente univoche. La classificazione richiede invece un giudizio: decidere quali promesse appartengono alla stessa categoria e dove fissare i confini implica ragionamento. Se comprimi tutto in un'unica chiamata, il modello prende la scorciatoia: salta l'estrazione annuncio per annuncio, ricava un'impressione da una parete di testo e restituisce una manciata di aggettivi positivi che pensa tu voglia sentire.

Con l'approccio one-shot manca anche un output intermedio. Ottieni la conclusione "punta sul rapporto qualità-prezzo", ma non puoi risalire agli annunci da cui deriva, alla loro quota nel campione o agli eventuali controesempi. Ripeti l'analisi su un nuovo batch e la conclusione cambia. Un'analisi senza artefatti intermedi non è verificabile né iterabile.

Il metodo giusto: estrarre i campi, poi raggrupparli

L'approccio corretto prevede due fasi, con uno strato di campi strutturati nel mezzo.

Prima fase: estrarre i campi da ciascun copy, uno alla volta, usando uno schema fisso. Servono almeno quattro dimensioni: promessa principale, tipo di prova, leva di urgenza e pubblico implicito. Qui si analizza un solo annuncio per volta e si produce JSON rigoroso, senza testo discorsivo.

You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.

<copy>
{{one piece of copy}}
</copy>

Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):

- promise: [save money, save time, look better, get healthier, make money,
  learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
  none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
  none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
  (e.g. "night owls", "moms with kids", "junior designers")

Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}

Dopo aver estratto trecento annunci, hai trecento record strutturati anziché trecento blocchi di testo. A quel punto, "riassumi i punti di vendita" smette di essere un compito semantico nebuloso e diventa un problema sui dati: puoi contare, raggruppare e visualizzare la distribuzione.

La seconda fase è il clustering, ma il clustering va eseguito sui campi, non sul testo originale. Raggruppare il testo grezzo ti riporta nella stessa nebbia della somiglianza semantica. Raggruppare i campi significa lavorare su poche dimensioni discrete, con confini chiari.

Il prompt di clustering deve chiedere anche un controesempio

L'elemento decisivo del prompt non è "raggruppa questi dati". È obbligare il modello a fornire un controesempio.

Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.

<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>

Output three things in order:

1. Combination clustering
   Group by (promise x evidence x urgency), and give each group's record
   count and one representative sample.

2. Counterexample check
   For the top 3 groups by record count, pick one record per group whose
   audience clearly departs from the group's mainstream, and explain why it
   got grouped there. Is it really the same selling point, or did step one
   extract a field wrong?

3. Gaps
   Which combinations that should be common don't appear even once in this
   batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?

La seconda sezione è quella che rende utile questo prompt. Il modello tende spontaneamente ad assecondarti e, se non lo costringi a fare altrimenti, ogni cluster risulterà sospettosamente coerente con se stesso. Chiedergli di estrarre da un gruppo appena creato un record che non sembra adattarsi lo obbliga a continuare la verifica oltre il punto in cui si sentirebbe già soddisfatto. Può così emergere un confine di classificazione troppo grossolano oppure un campo estratto male nella prima fase.

Questa tecnica, che porta il modello a mettere in discussione il proprio lavoro, non vale soltanto per l'analisi degli annunci. Nel reverse engineering del codice si parla di sezione delle controprove: quando il modello riconosce una famiglia di algoritmi, non gli si crede sulla parola, ma gli si chiede "in cosa differisce dall'implementazione standard?". È lo stesso principio che contrasta la tendenza del modello ad annuire quando si lavora con codice offuscato e con il fingerprinting degli algoritmi. Nel clustering dei copy, il controllo dei controesempi svolge proprio questo ruolo.

Un modello diverso per ogni fase

Le due fasi richiedono capacità opposte: usare lo stesso modello per entrambe è puro spreco.

La differenza di costo di un ordine di grandezza dipende proprio da questa separazione. L'estrazione dei campi è l'unica fase che cresce linearmente con il volume: trecento annunci richiedono trecento chiamate, mille annunci mille chiamate. Il clustering si esegue una volta per batch. Metti il livello di ragionamento più costoso sul clustering, che gira una o due volte, e quello più economico sull'estrazione, che gira centinaia di volte: il costo totale cambia di un fattore dieci. Fare il contrario, ossia usare il modello costoso per l'estrazione e quello economico per il clustering, è lo spreco più comune che abbia visto: l'estrazione non richiede tanto ragionamento, mentre il clustering fallisce esattamente dove il modello economico è più debole.

Per capire quanto puoi risparmiare abbassando il livello del modello, non fidarti sulla parola: fai un test.

1. Prendi 20-30 annunci tra quelli che hai già raccolto.

2. Estrai i campi: passa lo stesso batch a claude-sonnet-5 e claude-opus-5, quindi confronta record per record l'accordo sui quattro campi.

3. Esegui il clustering: usa gli stessi record estratti con entrambi i livelli e verifica due aspetti. Il controllo dei controesempi mette davvero in discussione i gruppi oppure si limita a ribadire il candidato? E i gap indicano un'azione concreta da intraprendere?

4. La conclusione è immediata: se l'accordo nell'estrazione è alto, sposta questa fase sul livello economico e risparmia; se il livello economico non riesce a produrre un controesempio utile nel clustering, quella fase deve restare sul livello di ragionamento.

Primo errore: lasciare al modello la scelta delle categorie

L'errore più facile consiste nel non fornire un enum durante l'estrazione e lasciare che il modello inventi le categorie.

Su un singolo batch può sembrare tutto corretto. Il modello restituisce categorie dal nome ragionevole. Il problema arriva con il secondo batch: lo stesso tipo di copy, ma nomi diversi per le categorie, granularità modificata e confini spostati. Provi a confrontare i due batch per individuare una tendenza e scopri che non sono sovrapponibili. Lo "sconto" del primo batch equivale al "risparmio" del secondo? Non si può sapere. Se le categorie cambiano a ogni batch, ogni confronto tra batch è fittizio.

La soluzione è separare la definizione delle categorie dal loro utilizzo. Prima usa il livello con contesto lungo per leggere in un passaggio un grande batch di esempi, centinaia alla volta: è esattamente il suo lavoro. Da lì induci un insieme di enum completo e coerente nella granularità, lo rivedi manualmente e lo congeli. Da quel momento, l'estrazione può scegliere esclusivamente da quell'enum fisso, usando unknown come categoria residuale e senza mai inventarne una sul momento. Nel prompt di estrazione, la riga "pick only from the given enum, do not invent" rende concreto proprio questo vincolo.

In breve: le categorie le definisci tu, il modello si limita a riempire le caselle.

Secondo errore: scambiare la frequenza per efficacia

Dopo estrazione e clustering, viene naturale ordinare i risultati per numero di record e considerare il punto di vendita più frequente anche il "più efficace". È un passaggio sbagliato, e facile da non notare.

Una frequenza elevata dice soltanto: "tutti stanno scrivendo in questo modo". Non dice: "scrivere così funziona". La catena imitativa nella pubblicità è reale: un annuncio ottiene risultati, nel giro di una settimana tutto il settore lo replica e nel creative center compaiono decine di headline identiche da un giorno all'altro. Il conteggio di frequenza ingloba tutti questi imitatori e conclude che quel punto di vendita è il più diffuso, quando magari stanno tutti andando male e nessuno ha ancora smesso. La frequenza misura il conformismo, non l'effetto.

Per distinguere frequenza ed efficacia, devi associare dati di performance a ogni record. Ogni asset in una libreria pubblica di annunci riporta campi come visualizzazioni, like, CTR e simili. Quello che dovresti ordinare non è il numero grezzo di record, ma "la quota di una determinata combinazione di punti di vendita che raggiunge un percentile alto di performance". Come trasformare retention al secondo e percentili CTR in segnali significativi è il tema di un altro articolo. Qui conta sottolineare un punto: la tabella della frequenza e quella dell'effetto devono restare due tabelle separate; nel momento in cui le fondi, la conclusione è compromessa.

In questa fase, il compito del modello è l'attribuzione, non l'ordinamento. Passa al livello di ragionamento intermedio una combinazione molto frequente insieme alla sua distribuzione di performance e chiedi: "questa frequenza è alta perché funziona o perché si stanno copiando a vicenda?". Il modello deve giudicare sui numeri. Se sbaglia l'attribuzione, il costo è limitato, perché alla fine verifichi comunque sui dati reali di performance.

Terzo errore: analizzare solo gli annunci vincenti

Il terzo errore si nasconde nella fonte dati e, se non fai attenzione, può passare del tutto inosservato: ad library e creative center mostrano per impostazione predefinita gli annunci che hanno ottenuto buoni risultati. Voci come "hot ads" o "Top Ads" sono, di fatto, sopravvissuti già filtrati dalla piattaforma in base alla performance.

Fai clustering su un insieme di vincenti, individui le "caratteristiche comuni degli annunci di successo" e le copi. È un classico caso di survivorship bias, perché gli annunci falliti potrebbero avere esattamente le stesse caratteristiche. Immagina che il 90% dei vincenti usi un "limite temporale" e che tu concluda: "i limiti temporali funzionano". Se però anche il 90% degli annunci falliti usa limiti temporali, questa caratteristica non ha alcun potere discriminante. È uno standard del settore, senza relazione con il successo o il fallimento.

La soluzione è affiancare al gruppo dei vincenti un gruppo di controllo. Una libreria pubblica di annunci consente di solito filtri per settore, obiettivo di marketing e finestra temporale. Usa gli stessi filtri per trovare asset che hanno ricevuto impression ma registrano un engagement chiaramente basso, estrai e raggruppa anche quelli, poi confrontali con il gruppo dei vincenti. Ciò che conta non è "cosa hanno i vincenti", ma l'insieme differenziale: "cosa hanno i vincenti che i perdenti non hanno". Solo una caratteristica presente in questa differenza merita di entrare nel prossimo asset.

Non otterrai un campione completo di annunci perdenti, ed è normale. Anche un piccolo gruppo di controllo a bassa performance è molto più credibile di una conclusione basata soltanto sulle Top Ads.

L'output finale è una tabella di variabili, non un riassunto

Una volta completate le due fasi ed evitati i tre errori, il prodotto finale non dovrebbe essere un paragrafo del tipo "i competitor in questo batch puntano su XX". Sarebbe un ritorno alla vaghezza iniziale. Il risultato deve essere una tabella di variabili:

• Quali valori assume ogni dimensione: promessa, prova, urgenza e pubblico.

• Quali combinazioni sono già validate come efficaci, cioè presenti nell'insieme differenziale e alte nel percentile di performance.

• Quali combinazioni nessuno ha ancora provato, emerse dalla sezione dei gap.

Questa tabella può diventare direttamente l'input per una generazione. Le combinazioni già validate come efficaci servono per produrre varianti in volume; quelle ancora vuote diventano test esplorativi a basso costo. Le variabili del copy alimentano un modello testuale per scrivere script, mentre le variabili visive e di tono alimentano modelli di immagini e video per produrre asset: così si chiude la catena che va dal copy dei competitor al tuo spot finito. Questa tabella di variabili è esattamente ciò che legge la fase di brief nella creative pipeline.

Il clustering non serve a produrre un bel grafico di classificazione. Serve a creare la tabella che guida il prossimo batch di produzione.

Quattro livelli di modello, una sola chiave

Il flusso descritto richiede quattro livelli: quello economico e ad alta concorrenza per l'estrazione, quello a contesto lungo per definire le categorie, quello di ragionamento per il clustering e quello di ragionamento intermedio per l'attribuzione. Arrivano da più fornitori, con SDK, sistemi di autenticazione e formati di errore diversi. Collegare il client a varie interfacce solo per cambiare modello tra una fase e l'altra non vale lo sforzo: è il vero motivo per cui molti usano un solo modello per tutto e finiscono nello spreco descritto prima, con un livello costoso che brucia budget nell'estrazione oppure uno economico incapace di produrre controesempi nel clustering.

AIReiter elimina questa complessità: una chiave, un'interfaccia compatibile con OpenAI e tutti e quattro i livelli dietro le quinte. Per cambiare modello basta modificare il campo model nel body della richiesta.

# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
  }'

# Cluster: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Frequency attribution:
#   "model": "gpt-5.6-sol"

Se usi già l'SDK OpenAI, imposta base_url su https://aireiter.com/api/v1 e non cambiare altro. Con l'SDK Anthropic, usa POST /api/v1/messages con la stessa chiave.

Sul prezzo, i modelli Claude hanno uno sconto del 30% rispetto al listino e i modelli GPT costano la metà: lo sconto incide esattamente sulla voce principale di questo flusso. L'estrazione dei campi è l'unica fase che cresce linearmente con il volume: trecento annunci richiedono trecento chiamate, mille annunci mille chiamate. Viene eseguita sul livello Sonnet più economico, con un ulteriore 30% di sconto, ed è qui che si concentra la maggior parte del risparmio. Clustering e attribuzione girano poche volte per batch, quindi usare lì un livello di ragionamento non pesa. La definizione delle categorie viene eseguita una volta per batch su Kimi K3, disponibile con la stessa chiave e pensato per il contesto lungo.

• Ottieni una chiave API

• Provalo senza registrarti: prima analizza manualmente alcuni annunci, confronta il livello economico e quello di ragionamento sull'accordo nell'estrazione e sui controesempi del clustering, poi automatizza il processo quando il metodo regge.

Conclusioni

L'analisi di grandi quantità di copy pubblicitari produce risposte vaghe non perché il modello sia debole, ma perché hai compresso estrazione e classificazione in una sola chiamata.

Dividi il lavoro in due: estrai campi strutturati per annuncio con un enum congelato, eseguendo centinaia di chiamate sul livello economico; poi raggruppa i campi e costringi il modello a portare un controesempio, eseguendo una sola chiamata sul livello di ragionamento. Tieni presenti i tre errori: non lasciare che il modello inventi categorie sul momento, non interpretare la frequenza come efficacia e affianca ai vincenti un gruppo di controllo. Il risultato deve essere una tabella di variabili che guida il batch produttivo successivo, non una frase come "punta sul rapporto qualità-prezzo".

In questo flusso, il modello svolge due ruoli distinti: un estrattore economico e un classificatore disposto a criticare il proprio lavoro. Usali separatamente, sui livelli adatti, e qualche centinaio di annunci produrrà insight operativi. Affidando tutto a un unico modello, otterrai soltanto aggettivi.