Budforespørsel

En budforespørsel er den strukturerte meldingen et annonsebørs eller en tilbudssideplattform sender ut i det øyeblikket en annonseplass blir tilgjengelig, og beskriver impresjonen, siden eller app-konteksten, og det som er kjent om brukeren og enheten, slik at potensielle kjøpere kan bestemme om de skal by og hvor mye.

Hva er inni en budforespørsel#

I henhold til OpenRTB-protokollen som mesteparten av bransjen standardiserer på, er en budforespørsel et JSON-objekt som bærer et ganske konsistent sett med felter: et impresjon-objekt som beskriver annonseplassens størrelse og format, utgiver og nettsted- eller app-ID, geografisk målrettingsdata som land og region, enhetstype og tilkoblingsinfo, og eventuelle bruker- eller førstepartsdata selger har lov til å dele. Hvis impresjonen er en del av en forhandlet avtale, bærer forespørselen også en avtaleidentifikator som refererer til den spesifikke avtalen.

Hver etterspørselssideplattform som er tilkoblet det børsen mottar den samme forespørselen samtidig, innenfor et vanligvis strengt svarvindu målt i millisekunder. Hver DSPs budlogikk evaluerer den mot aktive kampanjer og returnerer enten et budsvar med en pris og kreativt innhold, eller avstår fra å by i det hele tatt.

Hvorfor budforespørsler betyr noe for kjøpere#

Kvaliteten og fullstendigheten til en budforespørsel påvirker direkte hva en DSP kan gjøre med den. En forespørsel med rike kontekstuelle målrettingssignaler og ren nettsted- eller app-identifikasjon lar en kjøpers algoritme ta en virkelig informert beslutning. En sparsom eller dårlig merket forespørsel, som mangler app-ads.txt-verifisering eller et ufullstendig forsyningskjedeobjekt, gir DSP-en mindre å jobbe med, og forsiktige kjøpere byr ofte konservativt eller hopper over disse forespørslene helt i stedet for å by blindt.

Dette er også hvor svindel blir filtrert ut eller glir gjennom. En budforespørsel som hevder å representere en premium-utgivers beholdning, uten de medfølgende ads.txt- eller sellers.json-postene som støtter det kravet, er akkurat den typen signal DSP-er og kjøpere bruker for å avvise forfalsket eller feilrepresentert beholdning før de i det hele tatt byr på den.

Å lese budforespørselsvolum som et markedsignal#

Kjøpere ser sjelden individuelle budforespørsler direkte, men det aggregerte mønsteret, hvor mange forespørsler en gitt plassering eller geografi genererer, og hvordan det sammenlignes med faktiske budsvar, er en nyttig proxy for reell etterspørsel i markedet. For konkurranseanalyse snarere enn rå auksjonslogger, forteller det deg mer om markedet å se hvilke kreative innhold og annonsører som faktisk vinner og kjører live på tvers av nettverk, enn bare budvolum alene. OpenAdLibrary sin annonseintelligens-indeks er bygget for nettopp det: synlighet på kreativt nivå i sanntid i stedet for å trekke slutninger om markedet fra auksjonsinfrastruktur.

FAQ#

Ser hver DSP den samme budforespørselen?

Innenfor en enkelt auksjonsrunde, ja, tilkoblede DSP-er mottar vanligvis den samme forespørselen samtidig. Det som varierer, er hvordan hver DSPs egen logikk bestemmer om og hvor mye den skal by på den.

Hvor raskt må en DSP svare på en budforespørsel?

Svarvinduer måles vanligvis i titalls til noen få hundre millisekunder, så stramme at en DSP som ikke svarer i tide, rett og slett behandles som et ikke-bud for den impresjonen.

Er brukerdata alltid inkludert i en budforespørsel?

Nei. Hva som inkluderes avhenger av samtykke, regelverk, og hva utgiveren og dens SSP er konfigurert til å videresende. Mange forespørsler i dag inneholder mindre data på individuelt brukernivå enn før, og støtter seg mer på kontekstuelle og førsteparts-signaler i stedet.

Hva skjer hvis en budforespørsel mangler forsyningskjededata?

Kjøpere og deres svindeloppdagelsesverktøy behandler ofte ufullstendig forsyningskjede- eller ads.txt-data som en risikosignal. Noen DSP-er vil fortsatt by, men mer konservativt, mens andre er konfigurert til å hoppe over disse forespørslene helt.