Header bidding – какво означава това?

Източник: http://adprofs.co/beginners-guide-to-header-bidding/

Ако следвате технологиите в рекламата, то означава, че сте се сблъскали поне няколко пъти с термина “header bidding”. Ако не сте го срещали е доста неприятно, защото смятам че това е най-доброто постижение в технологиите за реклама от предоставянето на real-time bidding (RTB) /търг в реално време за реклами/.

Като голяма част от технологичните концепции, възприемането на новите иновации, как работят и как се напасват в текущия информационен свят е доста трудно. Доста информация има в Интернет, но тя е разбита на парчета. Тази статия има за цел да покаже един интензивен курс на основите, всичко на едно място.

В това ръководство, ще научите фундаментални неща за header bidding-а: какво представлява, защо има значение, как да го имплементирате и др.

Нека започнем с най-основният въпрос.

Какво е header bidding?

Това е един обединен търг, който се извършва от автори / издателства (publishers) извън техния основен ad server (рекламен сървър), чрез което се позволява на providers (advertisers, рекламодатели), да си избират импресии с най-висок приоритет. Понякога го наричат “first look” /първи поглед/.

Преди концепцията на header bidding-a, мястото за реклама бе из търгувано и предоставено тогава, когато дадения ad placement / AdUnit (мястото за реклама) започва да се зарежда на страницата. С други думи, в момента в който всичките места за реклама започнат да се зареждат на една страница и в момента в който на издателя се зареди сървъра за реклама, в повечето случаи DoubleClick for Publishers (DFP), като от там така наречения “Рекламен водопад” / “Waterfall of ad serving” започва:

Когато потребител посети сайта, директните поръчки трябва да бъдат показани първо, тъй като те са с най-висок приоритет в ad server-a. Директните поръчки гарантират точно определен брой от импресии за рекламодателя. Две от тези предимства – резервиране на инвентара и приоритет – са включени в цената, която рекламодателите заплащат.

Ако посетителя прегледа достатъчно на брой страници на сайта, така че достигне лимита на повтаряемост (честота), ad server-a слиза на следващия ред, където посетителя влиза в RTB среда, където множество от рекламодатели наддават, за да предоставят реклама към потребителя.

Към днешна дата, повечето от рекламодателите по този начин предоставят реклами. За съжаление, този подход не оптимизира дохода на издателя на база инвентар – цена.

Header bidding е допълнителен търг, който се случва извън server-a, в header-a на един сайт, като зарежда преди всичко останало на страницата. Този header обикновено съдържа meta данни за страницата, извиква скриптове за стилизирането и, следене и др. Заради това, тази зона е идеална за извършване на нов търг.

Въпреки че този нов търг се случва в браузъра на потребителя,  основно рекламодателя го контролира. (Този факт е много важна част от изместването на контрола)

Този нов тип header търг позволява на издателя да контролира каква стойност ще вземе за определена реклама, на база това колко натоварване има върху страницата, още преди да са се заредили разположенията на рекламите. С тези стойности на офертите за разположението на рекламата, авторите могат да приоритизират предоставянето на тези реклами преди рекламите идващи от директните поръчки, като вземем предвид че:

1. Този тип оферти са достатъчно скъпи
2. Не оказват отношение към доставката на директните поръчки

Нека да разгледаме защо този тип на показване на реклами е толкова важен.

Защо Header Bidding-a е важен?

Той е важен както и за рекламодателите, така и за издателите. Нека започнем с това, защо на издателите трябва да им пука.

Увеличаване на приходите

В старият подход “Водопад”, всеки един партньор ще има една отговаряща на него линия в ad server-a на издателя и всеки един от тях ще има различен приоритет. Ако първият партньор в тази поредица не купи дадената импресия, ще се спусне на долу към следващия и следващия, докато някой не я купи или докато не я предаде на Google AdSense или на някой друг line item за собствени реклами.

Обикновено, всеки партньор ще бъде конфигуриран на различна floor цена (минимума от която цената тръгва), така че цената на импресията пада с всяко едно стъпало по-надолу. Пример:

