ads.txt, app-ads.txt e sellers.json spiegati per i buyer programmatic

Ogni transazione programmatic si basa su un presupposto semplice: il seller che offre l’impression è effettivamente autorizzato a venderla. Per gran parte della storia del settore, i buyer non avevano un modo affidabile per verificare questo presupposto prima di investirci budget, e il domain spoofing, in cui seller fraudolenti si spacciano per publisher premium, faceva perdere agli inserzionisti budget reale senza alcuna possibilità di accorgersene in tempo reale.

Tre file hanno colmato questa lacuna: ads.txt, app-ads.txt e sellers.json. Insieme permettono a un buyer, o alla DSP che fa offerte per suo conto, di confermare che un determinato seller è autorizzato a vendere l’inventory di un determinato publisher prima ancora di piazzare un’offerta. Nessuno di questi file è complicato una volta chiariti i vari elementi, ma la terminologia si sovrappone al punto che proprietari di DSP e media buyer usano spesso i nomi in modo intercambiabile, anche se ciascun file risponde a una domanda diversa.

Questa guida spiega cos’è davvero ciascun file, come funzionano insieme tramite l’oggetto supply chain di OpenRTB, come dovrebbe controllarli in pratica il proprietario di una DSP e cosa succede alle campagne che saltano questo controllo.

Cos’è ads.txt e perché esiste

ads.txt sta per Authorized Digital Sellers. È un file di testo semplice che il publisher di un sito ospita in una posizione fissa e prevedibile: example.com/ads.txt. Il file elenca tutte le aziende autorizzate a vendere in modo programmatic l’inventory pubblicitario di quel publisher, una riga per ogni seller autorizzato.

L’IAB Tech Lab ha introdotto ads.txt nel 2017 proprio per fermare il domain spoofing, in cui un seller fraudolento dichiarava di rivendere inventory di un publisher noto che in realtà non lo aveva mai autorizzato. Prima di ads.txt, una DSP non aveva modo di verificare in modo indipendente questa affermazione: o si fidava della SSP che inoltrava la bid request, oppure no. ads.txt ha dato ai buyer una fonte di verità pubblica e controllata dal publisher con cui fare il confronto.

Ogni riga di un file ads.txt segue un formato fisso: il dominio della SSP, l’ID dell’account seller del publisher presso quella SSP, un tipo di relazione DIRECT o RESELLER e un ID facoltativo dell’autorità di certificazione. DIRECT significa che il publisher ha un account diretto con quella SSP. RESELLER significa che la SSP è autorizzata a rivendere l’inventory per conto di un altro intermediario, cosa frequente nelle configurazioni con ad network e aggregatori.

app-ads.txt: la stessa idea per le app mobile

ads.txt è stato pensato per i siti web, che hanno un dominio su cui ospitare il file. Le app mobile non hanno un dominio nello stesso senso, quindi nel 2019 l’IAB Tech Lab ha pubblicato app-ads.txt per colmare la stessa lacuna sull’inventory in-app.

Invece di risiedere nell’app stessa, il file app-ads.txt è ospitato sul dominio indicato come sito web dello sviluppatore nella scheda dello store dell’app, all’indirizzo developer-domain.com/app-ads.txt. Usa esattamente lo stesso formato di riga di ads.txt: dominio della SSP, ID dell’account seller, DIRECT o RESELLER e un ID di certificazione facoltativo. Una DSP che verifica una bid request in-app recupera il sito web dichiarato dallo sviluppatore nella scheda dello store indicata nella bid request, poi controlla il file app-ads.txt di quel dominio per la SSP che invia la richiesta.

sellers.json e l’oggetto Supply Chain: il quadro completo

ads.txt e app-ads.txt rispondono a una sola domanda: questa SSP è autorizzata a vendere l’inventory di questo publisher? Da soli, però, non dicono nulla al buyer sulle SSP e sugli intermediari che si trovano tra il publisher e la DSP quando è coinvolta una catena di reseller. È a questo che servono sellers.json e l’oggetto SupplyChain di OpenRTB, spesso indicato come schain.

sellers.json è un file che ogni SSP o exchange pubblica sul proprio dominio, elencando tutti gli account seller per conto dei quali opera, insieme al tipo di seller di ciascun account (publisher, intermediario o entrambi) e, facoltativamente, al nome e al dominio del seller. L’oggetto schain viaggia all’interno della bid request stessa ed elenca, in ordine, ogni intermediario attraverso cui l’impression è passata nel percorso dal publisher alla DSP. Incrociando i nodi dello schain con il file sellers.json di ogni SSP, il buyer può confermare che ogni passaggio della catena è una parte dichiarata e identificabile, e non un intermediario anonimo.

