I sju artikler har vi nå beskrevet impressionen: hva som er til salgs, hvem som ser på, på hvilken enhet, under hvilke regler, i hvem sitt felles språk.
Denne gangen handler spørsmålet ikke om impressionen i det hele tatt. Det handler om reisen den tok for å nå kjøperen – og om alle som var med underveis, er dem de utgir seg for å være.
Det finnes tre standarder som besvarer det: ads.txt, sellers.json og SupplyChain-objektet (schain). Nesten alle legger dem i den samme skuffen med etiketten "ad fraud-verktøy". Jeg vil hevde at det er feil skuff.
De fanger ikke svindel. En målrettet svindler kan også fylle ut et SupplyChain-objekt. Det de gjør, er noe mer stillferdig og mer nyttig: De gjør supply path-en ansvarlig. schain er ikke en lås på døren. Det er en signert kvittering for hver hånd impressionen har vært igjennom.
Sist gang argumenterte jeg for at OpenRTB er en kontrakt, ikke en spec – og at nyttige ideer starter livet i et blankt "ext"-felt og rykker opp i kjernen. Jeg brukte source.ext.schain, som ble til source.schain i OpenRTB 2.6, som et av de tre eksemplene. Dette er artikkelen om hva den opprykkede kandidaten faktisk gjør.
Fire begreper, i all hast:
*ads.txt = "Authorized Digital Sellers". Dens app- og CTV-søsken er app-ads.txt, som gjør den samme jobben for miljøer som ikke har noen website-rot å hoste filen på.
Den siste definisjonen er den du skal holde fast i. STEP Network er et mellomledd. Når vi selger en publishers impression, er vi en node i det bid requestets supply chain – en linje JSON som en kjøper i den andre enden kan slå opp.
Her er rammen for hele artikkelen. De tre standardene er ikke konkurrenter, og de er ikke redundante. De besvarer hvert sitt spørsmål, og de virker bare sammen.
To av dem er oppslagsverk, skrevet én gang og lest ofte. Én er en levende kvittering, stemplet på hver eneste auksjon. Magien er at de kryssrefererer hverandre: Annonsesystemets domene i din ads.txt er det samme asi i schainen; konto-ID-en din i ads.txt er den samme sid i schainen og den samme seller_id i annonsesystemets sellers.json. Samme verdier, tre dokumenter. En kjøper kan triangulere.
Visualisering generert med claude.ai
Vi selger to slags inventory, og ads.txt-filene avslører forskjellen med en gang.
jv.dk er en JFM-tittel som vi i STEP Network driver som owned-and-operated*. Her er en forkortet ads.txt, men du kan slå opp den fulle 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 er et datterselskap av JFM, og derfor "eier" vi JFM-domenene i schain-sammenheng.
Boligsiden.dk er annerledes. Boligsiden A/S eier det nettstedet; vi representerer det som mellomledd. Samme annonsesystemer, men se hva som endrer seg:
#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 forskjeller bærer hele skillet mellom eid og representert:
Ingen tvinger frem den ærligheten. Formatet gir deg bare plass til å være presis – og å være presis er dét som får deg betalt.
Se igjen på én linje som opptrer i begge filene:
omnicommediagroup.com, S012, RESELLER
Vi autoriserer byrågruppen Omnicom Media Group, konto S012, til å videreselge. Følg nå den ID-en inn i Omnicoms egen sellers.json:
{ "seller_id": "S012", "name": "STEP Network", "seller_type": "BOTH", "domain": "stepnetwork.dk" }
Der står vi som STEP Network – inne i byråets identitetsregister. Og seller_type er BOTH: Vi er publisher (av vårt eide inventory) og mellomledd (som videreselger inn i Omnicoms marketplace). Og så, i vår egen sellers.json:
{ "seller_id": "500", "seller_type": "PUBLISHER", "name": "JFM A/S", "domain": "jv.dk" }
Så en enkelt jv.dk-impression solgt gjennom byråveien lyder, i supply chain-termer: jv.dk, eid av JFM → solgt av STEP → videresolgt gjennom Omnicom → kjøpt av annonsøren. Tre filer, to sellers.json-registre, én enhet (oss) som opptrer i begge – og hvert hopp kan sjekkes i begge ender.
Det er den delen folk overser ved å jobbe som nettverk. I det øyeblikket demand-partneren din er et byrå som kjører sin egen sellers.json, opptrer du ikke bare i dine egne bøker – du opptrer i deres, og seller_type: BOTH gjør reelt arbeid. En kjøper som slår opp "BOTH", kan ikke ut fra de statiske filene alene anta om du eier inventoryet eller videreselger det i et gitt request. Bare den levende schainen avgjør det.
Ingenting av dette står stille når auksjonen kjører. Schainen settes sammen mens requestet reiser: Hvert system som rører det – ad-server, så SSP, så videre mot DSP-en – legger til sin egen node før det sendes videre.
"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 kjøperen, er nodes-arrayet den samlede historien om alle som har håndtert det. Og den mottakende siden forventes å sjekke det: parse hver node og bekrefte at asi og sid er autorisert i publisherens ads.txt og kan slås opp i annonsesystemets sellers.json. Oppslagsverk, møt den levende kvitteringen. Den rundturen – requestet går ned gjennom røret og verifiseres tilbake mot de statiske filene – er hele poenget med laget.
complete-flagget er den ærlige delen av spec-en. complete: 1 betyr at kjeden rommer hver node hele veien tilbake til inventoryets eier. complete: 0 betyr at det gjør den ikke – og reglene er strenge for hvordan man innrømmer det: Videreselger du inventory som ankom uten et SupplyChain-objekt, oppretter du ett, setter complete: 0 og legger bare til din egen node. Du har eksplisitt ikke lov til å kopiere kjeden videre og late som om du ikke var der.
Visualisering generert med claude.ai
Så hva skjer med en inkomplett kjede? Her er det som overrasker folk: Den blir fortsatt handlet. Kjøpere kan konfigurere DSP-ene sine til å avvise alt uten en komplett kjede, og noen gjør det. Men for det meste avviser de ikke. De trekker fra i prisen.
Tillit blir her priset, ikke håndhevet.
Supply path-benchmarks fra 2026 gjør det konkret: Videresolgt ("rebroadcasting") supply står nå for cirka 27 % av alle bid requests, men henter bare rundt 18 % av forbruket – et monetiseringsunderskudd på nesten 50 % per bid request målt mot de mest direkte veiene. Videresalgs-æraen er ikke over. Den blir bare priset om – nedover.
Jeg vil være ærlig om vår egen side av dette: Jeg kan ikke vise deg en haug med rotete data om "uautorisert demand", for det tillater vi ikke i STEP Network. Vi kjører stramt med partnerne våre, så kjedene våre er komplette som policy, ikke som håp. Den disiplinen er ikke byråkrati. Den er selve produktet.
Som kjøper skriver du ikke dette laget, og som leser ser du det stort sett ikke. Men selger du inventory, er det noe av det arbeidet i huset som gir mest effekt for minst glamour:
Tommelfingerregelen jeg vil etterlate deg med: Hvis en kjøper ikke kan spore impressionen tilbake til deg på tre oppslag, betaler de deg som om de ikke kan.
Hvis alt det ovenstående høres ut som mange bevegelige deler å holde ærlige – så er det fordi det er det. Tallene er tankevekkende: Topp-20-publisherne integrerer i gjennomsnitt med 24,5 SSP-er hver, og antallet ulike veier til en enkelt impression kan løpe helt opp i 600 (ifølge Sincera, nå en del av The Trade Desk).
Bransjens svar er å gjøre kjeden kortere. Det tydeligste eksempelet er OpenPath: The Trade Desk, som kobler seg direkte på en publishers inventory gjennom en Prebid-adapter, selv håndterer betalingen til publisheren og kutter ett eller flere SSP-hopp helt bort. Færre noder, færre fees, en kortere schain, en renere vei. De har siden kjøpt Sincera og lansert OpenSincera, som scorer veikvalitet på ting som ads-to-content ratio og sidevekt. Pitchen er, med deres egne ord, "a clean, unadulterated supply chain".
Det er i bunn og grunn et godt instinkt – sell-side-utgaven av å beskjære sine egne veier. Men jeg vil holde fast ved ett ærlig forbehold. En DSP som betaler publishere direkte, påtar seg, uansett hva den selv sier, en sell-side-rolle. Og en publisher som ruter gjennom én dominerende "direkte" vei, bytter mellomledd-villnis ut med plattformkonsentrasjon. Færre hopp, ja – men muligens også færre eiere av de hoppene. Om "direkte" forblir rent eller bare flytter gatekeeperen, er kanskje et tema for en annen god anledning.
Tre standarder, tre spørsmål, én jobb:
De er tre sider av det samme problemet, fordi de bare virker sammen – de kryssrefererer de samme verdiene, slik at en kjøper kan spore veien tilbake til eieren. Ingen av dem oppdager svindel. Alle tre skaper ansvarlighet – og i et marked der tillit prises fremfor å håndheves, er ansvarlighet bare et annet ord for yield. Du kontrollerer mer av dette laget enn noe annet i bid requestet. Å fylle det ut komplett er det billigste inntektsarbeidet i hele stacken.
Dette er den åttende artikkelen i serien i ni deler Hva skjuler seg egentlig i et bid request?
Neste gang, del 9 – seriens finale: Custom data & publisher-strategi. Vi har brukt åtte deler på hva bid requestet sier. Det siste spørsmålet er det bare du kan besvare: Hva velger du å avsløre om din egen målgruppe og ditt eget inventory – og hva er det verdt?
Neste: Del 9 av 9: Den ene delen av bid requestet du selv skriver →
La oss hjelpe deg med å få maksimalt ut av display-kampanjene dine.