• Exchange 1 (e.g., Index) @ floor price = $3.40
• Exchange 2 (e.g., Rubicon) @ floor price = $3.00
• Exchange 3 (e.g., OpenX) @ floor price = $2.50

Този подход е не ефикасен и в крайна сметка и доставчиците и авторите страдат.

Това е все едно предоставяш една торба ябълки на четири човека последователно и намаляваш цената всеки път, ако някой откаже ябълките. Евентуално някой ще каже да, заради сделката, но това не е най-добрият начин да вземеш най-хубава цена за ябълките. Освен това, това изглежда сякаш предлагаш ниско-качествена продукция – ябълки, които много хора са отказали. И като се има предвид реалността на несъответствията, когато се използва този каскаден подход, е като да изгубите няколко ябълки между всяка стъпка.

Чрез използването на header bidding, всяка една импресия се търгува към всички партньори желаещи да я закупят в едно и също време, още преди ad server-a на издателя дори да е извикан. Рекламодателя не просто може да погледне всяка една импресия, което не бе възможно преди, но сега той има т.н. “първи поглед” / first look / към всяка една, което сякаш е да вземе най-хубавото от останалото. Дали ще спечелят дадената импресия, зависи от това, колко са склонни да платят.

В резултат на което, издателите в крайна сметка могат да продадат техния рекламен инвентар по такъв начин, че той да им донесе най-добра монетаризация. Като поставиш всичките партньори, желаещи да рекламират, на едно и също ниво с цел определянето на истинската цена на една импресия създава ефикасност, която не е възможна при последователния подход на “Водопада”.

Header bidding-a оказва огромно влияние върху издателите, тъй като увеличава чувствително техния доход. Хората използващи header bidding са увеличили прихода си с от 30% до 60%. Разбира се, факторите са изключително важни носещи това увеличение: гео локацията, размера на публиката и др.

Допълнително, откакто рекламодателите имат възможност да избират импресиите с най-висок приоритет в ad server-a, това води до намаляване на непродадените рекламни места на издателя, който отиват в “последния вид”. По този начин се увеличават лихвите за непродадени рекламни места, като допълнително увеличение на приходите на издателите.

Първокласен инвентар за рекламодателите

По този начин, рекламодателите имат достъп до “първокласния” инвентар, който преди това бе единствено достъпен чрез директни сделки с издателите. Купуващите реклами чрез използване на програмни канали имат възможност да погледнат върху всички импресии на издателя, а не просто тези които са останали неизползвани при традиционния водопад.

Когато за първи път RTB се появява, получава доста негативна репутация. Причината за това е търгуването на непродадения инвентар, все едно ниско-качествена продукция (такава каквато никой не желе). Дори се създават и няколко забавни дефиниции на RTB, като например “race to the bottom”, които критиците си подхвърлят.

В някои ситуации, това е вярно. По-голямата част от RTB инвентара е достъпен на дъното на водопада, така че дълбочината на сесията е по-ниска. Това е резултат от гледна точка как издателите избират да имплементират тяхната supply-side platform (SSP) в техния ad server. Вместо да използват техните си SSP-та, начина по който трябва да се използва – като основен ad server за издателя – авторите ги възприемат като най-ниските по приоритет продукти в техните ad server-и.

С header bidding-a, RTB търсенето има възможност за first look в инвентара, дори над директните продажби, което е огромен скок в еволюцията при предоставянето на реклами.

Заради приходите, които издателите получават от header bidding-a и достъпа до първокачествен инвентар от рекламодателите, програмната реклама може да отхвърли репутацията си на ниско-качествен, сделков канал. Като резултат, header bidding-a е по-скоро усилена програмен ad tech сред авторите.

Как работи Header Bidding-а?

