Inainte de RTB – Real Time Bidding si programatic sa analizam putin functionarea in modul „clasic„, atunci cand advertiser-ul deruleaza o campanie pe spatiile unui publisher prin clasicul ad server. Componentele „clasice” isi vor pastra locul si in „programatic”, orchestratia fiind insa diferita.
Sa presupunem ca advertiser-ul dispune si el de un ad server pentru a servi si consolida indicatorii campaniei peste toti partenerii media (impressions, clicks, unici etc).
Pe scurt, Advertiser-ul incarca ad-ul/creatia in ad serverul propriu (ad server-ul pentru advertiser) si genereaza un script, ad tag pe care il trimite publisher-ului, acest script livrand si monitorizand creatia in pagina web a publisherului atunci cand acesta decide sa o afiseze prin ad serverul lui. Am presupus ca cele doua parti au negocia deja si s-au inteles asupra pretului, targetarii, volumului de afisari etc., campania urmand doar a fi executata, livrata conform media planului. Inainte de stabilirea deal-ului cu publisher-ii exista si un alt pas, planificarea media, important pentru eficienta campaniei.
Sa vedem acum ce ajunge la Publisher, si ce se va intampla: acesta seteaza in ad server-ul de publisher campania advertiserului conform conditiilor agreate cu acesta. Creatia in sine, ad-ul care va aparea in pagina este acum script-ul pe care advertiser-ul i l-a generat din ad server-ul de advertiser, aceasta fiind livrat in pagina web. Deci, ad server-ul publisher ruleaza in pagina web a publisher-ului si livreaza script-ul advertiser-ului, in consecinta inregistreaza o afisare corespunzatoare campaniei in sistemul publisher-ului. Script-ul advertiserului rulat prin ad serverul publisherului afiseaza reclama in pagina si inregistreaza si el o afisare in ad server advertiser.
Pana aici toate bune si frumoase, avem 1 afisare in ad server publisher, 1 afisare in ad server advertiser.
Exista si cazul in care advertiser-ul nu dispune de un ad server si trimite materialele campaniei direct publisher-ului, urmand ca acesta sa le incarce si sa le afiseze folosind doar ad server-ul lui (publisher). In acest caz advertiser-ul trebuie sa-i acorde toata increderea publisher-ului. La terminarea campaniei sau pe parcurs, advertiser-ul poate primi acces in ad server-ul publisher-ului pentru a vedea rapoartele partiale sau finale ale campaniei, sau le primeste direct pe suport electronic. Orice modificare in planul campaniei, schimbari ale creatiei etc. va trebui sa le ceara publisher-ului pentru ca acesta sa le opereze in ad server-ul lui.
Sa vedem ce probleme pot aparea: in realitate sunt sanse ca paritatea cifrelor din cele doua ad servere sa nu fie 1 la 1. Pentru ca in browser intr-o pagina web ruleaza simultan o multitudine de alte reclame, widget-uri si alte script-uri cu diverse functionalitati. Acestea nu se executa simultan, ci sunt prioritizate de browser conform unor algoritmi interni si rulate dintr-o coada de executie. De multe ori incarcarea si executia tuturor scripturilor si resurselor dintr-o pagina web poate dura de la 1- 3 secunde pana la 10-15 de sec. Script-urile celor doua ad servere, publisher si advertiser, sunt total independente unul de altul, iar browser-ul le pune si pe ele in aceeasi coada de executie. Rezultatul este ca in situatii in care user-ul paraseste pagina in timp ce se incarca, script-ul ad server publisher s-a executat, insa script-ul ad server advertiser nu, astfel ca vom avea 1 afisare la publisher si niciuna la advertiser. Acesta este doar unul din motivele care produc „ad server discrepancies”, cu o gramada de repercursiuni in procesul de business: reconciliere, facturare, replanificare, post-investigatii samd.
Discrepantele pot aparea si de la greseli de operare in ad servere, de la faptul ca fiecare ad server este diferit, fiecare site este diferit din punct de vedere al solutiei tehnice si a implementarii codurilor de ad server, codurile si implementarea metodelor de masurare difera samd. Toate acestea produc intarzieri si consum de resurse semnificativ in journey-ul campaniei, pornind dupa etapa de planificare si terminand cu facturarea si plata afisarilor.
Mai mult decat atat, in momentul incarcarii paginii web, cand ad server-ul de publisher decide sa livreze campania advertiser-ului si ruleaza script-ul ce va afisa ad-ul, ad server-ul advertiser-ului este obligat sa livreze reclama respectiva indiferent de caracteristicele afisarii (adica profilul utilizatorului care urmareste pagina web a publisher-ului – nu poate spune ca nu-i convine altfel ar lasa spatiul reclamei din pagina publisher-ului gol, alb, empty). Deci publisher-ul orchestreaza complet campania, advertiser-ul doar livrand efectiv mesajul in pagina si numarand afisarea, click-ul samd, practic el este un observator care ia act de livrarea reclamei, neputand decide daca afisarea respectiva se incadreaza in audienta planificata a campaniei respective.
Un alt minus important: orice modificare a campaniei implica comunicare si sincronizare tehnica intre advertiser si publisher, operandu-se doua sisteme paralele total deconectate unul de altul. O mare parte din responsabilitate pentru bunul mers al lucrurilor revine in sarcina echipelor de ad ops, pe langa tehnologia de ad serving utilizata in sine (fiecare cu particularitati, avantaje si dezavantaje).
De asemenea, in marea majoritate a cazurilor, exista un delay destul de mare intre etapa de planificare, negociere si achizitie si livrarea efectiva a campaniei, iar acest lucru face destul de greoaie reorientarea, realocarea sau regandirea strategiei de publicitate a advertiser-ului.
Toate acestea duc la procese operationale greoaie cu consum ridicat de resurse umane si feedback foarte greoi (legat de implementare, optimizare, schimbari etc). Nu uitati si ca intr-o campanie sunt implicate multi jucatori, in general business unit-uri diferite: cel care isi face reclama, cel care realizeaza creatia, agentia de publicitate, agentia de digital si media, asta pe partea de demand, pe partea de supply avem site-ul/publisher-ul care se vinde singur sau printr-o agentie de vanzari.
Era nevoie de o deschidere si o interconectare a player-ilor, astfel incat sa existe transparenta, eficienta si automatizare, si mai putina eroare si consum de resurse umane. Modul de lucru al clasicelor ad server-e se pare ca nu a reusit sa evolueze astfel incat sa permita scenarii de implementare in care toti player-ii sa poata lua decizii in timp real.
Noul protocol de Real Time Bidding aparut pentru interconectarea programatica a player-ilor permite reformarea unora din etapele procesului descris mai sus, si introduce cateva avantaje importante:
RTB-ul devine astfel limbajul de comunicatie intre diferitele aplicatii si platforme implicate in lantul programatic, poti (re)vedea aici the big picture.
Dar haideti sa vedem cum functioneaza de fapt RTB-ul si cum se schimba peisajul din advertising-ul digital in RTB journey part II…
