I sju artiklar har vi nu beskrivit impressionen: vad som är till salu, vem som tittar, på vilken enhet, under vilka regler, på vems gemensamma språk.
Denna gång handlar frågan inte alls om impressionen. Den handlar om den resa den gjorde för att nå köparen – och om alla som var med på vägen är de som de utger sig för att vara.
Det finns tre standarder som besvarar det: ads.txt, sellers.json och SupplyChain-objektet (schain). Nästan alla lägger dem i samma låda med etiketten "ad fraud-verktyg". Jag vill hävda att det är fel låda.
De fångar inte bedrägerier. En målmedveten bedragare kan också fylla i ett SupplyChain-objekt. Det de gör är något stillsammare och mer användbart: De gör supply pathen ansvarig. schain är inte ett lås på dörren. Det är ett underskrivet kvitto för varje hand impressionen har passerat.
Förra gången argumenterade jag för att OpenRTB är ett kontrakt, inte en spec – och att användbara idéer börjar livet i ett blankt "ext"-fält och flyttar upp i kärnan. Jag använde source.ext.schain, som blev source.schain i OpenRTB 2.6, som ett av de tre exemplen. Det här är artikeln om vad den uppflyttade kandidaten faktiskt gör.
Fyra begrepp, i all hast:
*ads.txt = "Authorized Digital Sellers". Dess app- och CTV-syskon är app-ads.txt, som gör samma jobb för miljöer som inte har någon webbplatsrot att hosta filen på.
Den sista definitionen är den du ska hålla fast vid. STEP Network är ett mellanled. När vi säljer en publishers impression är vi en nod i det bid requestets supply chain – en rad JSON som en köpare i andra änden kan slå upp.
Här är ramen för hela artikeln. De tre standarderna är inte konkurrenter, och de är inte redundanta. De besvarar var sin fråga, och de fungerar bara tillsammans.
Två av dem är uppslagsverk, skrivna en gång och lästa ofta. En är ett levande kvitto, stämplat på varje enskild auktion. Magin är att de korsrefererar varandra: Annonssystemets domän i din ads.txt är samma asi i schainen; ditt konto-ID i ads.txt är samma sid i schainen och samma seller_id i annonssystemets sellers.json. Samma värden, tre dokument. En köpare kan triangulera.
Visualisering genererad med claude.ai
Vi säljer två sorters inventory, och ads.txt-filerna avslöjar skillnaden direkt.
jv.dk är en JFM-titel som vi på STEP Network driver som owned-and-operated*. Här är en förkortad ads.txt, men du kan slå upp hela filen på jv.dk/ads.txt:
#JFM JV.DK stepnetwork.dk, 500, DIRECT adform.com, 122, DIRECT appnexus.com, 7779, DIRECT, f5ab79cb980f11d1 google.com, pub-5204991212765133, DIRECT, f08c47fec0942fa0 omnicommediagroup.com, S012, RESELLER ... OWNERDOMAIN=stepnetwork.dk MANAGERDOMAIN=stepnetwork.dk
*STEP Network är ett dotterbolag till JFM, och därför "äger" vi JFM-domänerna i schain-sammanhang.
Boligsiden.dk är annorlunda. Boligsiden A/S äger den sajten; vi representerar den som mellanled. Samma annonssystem, men se vad som ändras:
#STEP boligsiden.dk stepnetwork.dk, 9, DIRECT adform.com, 122, RESELLER appnexus.com, 7779, RESELLER, f5ab79cb980f11d1 omnicommediagroup.com, S012, RESELLER ... OWNERDOMAIN=boligsiden.dk MANAGERDOMAIN=stepnetwork.dk
Tre skillnader bär hela distinktionen mellan ägt och representerat:
Ingen tvingar fram den ärligheten. Formatet ger dig bara utrymme att vara exakt – och att vara exakt är det som gör att du får betalt.
Titta igen på en rad som förekommer i båda filerna:
omnicommediagroup.com, S012, RESELLER
Vi auktoriserar byråkoncernen Omnicom Media Group, konto S012, att vidaresälja. Följ nu det ID:t in i Omnicoms egen sellers.json:
{ "seller_id": "S012", "name": "STEP Network", "seller_type": "BOTH", "domain": "stepnetwork.dk" }
Där står vi som STEP Network – inne i byråns identitetsregister. Och seller_type är BOTH: Vi är publisher (av vårt ägda inventory) och mellanled (som vidaresäljer in i Omnicoms marketplace). Och sedan, i vår egen sellers.json:
{ "seller_id": "500", "seller_type": "PUBLISHER", "name": "JFM A/S", "domain": "jv.dk" }
Så en enskild jv.dk-impression såld genom byråvägen lyder, i supply chain-termer: jv.dk, ägd av JFM → såld av STEP → vidaresåld genom Omnicom → köpt av annonsören. Tre filer, två sellers.json-register, en enhet (vi) som förekommer i båda – och varje hopp kan kontrolleras i båda ändar.
Det är den del folk missar med att arbeta som nätverk. I samma ögonblick som din demand-partner är en byrå som kör sin egen sellers.json förekommer du inte bara i dina egna böcker – du förekommer i deras, och seller_type: BOTH utför verkligt arbete. En köpare som slår upp "BOTH" kan inte utifrån de statiska filerna ensamma anta om du äger inventoryt eller vidaresäljer det i ett givet request. Bara den levande schainen avgör det.
Inget av det här står stilla när auktionen kör. Schainen sätts ihop medan requestet reser: Varje system som rör det – ad-server, sedan SSP, sedan vidare mot DSP:n – lägger till sin egen nod innan det skickas vidare.
"source": {
"schain": {
"ver": "1.0",
"complete": 1,
"nodes": [
{ "asi": "stepnetwork.dk", "sid": "500", "hp": 1 },
{ "asi": "omnicommediagroup.com", "sid": "S012", "hp": 1 }
]
}
}
När det når köparen är nodes-arrayen den samlade historien om alla som har hanterat det. Och den mottagande sidan förväntas kontrollera den: parsa varje nod och bekräfta att asi och sid är auktoriserade i publisherns ads.txt och kan slås upp i annonssystemets sellers.json. Uppslagsverk, möt det levande kvittot. Den rundturen – requestet går ner genom röret och verifieras tillbaka mot de statiska filerna – är hela poängen med lagret.
complete-flaggan är den ärliga delen av specen. complete: 1 betyder att kedjan rymmer varje nod hela vägen tillbaka till inventoryts ägare. complete: 0 betyder att det gör den inte – och reglerna är strikta kring hur man erkänner det: Vidaresäljer du inventory som anlände utan ett SupplyChain-objekt skapar du ett, sätter complete: 0 och lägger bara till din egen nod. Du får uttryckligen inte kopiera kedjan vidare och låtsas att du inte var där.
Visualisering genererad med claude.ai
Så vad händer med en inkomplett kedja? Här kommer det som överraskar folk: Den handlas fortfarande. Köpare kan konfigurera sina DSP:er att avvisa allt utan en komplett kedja, och några gör det. Men för det mesta avvisar de inte. De drar av på priset.
Tillit prissätts här – den upprätthålls inte.
Supply path-benchmarks från 2026 gör det konkret: Vidaresåld ("rebroadcasting") supply står nu för cirka 27 % av alla bid requests men drar bara in omkring 18 % av spenden – ett monetariseringsunderskott på nästan 50 % per bid request mätt mot de mest direkta vägarna. Vidareförsäljningseran är inte över. Den prissätts bara om – nedåt.
Jag vill vara ärlig om vår egen sida av det här: Jag kan inte visa dig en hög röriga data om "oauktoriserad demand", för det tillåter vi inte i STEP Network. Vi kör strikt med våra partner, så våra kedjor är kompletta som policy, inte som förhoppning. Den disciplinen är inte byråkrati. Den är själva produkten.
Som köpare skriver du inte det här lagret, och som läsare ser du det knappt. Men säljer du inventory är det något av det arbete i huset som ger mest effekt för minst glamour:
Tumregeln jag vill lämna dig med: Om en köpare inte kan spåra impressionen tillbaka till dig på tre uppslag, betalar de dig som om de inte kan.
Om allt det ovanstående låter som många rörliga delar att hålla ärliga – så är det för att det är det. Siffrorna är tankeväckande: Topp-20-publisherna integrerar i genomsnitt med 24,5 SSP:er var, och antalet olika vägar till en enskild impression kan springa upp i hela 600 (enligt Sincera, nu en del av The Trade Desk).
Branschens svar är att göra kedjan kortare. Det tydligaste exemplet är OpenPath: The Trade Desk som kopplar upp sig direkt mot en publishers inventory genom en Prebid-adapter, själva hanterar betalningen till publishern och skär bort ett eller flera SSP-hopp helt. Färre noder, färre fees, en kortare schain, en renare väg. De har sedan dess köpt Sincera och lanserat OpenSincera, som poängsätter vägkvalitet på sådant som ads-to-content ratio och sidvikt. Pitchen är, med deras egna ord, "a clean, unadulterated supply chain".
Det är i grunden en sund instinkt – sell-side-versionen av att beskära sina egna vägar. Men jag vill hålla fast vid ett ärligt förbehåll. En DSP som betalar publishers direkt tar på sig, oavsett vad den själv säger, en sell-side-roll. Och en publisher som routar genom en dominerande "direkt" väg byter mellanledsdjungel mot plattformskoncentration. Färre hopp, ja – men möjligen också färre ägare av de hoppen. Om "direkt" förblir rent eller bara flyttar gatekeepern är kanske ett ämne för en annan gång.
Tre standarder, tre frågor, ett jobb:
De är tre sidor av samma problem, eftersom de bara fungerar tillsammans – de korsrefererar samma värden så att en köpare kan spåra vägen tillbaka till ägaren. Ingen av dem upptäcker bedrägerier. Alla tre skapar ansvarsskyldighet – och på en marknad där tillit prissätts snarare än upprätthålls är ansvarsskyldighet bara ett annat ord för yield. Du kontrollerar mer av det här lagret än något annat i bid requestet. Att fylla i det komplett är det billigaste intäktsarbetet i hela stacken.
Det här är den åttonde artikeln i serien i nio delar Vad döljer sig egentligen i ett bid request?
Nästa gång, del 9 – seriens final: Custom data & publisher-strategi. Vi har ägnat åtta delar åt vad bid requestet säger. Den sista frågan är den bara du kan besvara: Vad väljer du att avslöja om din egen målgrupp och ditt eget inventory – och vad är det värt?
Nästa: Del 9 av 9: Den enda delen av bid requestet du själv skriver →
Låt oss hjälpa dig att få ut maximalt av dina displaykampanjer.