HB се случва в момента, в който страницата започва да се зарежда. Кода на HB (който е разположен на header-а на страницата) се изпълнява и браузъра на потребителя извиква всички рекламни партньори (пр. AppNexus, Index, OpenX, Amazon, Criteo) едновременно, като казва: “Хей, ето ме! Колко ще наддадете за мен?” В рамките на няколкостотин милисекунди (обикновено под 500), всеки наддава за това място.

Имайте едно на ум: В рамките на тази прозорец от половин секунда, много от тези партньори провеждат техни си търгове, така че да определят кой от техните да изпрати. Amazon и Criteo имат по един търг. Борсите обикновено имат два търга, които провеждат: техните си и тези, които са включени към тях.

Няколко важни бележки относно горната диаграма:

1. Както може да се види от примера, най-високия наддавач от DSP-тата не печели търга, причината е заради модела използван от повечето борси – second-price auctions. (Като пояснение, модела second-price auction изпращат цената на втория най-висок наддавач + 1 цент). В един сценарии като горния, second-price auction модела не е оптимален, защото най-високо наддаващия е блокиран да спечели. Последиците са загуби в приходите на издателя и среда пълна със затруднения за рекламодателите. Най-очевадното решение е да се премине към first-price auction, където винаги най-високото наддаване се поддава без да бъде редуцирано, но този подход има своите си проблеми.
2. В сценария показан на тази илюстрация, header bidding wrapper-a е конфигуриран да бъде “посредник”, като по този начин той предава най-високото предложение към ad server-a. Header bidding wrappers, като Prebid.js например, позволяват възможността да бъдете “посредник”, което е по подразбиране и изпраща най-високото предложение или да бъдете “не-посредник”, който изпраща всяко едно предложение, което идва от всеки един header bidding партньор. Когато всичките предложения минат, ad server-a решава кое предложение да вземе кой ad slot.
   За да видите реален пример, инсталирайте Headerbid Expert добавката за Chrome. Тя ще покаже всичките рекламни партньори, които един издател използва в имплементацията си на header bidding-a и времето за отговор на всеки един рекламодател.
   Следващият screenshot е пример за рекламните партньори на weather.com

Най-високото предложение от всеки един партньор се предава от браузъра на посетителя към ad server-a на издателя. Предложението се приравнява към кореспондиращ line item в ad server-a на издателя, за да се подсигури, че гарантираната доставка няма да бъде компрометирана. Ако предложението от header-a е избрано, рекламата на спечелилия го рекламодател се показва.

Ефективен First-price търг

Красотата на header biding-a е, че издателствата взимат най-високото предложение от всичките им партньори и то с номинална стойност.

Докато рекламните борси (ad exchanges) провеждат second-price търгове на техните платформи, където най-много наддаващия плаща само $0.01 повече от втория-най-високо наддаващ, при header biding-a нещата са, че винаги се взима най-високото предложение от всеки един желаещ, така че това е ефективно first-price.

Това означава, че цялостната икономика на търгове е доста по-благоприятна за издателя. Чрез RTB, нещата са доста по-благоприятни за рекламодателите. Но като резултат, от гледна точка на издателя, той не получава перфектната стойност за своите места за реклама.

Как се имплементира Header Bidding

Тъй като това е ръководство за начинаещи, спускането в техническите детайли при имплементацията на header bidding е отвъд нашите възможности. Вместо това ще покрием няколко основни точки, които трябва да се вземат предвид, когато се извършва имплементация на header biding върху някой сайт.

За детайлна имплементация, препоръчваме “Getting Started” документацията на Prebid.js

Избирането на рекламни партньори

Да имаш силни рекламни партньори е ключово в максимизирането на приходите от header bidding-a. Като издател, ако имате взаимоотношения с рекламни борси или SSP, то тогава сте в позицията да ги добавите като нови рекламни партньори в header bidding-a. Ако обаче нямате такива взаимоотношения, то първата стъпка е да ги изградите.

В един header търг, рекламните партньори могат да включват гиганти от типа на Amazon и Criteo, както и рекламни борси, SSP-та като Index, AppNexus и Rubicon, които по същество сумират търсенето (агрегират го) за разлика от традиционните DSP-та.

