Čini se da bi područje online oglašavanja trebalo biti što tehnološki naprednije i automatizirano. Naravno, jer tamo rade takvi divovi i stručnjaci u svom području kao što su Yandex, Mail.Ru, Google i Facebook. Ali, kako se pokazalo, nema granica savršenstvu i uvijek postoji nešto za automatizirati.
Grupa za komunikacije Dentsu Aegis mreža Rusija je najveći igrač na tržištu digitalnog oglašavanja i aktivno ulaže u tehnologiju, nastojeći optimizirati i automatizirati svoje poslovne procese. Jedan od neriješenih problema tržišta online oglašavanja je zadatak prikupljanja statistike o oglasnim kampanjama s različitih internetskih platformi. Rješenje ovog problema u konačnici je rezultiralo stvaranjem proizvoda D1.Digitalno (čitaj DiVan), o čijem razvoju želimo govoriti.
Zašto?
1. U trenutku početka projekta na tržištu nije postojao niti jedan gotov proizvod koji je rješavao problem automatizacije prikupljanja statistike o reklamnim kampanjama. To znači da nitko osim nas samih neće zadovoljiti naše potrebe.
Usluge kao što su Improvado, Roistat, Supermetrics, SegmentStream nude integraciju s platformama, društvenim mrežama i Google Analitycsom, a također omogućuju izradu analitičkih nadzornih ploča za praktičnu analizu i kontrolu reklamnih kampanja. Prije nego što smo počeli razvijati naš proizvod, pokušali smo koristiti neke od ovih sustava za prikupljanje podataka sa stranica, ali, nažalost, nisu mogli riješiti naše probleme.
Glavni je problem bio taj što su se testirani proizvodi oslanjali na izvore podataka, prikazujući statistiku plasmana po web-mjestu i nisu pružali mogućnost agregiranja statistike o reklamnim kampanjama. Ovakav pristup nam nije omogućio da na jednom mjestu vidimo statistiku s različitih stranica i analiziramo stanje kampanje u cjelini.
Drugi čimbenik bio je taj što su u početnim fazama proizvodi bili usmjereni na zapadno tržište i nisu podržavali integraciju s ruskim stranicama. A za ona mjesta s kojima je implementirana integracija, sve potrebne metrike nisu uvijek bile preuzete s dovoljno detalja, a integracija nije uvijek bila prikladna i transparentna, posebno kada je bilo potrebno dobiti nešto što nije u sučelju sustava.
Općenito, odlučili smo se ne prilagođavati proizvodima trećih strana, već smo počeli razvijati vlastite...
2. Tržište online oglašavanja raste iz godine u godinu te je u 2018. godini po proračunima za oglašavanje prestiglo tradicionalno najveće tržište TV oglašavanja. Dakle, postoji ljestvica.
3. Za razliku od tržišta televizijskog oglašavanja, gdje je prodaja komercijalnog oglašavanja monopolizirana, na internetu postoji mnogo pojedinačnih vlasnika oglasnog inventara različitih veličina koji posluju na internetu sa svojim vlastitim računima za oglašavanje. Budući da se reklamna kampanja u pravilu odvija na više stranica odjednom, za razumijevanje stanja reklamne kampanje potrebno je prikupiti izvješća sa svih stranica i spojiti ih u jedno veliko izvješće koje će prikazati cjelokupnu sliku. To znači da postoji potencijal za optimizaciju.
4. Činilo nam se da vlasnici reklamnog inventara na Internetu već imaju infrastrukturu za prikupljanje statistike i njihovo prikazivanje u reklamnim računima, te će moći osigurati API za te podatke. To znači da ga je tehnički moguće provesti. Recimo odmah da se pokazalo da nije tako jednostavno.
Uglavnom, svi preduvjeti za realizaciju projekta bili su nam očiti i potrčali smo da projekt oživimo...
Veliki plan
Za početak smo formirali viziju idealnog sustava:
- Oglašavačke kampanje iz korporativnog sustava 1C trebale bi se automatski učitati u njega sa svojim nazivima, razdobljima, proračunima i plasmanima na različitim platformama.
- Za svaki plasman unutar reklamne kampanje potrebno je automatski preuzeti sve moguće statistike sa stranica na kojima se plasman odvija, kao što su broj impresija, klikova, pregleda itd.
- Neke se reklamne kampanje prate pomoću nadzora trećih strana od strane takozvanih reklamnih sustava kao što su Adriver, Weborama, DCM itd. U Rusiji postoji i industrijski internet mjerač - tvrtka Mediascope. Prema našem planu, podaci neovisnog i industrijskog nadzora također bi se trebali automatski učitavati u odgovarajuće reklamne kampanje.
- Većina reklamnih kampanja na internetu usmjerena je na određene ciljane radnje (kupnja, poziv, prijava na probnu vožnju i sl.), koje se prate pomoću Google Analyticsa, a čija je statistika također važna za razumijevanje statusa kampanje i treba učitati u naš alat.
Prva palačinka je lumpy
S obzirom na našu predanost fleksibilnim načelima razvoja softvera (agilno, sve), odlučili smo najprije razviti MVP, a zatim iterativno krenuti prema željenom cilju.
Odlučili smo izgraditi MVP na temelju našeg proizvoda DANBo (Dentsu Aegis Network Board), web aplikacija s općim informacijama o reklamnim kampanjama naših klijenata.
Za MVP je projekt maksimalno pojednostavljen u smislu implementacije. Odabrali smo ograničen popis platformi za integraciju. To su bile glavne platforme, kao što su Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, te glavni sustavi oglašavanja Adriver i Weborama.
Za pristup statistici na stranicama putem API-ja koristili smo jedan račun. Voditelj grupe klijenata koji je želio koristiti automatsko prikupljanje statistike o reklamnoj kampanji morao je prvo delegirati pristup potrebnim reklamnim kampanjama na web-mjestima na račun platforme.
Sljedeći je korisnik sustava DANBo morali u Excel sustav uploadati datoteku određenog formata koja je sadržavala sve podatke o plasmanu (oglašivačka kampanja, platforma, format, period plasmana, planirani pokazatelji, proračun itd.) i identifikatore pripadajućih oglasnih kampanja na stranice i brojači u sustavima oglašavanja.
Izgledalo je, iskreno, zastrašujuće:
Preuzeti podaci spremali su se u bazu podataka, a potom su zasebni servisi s njih prikupljali identifikatore kampanja na stranicama i preuzimali statistike o njima.
Za svaku web-lokaciju napisana je zasebna windows usluga, koja je jednom dnevno išla pod jedan račun usluge u API-ju web-lokacije i preuzimala statistiku za određene ID-ove kampanja. Ista se stvar dogodila sa sustavima oglašavanja.
Preuzeti podaci prikazani su na sučelju u obliku male prilagođene nadzorne ploče:
Neočekivano za nas, MVP je proradio i počeo preuzimati trenutnu statistiku reklamnih kampanja na internetu. Implementirali smo sustav na nekoliko klijenata, no pri pokušaju skaliranja naišli smo na ozbiljne probleme:
- Glavni problem bila je složenost pripreme podataka za učitavanje u sustav. Također, podaci o plasmanu morali su se pretvoriti u strogo fiksni format prije učitavanja. Bilo je potrebno uključiti identifikatore entiteta s različitih stranica u datoteku za preuzimanje. Suočeni smo s činjenicom da je tehnički neupućenim korisnicima vrlo teško objasniti gdje se ti identifikatori nalaze na stranici i gdje u datoteci ih treba unijeti. S obzirom na broj zaposlenih u odjelima koji vode kampanje na stranicama i promet, to je rezultiralo ogromnom podrškom s naše strane, s kojom nikako nismo bili zadovoljni.
- Drugi problem bio je taj što nisu sve platforme za oglašavanje imale mehanizme za delegiranje pristupa reklamnim kampanjama drugim računima. Ali čak i da je mehanizam delegiranja bio dostupan, nisu svi oglašivači bili voljni dopustiti pristup svojim kampanjama računima trećih strana.
- Važan čimbenik bilo je ogorčenje koje je kod korisnika izazvalo to što sve planske pokazatelje i podatke o plasmanu koje već unose u naš računovodstveni sustav 1C moraju ponovno unijeti. DANBo.
To nam je dalo ideju da primarni izvor informacija o plasmanu bude naš 1C sustav u koji se svi podaci unose točno i na vrijeme (ovdje se radi o tome da se fakture generiraju na temelju 1C podataka, dakle ispravan unos podataka u 1C je prioritet za sve KPI). Tako je nastao novi koncept sustava...
koncept
Prvo što smo odlučili napraviti je odvojiti sustav za prikupljanje statistike o reklamnim kampanjama na internetu u zaseban proizvod - D1.Digitalno.
U novom konceptu odlučili smo se učitati D1.Digitalno informacije o reklamnim kampanjama i položajima unutar njih iz 1C, a zatim povucite statistiku s web-mjesta i AdServing sustava na te položaje. 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 s kojim smo se susreli bio je organizacijske prirode i odnosio se na to da nismo mogli pronaći ključ ili znak po kojem bismo mogli usporediti entitete iz različitih sustava s kampanjama i plasmanima iz 1C. Činjenica je da je proces u našoj tvrtki osmišljen na način da se reklamne kampanje unose u različite sustave od strane različitih ljudi (media planeri, buying itd.).
Kako bismo riješili ovaj problem, morali smo izmisliti jedinstveni raspršeni ključ, DANBoID, koji bi povezivao entitete u različitim sustavima zajedno, i koji bi se mogao prilično lako i jedinstveno identificirati u preuzetim skupovima podataka. Ovaj identifikator generira se u internom 1C sustavu za svaki pojedinačni plasman i prenosi se na kampanje, plasmane i brojače na svim stranicama iu svim AdServing sustavima. Implementacija prakse postavljanja DANBoID-a u sve plasmane je potrajala, ali uspjeli smo u tome :)
Zatim smo saznali da nemaju sve stranice API za automatsko prikupljanje statistike, a čak ni one koje imaju API ne vraćaju sve potrebne podatke.
U ovoj smo fazi odlučili značajno smanjiti popis platformi za integraciju i usredotočiti se na glavne platforme koje su uključene u veliku većinu reklamnih kampanja. Ovaj popis uključuje sve najveće igrače na tržištu oglašavanja (Google, Yandex, Mail.ru), društvenih mreža (VK, Facebook, Twitter), glavnih AdServing i analitičkih sustava (DCM, Adriver, Weborama, Google Analytics) i drugih platformi.
Većina web lokacija koje smo odabrali imala je API koji je pružao mjerne podatke koji su nam bili potrebni. U slučajevima kada nije postojao API ili nije sadržavao potrebne podatke, za učitavanje podataka koristili smo izvješća koja su svakodnevno slana na našu uredsku e-poštu (u nekim sustavima moguće je konfigurirati takva izvješća, u drugima smo dogovorili izradu takva izvješća za nas).
Analizirajući podatke s različitih stranica, ustanovili smo da hijerarhija entiteta nije ista u različitim sustavima. Štoviše, informacije se moraju preuzimati s različitim detaljima iz različitih sustava.
Kako bi se riješio ovaj problem, razvijen je SubDANBoID koncept. Ideja SubDANBoID-a je vrlo jednostavna, glavni entitet kampanje na stranici označimo generiranim DANBoID-om, te učitamo sve ugniježđene entitete s jedinstvenim identifikatorima stranice i formiramo SubDANBoID po principu DANBoID + identifikator prve razine ugniježđeni entitet + identifikator ugniježđenog entiteta druge razine +... Ovaj pristup omogućio nam je povezivanje reklamnih kampanja u različitim sustavima i preuzimanje detaljne statistike o njima.
Morali smo riješiti i problem pristupa kampanjama na različitim platformama. Kao što smo gore napisali, mehanizam delegiranja pristupa kampanji zasebnom tehničkom računu nije uvijek primjenjiv. Stoga smo morali razviti infrastrukturu za automatsku autorizaciju putem OAutha korištenjem tokena i mehanizama za ažuriranje tih tokena.
U nastavku članka pokušat ćemo detaljnije opisati arhitekturu rješenja i tehničke detalje implementacije.
Arhitektura rješenja 1.0
Pri pokretanju implementacije novog proizvoda shvatili smo da odmah moramo predvidjeti mogućnost povezivanja novih stranica pa smo odlučili krenuti putem mikroservisne arhitekture.
Prilikom projektiranja arhitekture odvojili smo konektore za sve vanjske sustave - 1C, platforme za oglašavanje i sustave za oglašavanje - u zasebne usluge.
Glavna ideja je da svi konektori za web-mjesta imaju isti API i da su adapteri koji dovode API web-mjesta na sučelje koje nam odgovara.
U središtu našeg proizvoda je web aplikacija, koja je monolit koji je dizajniran na takav način da se može lako rastaviti na usluge. Ova aplikacija je odgovorna za obradu preuzetih podataka, prikupljanje statistika iz različitih sustava i njihovo predstavljanje korisnicima sustava.
Za komunikaciju između konektora i web aplikacije morali smo izraditi dodatnu uslugu koju smo nazvali Connector Proxy. Obavlja funkcije otkrivanja usluge i planera zadataka. Ova usluga svake noći izvršava zadatke prikupljanja podataka za svaki konektor. Pisanje sloja usluge bilo je lakše od povezivanja brokera poruka, a za nas je bilo važno dobiti rezultat što je brže moguće.
Radi jednostavnosti i brzine razvoja, također smo odlučili da će sve usluge biti web API-ji. To je omogućilo brzo sastavljanje dokaza koncepta i provjeru funkcionira li cijeli dizajn.
Poseban, prilično složen zadatak bio je postavljanje pristupa za prikupljanje podataka s različitih računa, što bi, kako smo odlučili, trebali provoditi korisnici putem web sučelja. Sastoji se od dva odvojena koraka: prvo korisnik dodaje token za pristup računu putem OAutha, a zatim konfigurira prikupljanje podataka za klijenta s određenog računa. Dobivanje tokena putem OAutha je neophodno jer, kao što smo već napisali, nije uvijek moguće delegirati pristup željenom računu na stranici.
Kako bismo stvorili univerzalni mehanizam za odabir računa s web-mjesta, morali smo dodati metodu u API konektora koja vraća JSON shemu, koja se prikazuje u obliku pomoću modificirane JSONEditor komponente. Na taj način korisnici su mogli odabrati račune s kojih će preuzeti podatke.
Kako bismo bili u skladu s ograničenjima zahtjeva koja postoje na stranicama, kombiniramo zahtjeve za postavkama unutar jednog tokena, ali možemo paralelno obrađivati različite tokene.
Odabrali smo MongoDB kao pohranu učitanih podataka za web aplikaciju i 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 svi podaci ne stanu dobro u MongoDB i da je, na primjer, praktičnije pohraniti dnevne statistike u relacijsku bazu podataka. Stoga smo za konektore čija je struktura podataka prikladnija za relacijsku bazu podataka počeli koristiti PostgreSQL ili MS SQL Server kao pohranu.
Odabrana arhitektura i tehnologije omogućile su nam relativno brzu izgradnju i lansiranje proizvoda D1.Digital. Tijekom dvije godine razvoja proizvoda, razvili smo 23 konektora za stranice, stekli neprocjenjivo iskustvo u radu s API-jima trećih strana, naučili izbjegavati zamke različitih stranica, od kojih je svaka imala svoje, pridonijeli razvoju API-ja od najmanje 3 stranicama, automatski preuzeli informacije o gotovo 15 kampanja i za više od 000 plasmana, prikupili mnogo povratnih informacija od korisnika o radu proizvoda i uspjeli promijeniti glavni proces proizvoda nekoliko puta, na temelju tih povratnih informacija.
Arhitektura rješenja 2.0
Od početka razvoja prošle su dvije godine D1.Digitalno. Stalno povećanje opterećenja sustava i pojava sve više novih izvora podataka postupno su otkrivali probleme u postojećoj arhitekturi rješenja.
Prvi problem je povezan s količinom podataka preuzetih sa stranica. Suočili smo se s činjenicom da je prikupljanje i ažuriranje svih potrebnih podataka s najvećih stranica počelo oduzimati previše vremena. Primjerice, prikupljanje podataka iz sustava oglašavanja AdRiver, kojim pratimo statistiku za većinu plasmana, traje oko 12 sati.
Kako bismo riješili ovaj problem, počeli smo koristiti sve vrste izvješća za preuzimanje podataka sa stranica, pokušavamo razviti njihov API zajedno sa stranicama kako bi brzina rada zadovoljila naše potrebe, te paralelizirati preuzimanje podataka što je više moguće.
Drugi problem odnosi se na obradu preuzetih podataka. Sada, kada stignu novi statistički podaci o plasmanu, pokreće se višefazni proces ponovnog izračuna metrike, koji uključuje učitavanje neobrađenih podataka, izračun agregiranih metrika za svaku stranicu, međusobnu usporedbu podataka iz različitih izvora i izračun sažetih metrika za kampanju. To uzrokuje veliko opterećenje web aplikacije koja radi sve izračune. Nekoliko puta, tijekom procesa preračunavanja, aplikacija je potrošila svu memoriju na poslužitelju, oko 10-15 GB, što je najštetnije utjecalo na rad korisnika sa sustavom.
Uočeni problemi i ambiciozni planovi za daljnji razvoj proizvoda doveli su nas do potrebe za preispitivanjem arhitekture aplikacije.
Počeli smo s konektorima.
Primijetili smo da svi konektori rade prema istom modelu, pa smo izgradili cjevovodni okvir u kojem je za izradu konektora trebalo programirati samo logiku koraka, ostalo je bilo univerzalno. Ako neki konektor zahtijeva poboljšanje, onda ga odmah prenosimo na novi framework u isto vrijeme dok se konektor poboljšava.
U isto vrijeme, počeli smo postavljati konektore za Docker i Kubernetes.
Prelazak na Kubernetes planirali smo dosta dugo, eksperimentirali s CI/CD postavkama, ali krenuli smo tek kada je jedan konektor zbog greške počeo gutati više od 20 GB memorije na serveru, praktički ubijajući ostale procese . Tijekom istrage, konektor je premješten u Kubernetes klaster, gdje je na kraju i ostao, čak i nakon što je greška ispravljena.
Vrlo brzo smo shvatili da je Kubernetes zgodan, te smo u roku od šest mjeseci prebacili 7 konektora i Connectors Proxy, koji troše najviše resursa, u proizvodni klaster.
Nakon konektora, odlučili smo promijeniti arhitekturu ostatka aplikacije.
Glavni problem bio je taj što podaci dolaze od konektora do proxyja u velikim serijama, a zatim dospijevaju u DANBoID i šalju se središnjoj web aplikaciji na obradu. Zbog velikog broja rekalkulacija metrika, postoji veliko opterećenje aplikacije.
Također se pokazalo prilično teškim pratiti status pojedinačnih poslova prikupljanja podataka i prijaviti pogreške koje se javljaju unutar konektora na središnju web aplikaciju kako bi korisnici mogli vidjeti što se događa i zašto se podaci ne prikupljaju.
Kako bismo riješili te 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 usluga. Da bismo to učinili, morali smo gotovo u potpunosti prepisati Connectors Proxy, čineći ga Connectors Hub. Naziv je promijenjen jer glavna uloga servisa više nije u prosljeđivanju zahtjeva konektorima i natrag, već u upravljanju prikupljanjem metrika iz konektora.
Iz središnje web aplikacije odvojili smo podatke o plasmanima i statistike sa stranica u zasebne servise, čime smo se oslobodili nepotrebnih preračunavanja i pohranjivali samo već izračunate i agregirane statistike na razini plasmana. Također smo ponovno napisali i optimizirali logiku za izračun osnovne statistike na temelju neobrađenih 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 architecture 2.0 proizvod D1.Digitalno spreman i radi u testnom okruženju s ograničenim skupom konektora. Sve što je preostalo učiniti jest prepisati još 20 konektora na novu platformu, testirati jesu li podaci ispravno učitani i sve metrike ispravno izračunate te cijeli dizajn staviti u proizvodnju.
Zapravo, ovaj će se proces odvijati postupno i morat ćemo napustiti kompatibilnost sa starim API-jima kako bi sve funkcioniralo.
Naši neposredni planovi uključuju razvoj novih konektora, integraciju s novim sustavima i dodavanje dodatnih metrika u skup podataka preuzetih s povezanih stranica i sustava za oglašavanje.
Također planiramo prebaciti sve aplikacije, uključujući središnju web aplikaciju, na Docker i Kubernetes. U kombinaciji s novom arhitekturom, to će značajno pojednostaviti implementaciju, praćenje i kontrolu potrošenih resursa.
Druga ideja je eksperimentirati s izborom baze podataka za pohranu 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 agregirane statistike po danima, koje se mogu tražiti za proizvoljno razdoblje, dobitak može biti prilično ozbiljan.
Općenito, planovi su grandiozni, idemo dalje :)
Autori članka R&D Dentsu Aegis Network Russia: Georgij Ostapenko (), Mikhail Kotsik ()
Izvor: www.habr.com