Tarjouspyyntö

Tarjouspyyntö on se rakenteellinen viesti, jonka mainosvaihto tai tarjontapuolen alusta lähettää heti, kun mainospaikka vapautuu, kuvaillen näyttöä, sivun tai sovelluksen kontekstia sekä kaiken käyttäjästä ja laitteesta tiedetyn, jotta mahdolliset ostajat voivat päättää, tarjotaanko ja kuinka paljon.

Mitä tarjouspyyntö sisältää#

OpenRTB-protokollan mukaisesti, jota suurin osa toimialasta standardoi, tarjouspyyntö on JSON-objekti, joka sisältää melko yhtenäisen kenttäjoukon: näyttöobjekti, joka kuvaa mainospaikan kokoa ja muotoa, julkaisijan ja sivuston tai sovelluksen tunnisteen, maantieteellisen kohdistusdatan kuten maan ja alueen, laitetyypin ja yhteystiedot sekä kaiken käyttäjä- tai ensipuolen datan, jonka myyjä saa jakaa. Jos näyttö on osa neuvoteltua järjestelyä, pyyntö sisältää myös diilitunnisteen, joka viittaa kyseiseen diiliin.

Jokainen kyseiseen vaihtoon yhdistetty kysyntäpuolen alusta saa saman pyynnön samanaikaisesti, tyypillisesti tiukan millisekunneissa mitatun vastausikkunan sisällä. Kunkin DSP:n tarjouslogiikka arvioi sitä aktiivisten kampanjoiden perusteella ja joko palauttaa tarjousvastauksen hinnan ja luovan sisällön kanssa tai kieltäytyy tarjoamasta kokonaan.

Miksi tarjouspyynnöt ovat tärkeitä ostajille#

Tarjouspyynnön laatu ja täydellisyys vaikuttavat suoraan siihen, mitä DSP voi tehdä sillä. Pyyntö, jossa on runsaita kontekstuaalisen kohdistuksen signaaleja ja puhtaat sivuston tai sovelluksen tunnisteet, antaa ostajan algoritmille mahdollisuuden tehdä todella perusteltuja päätöksiä. Vähäisen tai huonosti merkitty pyyntö, josta puuttuu sovellus-ads.txt-vahvistus tai täydellinen toimitusketjuobjekti, antaa DSP:lle vähemmän työskentelymateriaalia, ja varovaiset ostajat tarjoavat usein säästeliäästi tai ohittavat nämä pyynnöt kokonaan sen sijaan, että tarjoaisivat sokeasti.

Tässä myös petokset suodatetaan pois tai pääsevät läpi. Tarjouspyyntö, joka väittää edustavan premium-julkaisijan varastoa ilman sitä tukevia ads.txt- tai sellers.json-tietueita, on juuri sellainen signaali, jota DSP:t ja ostajat käyttävät hylätäkseen väärennetyn tai väärin esitetyn varaston ennen kuin edes tarjotaan siitä.

Tarjouspyyntövolyymin lukeminen markkinasignaalina#

Ostajat näkevät harvoin yksittäisiä tarjouspyyntöjä suoraan, mutta aggregaattikuvio, kuinka monta pyyntöä tietty sijoitus tai maantieteellinen alue tuottaa ja miten se vertautuu todellisiin tarjousvastauksiin, on hyödyllinen proxy todelliselle markkinakysynnälle. Kilpailututkimusta varten, ei raakoja huutokirjalokeja, näkemällä, mitkä luovat sisällöt ja mainostajat todella voittavat ja ajavat live-tilassa verkostoissa, saat enemmän tietoa markkinoista kuin pelkästään tarjousvolyymistä. OpenAdLibraryn mainostiedustelu-indeksi on rakennettu juuri tätä varten: live-luovan tason näkyvyys sen sijaan, että markkinat pääteltäisiin huutokauppa-infrastruktuurista.

UKK#

Näkeekö jokainen DSP saman tarjouspyynnön?

Yhden huutokierroksen sisällä kyllä, yhdistetyt DSP:t saavat tyypillisesti saman pyynnön samanaikaisesti. Erona on se, miten kunkin DSP:n oma logiikka päättää, tarjotaanko siitä ja kuinka paljon.

Kuinka nopeasti DSP:n täytyy vastata tarjouspyyntöön?

Vastausikkunat mitataan yleensä kymmenissä tai alhaisissa sadoissa millisekunneissa, niin tiukoiksi, että DSP, joka ei vastaa ajassa, käsitellään yksinkertaisesti ei-tarjouksena kyseisestä näytöstä.

Sisältyykö käyttäjädata aina tarjouspyyntöön?

Ei. Sisältö riippuu suostumuksesta, säädöksistä sekä siitä, mitä julkaisija ja sen SSP on määritetty välittämään. Monet pyynnöt sisältävät nykyään vähemmän yksilötason käyttäjädataa kuin ennen, nojautuen enemmän kontekstuaalisiin ja ensipuolen signaaleihin.

Mitä tapahtuu, jos tarjouspyynnöstä puuttuu toimitusketjun data?

Ostajat ja heidän petosten havaitsemistyökalunsa käsittelevät usein puutteellista toimitusketju- tai ads.txt-dataa riskisignaalina. Jotkut DSP:t tarjoavat silti, mutta varovaisemmin, kun taas toiset on määritetty ohittamaan nämä pyynnöt kokonaan.