Ŝajnas, ke la kampo de reta reklamado devus esti kiel eble plej teknologie progresinta kaj aŭtomatigita. Kompreneble, ĉar tiaj gigantoj kaj spertuloj en sia fako kiel Yandex, Mail.Ru, Google kaj Facebook laboras tie. Sed, kiel montriĝis, ne estas limo al perfekteco kaj ĉiam estas io por aŭtomatigi.
Komunika grupo Dentsu Aegis Reto Rusio estas la plej granda ludanto en la cifereca reklama merkato kaj aktive investas en teknologio, provante optimumigi kaj aŭtomatigi siajn komercajn procezojn. Unu el la nesolvitaj problemoj de la reta reklama merkato estas la tasko kolekti statistikojn pri reklamaj kampanjoj de malsamaj interretaj platformoj. La solvo al ĉi tiu problemo finfine rezultigis la kreadon de produkto D1.Cifereca (legu kiel DiVan), pri kies evoluo ni volas paroli.
Kial?
1. En la momento de la komenco de la projekto, ne estis unu preta produkto sur la merkato, kiu solvis la problemon de aŭtomatigo de la kolekto de statistikoj pri reklamaj kampanjoj. Ĉi tio signifas, ke neniu krom ni mem kontentigos niajn bezonojn.
Servoj kiel Improvado, Roistat, Supermetrics, SegmentStream ofertas integriĝon kun platformoj, sociaj retoj kaj Google Analitycs, kaj ankaŭ ebligas konstrui analizajn panelojn por oportuna analizo kaj kontrolo de reklamaj kampanjoj. Antaŭ ol ni komencis disvolvi nian produkton, ni provis uzi iujn ĉi tiujn sistemojn por kolekti datumojn de retejoj, sed, bedaŭrinde, ili ne povis solvi niajn problemojn.
La ĉefa problemo estis, ke la testitaj produktoj baziĝis sur datumfontoj, montrante lokigajn statistikojn laŭ retejo, kaj ne disponigis la kapablon aldoni statistikojn pri reklamaj kampanjoj. Ĉi tiu aliro ne permesis al ni vidi statistikojn de malsamaj retejoj en unu loko kaj analizi la staton de la kampanjo entute.
Alia faktoro estis, ke en la komencaj stadioj la produktoj celis la okcidentan merkaton kaj ne subtenis integriĝon kun rusaj retejoj. Kaj por tiuj retejoj kun kiuj integriĝo estis efektivigita, ĉiuj necesaj metrikoj ne ĉiam estis elŝutitaj kun sufiĉa detalo, kaj la integriĝo ne ĉiam estis oportuna kaj travidebla, precipe kiam necesis akiri ion, kio ne estas en la sistema interfaco.
Ĝenerale, ni decidis ne adaptiĝi al triaj produktoj, sed komencis disvolvi nian propran...
2. La reta reklama merkato kreskas de jaro al jaro, kaj en 2018, laŭ reklamaj buĝetoj, ĝi preterpasis la tradicie plej grandan televidan reklaman merkaton. Do estas skalo.
3. Male al la televida reklama merkato, kie la vendo de komerca reklamado estas monopoligita, ekzistas multaj individuaj posedantoj de reklama inventaro de diversaj grandecoj, kiuj funkcias en Interreto kun siaj propraj reklamaj kontoj. Ĉar reklamkampanjo, kiel regulo, funkcias sur pluraj retejoj samtempe, por kompreni la staton de la reklamkampanjo, necesas kolekti raportojn de ĉiuj retejoj kaj kombini ilin en unu grandan raporton, kiu montros la tutan bildon. Ĉi tio signifas, ke ekzistas potencialo por optimumigo.
4. Ŝajnis al ni, ke la posedantoj de reklama inventaro en Interreto jam havas la infrastrukturon por kolekti statistikojn kaj montri ilin en reklamaj kontoj, kaj ili povos provizi API por ĉi tiuj datumoj. Ĉi tio signifas, ke estas teknike eble efektivigi ĝin. Ni diru tuj, ke ĝi montriĝis ne tiel simpla.
Ĝenerale, ĉiuj antaŭkondiĉoj por la efektivigo de la projekto estis evidentaj al ni, kaj ni kuris por vivigi la projekton...
Grandioza Plano
Komence, ni formis vizion de ideala sistemo:
- Reklamaj kampanjoj de la kompania sistemo 1C devus esti aŭtomate ŝargitaj en ĝin kun siaj nomoj, periodoj, buĝetoj kaj allokigoj sur diversaj platformoj.
- Por ĉiu lokigo ene de reklamkampanjo, ĉiuj eblaj statistikoj devus esti aŭtomate elŝutitaj de la retejoj kie la lokigo okazas, kiel la nombro da impresoj, klakoj, vidoj, ktp.
- Iuj reklamaj kampanjoj estas spuritaj per triaparta monitorado de tiel nomataj reklamaj sistemoj kiel Driver, Weborama, DCM ktp. Ankaŭ ekzistas industria interreta mezurilo en Rusio - la kompanio Mediascope. Laŭ nia plano, datumoj de sendependa kaj industria monitorado ankaŭ devus esti aŭtomate ŝargitaj en la respondajn reklamajn kampanjojn.
- Plej multaj reklamaj kampanjoj en la Interreto celas certajn celajn agojn (aĉeti, voki, registriĝi por provo, ktp.), kiuj estas spuritaj per Google Analytics, kaj statistikoj por kiuj ankaŭ estas gravaj por kompreni la staton de la kampanjo kaj devus esti ŝarĝita en nian ilon.
La unua malbenita afero estas bulema
Konsiderante nian sindevontigon al flekseblaj principoj de programaro-disvolviĝo (facilmova, ĉio), ni decidis unue evoluigi MVP kaj poste movi al la celita celo ripete.
Ni decidis konstrui MVP surbaze de nia produkto DANBo (Dentsu Aegis Network Board), kiu estas retejo-aplikaĵo kun ĝeneralaj informoj pri reklamaj kampanjoj de niaj klientoj.
Por MVP, la projekto estis simpligita kiel eble plej multe laŭ efektivigo. Ni elektis limigitan liston de platformoj por integriĝo. Ĉi tiuj estis la ĉefaj platformoj, kiel Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, kaj la ĉefaj anoncaj sistemoj Adriver kaj Weborama.
Por aliri statistikojn en retejoj per la API, ni uzis ununuran konton. Administranto de klientgrupo, kiu volis uzi aŭtomatan kolekton de statistikoj pri reklamkampanjo, devis unue delegi aliron al la necesaj reklamkampanjoj en retejoj al la platformkonto.
Sekva estas la sistemuzanto DANBo devis alŝuti dosieron de certa formato en la Excel-sistemon, kiu enhavis ĉiujn informojn pri la lokigo (reklama kampanjo, platformo, formato, lokiga periodo, planitaj indikiloj, buĝeto ktp.) kaj identigilojn de la respondaj reklamaj kampanjoj sur la retejoj kaj nombriloj en reklamaj sistemoj.
Ĝi aspektis, sincere, terure:
La elŝutitaj datumoj estis konservitaj en datumbazon, kaj tiam apartaj servoj kolektis kampanjidentigilojn sur retejoj de ili kaj elŝutis statistikojn pri ili.
Por ĉiu retejo, aparta vindoza servo estis skribita, kiu unufoje tage iris sub unu servokonto en la API de la retejo kaj elŝutis statistikojn por specifitaj kampanjaj identigiloj. La sama afero okazis kun reklamaj sistemoj.
La elŝutitaj datumoj estis montritaj sur la interfaco en la formo de malgranda laŭmenda panelo:
Neatendite por ni, MVP eklaboris kaj komencis elŝuti aktualajn statistikojn pri reklamaj kampanjoj en Interreto. Ni efektivigis la sistemon sur pluraj klientoj, sed kiam ni provis skali, ni renkontis gravajn problemojn:
- La ĉefa problemo estis la komplekseco de preparado de datumoj por ŝarĝo en la sistemon. Ankaŭ, la lokigaj datumoj devis esti konvertitaj al strikte fiksita formato antaŭ ŝarĝo. Necesis enmeti entajn identigilojn de malsamaj retejoj en la elŝuta dosiero. Ni estas antaŭ la fakto, ke estas tre malfacile por teknike netrejnitaj uzantoj klarigi kie trovi ĉi tiujn identigilojn en la retejo kaj kie en la dosiero ili devas esti enigitaj. Konsiderante la nombron da dungitoj en la fakoj farantaj kampanjojn en retejoj kaj la spezo, tio rezultigis grandegan kvanton da subteno de nia flanko, pri kiu ni absolute ne estis feliĉaj.
- Alia problemo estis, ke ne ĉiuj reklamplatformoj havis mekanismojn por delegi aliron al reklamaj kampanjoj al aliaj kontoj. Sed eĉ se delega mekanismo estis disponebla, ne ĉiuj reklamantoj volis doni aliron al siaj kampanjoj al triaj kontoj.
- Grava faktoro estis la indigno, kiu vekis inter uzantoj pro la fakto, ke ĉiuj planitaj indikiloj kaj lokigaj detaloj, kiujn ili jam eniras en nian kontadan sistemon 1C, ili devas denove eniri. DANBo.
Ĉi tio donis al ni la ideon, ke la ĉefa fonto de informoj pri lokigo devus esti nia 1C-sistemo, en kiu ĉiuj datumoj estas enmetitaj precize kaj ĝustatempe (la punkto ĉi tie estas, ke fakturoj estas generitaj surbaze de 1C-datumoj, do ĝusta enigo de datumoj en 1C. estas prioritato por ĉiuj KPI). Jen kiel nova koncepto de la sistemo aperis...
Koncepto
La unua afero, kiun ni decidis fari, estis apartigi la sistemon por kolektado de statistikoj pri reklamaj kampanjoj en Interreto en apartan produkton - D1.Cifereca.
En la nova koncepto, ni decidis ŝarĝi en D1.Cifereca informojn pri reklamaj kampanjoj kaj allokigoj ene de ili de 1C, kaj tiam eltiri statistikojn de retejoj kaj AdServing-sistemoj al ĉi tiuj lokigoj. Ĉi tio devis signife simpligi la vivon por uzantoj (kaj, kiel kutime, aldoni pli da laboro al programistoj) kaj redukti la kvanton de subteno.
La unua problemo, kiun ni renkontis, estis de organiza naturo kaj rilatis al la fakto, ke ni ne povis trovi ŝlosilon aŭ signon, per kiu ni povus kompari entojn de malsamaj sistemoj kun kampanjoj kaj allokigoj de 1C. La fakto estas, ke la procezo en nia kompanio estas desegnita tiel, ke reklamaj kampanjoj estas enmetitaj en malsamaj sistemoj de malsamaj homoj (komunikiloj planistoj, aĉetado ktp.).
Por solvi ĉi tiun problemon, ni devis inventi unikan haketŝlosilon, DANBoID, kiu ligus entojn en malsamaj sistemoj kune, kaj kiu povus esti sufiĉe facile kaj unike identigita en elŝutitaj datumserioj. Ĉi tiu identigilo estas generita en la interna 1C-sistemo por ĉiu individua lokigo kaj estas transdonita al kampanjoj, allokigoj kaj sumigiloj en ĉiuj retejoj kaj en ĉiuj AdServing-sistemoj. Efektivigi la praktikon meti DANBoID en ĉiujn lokigojn prenis iom da tempo, sed ni sukcesis fari ĝin :)
Tiam ni eksciis, ke ne ĉiuj retejoj havas API por aŭtomate kolekti statistikon, kaj eĉ tiuj, kiuj havas API, ĝi ne resendas ĉiujn necesajn datumojn.
En ĉi tiu etapo, ni decidis signife redukti la liston de platformoj por integriĝo kaj koncentriĝi sur la ĉefaj platformoj, kiuj estas implikitaj en la granda plimulto de reklamaj kampanjoj. Ĉi tiu listo inkluzivas ĉiujn plej grandajn ludantojn en la reklama merkato (Google, Yandex, Mail.ru), sociaj retoj (VK, Facebook, Twitter), ĉefaj AdServing kaj analizaj sistemoj (DCM, Driver, Weborama, Google Analytics) kaj aliaj platformoj.
La plimulto de la retejoj, kiujn ni elektis, havis API, kiu provizis la metrikojn, kiujn ni bezonis. En kazoj kie ne ekzistis API aŭ ĝi ne enhavis la necesajn datumojn, ni uzis raportojn senditajn ĉiutage al nia oficejo-retpoŝto por ŝargi datumojn (en iuj sistemoj eblas agordi tiajn raportojn, en aliaj ni konsentis pri la disvolviĝo de tiaj raportoj. por ni).
Analizante datumojn de malsamaj retejoj, ni eksciis, ke la hierarkio de entoj ne estas la sama en malsamaj sistemoj. Krome, informoj devas esti elŝutitaj en malsama detalo de malsamaj sistemoj.
Por solvi ĉi tiun problemon, la koncepto SubDANBoID estis evoluigita. La ideo de SubDANBoID estas sufiĉe simpla, ni markas la ĉefan enton de la kampanjo en la retejo per la generita DANBoID, kaj ni alŝutas ĉiujn nestitajn entojn kun unikaj retejo-identigiloj kaj formas SubDANBoID laŭ la principo DANBoID + identigilo de la unua nivelo. nestita ento + identigilo de la dua nivela ento ento +... Ĉi tiu aliro permesis al ni konekti reklamajn kampanjojn en malsamaj sistemoj kaj elŝuti detalajn statistikojn pri ili.
Ni ankaŭ devis solvi la problemon de aliro al kampanjoj sur malsamaj platformoj. Kiel ni skribis supre, la mekanismo delegi aliron al kampanjo al aparta teknika konto ne ĉiam aplikeblas. Tial ni devis evoluigi infrastrukturon por aŭtomata rajtigo per OAuth uzante ĵetonojn kaj mekanismojn por ĝisdatigi ĉi tiujn ĵetonojn.
Poste en la artikolo ni provos priskribi pli detale la arkitekturon de la solvo kaj la teknikajn detalojn de la efektivigo.
Solva arkitekturo 1.0
Komencante la efektivigon de nova produkto, ni komprenis, ke ni tuj bezonas provizi la eblecon konekti novajn retejojn, do ni decidis sekvi la vojon de mikroserva arkitekturo.
Dum desegnado de la arkitekturo, ni apartigis konektilojn al ĉiuj eksteraj sistemoj - 1C, reklamplatformoj kaj reklamadsistemoj - en apartajn servojn.
La ĉefa ideo estas, ke ĉiuj konektiloj al retejoj havas la saman API kaj estas adaptiloj, kiuj alportas la retejon API al interfaco konvena por ni.
En la centro de nia produkto estas retejo-apliko, kiu estas monolito, kiu estas desegnita tiel, ke ĝi povas esti facile malmuntita en servojn. Ĉi tiu aplikaĵo respondecas pri prilaborado de la elŝutitaj datumoj, kompari statistikojn de malsamaj sistemoj kaj prezenti ilin al sistemuzantoj.
Por komuniki inter la konektiloj kaj la TTT-apliko, ni devis krei aldonan servon, kiun ni nomis Connector Proxy. Ĝi plenumas la funkciojn de Service Discovery kaj Task Scheduler. Ĉi tiu servo efektivigas datumkolektajn taskojn por ĉiu konektilo ĉiunokte. Skribi servotavolon estis pli facila ol konekti mesaĝan makleriston, kaj por ni estis grave akiri la rezulton kiel eble plej rapide.
Por simpleco kaj rapideco de disvolviĝo, ni ankaŭ decidis, ke ĉiuj servoj estos Retaj APIoj. Ĉi tio ebligis rapide kunmeti pruvon de koncepto kaj kontroli, ke la tuta dezajno funkcias.
Aparta, sufiĉe kompleksa tasko estis agordi aliron por kolekti datumojn de malsamaj kontoj, kiuj, kiel ni decidis, devus esti efektivigitaj de uzantoj per la retinterfaco. Ĝi konsistas el du apartaj paŝoj: unue, la uzanto aldonas ĵetonon por aliri la konton per OAuth, kaj poste agordas la kolekton de datumoj por la kliento de specifa konto. Akiri ĵetonon per OAuth estas necesa ĉar, kiel ni jam skribis, ne ĉiam eblas delegi aliron al la dezirata konto en la retejo.
Por krei universalan mekanismon por elekti konton el retejoj, ni devis aldoni metodon al la konektiloj API, kiu resendas JSON-Skemon, kiu estas prezentita en formo uzante modifitan JSONEditor-komponenton. Tiel, uzantoj povis elekti la kontojn el kiuj elŝuti datumojn.
Por plenumi la petajn limojn, kiuj ekzistas en retejoj, ni kombinas petojn por agordoj ene de unu ĵetono, sed ni povas procesi malsamajn ĵetonojn paralele.
Ni elektis MongoDB kiel stokadon por ŝarĝitaj datumoj kaj por la retejo-apliko kaj konektiloj, kio permesis al ni ne tro zorgi pri la datumstrukturo en la komencaj etapoj de evoluo, kiam la objektomodelo de la aplikaĵo ŝanĝiĝas ĉiun duan tagon.
Ni baldaŭ eksciis, ke ne ĉiuj datumoj bone taŭgas en MongoDB kaj, ekzemple, estas pli oportune konservi ĉiutagajn statistikojn en rilata datumbazo. Tial, por konektiloj, kies datumstrukturo pli taŭgas por interrilata datumbazo, ni komencis uzi PostgreSQL aŭ MS SQL Server kiel stokado.
La elektitaj arkitekturo kaj teknologioj permesis al ni konstrui kaj lanĉi la produkton D1.Digital relative rapide. Dum du jaroj da produkta evoluado, ni evoluigis 23 konektilojn al retejoj, akiris valoregan sperton laborante kun triaj API-oj, lernis eviti la malfacilaĵojn de malsamaj retejoj, kiuj ĉiu havis sian propran, kontribuis al la disvolviĝo de API-oj por almenaŭ 3 retejoj. , aŭtomate elŝutis informojn pri preskaŭ 15 000 kampanjoj kaj dum pli ol 80 000 allokigoj, kolektis multajn sugestojn de uzantoj pri la funkciado de la produkto kaj sukcesis plurfoje ŝanĝi la ĉefan procezon de la produkto, surbaze de ĉi tiu sugesto.
Solva arkitekturo 2.0
Du jaroj pasis ekde la komenco de evoluo D1.Cifereca. La konstanta pliiĝo de ŝarĝo sur la sistemo kaj la apero de pli kaj pli da novaj datumfontoj iom post iom malkaŝis problemojn en la ekzistanta solva arkitekturo.
La unua problemo rilatas al la kvanto da datumoj elŝutitaj de la retejoj. Ni alfrontis la fakton, ke kolekti kaj ĝisdatigi ĉiujn necesajn datumojn de la plej grandaj retejoj komencis preni tro da tempo. Ekzemple, kolektado de datumoj de la AdRiver reklamadsistemo, per kiu ni spuras statistikojn por plej multaj lokigoj, daŭras ĉirkaŭ 12 horojn.
Por solvi ĉi tiun problemon, ni komencis uzi ĉiajn raportojn por elŝuti datumojn de retejoj, ni provas disvolvi ilian API kune kun la retejoj, por ke la rapideco de ĝia funkciado plenumu niajn bezonojn, kaj paraleligi la elŝuton de datumoj kiel eble plej multe.
Alia problemo rilatas al la prilaborado de elŝutitaj datumoj. Nun, kiam alvenas novaj lokigaj statistikoj, plurŝtupa procezo de rekalkulado de metrikoj estas lanĉita, kiu inkluzivas ŝarĝi krudajn datumojn, kalkuli agregitajn metrikojn por ĉiu retejo, kompari inter si datumojn de malsamaj fontoj kaj kalkulante resumajn metrikojn por la kampanjo. Ĉi tio kaŭzas multe da ŝarĝo sur la retejo, kiu faras ĉiujn kalkulojn. Plurfoje, dum la rekalkula procezo, la aplikaĵo konsumis la tutan memoron en la servilo, ĉirkaŭ 10-15 GB, kio havis la plej malutilan efikon al la laboro de uzantoj kun la sistemo.
La identigitaj problemoj kaj ambiciaj planoj por pluevoluigo de la produkto kondukis nin al la bezono rekonsideri la aplikaĵarkitekturon.
Ni komencis per konektiloj.
Ni rimarkis, ke ĉiuj konektiloj funkcias laŭ la sama modelo, do ni konstruis duktan kadron, en kiu por krei konektilon oni nur devis programi la logikon de la paŝoj, la resto estis universala. Se iu konektilo postulas plibonigon, tiam ni tuj transdonas ĝin al nova kadro samtempe kiam la konektilo estas plibonigata.
Samtempe ni komencis disfaldi konektilojn al Docker kaj Kubernetes.
Ni planis la translokiĝon al Kubernetes dum sufiĉe longa tempo, eksperimentis kun CI/CD-agordoj, sed ekmoviĝis nur kiam unu konektilo, pro eraro, komencis manĝi pli ol 20 GB da memoro en la servilo, preskaŭ mortigante aliajn procezojn. . Dum la esploro, la konektilo estis movita al Kubernetes-areto, kie ĝi finfine restis, eĉ post kiam la eraro estis riparita.
Sufiĉe rapide ni rimarkis, ke Kubernetes estas oportuna, kaj ene de ses monatoj ni transdonis 7-konektilojn kaj Konektilojn Proxy, kiuj konsumas la plej multajn rimedojn, al la produktadgrupo.
Sekvante la konektilojn, ni decidis ŝanĝi la arkitekturon de la resto de la aplikaĵo.
La ĉefa problemo estis, ke datumoj venas de konektiloj al prokuriloj en grandaj aroj, kaj poste trafas la DANBoID kaj estas senditaj al la centra retejo por prilaborado. Pro la granda nombro da metrikaj rekalkuloj, estas granda ŝarĝo sur la aplikaĵo.
Ankaŭ montriĝis sufiĉe malfacile monitori la statuson de individuaj datumkolektaj laboroj kaj raporti erarojn okazantajn ene de konektiloj al centra TTT-aplikaĵo por ke uzantoj povu vidi kio okazas kaj kial datumoj ne estis kolektitaj.
Por solvi ĉi tiujn problemojn, ni evoluigis arkitekturon 2.0.
La ĉefa diferenco inter la nova versio de la arkitekturo estas, ke anstataŭ la TTT-API, ni uzas RabbitMQ kaj la MassTransit-bibliotekon por interŝanĝi mesaĝojn inter servoj. Por fari tion, ni devis preskaŭ tute reverki Connectors Proxy, farante ĝin Connectors Hub. La nomo estis ŝanĝita ĉar la ĉefa rolo de la servo ne plu estas en plusendado de petoj al konektiloj kaj reen, sed en administrado de la kolekto de metrikoj de konektiloj.
De la centra TTT-aplikaĵo, ni apartigis informojn pri lokigoj kaj statistikoj de retejoj en apartajn servojn, kio ebligis forigi nenecesajn rekalkulojn kaj stoki nur jam kalkulitajn kaj kunigitajn statistikojn ĉe la lokiga nivelo. Ni ankaŭ reverkis kaj optimumigis la logikon por kalkulado de bazaj statistikoj bazitaj sur krudaj datumoj.
Samtempe, ni migras ĉiujn servojn kaj aplikojn al Docker kaj Kubernetes por fari la solvon pli facile skalebla kaj pli oportuna administrebla.
Kie ni estas nun
Pruvo-de-koncepta arkitekturo 2.0 produkto D1.Cifereca preta kaj laboranta en testa medio kun limigita aro de konektiloj. Restas nur reverki aliajn 20 konektilojn al nova platformo, provi ke la datumoj estas ĝuste ŝarĝitaj kaj ĉiuj mezuriloj estas ĝuste kalkulitaj, kaj efektivigi la tutan dezajnon en produktadon.
Fakte, ĉi tiu procezo okazos iom post iom kaj ni devos forlasi malantaŭan kongruon kun malnovaj API-oj por ke ĉio funkcias.
Niaj tujaj planoj inkluzivas la disvolviĝon de novaj konektiloj, integriĝo kun novaj sistemoj kaj aldoni pliajn metrikojn al la aro de datumoj elŝutitaj de konektitaj retejoj kaj reklamaj sistemoj.
Ni ankaŭ planas translokigi ĉiujn aplikojn, inkluzive de la centra retejo, al Docker kaj Kubernetes. Kombinita kun la nova arkitekturo, ĉi tio signife simpligos la disfaldiĝon, monitoradon kaj kontrolon de konsumitaj rimedoj.
Alia ideo estas eksperimenti kun la elekto de datumbazo por stoki statistikojn, kiu estas nuntempe konservita en MongoDB. Ni jam transdonis plurajn novajn konektilojn al SQL-datumbazoj, sed tie la diferenco estas preskaŭ nerimarkebla, kaj por aldonitaj statistikoj tage, kiujn oni povas peti por arbitra periodo, la gajno povas esti sufiĉe grava.
Ĝenerale, la planoj estas grandiozaj, ni pluiru :)
Aŭtoroj de la artikolo R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Miĥail Kotsik ()
fonto: www.habr.com