Utilizzare ads.txt e sellers.json per l'Intelligence Pubblicitaria (Guida Pratica)
ads.txt e sellers.json sono due file gratuiti, ospitati pubblicamente, che consentono di verificare chi è effettivamente autorizzato a vendere l'inventario di un editore. Ecco un flusso di lavoro pratico per usarli nella ricerca pubblicitaria.

ads.txt e sellers.json sono due piccoli file di testo ospitati pubblicamente che, letti insieme, indicano chi è autorizzato a vendere l'inventario pubblicitario di un editore e chi possiede effettivamente un determinato ID venditore nella catena. Per la ricerca competitiva e sulla catena di fornitura, sono una delle poche fonti di dati realmente fattuali e verificabili in un settore dove la maggior parte delle affermazioni (spesa, copertura, "inventario premium") non può essere controllata. Ecco come usarli concretamente.
Cosa contiene ciascun file, nella pratica#
ads.txt risiede in domain.com/ads.txt su qualsiasi dominio radice di un editore, ed è un elenco di testo semplice di ogni azienda autorizzata a vendere l'inventario di quell'editore, una riga per relazione. Una riga tipica appare così:
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
Questo è il dominio dell'exchange o SSP, l'ID account dell'editore con quell'exchange, se la relazione è DIRECT (l'editore tratta direttamente con loro) o RESELLER (è coinvolto un intermediario), e un ID opzionale dell'autorità di certificazione. sellers.json è l'immagine speculare, ospitata dall'exchange o SSP in exchange.com/sellers.json, elenca ogni account venditore con cui l'exchange collabora, il loro nome (a volte) e se sono un PUBLISHER, un INTERMEDIARY o BOTH. Confrontando i due è possibile confermare se il venditore dichiarato per uno slot pubblicitario ha effettivamente una relazione autorizzata, o se qualcosa non quadra.
Perché è importante per la ricerca competitiva e sulla brand safety#
La catena di fornitura pubblicitaria tra il budget di un inserzionista e la pagina di un editore raramente è un unico salto. Gli annunci spesso passano attraverso una o più relazioni di inventario rivenduto prima di arrivare, e ogni salto è un'opportunità di rappresentazione errata, spoofing di dominio o semplice confusione su chi gestisce realmente l'annuncio. ads.txt e sellers.json esistono proprio per rendere quella catena verificabile:
- Verificare l'affermazione di una rete. Se una rete native o DSP afferma di avere accesso diretto all'inventario di un editore, il file ads.txt di quell'editore lo elencherà come DIRECT. Se appare solo come reseller a più salti di distanza, o non compare affatto, è un'informazione utile prima di acquistare.
- Individuare il domain spoofing. Operazioni fraudolente a volte dichiarano di rappresentare l'inventario di un editore premium senza alcuna autorizzazione. Confrontare ads.txt con il dominio della reale richiesta di offerta è un metodo standard e gratuito per rilevare ciò.
- Capire perché un annuncio appare in un certo modo. Quando si traccia come gli strumenti di spy sugli annunci catturano gli annunci native, l'abbinamento ads.txt/sellers.json è spesso il modo più veloce per confermare quale rete ha effettivamente servito una determinata collocazione, piuttosto che indovinare dallo stile visivo del widget.
- Auditare i propri percorsi di fornitura. Se sei un editore, il tuo file ads.txt è anche il modo più rapido per verificare se un partner che hai interrotto (o mai autorizzato) è ancora elencato, o se un'integrazione ha aggiunto righe inattese.
Un flusso di lavoro pratico in cinque passaggi#
- Recupera l'ads.txt dell'editore. Scarica
https://[publisher-domain]/ads.txtdirettamente in un browser o con uno script semplice. È testo semplice, nessuna autenticazione necessaria. - Trova la riga per l'exchange o la rete che stai indagando. Cerca il dominio (es.
taboola.com,outbrain.como l'SSP pertinente) e annota l'ID account dell'editore e se è contrassegnato DIRECT o RESELLER. - Recupera il sellers.json di quell'exchange. Scarica
https://[exchange-domain]/sellers.jsone cerca l'ID venditore trovato al punto 2. - Confronta nome e tipo del venditore. L'entry di sellers.json corrisponde all'editore di partenza? È elencata come PUBLISHER (come previsto per una relazione diretta) o INTERMEDIARY (prevista per una catena di reseller)?
- Segui la catena se è una relazione RESELLER. Una riga RESELLER indica che un'altra entità si pone tra l'editore e l'exchange. Idealmente quell'intermediario dovrebbe includere il proprio oggetto SupplyChain (schain) nella richiesta di offerta, che registra ogni salto per una completa auditabilità, anche se i dati schain non sono visibili dai soli file ads.txt/sellers.json; richiedono l'accesso al flusso reale di offerte o a uno strumento che lo cattura.
Risultati comuni e loro significato#
| Cosa trovi | Significato probabile |
|---|---|
| La rete che indaghi non compare affatto nell'ads.txt dell'editore | O l'inventario non è autorizzato, o stai guardando il dominio sbagliato per quella collocazione specifica (comune con sottodomini e ibridi app‑web) |
| Elencata solo come RESELLER, a più livelli di profondità | L'inventario è rivenduto tramite intermediari; vale una maggiore attenzione prima di acquistare in volume |
| voce sellers.json contrassegnata "CONFIDENTIAL" | L'exchange sta nascondendo il nome del venditore, consentito dalla specifica ma riduce la trasparenza |
| ID editore appare con più domini exchange diversi come DIRECT | Normale; la maggior parte degli editori lavora direttamente con diversi exchange contemporaneamente |
Dove si colloca rispetto all'identificazione delle reti pubblicitarie più in generale#
ads.txt e sellers.json sono più efficaci per verificare le relazioni lato offerta, non per identificare quale rete ha effettivamente consegnato un annuncio specifico che stai osservando come acquirente. Per questo, solitamente si parte dalla catena di reindirizzamento del creativo, dalla firma visiva del widget e dai domini dei pixel di tracciamento coinvolti, come descritto in come identificare la rete pubblicitaria dietro qualsiasi annuncio. Pensa ad ads.txt e sellers.json come la traccia di audit per le relazioni di fornitura, e all'analisi creativa/di reindirizzamento come la traccia di audit per ciò che l'inserzionista sta realmente pubblicando.
Note sugli strumenti#
Entrambi i formati sono disciplinati dalle specifiche IAB Tech Lab, e le specifiche originali sono il riferimento definitivo se incontri un caso limite che questi file non coprono bene, come configurazioni multi‑account o campi OWNERDOMAIN. Per controlli manuali occasionali, un browser e una ricerca testuale sono davvero sufficienti; non serve uno strumento a pagamento per verifiche sporadiche. Diventa laborioso solo quando si scala a decine di editori o si monitorano cambiamenti nel tempo, ed è qui che una piattaforma che indicizza già la catena di fornitura tra le reti elimina il lavoro ripetitivo di fetch‑and‑diff. L'indice di intelligence pubblicitaria di OpenAdLibrary abbina questo contesto di percorso di fornitura con il creativo live reale e la pagina di destinazione tracciata, così non devi più incrociare manualmente tre fonti separate per ogni collocazione da controllare.
Perché è più rilevante per il native rispetto a quanto sembra#
Le reti native rivendono costantemente l'inventario. Un singolo slot widget di raccomandazione di contenuti su una pagina editore può passare direttamente attraverso la rete, tramite un reseller regionale, o tramite un wrapper di header‑bidding che media diverse fonti di domanda simultaneamente. Poiché gli annunci native raramente mostrano un branding visibile come un banner display, e poiché il widget spesso appare identico indipendentemente dalla rete che lo gestisce, ads.txt e sellers.json sono talvolta l'unico modo affidabile per confermare quale rete detiene legittimamente una determinata relazione editore, specialmente quando un sito editore esegue più widget native affiancati da fornitori diversi. È anche il motivo per cui le configurazioni di header‑bidding, dove più exchange competono per lo stesso slot in tempo reale, beneficiano della stessa verifica: ogni exchange partecipante dovrebbe avere la propria riga autorizzata nell'ads.txt dell'editore e la corrispondente entry in sellers.json.
Farlo su larga scala vs farlo una sola volta#
Controllare manualmente il file di un editore richiede pochi minuti. Controllarlo su una watchlist di cinquanta editori, in modo ricorrente, per intercettare nuove o rimosse relazioni, è un problema diverso, ed è il tipo di attività che tende a fermarsi una volta che la curiosità iniziale svanisce, anche se il valore deriva dal farlo ripetutamente. Se lo integri in un processo di ricerca continuativo anziché in un controllo sporadico, conviene abbinarlo al monitoraggio della catena di fornitura pubblicitaria che già utilizzi per le variazioni di creativi e pagine di destinazione, così le immagini lato offerta e lato creativo si aggiornano insieme invece di divergere.
Nota sui limiti#
Questi file sono auto‑dichiarati da editori e exchange. Nulla obbliga un editore a mantenere aggiornato ads.txt, e un file obsoleto o incompleto è comune, soprattutto su siti più piccoli. Considera un'entrata mancante o incoerente come un invito a indagare ulteriormente, non come prova automatica di frode; molti piccoli editori legittimi semplicemente non hanno aggiornato il file di recente. Il valore di ads.txt e sellers.json è che rendono la catena di fornitura verificabile, non che la rendano infallibile.







