Panašu, kad reklamos internete sritis turėtų būti kuo technologiškai pažangesnė ir automatizuota. Žinoma, nes ten dirba tokie gigantai ir savo srities ekspertai kaip Yandex, Mail.Ru, Google ir Facebook. Tačiau, kaip paaiškėjo, tobulumui ribų nėra ir visada yra ką automatizuoti.
Ryšių grupė Dentsu Aegis tinklas Rusija yra didžiausias skaitmeninės reklamos rinkos žaidėjas ir aktyviai investuoja į technologijas, stengiasi optimizuoti ir automatizuoti savo verslo procesus. Viena iš neišspręstų internetinės reklamos rinkos problemų tapo uždavinys rinkti statistiką apie reklamines kampanijas iš skirtingų interneto platformų. Išsprendus šią problemą, galiausiai buvo sukurtas produktas D1.Skaitmeninis (skaityti kaip DiVan), apie kurio kūrimą norime pakalbėti.
Kodėl?
1. Projekto pradžios metu rinkoje nebuvo nė vieno paruošto produkto, kuris išspręstų reklamos kampanijų statistikos rinkimo automatizavimo problemą. Tai reiškia, kad niekas, išskyrus mus pačius, nepatenkins mūsų poreikių.
Tokios paslaugos kaip „Improvado“, „Ristat“, „Supermetrics“, „SegmentStream“ siūlo integraciją su platformomis, socialiniais tinklais ir „Google Analitycs“, taip pat leidžia kurti analitinius prietaisų skydelius patogiai reklaminių kampanijų analizei ir valdymui. Prieš pradėdami kurti savo produktą, bandėme naudoti kai kurias iš šių sistemų duomenims iš svetainių rinkti, bet, deja, jos negalėjo išspręsti mūsų problemų.
Pagrindinė problema buvo ta, kad išbandyti produktai buvo pagrįsti duomenų šaltiniais, rodydami talpinimo statistiką pagal svetaines ir nesuteikę galimybės apibendrinti reklaminių kampanijų statistikos. Šis metodas neleido mums vienoje vietoje matyti skirtingų svetainių statistikos ir analizuoti visos kampanijos būklės.
Kitas veiksnys buvo tai, kad pradiniame etape produktai buvo skirti Vakarų rinkai ir nepalaikė integracijos su Rusijos svetainėmis. O toms svetainėms, su kuriomis buvo įdiegta integracija, ne visada buvo pakankamai išsamiai atsisiunčiama visa reikalinga metrika, o integracija ne visada buvo patogi ir skaidri, ypač kai reikėjo gauti tai, ko nėra sistemos sąsajoje.
Apskritai nusprendėme neprisitaikyti prie trečiųjų šalių produktų, o pradėjome kurti savo...
2. Internetinės reklamos rinka metai iš metų auga ir 2018 metais pagal reklamos biudžetus aplenkė tradiciškai didžiausią TV reklamos rinką. Taigi yra skalė.
3. Skirtingai nei TV reklamos rinkoje, kur komercinės reklamos pardavimas yra monopolizuotas, internete veikia labai daug individualių įvairaus dydžio reklaminio inventoriaus savininkų, turinčių savo reklamines paskyras. Kadangi reklamos kampanija, kaip taisyklė, vienu metu vykdoma keliose svetainėse, norint suprasti reklamos kampanijos būseną, būtina surinkti ataskaitas iš visų svetainių ir sujungti jas į vieną didelę ataskaitą, kuri parodys visą vaizdą. Tai reiškia, kad yra optimizavimo galimybių.
4. Mums atrodė, kad reklaminių inventorių internete savininkai jau turi statistikos rinkimo ir jos atvaizdavimo reklamos paskyrose infrastruktūrą ir šiems duomenims galės pateikti API. Tai reiškia, kad techniškai įmanoma jį įgyvendinti. Iš karto pasakykime, kad viskas pasirodė ne taip paprasta.
Apskritai visos projekto įgyvendinimo prielaidos mums buvo akivaizdžios ir bėgome, kad projektas būtų įgyvendintas...
Didysis planas
Pirmiausia sukūrėme idealios sistemos viziją:
- Reklaminės kampanijos iš 1C įmonės sistemos turėtų būti automatiškai įkeliamos į ją su jų pavadinimais, laikotarpiais, biudžetais ir paskirties vietomis įvairiose platformose.
- Kiekvienai reklaminės kampanijos paskirties vietai visa įmanoma statistika turėtų būti automatiškai atsisiunčiama iš svetainių, kuriose vyksta paskirties vieta, pvz., parodymų, paspaudimų, peržiūrų skaičius ir kt.
- Kai kurios reklamos kampanijos yra stebimos naudojant trečiųjų šalių stebėjimą vadinamosiomis reklamos sistemomis, tokiomis kaip Adriver, Weborama, DCM ir kt. Rusijoje taip pat yra pramoninis interneto skaitiklis - bendrovė Mediascope. Pagal mūsų planą nepriklausomos ir pramoninės stebėsenos duomenys taip pat turėtų būti automatiškai įkeliami į atitinkamas reklamos kampanijas.
- Dauguma reklaminių kampanijų internete yra skirtos tam tikriems tiksliniams veiksmams (pirkti, skambinti, užsiregistruoti bandomajam važiavimui ir pan.), kurie yra sekami naudojant Google Analytics, o kurių statistika taip pat svarbi norint suprasti kampanijos būseną ir turėtų būti įkeltas į mūsų įrankį.
Pirmasis blynas yra vienkartinis
Atsižvelgdami į mūsų įsipareigojimą laikytis lanksčių programinės įrangos kūrimo principų (judrus, viskas), nusprendėme pirmiausia sukurti MVP, o tada pakartotinai judėti link numatyto tikslo.
Mes nusprendėme sukurti MVP pagal mūsų produktą DANBo (Dentsu Aegis tinklo valdyba), kuri yra žiniatinklio programa su bendra informacija apie mūsų klientų reklamines kampanijas.
MVP atveju projektas buvo kiek įmanoma supaprastintas įgyvendinimo požiūriu. Integravimui pasirinkome ribotą platformų sąrašą. Tai buvo pagrindinės platformos, tokios kaip Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB ir pagrindinės reklamos sistemos Adriver ir Weborama.
Norėdami pasiekti svetainių statistiką per API, naudojome vieną paskyrą. Klientų grupės vadovas, norintis naudoti automatinį reklamos kampanijos statistikos rinkimą, pirmiausia turėjo deleguoti prieigą prie reikiamų reklamos kampanijų svetainėse platformos paskyrai.
Kitas yra sistemos vartotojas DANBo turėjo įkelti į Excel sistemą tam tikro formato failą, kuriame buvo visa informacija apie talpinimą (reklaminė kampanija, platforma, formatas, talpinimo laikotarpis, planuojami rodikliai, biudžetas ir kt.) ir atitinkamų reklaminių kampanijų identifikatoriai. svetainių ir skaitiklių skelbimų sistemose.
Atvirai kalbant, tai atrodė siaubingai:
Atsisiųsti duomenys buvo įrašyti į duomenų bazę, o tada atskiros tarnybos iš jų rinko kampanijos identifikatorius svetainėse ir atsisiuntė jų statistiką.
Kiekvienai svetainei buvo parašyta atskira windows paslauga, kuri kartą per dieną eidavo į vieną paslaugos paskyrą svetainės API ir atsisiųsdavo nurodytų kampanijų ID statistiką. Tas pats nutiko ir su skelbimų sistemomis.
Atsisiųsti duomenys buvo rodomi sąsajoje mažos tinkintos prietaisų skydelio pavidalu:
Netikėtai mums MVP pradėjo dirbti ir pradėjo atsisiųsti naujausią reklaminių kampanijų statistiką internete. Sistemą įdiegėme keliems klientams, tačiau bandydami išplėsti mastelį susidūrėme su rimtomis problemomis:
- Pagrindinė problema buvo duomenų paruošimo įkėlimui į sistemą sudėtingumas. Be to, prieš įkeliant vietos duomenis reikėjo konvertuoti į griežtai fiksuotą formatą. Į atsisiuntimo failą reikėjo įtraukti objektų identifikatorius iš skirtingų svetainių. Susidūrėme su tuo, kad techniškai neapmokytiems vartotojams labai sunku paaiškinti, kur svetainėje rasti šiuos identifikatorius ir kur faile juos reikia įvesti. Atsižvelgiant į darbuotojų skaičių padaliniuose, vykdančius kampanijas aikštelėse, ir į apyvartą, tai lėmė didžiulę paramą iš mūsų pusės, kuria nebuvome patenkinti.
- Kita problema buvo ta, kad ne visos reklamos platformos turėjo mechanizmus, leidžiančius perleisti prieigą prie reklaminių kampanijų kitoms paskyroms. Tačiau net jei delegavimo mechanizmas būtų prieinamas, ne visi reklamuotojai norėjo suteikti prieigą prie savo kampanijų trečiųjų šalių paskyroms.
- Svarbus veiksnys buvo vartotojų pasipiktinimas dėl to, kad visi suplanuoti rodikliai ir paskirties vietos duomenys, kuriuos jie jau įveda į mūsų 1C apskaitos sistemą, turi iš naujo įvesti DANBo.
Taip kilo mintis, kad pirminis informacijos apie talpinimą šaltinis turėtų būti mūsų 1C sistema, į kurią visi duomenys įvedami tiksliai ir laiku (esmė ta, kad sąskaitos generuojamos remiantis 1C duomenimis, todėl teisingas duomenų įvedimas į 1C yra kiekvieno KPI prioritetas). Taip atsirado nauja sistemos koncepcija...
Sąvoka
Pirmas dalykas, kurį nusprendėme padaryti, buvo atskirti reklamos kampanijų internete statistikos rinkimo sistemą į atskirą produktą - D1.Skaitmeninis.
Į naują koncepciją nusprendėme įkelti D1.Skaitmeninis informaciją apie reklamines kampanijas ir paskirties vietas jose iš 1C, o tada į šias paskirties vietas pateikite statistiką iš svetainių ir skelbimų teikimo sistemų. Tai turėjo žymiai supaprastinti vartotojų gyvenimą (ir, kaip įprasta, pridėti daugiau darbo kūrėjams) ir sumažinti paramos kiekį.
Pirmoji problema, su kuria susidūrėme, buvo organizacinio pobūdžio ir buvo susijusi su tuo, kad negalėjome rasti rakto ar ženklo, pagal kurį galėtume palyginti skirtingų sistemų objektus su kampanijomis ir paskirties vietomis iš 1C. Faktas yra tas, kad procesas mūsų įmonėje yra suplanuotas taip, kad reklamos kampanijas į skirtingas sistemas įveda skirtingi žmonės (žiniasklaidos planuotojai, pirkimas ir pan.).
Norėdami išspręsti šią problemą, turėjome išrasti unikalų maišos raktą DANBoID, kuris susietų skirtingų sistemų objektus ir kurį būtų galima gana lengvai ir unikaliai identifikuoti atsisiųstuose duomenų rinkiniuose. Šis identifikatorius sugeneruojamas vidinėje 1C sistemoje kiekvienai atskirai paskirties vietai ir perkeliamas į kampanijas, paskirties vietas ir skaitiklius visose svetainėse ir visose skelbimų teikimo sistemose. Įdiegti DANBoID visose paskirties vietose prireikė šiek tiek laiko, bet mums tai pavyko :)
Tada išsiaiškinome, kad ne visos svetainės turi API automatiniam statistikos rinkimui, o net ir turinčiose API ji nepateikia visų reikiamų duomenų.
Šiame etape nusprendėme gerokai sumažinti integruojamų platformų sąrašą ir sutelkti dėmesį į pagrindines platformas, kurios dalyvauja didžiojoje daugumoje reklaminių kampanijų. Šiame sąraše yra visi didžiausi reklamos rinkos žaidėjai (Google, Yandex, Mail.ru), socialiniai tinklai (VK, Facebook, Twitter), pagrindinės AdServing ir analitinės sistemos (DCM, Adriver, Weborama, Google Analytics) ir kitos platformos.
Daugumoje mūsų pasirinktų svetainių buvo API, kuri pateikė mums reikalingą metriką. Tais atvejais, kai nebuvo API arba joje nebuvo reikiamų duomenų, duomenims įkelti naudojome ataskaitas, kurios buvo siunčiamos kasdien į biuro el. paštą (vienose sistemose tokias ataskaitas galima konfigūruoti, kitose susitarėme dėl tokie pranešimai mums).
Analizuodami duomenis iš skirtingų svetainių, išsiaiškinome, kad objektų hierarchija skirtingose sistemose nėra vienoda. Be to, informaciją iš skirtingų sistemų reikia atsisiųsti skirtingai.
Šiai problemai išspręsti buvo sukurta SubDANBoID koncepcija. SubDANBoID idėja gana paprasta, pagrindinį kampanijos objektą svetainėje pažymime sugeneruotu DANBoID, o visus įdėtus objektus įkeliame su unikaliais svetainės identifikatoriais ir formuojame SubDANBoID pagal DANBoID principą + pirmojo lygio identifikatorius įdėtas objektas + antrojo lygio įdėto objekto identifikatorius +... Šis metodas leido sujungti reklamos kampanijas skirtingose sistemose ir atsisiųsti išsamią jų statistiką.
Taip pat turėjome išspręsti prieigos prie kampanijų įvairiose platformose problemą. Kaip rašėme aukščiau, prieigos prie kampanijos delegavimo atskirai techninei paskyrai mechanizmas ne visada taikomas. Todėl turėjome sukurti automatinio autorizavimo per OAuth infrastruktūrą, naudojant žetonus ir šių žetonų atnaujinimo mechanizmus.
Vėliau straipsnyje pabandysime išsamiau aprašyti sprendimo architektūrą ir technines įgyvendinimo detales.
Sprendimo architektūra 1.0
Pradėdami diegti naują produktą supratome, kad iš karto reikia numatyti naujų svetainių prijungimo galimybę, todėl nusprendėme eiti mikroservisų architektūros keliu.
Kurdami architektūrą, jungtis prie visų išorinių sistemų – 1C, reklamos platformų ir skelbimų sistemų – išskyrėme į atskiras paslaugas.
Pagrindinė mintis yra ta, kad visos svetainių jungtys turi tą pačią API ir yra adapteriai, perkeliantys svetainės API į mums patogią sąsają.
Mūsų gaminio centre yra žiniatinklio programa, kuri yra monolitas, sukurtas taip, kad jį būtų galima lengvai išardyti į paslaugas. Ši programa yra atsakinga už atsisiųstų duomenų apdorojimą, skirtingų sistemų statistikos palyginimą ir pateikimą sistemos vartotojams.
Norėdami susisiekti tarp jungčių ir žiniatinklio programos, turėjome sukurti papildomą paslaugą, kurią pavadinome Connector Proxy. Jis atlieka paslaugų aptikimo ir užduočių planuoklio funkcijas. Ši paslauga kiekvieną naktį vykdo kiekvienos jungties duomenų rinkimo užduotis. Parašyti paslaugų sluoksnį buvo lengviau nei prijungti pranešimų brokerį, o mums buvo svarbu kuo greičiau gauti rezultatą.
Dėl kūrimo paprastumo ir greičio taip pat nusprendėme, kad visos paslaugos bus žiniatinklio API. Tai leido greitai surinkti koncepcijos įrodymą ir patikrinti, ar visas projektas veikia.
Atskira, gana sudėtinga užduotis buvo nustatyti prieigą rinkti duomenis iš skirtingų paskyrų, kurią, kaip nusprendėme, turėtų atlikti vartotojai per žiniatinklio sąsają. Jį sudaro du atskiri veiksmai: pirma, vartotojas prideda prieigos raktą, kad pasiektų paskyrą per OAuth, o tada sukonfigūruoja kliento duomenų rinkimą iš konkrečios paskyros. Gauti prieigos raktą per OAuth būtina, nes, kaip jau rašėme, ne visada galima deleguoti prieigą prie norimos paskyros svetainėje.
Norėdami sukurti universalų paskyros pasirinkimo iš svetainių mechanizmą, prie jungčių API turėjome pridėti metodą, kuris grąžina JSON schemą, kuri atvaizduojama į formą naudojant modifikuotą JSONEditor komponentą. Tokiu būdu vartotojai galėjo pasirinkti paskyras, iš kurių siųsti duomenis.
Siekdami laikytis svetainėse taikomų užklausų apribojimų, nustatymų užklausas sujungiame viename prieigos rakte, tačiau lygiagrečiai galime apdoroti skirtingus prieigos raktus.
Pasirinkome MongoDB kaip įkeliamų duomenų saugyklą tiek žiniatinklio aplikacijai, tiek jungtims, o tai leido per daug nesijaudinti dėl duomenų struktūros pradinėse kūrimo stadijose, kai aplikacijos objektinis modelis keičiasi kas antrą dieną.
Netrukus išsiaiškinome, kad ne visi duomenys gerai telpa MongoDB ir, pavyzdžiui, patogiau kasdienę statistiką saugoti reliacinėje duomenų bazėje. Todėl jungtims, kurių duomenų struktūra labiau tinka reliacinei duomenų bazei, kaip saugyklą pradėjome naudoti PostgreSQL arba MS SQL Server.
Pasirinkta architektūra ir technologijos leido palyginti greitai sukurti ir paleisti produktą D1.Digital. Per dvejus produkto kūrimo metus sukūrėme 23 jungtis prie svetainių, įgijome neįkainojamos patirties dirbdami su trečiųjų šalių API, išmokome išvengti skirtingų svetainių spąstų, kurių kiekviena turėjo savo, prisidėjome prie mažiausiai 3 API kūrimo. svetaines, automatiškai atsisiuntė informaciją apie beveik 15 000 kampanijų ir daugiau nei 80 000 vietų, surinko daug vartotojų atsiliepimų apie produkto veikimą ir, remiantis šiais atsiliepimais, kelis kartus pavyko pakeisti pagrindinį produkto procesą.
Sprendimo architektūra 2.0
Nuo kūrimo pradžios praėjo dveji metai D1.Skaitmeninis. Nuolat didėjantis sistemos apkrovimas ir atsirandantis vis daugiau naujų duomenų šaltinių pamažu atskleidė esamos sprendimo architektūros problemas.
Pirmoji problema susijusi su iš svetainių atsisiunčiamų duomenų kiekiu. Susidūrėme su tuo, kad visų reikiamų duomenų surinkimas ir atnaujinimas iš didžiausių svetainių pradėjo užtrukti per daug laiko. Pavyzdžiui, duomenų rinkimas iš AdRiver reklamos sistemos, su kuria sekame daugumos vietų statistiką, užtrunka apie 12 valandų.
Norėdami išspręsti šią problemą, pradėjome naudoti visokias ataskaitas duomenims iš svetainių atsisiųsti, stengiamės kurti jų API kartu su svetainėmis, kad jos veikimo greitis atitiktų mūsų poreikius, ir kiek įmanoma lygiagretinti duomenų atsisiuntimą.
Kita problema susijusi su atsisiųstų duomenų apdorojimu. Dabar, kai gaunama nauja paskirties vietų statistika, pradedamas kelių etapų metrikos perskaičiavimo procesas, apimantis neapdorotų duomenų įkėlimą, kiekvienos svetainės apibendrintos metrikos apskaičiavimą, duomenų iš skirtingų šaltinių palyginimą tarpusavyje ir kampanijos suvestinės metrikos skaičiavimą. Tai sukelia daug apkrovos žiniatinklio programai, kuri atlieka visus skaičiavimus. Kelis kartus perskaičiavimo proceso metu programa sunaudojo visą serveryje esančią atmintį, apie 10-15 GB, o tai labiausiai paveikė vartotojų darbą su sistema.
Nustatytos problemos ir ambicingi tolesni produkto tobulinimo planai paskatino mus persvarstyti programos architektūrą.
Pradėjome nuo jungčių.
Pastebėjome, kad visos jungtys veikia pagal tą patį modelį, todėl sukonstravome vamzdynų karkasą, kuriame norint sukurti jungtį tereikėjo suprogramuoti žingsnių logiką, visa kita buvo universali. Jei kurią nors jungtį reikia patobulinti, tuo pačiu metu, kai tobulinama jungtis, ją iškart perkeliame į naują karkasą.
Tuo pačiu metu pradėjome diegti „Docker“ ir „Kubernetes“ jungtis.
Persikėlimą į Kubernetes planavome gana ilgai, eksperimentavome su CI/CD nustatymais, bet pradėjome judėti tik tada, kai viena jungtis dėl klaidos pradėjo valgyti daugiau nei 20 GB atminties serveryje, praktiškai užmušdama kitus procesus. . Tyrimo metu jungtis buvo perkelta į Kubernetes klasterį, kur galiausiai liko, net ir ištaisius klaidą.
Gana greitai supratome, kad Kubernetes patogu, ir per šešis mėnesius į gamybos klasterį perkėlėme daugiausiai resursų sunaudojančias 7 jungtis ir Connectors Proxy.
Atsižvelgdami į jungtis, nusprendėme pakeisti likusios programos architektūrą.
Pagrindinė problema buvo ta, kad iš jungčių į tarpinius serverius gaunami duomenys didelėmis partijomis, tada patenka į DANBoID ir siunčiami į centrinę žiniatinklio programą apdoroti. Dėl daugybės metrikų perskaičiavimų, programai tenka didelė apkrova.
Taip pat pasirodė gana sunku stebėti atskirų duomenų rinkimo užduočių būseną ir pranešti apie klaidas, atsirandančias jungtyse į centrinę žiniatinklio programą, kad vartotojai matytų, kas vyksta ir kodėl duomenys nerenkami.
Norėdami išspręsti šias problemas, sukūrėme architektūrą 2.0.
Pagrindinis skirtumas tarp naujos architektūros versijos yra tas, kad vietoj žiniatinklio API mes naudojame RabbitMQ ir MassTransit biblioteką, norėdami keistis pranešimais tarp paslaugų. Norėdami tai padaryti, turėjome beveik visiškai perrašyti jungčių tarpinį serverį ir padaryti jį Connectors Hub. Pavadinimas buvo pakeistas, nes pagrindinis paslaugos vaidmuo nebėra užklausų persiuntimas į jungtis ir atgal, o metrikos rinkimo iš jungčių valdymas.
Iš centrinės žiniatinklio programos informaciją apie vietas ir statistiką iš svetainių išskyrėme į atskiras paslaugas, kurios leido atsikratyti nereikalingų perskaičiavimų ir talpinimo lygmeniu saugoti tik jau apskaičiuotą ir apibendrintą statistiką. Taip pat perrašėme ir optimizavome pagrindinės statistikos skaičiavimo logiką pagal neapdorotus duomenis.
Tuo pačiu metu visas paslaugas ir programas perkeliame į „Docker“ ir „Kubernetes“, kad sprendimas būtų lengviau keičiamas ir valdomas.
Kur mes dabar
Koncepcinės architektūros 2.0 produktas D1.Skaitmeninis paruoštas ir veikia bandomojoje aplinkoje su ribotu jungčių rinkiniu. Belieka perrašyti dar 20 jungčių į naują platformą, patikrinti, ar tinkamai įkelti duomenys ir teisingai apskaičiuoti visi rodikliai, ir pradėti gaminti visą dizainą.
Tiesą sakant, šis procesas vyks palaipsniui ir turėsime palikti atgalinį suderinamumą su senomis API, kad viskas veiktų.
Mūsų artimiausi planai apima naujų jungčių kūrimą, integravimą su naujomis sistemomis ir papildomų metrikų įtraukimą į duomenų rinkinį, atsisiunčiamą iš prijungtų svetainių ir skelbimų sistemų.
Taip pat planuojame visas programas, įskaitant centrinę žiniatinklio programą, perkelti į „Docker“ ir „Kubernetes“. Kartu su nauja architektūra tai žymiai supaprastins sunaudotų išteklių diegimą, stebėjimą ir kontrolę.
Kita idėja – eksperimentuoti pasirenkant duomenų bazę, skirtą statistikai saugoti, kuri šiuo metu saugoma MongoDB. Į SQL duomenų bazes jau perkėlėme keletą naujų jungčių, tačiau ten skirtumas beveik nepastebimas, o apibendrinta statistika pagal dieną, kurios galima prašyti savavališkai, prieaugis gali būti gana rimtas.
Apskritai planai grandioziniai, judam toliau :)
Straipsnio R&D Dentsu Aegis Network Russia autoriai: Georgijus Ostapenko (), Michailas Kotsikas ()
Šaltinis: www.habr.com