Процесът за оценяване на ad tech партньори е отвъд възможностите на това ръководство. Въпреки това има една доста полезна таблица поддържана от членове на r/adops от Reddit, което представлява сравнителна таблица на множество ad tech доставчици. Не може да бъде гарантирано на 100 процента за нейната точност, но е добра отправна точка с осъзнаване на опциите.

Поддържане на Header латентност

Едно от предизвикателствата при header bidding-a е забавянето (латентността) при зареждане на страницата. Процесът за header търг отнема малко повече време отколкото RTB търг в една рекламна борса, което отнема около 100 милисекунди. Въпреки това, тъй като доста издатели използват множество обменни партньори в традиционна водопадна настройка, такава латентност винаги е съществувала, просто не е била в header-a.

Header biding-a иска от множество източника на реклами да предоставят своите най-добри цени, така че брой RTB търгове се случват едновременно. Като резултат, издателите имат нужда от управление на паузите, така че нито един партньор няма да забави търга, така че да навреди на зареждането на страницата. В идеалния вариант паузата при зареждане трябва да е около половин секунда.

Header bidding wrappers (обвивки)

В ранните дни на header biding, издателите управляваха техните header търгове ръчно. Това се оказа тромаво и неефективно, така че бързо присвоиха използването на header biding wrappers (containers) с цел процесът да е по-ефикасен.

HBW са като системи за управление на тагове, но за партньори участващи в header biding-a. Те позволяват на издателите да управляват партньорите си доста по-лесно, добавяйки ги или премахвайки ги ако се налага. Те превеждат всеки един от уникалните параметри на рекламните партньори в обикновена стойност, която може да бъде предадена на аd server-a еднакво, както и да позволи важни настройки, като централизирана пауза, която да направи deadline за търга. По този начин се подсигурява, че header търга се случва асинхронно, така че няма да навреди на зареждането на останалата част от страницата.

Решенията с отворен код като Prebid.js и Pubfood.js, докато платени решения могат да бъдат намерени от Index Exchange и OpenX. Най-важното решение днес изглежда Prebid.js поради причини, които ще обясним по-натам.

Конфигурация на Ad Server-a на издателя

Много хора възприемат header bidding-a като хак или нещо подобно.

В момента в който един издател конфигурира своя HBW и асоциира рекламните партньори, то тогава е време да се създадат хиляди line items в Ad Server-a си с цел да хване всяка една предложена стойност, която идва от header търга. Това без съмнение е най-много време-отнемаща и тромава част от настройките на header biding процеса. Това тук е частта, в която осъзнаваш всъщност наистина какъв хак е това. Това е workaround, който създава един обединен търг извън ad server-a на издателя. За да дам пример как изглежда този процес, погледнете този YouTube клип

Това покрива доста от главните точки върху, които трябва да се помисли, когато се имплементира header bidding-а. Нека обходим какво означава header bidding за ad tech индустрията като цяло

Какви са последиците от Header Bidding-a?

Header bidding-a е еволюция от RTB, като предоставя доста повече стойност към авторите, докато предоставя на рекламодателите много важни облаги. Въпреки всичко има брой от доста чувствителни последици за индустрията като цяло.

Намаление на несъответствията в отчетите

Винаги има някакъв процент несъответствие при online рекламите. Несъответствията винаги се изострят, когато има латентност при предаване на импресиите между няколко ad servers и JS тагове.

Тъй като header bidding е един търг, който се случва между много различни рекламни партньори едновременно, няма последователен daisy chain на партньори, което драстично намаля несъответствието в отчетите. Да не коментираме и количествата JS, които трябва да се заредят на браузъра на потребителя, което допринася още за важността при използването на технологията за header bidding.

Увеличени разходи за инфраструктурата

За двете големи категории на доставчици в ad tech пейзажа – платформи за търсене и платформи за снабдяване – разходите за инфраструктурата са доста високи. С цел управление на милиарди импресии на ден, DPS и SSP имат нужда от стотици, в някои случаи, хиляди сървъри, които да поемат натоварването.