Usati insieme, questi quattro elementi permettono alla logica di acquisto di una DSP di confermare, su ogni singola bid request, che l’inventory offerto proviene da un percorso autorizzato dal publisher e non da uno non verificato o contraffatto.

Come verificare concretamente l’autorizzazione tramite ads.txt e sellers.json

Verificare l’autorizzazione della supply chain non è un’attività di configurazione da fare una volta sola. È un processo continuo, idealmente un passaggio automatizzato nella pipeline di bidding piuttosto che un audit manuale. Un processo di verifica pratico è questo:

1. Recupera e metti in cache i file ads.txt / app-ads.txt dei publisher e delle app che inviano traffico, aggiornando la cache a intervalli regolari, dato che i publisher modificano questi file senza preavviso.
2. Confronta il dominio del publisher o il bundle dell’app della bid request in arrivo con il file in cache, verificando che la SSP mittente compaia con il tipo di relazione corretto.
3. Recupera e metti in cache i file sellers.json di tutte le SSP collegate, anche in questo caso aggiornandoli periodicamente e non solo al momento dell’integrazione.
4. Analizza l’oggetto schain di ogni bid request e verifica che ogni nodo corrisponda a un account seller presente nel relativo file sellers.json.
5. Segnala o scarta le bid request in cui la SSP è del tutto assente da ads.txt, è elencata con il tipo di relazione sbagliato, oppure in cui un nodo dello schain non trova corrispondenza in sellers.json.
6. Registra gli errori di autorizzazione per SSP, in modo che uno schema di errori ripetuti da una stessa fonte, e non un caso isolato, venga segnalato per una revisione manuale della connessione.

Questo è uno dei controlli che fanno parte della checklist tecnica prima di collegare una nuova SSP a una DSP, e va ripetuto periodicamente anche dopo che la connessione è attiva, non solo una volta durante l’onboarding. Le fonti di supply cambiano nel tempo ciò che rappresentano, e una connessione pulita al momento della configurazione non è detto che resti tale.

Cosa succede quando questi file mancano o vengono ignorati

Un publisher senza file ads.txt, o una SSP senza file sellers.json, non è automaticamente fraudolento. Molti publisher più piccoli o più recenti semplicemente non hanno ancora configurato i file. Ma dal punto di vista del buyer, un inventory non verificabile ha un profilo di rischio più vicino a quello di un inventory non verificato che a quello di un inventory che ha superato un controllo.

Le DSP che saltano del tutto il controllo, o che lo eseguono una sola volta al momento dell’integrazione e mai più, tendono a incorrere sempre negli stessi problemi: budget speso su inventory soggetto a domain spoofing che non raggiunge mai l’audience reale che dichiara; uno schain con intermediari non risolti o anonimi, che rende impossibile sapere quante parti trattengono una quota della spesa media tra il publisher e la DSP; e incidenti di brand safety in cui un inserzionista scopre a posteriori che i suoi annunci sono passati attraverso un percorso di reseller che nessuno sul lato buy aveva effettivamente verificato.

Nessuno di questi esiti richiede che qualcuno sul lato buy agisca in malafede. È semplicemente ciò che accade di default quando un passaggio di verifica che potrebbe essere eseguito automaticamente viene lasciato fuori dalla pipeline.

Errori comuni dei buyer programmatic nella verifica della supply

• Controllare ads.txt una sola volta durante l’onboarding della SSP senza mai aggiornare il file in cache, perdendo le modifiche che i publisher apportano in seguito.
• Trattare una riga RESELLER come una riga DIRECT senza verificare che la catena di reseller sia effettivamente dichiarata in modo corretto in sellers.json.
• Saltare i controlli app-ads.txt sul traffico in-app perché il workflow era stato originariamente costruito solo per l’inventory web.
• Registrare gli errori di autorizzazione senza mai analizzarli, così che una connessione SSP che fallisce ripetutamente passi inosservata per mesi.
• Dare per scontato che una SSP grande e nota non richieda lo stesso livello di controllo di una più piccola, quando l’autorizzazione può fallire a livello del singolo account seller indipendentemente dalle dimensioni complessive della SSP.

