Zdi se, da bi moralo biti področje spletnega oglaševanja čim bolj tehnološko napredno in avtomatizirano. Seveda, ker tam delajo takšni velikani in strokovnjaki na svojem področju, kot so Yandex, Mail.Ru, Google in Facebook. Toda, kot se je izkazalo, ni omejitev za popolnost in vedno je nekaj za avtomatizacijo.
Komunikacijska skupina Dentsu Aegis Network Rusija je največji igralec na trgu digitalnega oglaševanja in aktivno vlaga v tehnologijo ter poskuša optimizirati in avtomatizirati svoje poslovne procese. Eden od nerešenih problemov trga spletnega oglaševanja je naloga zbiranja statističnih podatkov o oglaševalskih akcijah z različnih internetnih platform. Rešitev tega problema se je na koncu končala z nastankom izdelka D1.Digitalno (beri kot DiVan), o razvoju katerega želimo govoriti.
Zakaj?
1. V času začetka projekta na trgu ni bilo niti enega že pripravljenega izdelka, ki bi rešil problem avtomatizacije zbiranja statistike oglaševalskih akcij. To pomeni, da nihče razen nas samih ne bo zadovoljil naših potreb.
Storitve, kot so Improvado, Roistat, Supermetrics, SegmentStream, ponujajo integracijo s platformami, družbenimi omrežji in Google Analitycs ter omogočajo izdelavo analitičnih nadzornih plošč za priročno analizo in nadzor oglaševalskih kampanj. Preden smo začeli razvijati naš izdelek, smo poskušali uporabiti nekatere od teh sistemov za zbiranje podatkov s spletnih mest, vendar žal niso mogli rešiti naših težav.
Glavna težava je bila, da so preizkušeni izdelki temeljili na podatkovnih virih, prikazovali statistiko umestitev po spletnih mestih in niso omogočali združevanja statistik o oglaševalskih akcijah. Ta pristop nam ni omogočal, da bi na enem mestu videli statistiko z različnih spletnih mest in analizirali stanje kampanje kot celote.
Drugi dejavnik je bil, da so bili izdelki v začetnih fazah namenjeni zahodnemu trgu in niso podpirali integracije z ruskimi mesti. In za tista spletna mesta, s katerimi je bila izvedena integracija, vse potrebne metrike niso bile vedno prenesene z dovolj podrobnostmi, integracija pa ni bila vedno priročna in pregledna, zlasti ko je bilo treba pridobiti nekaj, česar ni v sistemskem vmesniku.
Na splošno smo se odločili, da se ne bomo prilagajali izdelkom tretjih proizvajalcev, ampak smo začeli razvijati lastne...
2. Trg spletnega oglaševanja iz leta v leto raste in je v letu 2018 po oglaševalskih proračunih prehitel tradicionalno največji trg televizijskega oglaševanja. Torej obstaja tehtnica.
3. Za razliko od televizijskega oglaševalskega trga, kjer je prodaja komercialnih oglasov monopolizirana, na internetu deluje veliko individualnih lastnikov oglasnega inventarja različnih velikosti s svojimi oglaševalskimi računi. Ker oglaševalska kampanja praviloma teče na več mestih hkrati, je za razumevanje stanja oglaševalske akcije potrebno zbrati poročila z vseh spletnih mest in jih združiti v eno veliko poročilo, ki bo prikazalo celotno sliko. To pomeni, da obstaja možnost optimizacije.
4. Zdelo se nam je, da lastniki oglasnega inventarja na internetu že imajo infrastrukturo za zbiranje statistike in prikaz le-teh v oglaševalskih računih in bodo lahko zagotovili API za te podatke. To pomeni, da ga je tehnično mogoče izvesti. Recimo takoj, da se je izkazalo, da ni tako preprosto.
Na splošno so nam bili vsi predpogoji za izvedbo projekta očitni in smo se pognali, da bi projekt zaživel ...
Veliki načrt
Za začetek smo oblikovali vizijo idealnega sistema:
- Oglaševalske akcije iz korporativnega sistema 1C je treba samodejno naložiti vanj s svojimi imeni, obdobji, proračuni in umestitvami na različnih platformah.
- Za vsako umestitev v okviru oglaševalske akcije je treba samodejno prenesti vse možne statistike s strani, kjer se umestitev izvaja, kot so število prikazov, klikov, ogledov itd.
- Nekatere oglaševalske akcije se spremljajo s pomočjo nadzora tretjih oseb s tako imenovanimi sistemi za oglaševanje, kot so Adriver, Weborama, DCM itd. V Rusiji obstaja tudi industrijski internetni merilnik - podjetje Mediascope. Po našem načrtu naj bi se podatki neodvisnega in industrijskega monitoringa avtomatsko nalagali tudi v ustrezne oglaševalske akcije.
- Večina oglaševalskih kampanj na spletu je usmerjenih v določene ciljne akcije (nakup, klic, prijava na testno vožnjo ipd.), ki se jim sledi s pomočjo Google Analytics in katerih statistika je prav tako pomembna za razumevanje statusa akcije in je treba naložiti v naše orodje.
Prva palačinka je kockasta
Glede na našo zavezanost fleksibilnim principom razvoja programske opreme (agilen, vse stvari), smo se odločili, da najprej razvijemo MVP in se nato iterativno premikamo proti zastavljenemu cilju.
Odločili smo se zgraditi MVP na podlagi našega izdelka DANBo (Dentsu Aegis Network Board), ki je spletna aplikacija s splošnimi informacijami o oglaševalskih akcijah naših strank.
Za MVP je bil projekt izvedbeno maksimalno poenostavljen. Izbrali smo omejen seznam platform za integracijo. To so bile glavne platforme, kot so Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB ter glavna oglaševalska sistema Adriver in Weborama.
Za dostop do statistike na spletnih mestih prek API-ja smo uporabili en sam račun. Vodja skupine strank, ki je želel uporabiti samodejno zbiranje statističnih podatkov o oglaševalski akciji, je moral najprej prenesti dostop do potrebnih oglaševalskih akcij na spletnih mestih na račun platforme.
Naslednji je uporabnik sistema DANBo je moral v sistem Excel naložiti datoteko določenega formata, ki je vsebovala vse podatke o umestitvi (oglaševalska kampanja, platforma, format, obdobje umestitve, načrtovani kazalniki, proračun itd.) in identifikatorje pripadajočih oglaševalskih akcij na mesta in števci v sistemih za oglaševanje.
Videti je bilo, odkrito povedano, grozljivo:
Preneseni podatki so bili shranjeni v bazo podatkov, nato pa so ločene storitve iz njih zbirale identifikatorje kampanj na spletnih mestih in o njih prenesle statistiko.
Za vsako spletno mesto je bila napisana ločena storitev Windows, ki je enkrat na dan šla pod en storitveni račun v API spletnega mesta in prenašala statistiko za določene ID-je oglaševalske akcije. Enako se je zgodilo z oglaševalskimi sistemi.
Preneseni podatki so bili prikazani na vmesniku v obliki majhne nadzorne plošče po meri:
Za nas nepričakovano je MVP začel delovati in začel prenašati aktualne statistike oglaševalskih akcij na internetu. Sistem smo implementirali na več odjemalcih, vendar smo pri poskusu skaliranja naleteli na resne težave:
- Glavna težava je bila kompleksnost priprave podatkov za nalaganje v sistem. Poleg tega je bilo treba podatke o umestitvi pred nalaganjem pretvoriti v strogo določeno obliko. V datoteko za prenos je bilo treba vključiti identifikatorje subjektov z različnih mest. Soočamo se z dejstvom, da je tehnično nepoučenim uporabnikom zelo težko razložiti, kje na spletnem mestu najti te identifikatorje in kam v datoteki jih je treba vpisati. Glede na število zaposlenih v oddelkih, ki izvajajo akcije na straneh in promet, je to povzročilo ogromno podpore na naši strani, s katero nikakor nismo bili zadovoljni.
- Druga težava je bila, da vse oglaševalske platforme niso imele mehanizmov za prenos dostopa do oglaševalskih kampanj na druge račune. Toda tudi če bi bil na voljo mehanizem pooblastil, vsi oglaševalci niso bili pripravljeni omogočiti dostopa do svojih kampanj računom tretjih oseb.
- Pomemben dejavnik je bilo ogorčenje, ki ga je med uporabniki vzbudilo dejstvo, da morajo vse planirane kazalnike in podatke o uvrstitvah, ki jih že vnesejo v naš računovodski sistem 1C, ponovno vnesti. DANBo.
To nam je dalo idejo, da bi moral biti primarni vir informacij o plasiranju naš sistem 1C, v katerega so vsi podatki vneseni točno in pravočasno (tukaj gre za to, da se računi generirajo na podlagi podatkov 1C, torej pravilen vnos podatkov v 1C). je prednostna naloga za vse KPI). Tako je nastal nov koncept sistema...
Koncept
Prva stvar, za katero smo se odločili, je bila ločitev sistema za zbiranje statistik o oglaševalskih akcijah na internetu v ločen izdelek - D1.Digitalno.
V novem konceptu smo se odločili naložiti v D1.Digitalno informacije o oglaševalskih akcijah in umestitvah v njih iz 1C, nato pa potegnite statistiko s spletnih mest in sistemov AdServing na te umestitve. To naj bi občutno poenostavilo življenje uporabnikom (in, kot običajno, dodalo več dela razvijalcem) in zmanjšalo količino podpore.
Prva težava, s katero smo se srečali, je bila organizacijske narave in je bila povezana s tem, da nismo našli ključa oziroma znaka, po katerem bi lahko primerjali entitete iz različnih sistemov z akcijami in umestitvami iz 1C. Dejstvo je, da je proces v našem podjetju zasnovan tako, da oglaševalske akcije v različne sisteme vnašajo različni ljudje (medijski načrtovalci, nakupi itd.).
Da bi rešili to težavo, smo morali izumiti edinstven zgoščeni ključ, DANBoID, ki bi povezal entitete v različnih sistemih skupaj in ki bi ga bilo mogoče dokaj enostavno in enolično identificirati v prenesenih nizih podatkov. Ta identifikator se ustvari v internem sistemu 1C za vsako posamezno umestitev in se prenese v akcije, umestitve in števce na vseh spletnih mestih in v vseh sistemih AdServing. Uvedba prakse dodajanja DANBoID-a v vse umestitve je trajala nekaj časa, vendar nam je uspelo :)
Potem smo ugotovili, da vsa spletna mesta nimajo API-ja za samodejno zbiranje statističnih podatkov in tudi tista, ki imajo API, ne vrnejo vseh potrebnih podatkov.
Na tej stopnji smo se odločili bistveno zmanjšati seznam platform za integracijo in se osredotočiti na glavne platforme, ki so vključene v veliko večino oglaševalskih kampanj. Ta seznam vključuje vse največje akterje na oglaševalskem trgu (Google, Yandex, Mail.ru), socialnih omrežjih (VK, Facebook, Twitter), večjih AdServing in analitičnih sistemih (DCM, Adriver, Weborama, Google Analytics) in drugih platformah.
Večina spletnih mest, ki smo jih izbrali, je imela API, ki je zagotavljal potrebne meritve. V primerih, ko ni bilo API-ja ali ni vseboval potrebnih podatkov, smo za nalaganje podatkov uporabili poročila, ki so bila dnevno poslana na naš službeni e-mail (v nekaterih sistemih je možno konfigurirati taka poročila, v drugih smo se dogovorili za razvoj takih poročil za nas).
Pri analizi podatkov iz različnih lokacij smo ugotovili, da hierarhija entitet v različnih sistemih ni enaka. Poleg tega je treba informacije prenesti z različnimi podrobnostmi iz različnih sistemov.
Za rešitev tega problema je bil razvit koncept SubDANBoID. Ideja SubDANBoID je precej enostavna, z generiranim DANBoID označimo glavno entiteto kampanje na spletnem mestu, vse ugnezdene entitete pa naložimo z unikatnimi identifikatorji spletnega mesta in oblikujemo SubDANBoID po principu DANBoID + identifikator prve stopnje. ugnezdena entiteta + identifikator ugnezdene entitete druge ravni +... Ta pristop nam je omogočil povezovanje oglaševalskih akcij v različnih sistemih in prenos podrobne statistike o njih.
Rešiti smo morali tudi problem dostopa do kampanj na različnih platformah. Kot smo zapisali zgoraj, mehanizem prenosa dostopa do oglaševalske akcije na ločen tehnični račun ni vedno uporaben. Zato smo morali razviti infrastrukturo za samodejno avtorizacijo preko OAuth z uporabo žetonov in mehanizmov za posodabljanje teh žetonov.
V nadaljevanju članka bomo skušali podrobneje opisati arhitekturo rešitve in tehnične podrobnosti izvedbe.
Arhitektura rešitve 1.0
Ob začetku implementacije novega produkta smo razumeli, da moramo takoj poskrbeti za možnost povezovanja novih lokacij, zato smo se odločili iti po poti mikrostoritvene arhitekture.
Pri zasnovi arhitekture smo priključke na vse zunanje sisteme – 1C, oglaševalske platforme in oglaševalske sisteme – ločili v ločene storitve.
Glavna ideja je, da imajo vsi povezovalniki s spletnimi mesti enak API in so adapterji, ki API spletnega mesta pripeljejo do vmesnika, ki nam ustreza.
V središču našega produkta je spletna aplikacija, ki je monolit, zasnovan tako, da jo je mogoče enostavno razstaviti na storitve. Ta aplikacija je odgovorna za obdelavo prenesenih podatkov, zbiranje statističnih podatkov iz različnih sistemov in njihovo predstavitev uporabnikom sistema.
Za komunikacijo med konektorji in spletno aplikacijo smo morali ustvariti dodatno storitev, ki smo jo poimenovali Connector Proxy. Izvaja funkcije odkrivanja storitev in načrtovalca opravil. Ta storitev vsako noč izvaja naloge zbiranja podatkov za vsak konektor. Pisanje sloja storitve je bilo lažje kot povezovanje posrednika sporočil in za nas je bilo pomembno, da dobimo rezultat čim hitreje.
Zaradi enostavnosti in hitrosti razvoja smo se tudi odločili, da bodo vse storitve spletni API-ji. To je omogočilo hitro sestavljanje dokaza koncepta in preverjanje, ali celotna zasnova deluje.
Posebna, dokaj kompleksna naloga je bila nastavitev dostopa do zbiranja podatkov iz različnih računov, ki naj bi jo, kot smo se odločili, izvajali uporabniki prek spletnega vmesnika. Sestavljen je iz dveh ločenih korakov: najprej uporabnik doda žeton za dostop do računa prek OAuth, nato pa konfigurira zbiranje podatkov za odjemalca iz določenega računa. Pridobitev žetona prek OAuth je nujna, saj, kot smo že zapisali, ni vedno mogoče delegirati dostopa do želenega računa na strani.
Da bi ustvarili univerzalni mehanizem za izbiro računa s spletnih mest, smo morali API-ju konektorjev dodati metodo, ki vrne shemo JSON, ki je upodobljena v obrazec s spremenjeno komponento JSONEditor. Tako so lahko uporabniki izbrali račune, s katerih bodo prenesli podatke.
Zaradi skladnosti z omejitvami zahtev, ki obstajajo na spletnih mestih, združujemo zahteve za nastavitve znotraj enega žetona, vendar lahko vzporedno obdelujemo različne žetone.
MongoDB smo izbrali kot shrambo za naložene podatke tako za spletno aplikacijo kot za konektorje, kar nam je omogočilo, da nismo preveč skrbeli za strukturo podatkov v začetnih fazah razvoja, ko se objektni model aplikacije spreminja vsak drugi dan.
Kmalu smo ugotovili, da se vsi podatki ne prilegajo dobro v MongoDB in je na primer dnevne statistike bolj priročno shranjevati v relacijski bazi podatkov. Zato smo za konektorje, katerih podatkovna struktura je primernejša za relacijsko bazo podatkov, kot pomnilnik začeli uporabljati PostgreSQL ali MS SQL Server.
Izbrana arhitektura in tehnologije so nam omogočile relativno hitro izgradnjo in lansiranje produkta D1.Digital. V dveh letih razvoja izdelkov smo razvili 23 povezovalnikov s spletnimi mesti, pridobili neprecenljive izkušnje pri delu z API-ji tretjih oseb, se naučili izogibati pastem različnih spletnih mest, ki so imela vsaka svojega, prispevali k razvoju API-jev vsaj 3 strani, avtomatsko prenesli informacije o skoraj 15 kampanjah in za več kot 000 umestitvah, zbrali veliko povratnih informacij uporabnikov o delovanju produkta in na podlagi teh povratnih informacij večkrat spremenili glavni proces produkta.
Arhitektura rešitve 2.0
Od začetka razvoja sta minili dve leti D1.Digitalno. Nenehno povečevanje obremenitev sistema in pojav vedno več novih podatkovnih virov so postopoma razkrivali težave v obstoječi arhitekturi rešitve.
Prva težava je povezana s količino podatkov, prenesenih s spletnih mest. Soočili smo se z dejstvom, da je zbiranje in posodabljanje vseh potrebnih podatkov z največjih spletnih mest začelo vzeti preveč časa. Na primer, zbiranje podatkov iz oglaševalskega sistema AdRiver, s katerim spremljamo statistiko za večino umestitev, traja približno 12 ur.
Da bi rešili to težavo, smo začeli uporabljati vse vrste poročil za prenos podatkov s spletnih mest, skupaj s spletnimi mesti poskušamo razviti njihov API, tako da hitrost njegovega delovanja ustreza našim potrebam, in čim bolj paralelizirati prenos podatkov.
Druga težava je povezana z obdelavo prenesenih podatkov. Zdaj, ko prispejo novi statistični podatki o umestitvah, se sproži večstopenjski postopek ponovnega izračuna metrik, ki vključuje nalaganje neobdelanih podatkov, izračun združenih metrik za vsako spletno mesto, medsebojno primerjavo podatkov iz različnih virov in izračun povzetkov metrik za kampanjo. To povzroči veliko obremenitev spletne aplikacije, ki izvaja vse izračune. Večkrat je aplikacija med postopkom preračunavanja porabila ves pomnilnik na strežniku, cca 10-15 GB, kar je najbolj slabo vplivalo na delo uporabnikov s sistemom.
Ugotovljene težave in ambiciozni načrti za nadaljnji razvoj produkta so nas pripeljali do potrebe po ponovnem premisleku o arhitekturi aplikacije.
Začeli smo s priključki.
Opazili smo, da vsi konektorji delujejo po istem modelu, zato smo zgradili cevovodno ogrodje, v katerem ste morali za ustvarjanje konektorja programirati samo logiko korakov, ostalo je bilo univerzalno. Če kakšen konektor potrebuje izboljšavo, ga takoj prenesemo v novo ogrodje, hkrati z izboljšavo konektorja.
Istočasno smo začeli uvajati konektorje za Docker in Kubernetes.
Prehod na Kubernetes smo načrtovali kar dolgo časa, eksperimentirali z nastavitvami CI/CD, a selitve začeli šele, ko je en konektor zaradi napake začel jesti več kot 20 GB pomnilnika na strežniku in tako rekoč ubijal druge procese. . Med preiskavo je bil konektor premaknjen v gručo Kubernetes, kjer je na koncu ostal tudi po odpravi napake.
Kar hitro smo ugotovili, da je Kubernetes priročen, in v šestih mesecih smo 7 konektorjev in Connectors Proxy, ki porabijo največ virov, prenesli v produkcijski grozd.
Po konektorjih smo se odločili spremeniti arhitekturo preostale aplikacije.
Glavna težava je bila, da podatki prihajajo iz konektorjev v posrednike v velikih serijah, nato pa pridejo do DANBoID in se pošljejo v osrednjo spletno aplikacijo v obdelavo. Zaradi velikega števila preračunavanj metrik je aplikacija velika obremenitev.
Prav tako se je izkazalo za precej težavno spremljanje statusa posameznih opravil zbiranja podatkov in poročanje o napakah, ki se pojavljajo v konektorjih za osrednjo spletno aplikacijo, tako da so lahko uporabniki videli, kaj se dogaja in zakaj se podatki ne zbirajo.
Za rešitev teh težav smo razvili arhitekturo 2.0.
Glavna razlika med novo različico arhitekture je v tem, da namesto spletnega API-ja uporabljamo RabbitMQ in knjižnico MassTransit za izmenjavo sporočil med storitvami. Da bi to naredili, smo morali skoraj v celoti prepisati Connectors Proxy, tako da je postal Connectors Hub. Ime je bilo spremenjeno, ker glavna vloga storitve ni več posredovanje zahtev konektorjem in nazaj, temveč upravljanje zbiranja metrik iz konektorjev.
Iz osrednje spletne aplikacije smo podatke o umestitvah in statistike s strani ločili v ločene storitve, s čimer smo se znebili nepotrebnih preračunavanj in hranili le že izračunane in agregirane statistike na ravni umestitev. Prav tako smo prenovili in optimizirali logiko za izračun osnovne statistike na podlagi neobdelanih podatkov.
Hkrati selimo vse storitve in aplikacije v Docker in Kubernetes, da bo rešitev lažja za prilagajanje in bolj priročna za upravljanje.
Kje smo zdaj
Proof-of-concept architecture 2.0 izdelek D1.Digitalno pripravljen in deluje v testnem okolju z omejenim naborom priključkov. Vse, kar morate storiti, je, da na novo napišete še 20 konektorjev na novo platformo, preizkusite, ali so podatki pravilno naloženi in so vse metrike pravilno izračunane, ter uvedete celotno zasnovo v proizvodnjo.
Pravzaprav se bo ta proces zgodil postopoma in morali bomo opustiti združljivost za nazaj s starimi API-ji, da bo vse delovalo.
Naši neposredni načrti vključujejo razvoj novih konektorjev, integracijo z novimi sistemi in dodajanje dodatnih meritev naboru podatkov, prenesenih s povezanih spletnih mest in sistemov za oglaševanje.
Načrtujemo tudi prenos vseh aplikacij, vključno s centralno spletno aplikacijo, na Docker in Kubernetes. V kombinaciji z novo arhitekturo bo to bistveno poenostavilo uvajanje, spremljanje in nadzor porabljenih virov.
Druga ideja je poskusiti z izbiro baze podatkov za shranjevanje statistike, ki je trenutno shranjena v MongoDB. V baze podatkov SQL smo že prenesli nekaj novih konektorjev, a tam je razlika skoraj neopazna, pri agregirani statistiki po dnevih, ki jo lahko zahtevamo za poljubno obdobje, pa je lahko dobiček kar resen.
Na splošno so načrti veličastni, gremo naprej :)
Avtorji članka R&D Dentsu Aegis Network Russia: Georgij Ostapenko (), Mikhail Kotsik ()
Vir: www.habr.com