Преди появата на header bidding-a, повечето борси биха виждали импресиите само веднъж – когато е техен ред във водопада. А DPS-ите, могат да видят една и съща импресия два-три пъти след което я предават към следващото ниво на водопада от една борса към следващата. Въпреки това, с допълнението на header търга, борсите виждат една импресия два пъти, което дублира броят от заявки към техните сървъри. Не е изненада, че Rubicon харчат 25 милиона долара, само за хардуерна инфраструктура в последната година. И с тяхното отдаване към header bidding-a, се очаква този номер да се повиши драстично.

При DSP, даже е и по-зле. За всяка една борса в header търга, всяка една импресия бива оферирана към DSP партньорите на борсата. Така че, вместо да се вижда една и съща импресия два или три пъти, сега е напълно възможно DSP-то да види една и съща импресия доста повече от само два пъти. Сега умножете това по милиард и това се превежда в доста високо увеличение на hosting наема. Освен ако тези нови импресии не са спечелени, те се появяват като разход с много малки приходи или въобще без приходи.

Потенциал за посредничество

С header bidding-a, издателите са тези които извършват уникалния обединен търг за инвентара си. И не просто SSP-тата и рекламните борси получават места за участие в тоя търг. Другите източници на оферти като DSP (demand-source platforms) и други лица като Amazon и Critero, също могат да участват. Всяка една компания е на едно и също ниво.

Замислете се за секунда. Като издател, да приемате оферти директно от DSP, означава че не трябва да заплащате 15 – 20 % такса за технологията към вашата борса или SSP партньор. Това е отлично за издателите, които дават информация, че вече виждат 30% до 50% от всеки един рекламен долар изхарчен на техните страници. Това е чудесно и за рекламодателя, защото означава, че много от техните рекламни бюджети отиват в собственика на медията, а не в посредниците. В този сценарии – борсите и SSP-тата изглеждат един скъп канал за предоставяне на оферти.

Дори и в крайна сметка да не ви се увеличи целият приход, което не е ситуацията, да си избереш партньор, който ти позволява да запазиш между 15 и 20% от всеки долар е доста добре. Това е отлично за издателите и платформите, които са с голямо търсене. Но е неприятен момент за агрегатори на търсене, като малките борси и SSP-та, които имат риска да се превърнат в скъпи услуги.

Потенциал за обединение

Един страничен ефект от header bidding-a е, че създава ограничено място за рекламодателите в header-a, който се определя от проблемите с латентността. Като резултат партньорите в търсенето, трябва да имат достатъчно търсене, така че да си заслужава включването им в търга. Ако един рекламен партньор е включен в header търга, но непрекъснато отпада, поради липса на конкурентно-способни оферти, то издателя може с пълно право да го изгони от header търга.

Въпреки това има доста нови header bidding решения, които са server базирани. Server-side решения, намаляват до незначително проблемите с латентността, като провеждат търга на самият сървър вместо в браузъра на посетителя, като по този начин намалят ограниченията за партньорите. Потенциалния проблем е, че търговете провеждани на сървър са не прозрачни, премахват количеството прозрачност през целия процес, освен ако нещо друго не е предоставено.

Нова надпревара за контрол на header-a

В конкурентната индустрия на технологията при рекламите е, че повечето компании искат да доминират. С header bidding, истинската сила идва чрез контролиране на wrapper-a, който управлява всичките header партньори. Управление на wrapper-a дава възможност на собственика на въпросния wrapper да събира данни за инвентара на издателя и динамиката на търга, чийто резултат е даване на информация относно икономиката като цяло.

Благодарение на тази сила и поради причините обяснени до момента, едно решение с отворен код би било най-доброто решение. Чрез използването на такова решение, рекламодателите могат да проверяват кода на wrapper-a и да се уверят, че няма нищо скрито-покрито, което да навреди на техните интереси. Точно заради това Prebid.js изключително бързо се превърна в един от най-популярните HBW.
От друга страна, едно решение на някоя рекламна и технологична копания не предлага такъв комфорт или способности.

