Publicitate online si programatic, journey to RTB, part I

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.

marketingland.com

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:

  •  scade efortul de implementare al campaniei de catre advertiser (prin reducerea numarului de parteneri directi, advertiser-ul nu mai lucreaza direct cu fiecare publisher, ci doar cu cateva DSP-uri prin Trade desk);
  • targetarea si controlul se muta in zona advertiser-ului, el putand sa decida singur catre ce utilizatori si cand va livra respectiva reclama, nefiind obligat doar sa priveasca la cum decurge campania; aici intervin sursele de date si audientele, DMP-ul;
  • efortul de resurse umane, sales si ad ops, scade considerabil prin automatizare pe partea ambelor parti, advertiser si publisher;
  • audienta pe care un advertiser o are la dispozitie creste simtitor prin accesul simultan la inventory-ul web (afisarile) din mai multe Exchange-uri;
  • optimizarea unei campanii se poate face mult mai rapid si usor, advertiser-ul fiind cel care controleaza si orchestreaza “derularea” campaniei, publisher-ul nemaifiind implicat in controlul fin al fiecarei campanii,
  • publisher-ul isi poate vinde afisarile catre un numar mult mai mare de advertiser-i prin metode de tip licitatie.

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

Author: AdUnity

+10 years together in computer tehnology development