I syv artikler har vi nu beskrevet impressionen: hvad der er til salg, hvem der kigger, på hvilken enhed, under hvilke regler, i hvis fælles sprog.
Denne gang handler spørgsmålet slet ikke om impressionen. Det handler om den rejse, den tog for at nå køberen – og om alle, der var med undervejs, er dem, de udgiver sig for at være.
Der findes tre standarder, der besvarer det: ads.txt, sellers.json og SupplyChain-objektet (schain). Næsten alle lægger dem i den samme skuffe med etiketten "ad fraud-værktøjer". Jeg vil hævde, det er den forkerte skuffe.
De fanger ikke svindel. En målrettet svindler kan også udfylde et SupplyChain-objekt. Det, de gør, er noget mere stilfærdigt og mere nyttigt: De gør supply path'en ansvarlig. schain er ikke en lås på døren. Det er en underskrevet kvittering for hver hånd, impressionen har været igennem.
Sidste gang argumenterede jeg for, at OpenRTB er en kontrakt, ikke en spec – og at nyttige idéer starter livet i et blankt "ext"-felt og rykker op i kernen. Jeg brugte source.ext.schain, der blev til source.schain i OpenRTB 2.6, som et af de tre eksempler. Det her er artiklen om, hvad den oprykkede kandidat rent faktisk laver.
Fire begreber, i al hast:
*ads.txt = "Authorized Digital Sellers". Dens app- og CTV-søskende er app-ads.txt, som gør det samme job for miljøer, der ikke har nogen website-rod at hoste filen på.
Den sidste definition er den, du skal holde fast i. STEP Network er et mellemled. Når vi sælger en publishers impression, er vi en node i det bid requests supply chain – en linje JSON, som en køber i den anden ende kan slå op.
Her er rammen for hele artiklen. De tre standarder er ikke konkurrenter, og de er ikke redundante. De besvarer hver sit spørgsmål, og de virker kun sammen.
To af dem er opslagsværker, skrevet én gang og læst ofte. Én er en levende kvittering, stemplet på hver eneste auktion. Magien er, at de krydsrefererer hinanden: Annoncesystemets domæne i din ads.txt er det samme asi i schainen; dit konto-ID i ads.txt er det samme sid i schainen og det samme seller_id i annoncesystemets sellers.json. Samme værdier, tre dokumenter. En køber kan triangulere.
Visualisering genereret med claude.ai
Vi sælger to slags inventory, og ads.txt-filerne afslører forskellen med det samme.
jv.dk er en JFM-titel, som vi hos STEP Network driver som owned-and-operated*. Her er en forkortet ads.txt, men du kan slå den fulde fil op 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 datterselskab af JFM, og derfor "ejer" vi JFM-domænerne i schain-sammenhæng.
Boligsiden.dk er anderledes. Boligsiden A/S ejer det site; vi repræsenterer det som mellemled. Samme annoncesystemer, men se, hvad der ændrer sig:
#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 forskelle bærer hele skellet mellem ejet og repræsenteret:
Ingen tvinger den ærlighed frem. Formatet giver dig bare plads til at være præcis – og at være præcis er dét, der får dig betalt.
Kig igen på én linje, der optræder i begge filer:
omnicommediagroup.com, S012, RESELLER
Vi autoriserer bureaukoncernen Omnicom Media Group, konto S012, til at videresælge. Følg nu det ID ind 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 – inde i bureauets identitetsregister. Og seller_type er BOTH: Vi er publisher (af vores ejede inventory) og mellemled (der videresælger ind i Omnicoms marketplace). Og så, i vores egen sellers.json:
{ "seller_id": "500", "seller_type": "PUBLISHER", "name": "JFM A/S", "domain": "jv.dk" }
Så en enkelt jv.dk-impression solgt gennem bureauvejen lyder, i supply chain-termer: jv.dk, ejet af JFM → solgt af STEP → videresolgt gennem Omnicom → købt af annoncøren. Tre filer, to sellers.json-registre, én enhed (os), der optræder i begge – og hvert hop kan tjekkes i begge ender.
Det er den del, folk overser ved at arbejde som netværk. I det øjeblik din demand-partner er et bureau, der kører sin egen sellers.json, optræder du ikke kun i dine egne bøger – du optræder i deres, og seller_type: BOTH udfører reelt arbejde. En køber, der slår "BOTH" op, kan ikke ud fra de statiske filer alene antage, om du ejer inventoryet eller videresælger det i et givent request. Kun den levende schain afgør det.
Intet af det her står stille, når auktionen kører. Schainen samles, mens requestet rejser: Hvert system, der rører det – ad-server, så SSP, så videre mod DSP'en – tilføjer 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 køberen, er nodes-arrayet den samlede historie om alle, der har håndteret det. Og den modtagende side forventes at tjekke det: parse hver node og bekræfte, at asi og sid er autoriseret i publisherens ads.txt og kan slås op i annoncesystemets sellers.json. Opslagsværker, mød den levende kvittering. Den rundtur – requestet går ned gennem røret og verificeres tilbage mod de statiske filer – er hele pointen med laget.
complete-flaget er den ærlige del af spec'en. complete: 1 betyder, at kæden rummer hver node hele vejen tilbage til inventoryets ejer. complete: 0 betyder, at det gør den ikke – og reglerne er strikse omkring, hvordan man indrømmer det: Videresælger du inventory, der ankom uden et SupplyChain-objekt, opretter du ét, sætter complete: 0 og tilføjer kun din egen node. Du har eksplicit ikke lov til at kopiere kæden videre og lade som om, du ikke var der.
Visualisering genereret med claude.ai
Så hvad sker der med en inkomplet kæde? Her er det, der overrasker folk: Den bliver stadig handlet. Købere kan konfigurere deres DSP'er til at afvise alt uden en komplet kæde, og nogle gør. Men for det meste afviser de ikke. De trækker fra i prisen.
Tillid bliver her prissat, ikke håndhævet.
Supply path-benchmarks fra 2026 gør det konkret: Videresolgt ("rebroadcasting") supply står nu for cirka 27 % af alle bid requests, men henter kun omkring 18 % af forbruget – et monetariseringsunderskud på næsten 50 % pr. bid request målt mod de mest direkte veje. Videresalgs-æraen er ikke forbi. Den bliver bare prissat om – nedad.
Jeg vil være ærlig omkring vores egen side af det her: Jeg kan ikke vise dig en bunke rodede data om "uautoriseret demand", for det tillader vi ikke i STEP Network. Vi kører stramt med vores partnere, så vores kæder er komplette som politik, ikke som håb. Den disciplin er ikke bureaukrati. Den er selve produktet.
Som køber skriver du ikke dette lag, og som læser ser du det stort set ikke. Men sælger du inventory, er det noget af det arbejde i huset, der giver mest effekt for mindst glamour:
Tommelfingerreglen, jeg vil efterlade dig med: Hvis en køber ikke kan spore impressionen tilbage til dig på tre opslag, betaler de dig, som om de ikke kan.
Hvis alt det ovenstående lyder som mange bevægelige dele at holde ærlige – så er det, fordi det er det. Tallene er tankevækkende: Top-20-publisherne integrerer i gennemsnit med 24,5 SSP'er hver, og antallet af forskellige veje til en enkelt impression kan løbe helt op i 600 (ifølge Sincera, nu en del af The Trade Desk).
Branchens svar er at gøre kæden kortere. Det tydeligste eksempel er OpenPath: The Trade Desk, der kobler sig direkte på en publishers inventory gennem en Prebid-adapter, selv håndterer betalingen til publisheren og skærer et eller flere SSP-hop helt væk. Færre noder, færre fees, en kortere schain, en renere vej. De har siden købt Sincera og lanceret OpenSincera, der scorer vejkvalitet på ting som ads-to-content ratio og sidevægt. Pitchen er, med deres egne ord, "a clean, unadulterated supply chain".
Det er grundlæggende et godt instinkt – sell-side-udgaven af at beskære sine egne veje. Men jeg vil fastholde ét ærligt forbehold. En DSP, der betaler publishere direkte, påtager sig, uanset hvad den selv siger, en sell-side-rolle. Og en publisher, der router gennem én dominerende "direkte" vej, bytter mellemleds-vildnis ud med platformskoncentration. Færre hop, ja – men muligvis også færre ejere af de hop. Om "direkte" forbliver rent eller bare flytter gatekeeperen, er måske et emne til en anden god gang.
Tre standarder, tre spørgsmål, ét job:
De er tre sider af det samme problem, fordi de kun virker sammen – de krydsrefererer de samme værdier, så en køber kan spore vejen tilbage til ejeren. Ingen af dem opdager svindel. Alle tre skaber ansvarlighed – og i et marked, hvor tillid prissættes frem for at håndhæves, er ansvarlighed bare et andet ord for yield. Du kontrollerer mere af dette lag end noget andet i bid requestet. At udfylde det komplet er det billigste omsætningsarbejde i hele stacken.
Det her er ottende artikel i serien i ni dele Hvad gemmer der sig egentlig i et bid request?
Næste gang, del 9 – seriens finale: Custom data & publisher-strategi. Vi har brugt otte dele på, hvad bid requestet siger. Det sidste spørgsmål er det, kun du kan besvare: Hvad vælger du at afsløre om din egen målgruppe og dit eget inventory – og hvad er det værd?
Næste: Del 9 af 9: Den ene del af bid requestet, du selv skriver →
Lad os hjælpe dig med at få maksimalt ud af dine display-kampagner.