Може би точно заради това Rubicon решиха да поддържат пътя на отворения код, потвърждение е следния цитат:

Ние поддържаме Prebid.js, защото вярваме че трябва да действаме върху отворен пазар, който позволявана всички участници да търгуват и извършват транзакции, които са прозрачни – това е съществено когато говорим за здравето на нашите издатели и рекламната индустрия като цяло.

Какво се очаква в бъдеще за Header Bidding-a?

Header bidding-a се оказа трън в петата за последователния модел на водопада. Един обединен търг е доста по-изключителен, както се показва с всяка една имплементация на header bidding-a. Но тези имплементации в голяма част са workarounds, издигнати върху технологично остарели системи като DFP-то на Google.

Такива решения са директна заплаха за хегемонията на Google и тяхното рекламно пространство. Въпреки всичко header bidding-a е предоставен с цел да е конкурентоспособен с рекламната борса на Google.

Дефицит на DoubleClick, Google алчност

Google имат голямо общество, тъй като държат голям брой от издатели, заради DoubleClick ad serve-a си и взимат преимущество от това. Един перфектен пример бе представянето на динамичното разпределение. Тази функция позволява на Google Ad Exchange (AdX) да печели импресии над директните поръчки, ако предложенията са достатъчно високи. Този тип отношение е разбираем към акционерите на Google, но това е монопол, който не е в изгода за останалите.

Header bidding изложи този дефицит в DFP-то на Google ad server-a. Той е направен като водопад и динамичното разпределение е предоставено изцяло по лични причини. Google нямат финансов стимул за да отвори DFP офертите към външните партньори, макар и да е имало някаква устна уговорка за такава откритост се създава Обмен на оферти в динамично разпределение (EBDA – Exchange Bidding in Dynamic Allocation), което, като всичките продукти на Google, е черна кутия.

С две думи header bidding-a поставя монопола на Google в техния ad server в доста неблагоприятна ситуация.

Заплахата: Алтернативни рекламни сървъри

Най-основната заплаха идва от алтернативните ad server-и създадени да бъдат по-холистични решения, с отвореност и наддавания в реално време, като основни функционалности, а не като допълнения. Един ad server, който позволява на издателите да имплементират един обединен търг с server-to-server връзки с борсите – и без абсурдната задача, ръчно да създава стотици или хиляди елементи – ясно е на къде отиват нещата.

Колкото по-дълго издателите продължават да имплементират header bidding-a върху DFP ad server-ите, Google ще държат контрола върху показването на реклами.

Като издател, заменянето на основния ad server не е много лесно. Представете си, че сменяте двигател на самолет в средата на полета. Като това е основният ви (единствен) двигател. Трудно е да си представите много издатели, да искат да поемат такъв риск. Но тези които го правят показват че това е решение в правилната посока и се радват на миграцията извън Google DFP.

Въпреки прогреса, имаме нужда от по-добри инструменти

Header bidding-a повдига доста важни въпроси: Колко време още ще отнеме на header bidding-a да премине от hack към mainstream? Точно в момента тече една фаза на възприемане при издателите. В момента в който голяма част от тях го приемат, колко ще размени наклона в силите в динамичността на технологичния свят на рекламата? Колко време ще е нужно да бъде като хак? Колко ще се променят ad server-ите на издателите? Кой ще е най-голямата заплаха за Google?

Ясно е – издателите имат нужда от доста по-хубави инструменти да поддържат инвентара си в един ефикасен, холистичен начин. Header bidding-a е главен скок в правилната дирекция, не е идеалното решение. Но е крачка към правилното решение. И като повечето иновации, кара технологията в рекламата да еволюира. На къде ще ни заведе тази еволюция – изглежда редизайн на рекламния сървър на издателя – където програмното решение е централно, а не впоследствие.