It liket derop dat it fjild fan online reklame sa technologysk avansearre en automatisearre mooglik wêze moat. Fansels, om't sokke reuzen en saakkundigen op har fjild as Yandex, Mail.Ru, Google en Facebook wurkje dêr. Mar, sa die bliken, is d'r gjin limyt foar perfeksje en d'r is altyd wat te automatisearjen.
Kommunikaasje groep Dentsu Aegis Network Ruslân is de grutste spiler yn 'e digitale reklamemerk en ynvestearret aktyf yn technology, besiket har saaklike prosessen te optimalisearjen en te automatisearjen. Ien fan 'e ûnoploste problemen fan' e online reklamemerk is de taak om statistiken te sammeljen oer reklamekampanjes fan ferskate ynternetplatfoarms. De oplossing foar dit probleem resultearre úteinlik yn it meitsjen fan in produkt D1.Digitaal (lêzen as DiVan), de ûntwikkeling wêrfan wy wolle prate oer.
Wêrom?
1. Yn 'e tiid fan' e start fan it projekt wie d'r gjin inkeld klear produkt op 'e merk dy't it probleem oploste fan it automatisearjen fan it sammeljen fan statistiken oer reklamekampanjes. Dit betsjut dat gjinien útsein ússels sil foldwaan oan ús behoeften.
Tsjinsten lykas Improvado, Roistat, Supermetrics, SegmentStream biede yntegraasje mei platfoarms, sosjale netwurken en Google Analitycs, en meitsje it ek mooglik om analytyske dashboards te bouwen foar handige analyse en kontrôle fan reklamekampanjes. Foardat wy ús produkt begûnen te ûntwikkeljen, besochten wy guon fan dizze systemen te brûken om gegevens fan siden te sammeljen, mar spitigernôch koene se ús problemen net oplosse.
It wichtichste probleem wie dat de hifke produkten wiene basearre op gegevens boarnen, werjaan fan pleatsing statistiken per side, en net levere de mooglikheid om te aggregearjen statistiken oer reklame kampanjes. Dizze oanpak liet ús net sjen statistyk fan ferskate siden op ien plak en analysearje de steat fan 'e kampanje as gehiel.
In oare faktor wie dat de produkten yn 'e earste fazen rjochte wiene op' e westerske merk en net stipe yntegraasje mei Russyske siden. En foar dy siden wêrmei yntegraasje waard útfierd, alle nedige metriken waarden net altyd ynladen mei genôch detail, en de yntegraasje wie net altyd handich en transparant, benammen as it wie nedich om te krijen wat dat is net yn it systeem ynterface.
Yn 't algemien hawwe wy besletten om net oan te passen oan produkten fan tredden, mar begon ús eigen te ûntwikkeljen ...
2. De online reklame merk groeit fan jier nei jier, en yn 2018, yn termen fan reklame budzjetten, it oerhelle de tradisjoneel grutste TV reklame merk. Sa is der in skaal.
3. Oars as de TV reklame merk, dêr't de ferkeap fan kommersjele reklame wurdt monopolisearre, der binne in protte yndividuele eigners fan reklame ynventarisaasje fan ferskate maten operearje op it ynternet mei harren eigen reklame akkounts. Sûnt in reklamekampanje, yn 'e regel, rint op ferskate siden tagelyk, om de steat fan' e reklamekampanje te begripen, is it nedich om rapporten fan alle siden te sammeljen en te kombinearjen yn ien grut rapport dat it heule byld sjen sil. Dit betsjut dat d'r potinsjeel is foar optimalisaasje.
4. It like ús dat de eigners fan reklame ynventarisaasje op it ynternet al hawwe de ynfrastruktuer foar it sammeljen fan statistiken en werjaan se yn reklame akkounts, en se sille wêze kinne om te foarsjen in API foar dizze gegevens. Dit betsjut dat it technysk mooglik is om it út te fieren. Lit ús daliks sizze dat it net sa ienfâldich blykt te wêzen.
Yn 't algemien wiene alle betingsten foar de útfiering fan it projekt foar ús fanselssprekkend, en wy rûnen om it projekt ta libben te bringen ...
Grutte Plan
Om te begjinnen, foarme wy in fyzje fan in ideaal systeem:
- Reklamekampanjes fan it 1C-bedriuwsysteem moatte der automatysk yn laden wurde mei har nammen, perioaden, budzjetten en pleatsingen op ferskate platfoarms.
- Foar elke pleatsing binnen in reklamekampanje moatte alle mooglike statistiken automatysk downloade wurde fan 'e siden wêr't de pleatsing plakfynt, lykas it oantal yndrukken, klikken, werjeften, ensfh.
- Guon reklamekampanjes wurde folge mei tafersjoch fan tredden troch saneamde reklamesystemen lykas Adriver, Weborama, DCM, ensfh. Der is ek in yndustriële ynternet meter yn Ruslân - it bedriuw Mediascope. Neffens ús plan moatte gegevens fan ûnôfhinklike en yndustriële tafersjoch ek automatysk laden wurde yn 'e oerienkommende reklamekampanjes.
- De measte reklamekampanjes op it ynternet binne rjochte op bepaalde doelaksjes (keapje, skilje, oanmelde foar in proefrit, ensfh.), dy't wurde folge mei Google Analytics, en statistiken wêrfoar't ek wichtich binne foar it begripen fan 'e status fan' e kampanje en moatte wurde laden yn ús ark.
De earste pankoek is kloften
Sjoen ús ynset foar fleksibele prinsipes fan softwareûntwikkeling (agile, alle dingen), besletten wy earst in MVP te ûntwikkeljen en dan iteratyf nei it beëage doel te bewegen.
Wy besletten om MVP te bouwen basearre op ús produkt DANBo (Dentsu Aegis Network Board), dat is in webapplikaasje mei algemiene ynformaasje oer advertinsjekampanjes fan ús kliïnten.
Foar MVP waard it projekt qua útfiering safolle mooglik ferienfâldige. Wy hawwe in beheinde list mei platfoarms selektearre foar yntegraasje. Dit wiene de wichtichste platfoarms, lykas Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, en de wichtichste adservingsystemen Adriver en Weborama.
Om tagong te krijen ta statistiken oer siden fia de API, hawwe wy ien inkeld akkount brûkt. In kliïntgroepbehearder dy't de automatyske kolleksje fan statistiken brûke woe op in reklamekampanje moast earst tagong ta de nedige reklamekampanjes op siden delegearje oan it platfoarmkonto.
Folgjende is de systeem brûker DANBo moast in bestân fan in bepaald formaat yn it Excel-systeem uploade, dat alle ynformaasje befette oer de pleatsing (reklamekampanje, platfoarm, opmaak, pleatsingsperioade, plande yndikatoaren, budzjet, ensfh.) sites en tellers yn adserving systemen.
It like, earlik sein, skriklik:
De ynladen gegevens waarden bewarre yn in databank, en dan aparte tsjinsten sammele kampanje identifiers op sites fan harren en ynladen statistiken op harren.
Foar elke side waard in aparte finstertsjinst skreaun, dy't ien kear deis ûnder ien tsjinstkonto yn 'e API fan' e side gie en statistiken downloade foar oantsjutte kampanje-ID's. Itselde barde mei advertinsjesystemen.
De ynladen gegevens waarden werjûn op 'e ynterface yn' e foarm fan in lyts oanpast dashboard:
Unferwachts foar ús begon MVP te wurkjen en begon aktuele statistiken te downloaden oer reklamekampanjes op it ynternet. Wy hawwe it systeem op ferskate kliïnten ymplementearre, mar by it besykjen fan skaalfergrutting tsjinkamen wy serieuze problemen:
- It wichtichste probleem wie de kompleksiteit fan it tarieden fan gegevens foar it laden yn it systeem. Ek moasten de pleatsingsgegevens foar it laden wurde omboud nei in strikt fêst formaat. It wie nedich om entiteitidentifikatoren fan ferskate siden op te nimmen yn it ynlaadbestân. Wy wurde konfrontearre mei it feit dat it heul lestich is foar technysk net oplaat brûkers om te ferklearjen wêr't dizze identifiers op 'e side te finen binne en wêr't yn it bestân se ynfierd wurde moatte. Sjoen it tal meiwurkers op de ôfdielingen dy’t kampanjes op sites draait en de omset, soarge dat foar in soad stipe oan ús kant, dêr’t wy perfoarst net bliid mei wiene.
- In oar probleem wie dat net alle reklameplatfoarms meganismen hiene foar it delegearjen fan tagong ta reklamekampanjes nei oare akkounts. Mar sels as in delegaasjemeganisme beskikber wie, wiene net alle advertearders ree om tagong te jaan ta har kampanjes oan akkounts fan tredden.
- In wichtige faktor wie de argewaasje dy't opwekke ûnder brûkers troch it feit dat alle plande yndikatoaren en pleatsingsdetails dy't se al ynfiere yn ús 1C-boekhâldingsysteem, se moatte opnij ynfiere DANBo.
Dit joech ús it idee dat de primêre boarne fan ynformaasje oer pleatsing ús 1C-systeem moat wêze, wêryn alle gegevens krekt en op 'e tiid wurde ynfierd (it punt hjir is dat faktueren wurde generearre op basis fan 1C-gegevens, dus korrekte ynfier fan gegevens yn 1C is in prioriteit foar elkenien KPI). Dit is hoe't in nij konsept fan it systeem ûntstie ...
Konsept
It earste ding dat wy besletten om te dwaan wie om it systeem foar it sammeljen fan statistiken oer reklamekampanjes op it ynternet te skieden yn in apart produkt - D1.Digitaal.
Yn it nije konsept hawwe wy besletten om yn te laden D1.Digitaal ynformaasje oer reklame kampanjes en pleatsingen binnen harren út 1C, en dan lûke statistiken fan sites en AdServing systemen oan dizze pleatsingen. Dit soe it libben foar brûkers signifikant ferienfâldigje (en, lykas gewoanlik, mear wurk tafoegje oan ûntwikkelders) en it bedrach fan stipe ferminderje.
It earste probleem dat wy tsjinkamen wie fan organisatoaryske aard en wie relatearre oan it feit dat wy gjin kaai of teken koene fine wêrmei't wy entiteiten fan ferskate systemen kinne fergelykje mei kampanjes en pleatsingen fan 1C. It feit is dat it proses yn ús bedriuw is ûntwurpen op sa'n manier dat advertinsjekampanjes wurde ynfierd yn ferskate systemen troch ferskate minsken (mediaplanners, keapje, ensfh.).
Om dit probleem op te lossen, moasten wy in unike hashed-kaai útfine, DANBoID, dy't entiteiten yn ferskate systemen mei-inoar keppele soe, en dat koe frij maklik en unyk identifisearre wurde yn ynladen datasets. Dizze identifier wurdt generearre yn it ynterne 1C-systeem foar elke yndividuele pleatsing en wurdt oerdroegen oan kampanjes, pleatsingen en tellers op alle siden en yn alle AdServing-systemen. It ymplementearjen fan de praktyk fan it pleatsen fan DANBoID yn alle pleatsingen duorre wat tiid, mar wy binne it slagge om it te dwaan :)
Doe fûnen wy út dat net alle siden in API hawwe foar it automatysk sammeljen fan statistiken, en sels dyjingen dy't in API hawwe, it jout net alle nedige gegevens werom.
Op dit stadium hawwe wy besletten om de list mei platfoarms foar yntegraasje signifikant te ferminderjen en te fokusjen op 'e wichtichste platfoarms dy't belutsen binne by de grutte mearderheid fan reklamekampanjes. Dizze list befettet alle grutste spilers yn 'e reklamemerk (Google, Yandex, Mail.ru), sosjale netwurken (VK, Facebook, Twitter), grutte AdServing- en analytyske systemen (DCM, Adriver, Weborama, Google Analytics) en oare platfoarms.
De mearderheid fan 'e siden dy't wy selekteare hiene in API dy't de metriken levere dy't wy nedich wiene. Yn gefallen wêr't d'r gjin API wie of it net de nedige gegevens befette, brûkten wy rapporten dy't alle dagen nei ús kantoar e-post stjoerd binne om gegevens te laden (yn guon systemen is it mooglik om sokke rapporten te konfigurearjen, yn oaren binne wy it iens oer de ûntwikkeling fan sokke rapporten foar ús).
By it analysearjen fan gegevens fan ferskate siden, fûnen wy út dat de hiërargy fan entiteiten net itselde is yn ferskate systemen. Boppedat moat ynformaasje yn ferskillende details downloade wurde fan ferskate systemen.
Om dit probleem op te lossen waard it SubDANBoID-konsept ûntwikkele. It idee fan SubDANBoID is frij ienfâldich, wy markearje de haadentiteit fan 'e kampanje op' e side mei it generearre DANBoID, en wy uploade alle nestele entiteiten mei unike side-identifikaasjes en foarmje SubDANBoID neffens it DANBoID-prinsipe + identifier fan it earste nivo nested entity + identifier fan it twadde nivo nested entiteit +... Dizze oanpak tastien ús te ferbinen reklame kampanjes yn ferskillende systemen en download detaillearre statistiken oer harren.
Wy moasten ek it probleem oplosse fan tagong ta kampanjes op ferskate platfoarms. Lykas wy hjirboppe skreaun hawwe, is it meganisme fan it delegearjen fan tagong ta in kampanje nei in apart technysk akkount net altyd fan tapassing. Dêrom moasten wy in ynfrastruktuer ûntwikkelje foar automatyske autorisaasje fia OAuth mei tokens en meganismen foar it bywurkjen fan dizze tokens.
Letter yn it artikel sille wy besykje yn mear detail de arsjitektuer fan 'e oplossing en de technyske details fan' e útfiering te beskriuwen.
Oplossingsarsjitektuer 1.0
By it begjinnen fan de ymplemintaasje fan in nij produkt, begrepen wy dat wy fuortendaliks moatte soargje foar de mooglikheid om nije siden te ferbinen, dus besleaten wy it paad fan mikroservicearsjitektuer te folgjen.
By it ûntwerpen fan 'e arsjitektuer hawwe wy ferbiningen skieden foar alle eksterne systemen - 1C, advertinsjeplatfoarms en advertinsjesystemen - yn aparte tsjinsten.
It wichtichste idee is dat alle Anschlüsse nei siden hawwe deselde API en binne adapters dy't bringe de site API nei in ynterface handich foar ús.
Yn it sintrum fan ús produkt is in webapplikaasje, dat is in monolith dy't is ûntwurpen op sa'n manier dat it maklik kin wurde disassembled yn tsjinsten. Dizze applikaasje is ferantwurdlik foar it ferwurkjen fan de downloade gegevens, it sammeljen fan statistiken fan ferskate systemen en it presintearjen fan dizze oan systeembrûkers.
Om te kommunisearjen tusken de ferbiningen en de webapplikaasje, moasten wy in ekstra tsjinst meitsje, dy't wy Connector Proxy neamden. It fiert de funksjes fan Service Discovery en Task Scheduler. Dizze tsjinst rint elke nacht taken foar it sammeljen fan gegevens foar elke ferbining. It skriuwen fan in tsjinstlaach wie makliker as it ferbinen fan in berjochtmakelaar, en foar ús wie it wichtich om it resultaat sa gau mooglik te krijen.
Foar ienfâld en snelheid fan ûntwikkeling hawwe wy ek besletten dat alle tsjinsten Web API's sille wêze. Dit makke it mooglik om fluch in proof-of-concept te sammeljen en te kontrolearjen dat it heule ûntwerp wurket.
In aparte, frij komplekse taak wie it ynstellen fan tagong om gegevens te sammeljen fan ferskate akkounts, dy't, lykas wy besletten, moatte wurde útfierd troch brûkers fia de webynterface. It bestiet út twa aparte stappen: earst foeget de brûker in token ta om tagong te krijen ta it akkount fia OAuth, en konfigurearret dan de kolleksje fan gegevens foar de kliïnt fan in spesifyk akkount. It krijen fan in token fia OAuth is nedich, om't, lykas wy al skreaun hawwe, it net altyd mooglik is om tagong ta it winske akkount op 'e side te delegearjen.
Om in universele meganisme te meitsjen foar it selektearjen fan in akkount fan siden, moasten wy in metoade tafoegje oan 'e connectors API dy't JSON Schema werombringt, dat wurdt werjûn yn in foarm mei in wizige JSONEditor-komponint. Op dizze manier koene brûkers de akkounts selektearje wêrfan de gegevens downloade koene.
Om te foldwaan oan de fersyk grinzen dy't bestean op sites, wy kombinearje fersiken foar ynstellings binnen ien token, mar wy kinne ferwurkje ferskate tokens parallel.
Wy hawwe MongoDB keazen as opslach foar laden gegevens foar sawol de webapplikaasje as ferbiningen, wêrtroch't wy ús net te folle soargen hawwe oer de gegevensstruktuer yn 'e earste stadia fan ûntwikkeling, as it objektmodel fan' e applikaasje elke oare dei feroaret.
Wy fûnen al gau út dat net alle gegevens goed passe yn MongoDB en it is bygelyks handiger om deistige statistiken op te slaan yn in relationele databank. Dêrom, foar Anschlüsse waans gegevensstruktuer is mear geskikt foar in relational databank, wy begûn te brûken PostgreSQL of MS SQL Server as opslach.
De keazen arsjitektuer en technologyen lieten ús bouwe en lansearje it produkt D1.Digital relatyf fluch. Mear as twa jier fan produktûntwikkeling hawwe wy 23-ferbiningen foar siden ûntwikkele, ûnskatbere ûnderfining opdien mei it wurkjen mei API's fan tredden, learden om de falkûlen te foarkommen fan ferskate siden, dy't elk har eigen hiene, bydroegen oan 'e ûntwikkeling fan 'e API fan op syn minst 3 sites, automatysk ynladen ynformaasje oer hast 15 kampanjes en foar mear as 000 pleatsingen, sammele in soad feedback fan brûkers op it produkt syn operaasje en slagge te feroarjen de wichtichste proses fan it produkt ferskate kearen, basearre op dizze feedback.
Oplossingsarsjitektuer 2.0
Twa jier binne ferrûn sûnt it begjin fan 'e ûntwikkeling D1.Digitaal. De konstante tanimming fan de lading op it systeem en it ûntstean fan mear en mear nije gegevens boarnen stadichoan iepenbiere problemen yn de besteande oplossing arsjitektuer.
It earste probleem is relatearre oan de hoemannichte gegevens ynladen fan 'e siden. Wy waarden konfrontearre mei it feit dat it sammeljen en aktualisearjen fan alle nedige gegevens fan 'e grutste siden begon te folle tiid te nimmen. Bygelyks, it sammeljen fan gegevens fan it AdRiver-advertinsjesysteem, wêrmei't wy statistiken foar de measte pleatsingen folgje, duorret sawat 12 oeren.
Om dit probleem op te lossen, binne wy begon alle soarten rapporten te brûken om gegevens fan siden te downloaden, wy besykje har API tegearre mei de siden te ûntwikkeljen sadat de snelheid fan har operaasje foldocht oan ús behoeften, en parallelisearje de download fan gegevens safolle mooglik.
In oar probleem hat te krijen mei de ferwurking fan ynladen gegevens. No, as nije pleatsingsstatistiken oankomme, wurdt in multi-stage-proses lansearre foar it opnij berekkenjen fan metriken, dat omfettet it laden fan rauwe gegevens, it berekkenjen fan aggregearre metriken foar elke side, it fergelykjen fan gegevens fan ferskate boarnen mei elkoar, en it berekkenjen fan gearfettingsmetriken foar de kampanje. Dit soarget foar in soad lêst op 'e webapplikaasje dy't alle berekkeningen docht. Ferskate kearen, tidens it werberekkeningsproses, konsumearre de applikaasje al it ûnthâld op 'e tsjinner, sawat 10-15 GB, wat it meast skealik effekt hie op it wurk fan brûkers mei it systeem.
De identifisearre problemen en ambisjeuze plannen foar fierdere ûntwikkeling fan it produkt liede ús ta de needsaak om de applikaasje-arsjitektuer opnij te besjen.
Wy begûnen mei connectors.
Wy hawwe opmurken dat alle Anschlüsse wurkje neffens itselde model, dus wy bouden in pipeline ramt wêryn te meitsjen in ferbining jo hoege allinnich programmearje de logika fan de stappen, de rest wie universele. As guon connector ferbettering fereasket, dan drage wy it daliks oer nei in nij ramt tagelyk as de connector wurdt ferbettere.
Tagelyk binne wy begon mei it ynsetten fan ferbiningen nei Docker en Kubernetes.
Wy planden de ferhuzing nei Kubernetes foar in lange tiid, eksperimintearre mei CI / CD-ynstellingen, mar begon te ferpleatsen allinich doe't ien ferbining, fanwege in flater, mear as 20 GB oan ûnthâld op 'e tsjinner begon te iten, wat oare prosessen praktysk fermoarde . Tidens it ûndersyk waard de ferbining ferpleatst nei in Kubernetes-kluster, wêr't it úteinlik bleau, sels nei't de flater reparearre wie.
Hiel fluch realisearre wy dat Kubernetes handich wie, en binnen seis moannen hawwe wy 7 Anschlüsse en Connectors Proxy, dy't de measte boarnen konsumearje, oerbrocht nei it produksjekluster.
Nei oanlieding fan de ferbiningen hawwe wy besletten de arsjitektuer fan 'e rest fan' e applikaasje te feroarjen.
It wichtichste probleem wie dat gegevens komme fan ferbinings nei proxy's yn grutte batches, en dan rekket de DANBoID en wurdt stjoerd nei de sintrale webapplikaasje foar ferwurking. Troch it grutte oantal metrike-herberekkeningen is d'r in grutte lêst op 'e applikaasje.
It bliek ek frij lestich om de status fan yndividuele banen foar gegevenssammeling te kontrolearjen en flaters te rapportearjen dy't foarkomme binnen ferbinings nei in sintrale webapplikaasje, sadat brûkers koene sjen wat der bart en wêrom gegevens net waarden sammele.
Om dizze problemen op te lossen, hawwe wy arsjitektuer 2.0 ûntwikkele.
It wichtichste ferskil tusken de nije ferzje fan de arsjitektuer is dat ynstee fan de Web API, wy brûke RabbitMQ en de MassTransit bibleteek te wikseljen berjochten tusken tsjinsten. Om dit te dwaan, moasten wy Connectors Proxy hast folslein oerskriuwe, wêrtroch it Connectors Hub is. De namme waard feroare om't de haadrol fan 'e tsjinst net mear is yn it trochstjoeren fan fersiken nei ferbiningen en werom, mar yn it behearen fan it sammeljen fan metriken fan ferbiningen.
Fan 'e sintrale webapplikaasje skieden wy ynformaasje oer pleatsingen en statistiken fan siden yn aparte tsjinsten, wat it mooglik makken om ûnnedige werberekkeningen kwyt te reitsjen en allinich al berekkene en aggregearre statistiken op pleatsingsnivo op te slaan. Wy hawwe ek de logika opnij skreaun en optimalisearre foar it berekkenjen fan basisstatistiken basearre op rauwe gegevens.
Tagelyk migrearje wy alle tsjinsten en applikaasjes nei Docker en Kubernetes om de oplossing makliker te skaaljen en handiger te behearjen.
Wêr binne wy no
Proof-of-concept arsjitektuer 2.0 produkt D1.Digitaal klear en wurkje yn in test omjouwing mei in beheinde set fan Anschlüsse. Alles wat oerbleaun is om noch 20 ferbiningen nei in nij platfoarm te herskriuwen, te testen dat de gegevens goed laden binne en alle metriken korrekt binne berekkene, en it heule ûntwerp yn produksje útrolje.
Yn feite sil dit proses stadichoan barre en wy sille efterútkompatibiliteit moatte ferlitte mei âlde API's om alles wurkje te hâlden.
Us direkte plannen omfetsje de ûntwikkeling fan nije ferbiningen, yntegraasje mei nije systemen en it tafoegjen fan ekstra metriken oan 'e set fan gegevens dy't downloade fan ferbûne siden en advertinsjesystemen.
Wy binne ek fan plan om alle applikaasjes, ynklusyf de sintrale webapplikaasje, oer te bringen nei Docker en Kubernetes. Yn kombinaasje mei de nije arsjitektuer sil dit de ynset, tafersjoch en kontrôle fan konsumeare boarnen signifikant ferienfâldigje.
In oar idee is om te eksperimintearjen mei de kar fan databank foar it bewarjen fan statistiken, dy't op it stuit opslein is yn MongoDB. Wy hawwe al ferskate nije Anschlüsse oerbrocht nei SQL-databases, mar dêr is it ferskil hast net te merken, en foar aggregearre statistyk per dei, dat kin wurde oanfrege foar in willekeurige perioade, kin de winst frij serieus wêze.
Yn 't algemien binne de plannen grandioos, litte wy trochgean :)
Auteurs fan it artikel R&D Dentsu Aegis Network Ruslân: Georgy Ostapenko (), Mikhail Kotsik ()
Boarne: www.habr.com