Čini se da bi područje online oglašavanja trebalo biti tehnološki naprednije i automatizirano što je više moguće. Naravno, jer tamo rade takvi divovi i stručnjaci u svojoj oblasti kao što su Yandex, Mail.Ru, Google i Facebook. Ali, kako se pokazalo, ne postoji granica savršenstvu i uvijek postoji nešto što se može automatizirati.
Grupa za komunikacije Dentsu Aegis Network Rusija je najveći igrač na tržištu digitalnog oglašavanja i aktivno ulaže u tehnologiju, pokušavajući optimizirati i automatizirati svoje poslovne procese. Jedan od neriješenih problema tržišta online oglašavanja postao je zadatak prikupljanja statističkih podataka o reklamnim kampanjama sa različitih internetskih platformi. Rješenje ovog problema je u konačnici rezultiralo stvaranjem proizvoda D1.Digital (čitaj kao DiVan), o čijem razvoju želimo da pričamo.
Zašto?
1. U trenutku početka projekta na tržištu nije postojao niti jedan gotov proizvod koji je riješio problem automatizacije prikupljanja statistike o reklamnim kampanjama. To znači da niko osim nas samih neće zadovoljiti naše potrebe.
Usluge kao što su Improvado, Roistat, Supermetrics, SegmentStream nude integraciju sa platformama, društvenim mrežama i Google Analitycs, a također omogućavaju izradu analitičkih nadzornih ploča za praktičnu analizu i kontrolu reklamnih kampanja. Pre nego što smo počeli da razvijamo naš proizvod, pokušali smo da koristimo neke od ovih sistema za prikupljanje podataka sa sajtova, ali, nažalost, nisu mogli da reše naše probleme.
Glavni problem je bio u tome što su testirani proizvodi bili bazirani na izvorima podataka, prikazujući statistiku plasmana po sajtovima, i nisu davali mogućnost agregiranja statistike o reklamnim kampanjama. Ovakav pristup nam nije omogućio da na jednom mjestu vidimo statistiku sa različitih sajtova i analiziramo stanje kampanje u cjelini.
Drugi faktor je bio to što su u početnim fazama proizvodi bili usmjereni na zapadno tržište i nisu podržavali integraciju s ruskim stranicama. A za one sajtove sa kojima je implementirana integracija, sve potrebne metrike nisu uvek bile preuzete sa dovoljno detalja, a integracija nije uvek bila zgodna i transparentna, posebno kada je bilo potrebno nabaviti nešto što nije u interfejsu sistema.
Generalno, odlučili smo da se ne prilagođavamo proizvodima trećih strana, već smo počeli da razvijamo sopstvene...
2. Tržište oglašavanja na mreži raste iz godine u godinu, te je u 2018. godini, u smislu budžeta za oglašavanje, preteklo tradicionalno najveće tržište TV oglašavanja. Dakle, postoji skala.
3. Za razliku od tržišta TV oglašavanja, gdje je prodaja komercijalnog oglašavanja monopolizirana, postoji veliki broj pojedinačnih vlasnika reklamnog inventara različitih veličina koji posluju na Internetu sa vlastitim reklamnim računima. S obzirom da se reklamna kampanja u pravilu odvija na nekoliko stranica odjednom, da bi se razumjelo stanje reklamne kampanje, potrebno je prikupiti izvještaje sa svih stranica i objediniti ih u jedan veliki izvještaj koji će prikazati cijelu sliku. To znači da postoji potencijal za optimizaciju.
4. Činilo nam se da vlasnici oglasnog inventara na Internetu već imaju infrastrukturu za prikupljanje statistike i njihovo prikazivanje na reklamnim nalozima, te će za ove podatke moći obezbijediti API. To znači da je to tehnički moguće implementirati. Recimo odmah da se pokazalo da nije tako jednostavno.
Generalno, svi preduslovi za realizaciju projekta su nam bili očigledni i mi smo trčali da projekat oživimo...
Veliki plan
Za početak smo formirali viziju idealnog sistema:
- Reklamne kampanje iz 1C korporativnog sistema treba automatski učitati u njega sa svojim nazivima, periodima, budžetima i plasmanima na različitim platformama.
- Za svaki plasman u okviru reklamne kampanje treba automatski preuzeti svu moguću statistiku sa sajtova na kojima se plasman odvija, kao što su broj impresija, klikova, pregleda itd.
- Neke reklamne kampanje se prate korištenjem nadzora treće strane od strane takozvanih adserving sistema kao što su Adriver, Weborama, DCM, itd. U Rusiji postoji i industrijski internet mjerač - kompanija Mediascope. Prema našem planu, podaci iz nezavisnog i industrijskog monitoringa bi takođe trebali biti automatski učitani u odgovarajuće reklamne kampanje.
- Većina reklamnih kampanja na internetu usmjerena je na određene ciljne radnje (kupovina, poziv, prijava za probnu vožnju i sl.), koje se prate pomoću Google Analyticsa, a statistika za koje je također važna za razumijevanje statusa kampanje i treba učitati u naš alat.
Prva palačinka je grupisana
S obzirom na našu posvećenost fleksibilnim principima razvoja softvera (agilno, sve), odlučili smo prvo razviti MVP, a zatim iterativno krenuti ka željenom cilju.
Odlučili smo da napravimo MVP na osnovu našeg proizvoda DANBo (Dentsu Aegis mrežna ploča), što je web aplikacija s općim informacijama o reklamnim kampanjama naših klijenata.
Za MVP, projekat je maksimalno pojednostavljen u smislu implementacije. Odabrali smo ograničenu listu platformi za integraciju. To su bile glavne platforme, kao što su Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB i glavni sistemi za oglašavanje Adriver i Weborama.
Za pristup statističkim podacima o web lokacijama putem API-ja koristili smo jedan račun. Menadžer grupe klijenata koji je želio koristiti automatsko prikupljanje statistike o reklamnoj kampanji morao je prvo delegirati pristup potrebnim reklamnim kampanjama na stranicama na račun platforme.
Sljedeći je korisnik sistema DANBo morao u Excel sistem učitati datoteku određenog formata koja je sadržavala sve podatke o plasmanu (reklamna kampanja, platforma, format, period plasmana, planirani pokazatelji, budžet itd.) i identifikatore odgovarajućih reklamnih kampanja na stranice i šalteri u sistemima za oglašavanje.
Iskreno, izgledalo je zastrašujuće:
Preuzeti podaci su pohranjeni u bazu podataka, a zatim su odvojeni servisi sa njih prikupljali identifikatore kampanja na stranicama i preuzimali statistiku o njima.
Za svaku web lokaciju napisan je poseban windows servis, koji je jednom dnevno išao pod jedan servisni račun u API-ju stranice i preuzimao statistiku za određene ID-ove kampanja. Ista stvar se desila i sa sistemima za oglašavanje.
Preuzeti podaci su prikazani na interfejsu u obliku male prilagođene kontrolne table:
Neočekivano za nas, MVP je počeo sa radom i počeo da preuzima trenutnu statistiku o reklamnim kampanjama na internetu. Sistem smo implementirali na nekoliko klijenata, ali prilikom pokušaja skaliranja naišli smo na ozbiljne probleme:
- Glavni problem je bila složenost pripreme podataka za učitavanje u sistem. Takođe, podaci o plasmanu su morali da se konvertuju u strogo fiksni format pre učitavanja. Bilo je neophodno uključiti identifikatore entiteta sa različitih lokacija u datoteku za preuzimanje. Suočeni smo s činjenicom da je tehnički neobučenim korisnicima vrlo teško objasniti gdje na sajtu pronaći ove identifikatore i gdje ih u fajlu treba unijeti. S obzirom na broj zaposlenih u odjeljenjima koji vode kampanje na sajtovima i promet, to je rezultiralo ogromnom podrškom na našoj strani, s kojom apsolutno nismo bili zadovoljni.
- Drugi problem je bio što nisu sve platforme za oglašavanje imale mehanizme za delegiranje pristupa reklamnim kampanjama na druge naloge. Ali čak i da je mehanizam delegiranja bio dostupan, nisu svi oglašivači bili voljni dati pristup svojim kampanjama računima trećih strana.
- Važan faktor je bilo ogorčenje koje je izazvalo među korisnicima činjenica da sve planirane indikatore i detalje plasmana koje već unose u naš 1C računovodstveni sistem, moraju ponovo unijeti u DANBo.
To nam je dalo ideju da primarni izvor informacija o plasmanu treba da bude naš 1C sistem, u koji se svi podaci unose tačno i na vreme (ovde se radi o tome da se fakture generišu na osnovu podataka 1C, tako da ispravan unos podataka u 1C je prioritet za sve KPI). Tako je nastao novi koncept sistema...
Koncept
Prvo što smo odlučili je da odvojimo sistem za prikupljanje statistike o reklamnim kampanjama na Internetu u poseban proizvod - D1.Digital.
U novom konceptu odlučili smo se ubaciti D1.Digital informacije o reklamnim kampanjama i plasmanima unutar njih iz 1C, a zatim povući statistiku sa web lokacija i AdServing sistema do ovih plasmana. Ovo je trebalo značajno pojednostaviti život korisnicima (i, kao i obično, dodati više posla programerima) i smanjiti količinu podrške.
Prvi problem na koji smo naišli bio je organizacijske prirode i odnosio se na činjenicu da nismo mogli pronaći ključ ili znak po kojem bismo mogli uporediti entitete iz različitih sistema sa kampanjama i plasmanima iz 1C. Činjenica je da je proces u našoj kompaniji osmišljen tako da reklamne kampanje unose različiti ljudi u različite sisteme (medijski planeri, kupovina itd.).
Da bismo riješili ovaj problem, morali smo izmisliti jedinstveni heširani ključ, DANBoID, koji bi povezivao entitete u različitim sistemima zajedno, i koji bi se mogao prilično lako i jedinstveno identificirati u preuzetim skupovima podataka. Ovaj identifikator se generiše u internom 1C sistemu za svaki pojedinačni plasman i prenosi se na kampanje, plasmane i šaltere na svim sajtovima iu svim AdServing sistemima. Implementacija prakse stavljanja DANBoID-a na sve plasmane je potrajala, ali smo uspjeli :)
Tada smo saznali da nemaju sve stranice API za automatsko prikupljanje statistike, a čak i one koje imaju API ne vraćaju sve potrebne podatke.
U ovoj fazi odlučili smo značajno smanjiti listu platformi za integraciju i fokusirati se na glavne platforme koje su uključene u veliku većinu reklamnih kampanja. Ova lista uključuje sve najveće igrače na tržištu oglašavanja (Google, Yandex, Mail.ru), društvenim mrežama (VK, Facebook, Twitter), glavnim AdServing i analitičkim sistemima (DCM, Adriver, Weborama, Google Analytics) i drugim platformama.
Većina web lokacija koje smo odabrali imala je API koji je pružao potrebne metrike. U slučajevima kada nije postojao API ili nije sadržavao potrebne podatke, koristili smo izvještaje koji se svakodnevno šalju na našu kancelarijsku e-poštu za učitavanje podataka (u nekim sistemima je moguće konfigurirati takve izvještaje, u drugima smo dogovorili izradu takvih izvještaja za nas).
Analizirajući podatke sa različitih sajtova, otkrili smo da hijerarhija entiteta nije ista u različitim sistemima. Štaviše, informacije se moraju preuzimati u različitim detaljima iz različitih sistema.
Za rješavanje ovog problema razvijen je koncept SubDANBoID. Ideja SubDANBoID-a je prilično jednostavna, generisanim DANBoID-om označavamo glavni entitet kampanje na sajtu, a sve ugniježđene entitete učitavamo jedinstvenim identifikatorima stranice i formiramo SubDANBoID po DANBoID principu + identifikator prvog nivoa ugniježđeni entitet + identifikator drugog nivoa ugniježđenog entiteta +... Ovaj pristup nam je omogućio da povežemo reklamne kampanje u različitim sistemima i preuzmemo detaljnu statistiku o njima.
Također smo morali riješiti problem pristupa kampanjama na različitim platformama. Kao što smo gore napisali, mehanizam delegiranja pristupa kampanji na poseban tehnički račun nije uvijek primjenjiv. Stoga smo morali razviti infrastrukturu za automatsku autorizaciju putem OAuth-a koristeći tokene i mehanizme za ažuriranje ovih tokena.
Kasnije ćemo u članku pokušati detaljnije opisati arhitekturu rješenja i tehničke detalje implementacije.
Arhitektura rješenja 1.0
Kada smo krenuli u implementaciju novog proizvoda, shvatili smo da odmah trebamo obezbijediti mogućnost povezivanja novih lokacija, pa smo odlučili krenuti putem mikroservisne arhitekture.
Prilikom projektovanja arhitekture izdvojili smo konektore za sve eksterne sisteme - 1C, reklamne platforme i sisteme za oglašavanje - u zasebne servise.
Glavna ideja je da svi konektori za sajtove imaju isti API i da su adapteri koji dovode API sajta do interfejsa koji nam odgovara.
U središtu našeg proizvoda je web aplikacija, koja je monolit koji je dizajniran na način da se lako može rastaviti na servise. Ova aplikacija je odgovorna za obradu preuzetih podataka, prikupljanje statističkih podataka iz različitih sistema i njihovo predstavljanje korisnicima sistema.
Da bismo komunicirali između konektora i web aplikacije, morali smo kreirati dodatnu uslugu, koju smo nazvali Connector Proxy. Obavlja funkcije otkrivanja usluga i planera zadataka. Ova usluga izvršava zadatke prikupljanja podataka za svaki konektor svake noći. Pisanje sloja usluge bilo je lakše od povezivanja brokera poruka, a nama je bilo važno da dobijemo rezultat što je brže moguće.
Radi jednostavnosti i brzine razvoja, odlučili smo da svi servisi budu Web API-ji. To je omogućilo brzo sastavljanje dokaza o konceptu i provjeru funkcioniranja cijelog dizajna.
Poseban, prilično složen zadatak bilo je postavljanje pristupa za prikupljanje podataka sa različitih naloga, koje bi, kako smo odlučili, korisnici trebali obavljati putem web interfejsa. Sastoji se od dva odvojena koraka: prvo, korisnik dodaje token za pristup nalogu putem OAuth-a, a zatim konfiguriše prikupljanje podataka za klijenta sa određenog naloga. Dobijanje tokena putem OAuth-a je neophodno jer, kao što smo već pisali, nije uvijek moguće delegirati pristup željenom računu na stranici.
Da bismo kreirali univerzalni mehanizam za odabir naloga sa sajtova, morali smo da dodamo metod u API konektora koji vraća JSON šemu, koja se prikazuje u formu pomoću modifikovane komponente JSONEditor. Na ovaj način, korisnici su mogli odabrati račune sa kojih će preuzeti podatke.
Da bismo ispunili ograničenja zahtjeva koja postoje na web lokacijama, kombiniramo zahtjeve za postavke unutar jednog tokena, ali možemo paralelno obraditi različite tokene.
Odabrali smo MongoDB kao skladište za učitane podatke i za web aplikaciju i za konektore, što nam je omogućilo da ne brinemo previše o strukturi podataka u početnim fazama razvoja, kada se objektni model aplikacije mijenja svaki drugi dan.
Ubrzo smo otkrili da se svi podaci ne uklapaju dobro u MongoDB i da je, na primjer, zgodnije pohranjivati dnevnu statistiku u relacijsku bazu podataka. Stoga smo za konektore čija je struktura podataka pogodnija za relacionu bazu podataka, počeli koristiti PostgreSQL ili MS SQL Server kao skladište.
Odabrana arhitektura i tehnologije omogućile su nam da napravimo i lansiramo D1.Digital proizvod relativno brzo. Tokom dvije godine razvoja proizvoda razvili smo 23 konektora za web stranice, stekli neprocjenjivo iskustvo u radu sa API-jima trećih strana, naučili izbjegavati zamke različitih stranica, od kojih je svaka imala svoje, doprinijeli razvoju API-ja od najmanje 3 stranicama, automatski preuzeli informacije o gotovo 15 kampanja i za više od 000 plasmana, prikupili su dosta povratnih informacija od korisnika o radu proizvoda i uspjeli nekoliko puta promijeniti glavni proces proizvoda na osnovu ovih povratnih informacija.
Arhitektura rješenja 2.0
Prošle su dvije godine od početka razvoja D1.Digital. Konstantno povećanje opterećenja sistema i pojava sve više i više novih izvora podataka postepeno su otkrivali probleme u postojećoj arhitekturi rješenja.
Prvi problem je vezan za količinu podataka preuzetih sa sajtova. Suočili smo se sa činjenicom da je prikupljanje i ažuriranje svih potrebnih podataka sa najvećih sajtova počelo da oduzima previše vremena. Na primjer, prikupljanje podataka iz AdRiver adserving sistema, pomoću kojeg pratimo statistiku za većinu plasmana, traje oko 12 sati.
Kako bismo riješili ovaj problem, počeli smo koristiti sve vrste izvještaja za preuzimanje podataka sa sajtova, trudimo se da zajedno sa sajtovima razvijemo njihov API kako bi brzina njegovog rada odgovarala našim potrebama, i što više paralelizirali preuzimanje podataka.
Drugi problem se odnosi na obradu preuzetih podataka. Sada, kada stigne nova statistika plasmana, pokreće se višefazni proces ponovnog izračunavanja metrike, koji uključuje učitavanje neobrađenih podataka, izračunavanje agregiranih metrika za svaku web lokaciju, međusobno poređenje podataka iz različitih izvora i izračunavanje zbirnih metrika za kampanju. To uzrokuje veliko opterećenje na web aplikaciji koja obavlja sve proračune. Nekoliko puta je tokom procesa ponovnog izračunavanja aplikacija potrošila svu memoriju na serveru, oko 10-15 GB, što je najštetnije uticalo na rad korisnika sa sistemom.
Identifikovani problemi i ambiciozni planovi za dalji razvoj proizvoda doveli su nas do potrebe da preispitamo arhitekturu aplikacije.
Počeli smo sa konektorima.
Primijetili smo da svi konektori rade po istom modelu, pa smo izgradili okvir pipelinea u kojem je za kreiranje konektora trebalo samo programirati logiku koraka, ostalo je bilo univerzalno. Ako neki konektor zahtijeva poboljšanje, onda ga odmah prenosimo u novi okvir u isto vrijeme kada se konektor poboljšava.
U isto vrijeme, počeli smo s postavljanjem konektora na Docker i Kubernetes.
Planirali smo prelazak na Kubernetes dosta dugo, eksperimentirali sa CI/CD postavkama, ali smo krenuli tek kada je jedan konektor, zbog greške, počeo da jede više od 20 GB memorije na serveru, praktično ubijajući druge procese . Tokom istrage, konektor je premješten u Kubernetes klaster, gdje je na kraju ostao, čak i nakon što je greška ispravljena.
Vrlo brzo smo shvatili da je Kubernetes zgodan i u roku od šest mjeseci prebacili smo 7 konektora i Connectors Proxy, koji troše najviše resursa, u proizvodni klaster.
Prateći konektore, odlučili smo da promijenimo arhitekturu ostatka aplikacije.
Glavni problem je bio što podaci dolaze od konektora do proksija u velikim serijama, a zatim pogađaju DANBoID i šalju se u centralnu web aplikaciju na obradu. Zbog velikog broja preračunavanja metrike, postoji veliko opterećenje aplikacije.
Također se pokazalo prilično teškim pratiti status pojedinačnih poslova prikupljanja podataka i prijaviti greške koje se javljaju unutar konektora centralnoj web aplikaciji kako bi korisnici mogli vidjeti šta se dešava i zašto se podaci ne prikupljaju.
Da bismo riješili ove probleme, razvili smo arhitekturu 2.0.
Glavna razlika između nove verzije arhitekture je u tome što umjesto Web API-ja koristimo RabbitMQ i biblioteku MassTransit za razmjenu poruka između servisa. Da bismo to učinili, morali smo skoro u potpunosti prepisati Connectors Proxy, čineći ga Connectors Hub-om. Naziv je promijenjen jer glavna uloga servisa više nije u prosljeđivanju zahtjeva do konektora i nazad, već u upravljanju prikupljanjem metrika iz konektora.
Iz centralne web aplikacije smo izdvojili informacije o plasmanima i statistiku sa sajtova u zasebne servise, što je omogućilo da se oslobodimo nepotrebnih preračunavanja i pohranimo samo već izračunatu i agregiranu statistiku na nivou plasmana. Također smo prepisali i optimizirali logiku za izračunavanje osnovne statistike na osnovu sirovih podataka.
U isto vrijeme, migriramo sve usluge i aplikacije na Docker i Kubernetes kako bismo rješenje učinili lakšim za skaliranje i praktičnijim za upravljanje.
Gdje smo sada
Proof-of-concept arhitektura 2.0 proizvod D1.Digital spreman i radi u testnom okruženju sa ograničenim skupom konektora. Sve što je preostalo je da prepišete još 20 konektora na novu platformu, testirate da li su podaci ispravno učitani i da su sve metrike ispravno izračunate, te uvesti cijeli dizajn u proizvodnju.
Zapravo, ovaj proces će se odvijati postepeno i morat ćemo ostaviti kompatibilnost unatrag sa starim API-jima da bi sve funkcioniralo.
Naši neposredni planovi uključuju razvoj novih konektora, integraciju sa novim sistemima i dodavanje dodatnih metrika skupu podataka preuzetih sa povezanih sajtova i sistema za oglašavanje.
Također planiramo prebaciti sve aplikacije, uključujući centralnu web aplikaciju, na Docker i Kubernetes. U kombinaciji sa novom arhitekturom, ovo će značajno pojednostaviti implementaciju, praćenje i kontrolu utrošenih resursa.
Druga ideja je eksperimentisanje sa izborom baze podataka za skladištenje statistike, koja je trenutno pohranjena u MongoDB. Već smo prebacili nekoliko novih konektora u SQL baze podataka, ali tu je razlika gotovo neprimjetna, a za zbirnu statistiku po danu, koja se može tražiti za proizvoljan period, dobitak može biti prilično ozbiljan.
Generalno, planovi su grandiozni, idemo dalje :)
Autori članka R&D Dentsu Aegis Network Russia: Georgij Ostapenko (), Mihail Kotsik ()
izvor: www.habr.com