Questo tipo di verifica della supply si affianca alla disciplina più ampia della supply path optimization, che si occupa di instradare ogni impression attraverso il percorso più pulito disponibile quando più fonti si sovrappongono. La verifica conferma che un percorso è legittimo; l’ottimizzazione decide quale percorso legittimo vale la pena usare. Una DSP ha bisogno di entrambe, e nessuna delle due sostituisce l’altra.

Perché tutto questo conta di più per i proprietari di DSP che per chi acquista tramite una piattaforma gestita

Gli inserzionisti che acquistano tramite una DSP gestita di terze parti in genere si affidano alla piattaforma per eseguire questi controlli per loro conto, senza avere molta visibilità su quanto siano approfonditi. Il proprietario di una DSP non ha questo livello di astrazione. La pipeline di verifica o è integrata nella logica di bidding della piattaforma o non lo è, e se non lo è, ogni campagna che passa dalla piattaforma eredita questa lacuna.

Questo è uno dei motivi pratici per cui chi sceglie la strada White Label, Licenza o Acquisizione con una piattaforma che ha già la verifica di ads.txt, app-ads.txt e sellers.json integrata nella pipeline di bidding parte da una posizione sostanzialmente diversa rispetto a chi costruisce la logica di verifica da zero. Le piattaforme di AdTech Europe eseguono questi controlli sulle oltre 1.000 integrazioni SSP già pre-collegate, e lo stesso processo di onboarding della supply che porta una nuova SSP nella piattaforma include la verifica che il suo sellers.json sia presente prima che il traffico inizi a scorrere.

Pronto ad acquistare inventory programmatic con supply path verificati?

AdTech Europe aiuta agenzie, ad network e team di media buying a possedere una DSP invece di noleggiarne l’accesso, con la verifica della supply chain tramite ads.txt, app-ads.txt e sellers.json integrata nella pipeline di bidding della piattaforma fin dal primo giorno. Che l’obiettivo sia una piattaforma white-label completamente gestita, una DSP in licenza o l’acquisizione completa del codice sorgente, i prezzi aggiornati per ciascun modello di proprietà sono pubblicati e mantenuti sempre aggiornati.

Per vedere come funziona la verifica della supply chain all’interno della piattaforma, o per discutere una configurazione di brand safety e prevenzione delle frodi per un caso d’uso specifico, prenota un incontro sulla strategia programmatic con il team di AdTech Europe.

FAQ

Qual è la differenza tra ads.txt e sellers.json?

ads.txt è pubblicato da un publisher ed elenca quali SSP sono autorizzate a vendere il suo inventory. sellers.json è pubblicato da una SSP ed elenca quali account seller quella SSP gestisce o rappresenta. In genere un buyer li verifica entrambi insieme all’oggetto schain per controllare l’intero percorso della transazione.

app-ads.txt è obbligatorio per l’inventory delle app mobile?

Non è obbligatorio per legge, ma è lo standard di settore per verificare i seller autorizzati dell’inventory in-app, e la maggior parte delle principali SSP e DSP considera non verificato il traffico app privo di una voce app-ads.txt valida.

Cosa significano DIRECT e RESELLER in un file ads.txt?

DIRECT significa che il publisher ha un rapporto diretto con quella SSP tramite un proprio account. RESELLER significa che la SSP è autorizzata a rivendere l’inventory per conto di un altro intermediario, cosa frequente quando l’inventory passa attraverso un ad network o un aggregatore prima di arrivare alla SSP.

Cos’è l’oggetto SupplyChain (schain)?

L’oggetto schain è un campo della bid request OpenRTB che elenca, in ordine, ogni intermediario attraverso cui un’impression è passata tra il publisher e la SSP che invia la bid request, così che il buyer possa ricostruire l’intero supply path e non solo l’ultimo passaggio.

Avere ads.txt garantisce che il traffico sia privo di frodi?

No. ads.txt conferma l’autorizzazione, non la qualità del traffico. Un seller correttamente autorizzato può comunque inviare traffico di bassa qualità o non valido, ed è per questo che la verifica della supply chain viene in genere affiancata da misure separate di controllo della qualità del traffico e di rilevamento delle frodi, senza sostituirle.

Chi è responsabile del controllo di ads.txt e sellers.json, la DSP o la SSP?

In pratica la responsabilità è del lato buy, perché è la DSP a decidere se fare un’offerta. Alcune SSP eseguono controlli propri prima di inoltrare le bid request, ma una DSP che si affida esclusivamente al filtraggio della SSP non ha alcuna verifica indipendente propria.