Badirudi sareko publizitatearen arloak teknologikoki ahalik eta aurreratuena eta automatizatua izan behar duela. Noski, Yandex, Mail.Ru, Google eta Facebook bezalako erraldoi eta adituek bertan lan egiten dutelako. Baina, ondorioztatu denez, ez dago perfekzioaren mugarik eta beti dago automatizatzeko zerbait.
Komunikazio taldea Dentsu Aegis Sarea Errusia publizitate digitaleko merkatuko eragilerik handiena da eta teknologian aktiboki inbertitzen ari da, bere negozio-prozesuak optimizatu eta automatizatu nahian. Online publizitate-merkatuaren konpondu gabeko arazoetako bat Interneteko plataforma ezberdinetako publizitate-kanpainei buruzko estatistikak biltzea da. Arazo honen konponbideak produktu bat sortzea ekarri zuen azkenean D1.Digitala (DiVan bezala irakurri), zeinaren garapenaz hitz egin nahi dugun.
Zergatik?
1. Proiektua hasi zen unean, merkatuan ez zegoen prest egindako produktu bakar bat ere publizitate kanpainei buruzko estatistiken bilketa automatizatzearen arazoa konpondu zuenik. Horrek esan nahi du inork ez dituela gure beharrak asetuko.
Improvado, Roistat, Supermetrics, SegmentStream bezalako zerbitzuek plataformekin, sare sozialekin eta Google Analitycs-ekin integratzeko aukera eskaintzen dute, eta publizitate-kanpainen azterketa eta kontrol erosoa egiteko panel analitikoak eraikitzeko aukera ere ematen dute. Gure produktua garatzen hasi aurretik, sistema horietako batzuk guneetako datuak biltzeko erabiltzen saiatu ginen, baina, tamalez, ezin izan zituzten gure arazoak konpondu.
Arazo nagusia izan zen probatutako produktuak datu-iturrietan oinarritzen zirela, guneen araberako kokapen-estatistikak bistaratzen zirela eta ez zutela publizitate-kanpainen estatistikak gehitzeko gaitasunik ematen. Ikuspegi honek ez zigun gune ezberdinetako estatistikak leku bakarrean ikusi eta kanpainaren egoera bere osotasunean aztertzea.
Beste faktore bat izan zen hasierako faseetan produktuak Mendebaldeko merkatura zuzenduta zeudela eta ez zutela onartzen Errusiako guneekin integratzea. Eta integrazioa ezarri zen gune horietarako, beharrezko neurketa guztiak ez ziren beti xehetasun nahikoarekin deskargatzen, eta integrazioa ez zen beti erosoa eta gardena izan, batez ere sistemaren interfazean ez dagoen zerbait lortu behar zenean.
Oro har, hirugarrenen produktuetara ez egokitzea erabaki genuen, baina gurea garatzen hasi ginen...
2. Sareko publizitate-merkatua hazten ari da urtetik urtera, eta 2018an, publizitate-aurrekontuei dagokienez, tradizioz telebistako publizitate-merkatu handiena gainditu zuen. Beraz, eskala bat dago.
3. Telebistako publizitate-merkatuan ez bezala, non publizitate komertzialaren salmenta monopolizatuta dagoen, hainbat tamainatako publizitate-inbentarioaren jabe indibidual asko daude Interneten beren publizitate-kontuekin. Publizitate-kanpaina bat, oro har, hainbat gunetan aldi berean exekutatzen denez, publizitate-kanpainaren egoera ulertzeko, beharrezkoa da gune guztietako txostenak biltzea eta argazki osoa erakutsiko duen txosten handi batean konbinatzea. Horrek esan nahi du optimizaziorako potentziala dagoela.
4. Iruditu zitzaigun Interneten publizitate-inbentarioaren jabeek estatistikak jasotzeko eta publizitate-kontuetan bistaratzeko azpiegitura dutela jada, eta datu horietarako API bat eman ahal izango dute. Horrek esan nahi du teknikoki posible dela inplementatzea. Demagun berehala ez dela hain sinplea izan.
Orokorrean, proiektua gauzatzeko aurrebaldintza guztiak begien bistakoak ziren guretzat, eta korrika egin genuen proiektua bizitzera...
Plan handia
Hasteko, sistema ideal baten ikuspegia osatu genuen:
- 1C sistema korporatiboko publizitate-kanpainak automatikoki kargatu behar dira bere izenekin, aldiekin, aurrekontuekin eta hainbat plataformatan kokatutako kokapenekin.
- Publizitate-kanpaina bateko kokapen bakoitzerako, automatikoki deskargatu behar dira kokatzea egiten ari den guneetako estatistika posible guztiak, hala nola inpresio, klik, ikustaldi, etab.
- Publizitate-kanpaina batzuen jarraipena egiten da hirugarrenen monitorizazioa erabiliz, Adriver, Weborama, DCM, etab. Errusian Internet neurgailu industrial bat ere badago - Mediascope konpainia. Gure planaren arabera, monitorizazio independente eta industrialaren datuak ere automatikoki kargatu behar dira dagozkien publizitate kanpainetan.
- Interneteko publizitate-kanpaina gehienak helburu-ekintza jakin batzuetara zuzenduta daude (erosketa, deitu, probako gidaritza batean izena eman, etab.), Google Analytics-en bidez jarraipena egiten zaienak, eta horien estatistikak ere garrantzitsuak dira kanpainaren egoera ulertzeko eta gure tresnan kargatu behar da.
Lehen pankarra lumpy da
Softwarearen garapenaren printzipio malguekiko dugun konpromisoa kontuan hartuta (arina, gauza guztiak), lehenik eta behin MVP bat garatzea erabaki genuen eta, ondoren, aurreikusitako helburura joatea iteratiboki.
Gure produktuan oinarrituta MVP eraikitzea erabaki genuen DANBo (Dentsu Aegis Network Board), gure bezeroen publizitate kanpainei buruzko informazio orokorra duen web aplikazio bat da.
MVPrentzat, proiektua ahalik eta gehien sinplifikatu zen ezarpenari dagokionez. Integraziorako plataformen zerrenda mugatu bat hautatu dugu. Hauek izan ziren plataforma nagusiak, hala nola Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, eta iragarki-sistema nagusiak Adriver eta Weborama.
APIaren bidez guneetako estatistikak sartzeko, kontu bakarra erabili dugu. Publizitate-kanpaina batean estatistiken bilketa automatikoa erabili nahi zuen bezero-taldeen kudeatzaileak lehenik eta behin guneetako beharrezko publizitate-kanpainetarako sarbidea plataforma-kontuan utzi behar izan zuen.
Hurrengoa sistemaren erabiltzailea da DANBo Excel sistemara formatu jakin bateko fitxategi bat igo behar izan zuen, eta bertan kokatzeari buruzko informazio guztia (iragarki-kanpaina, plataforma, formatua, jartze-aldia, aurreikusitako adierazleak, aurrekontua, etab.) eta dagozkien publizitate-kanpainen identifikatzaileak biltzen zituen. guneak eta kontagailuak iragarki-sistemetan.
Zintzoki, beldurgarria zirudien:
Deskargatutako datuak datu-base batean gorde ziren, eta, ondoren, zerbitzu bereiziek kanpainaren identifikatzaileak biltzen zituzten haietatik guneetan eta haiei buruzko estatistikak deskargatzen zituzten.
Gune bakoitzerako, Windows zerbitzu bereizi bat idatzi zen, egunean behin guneko APIan zerbitzu-kontu batean sartzen zena eta zehaztutako kanpainaren IDen estatistikak deskargatzen zituena. Gauza bera gertatu zen iragarkietarako sistemekin.
Deskargatutako datuak interfazean bistaratu ziren panel pertsonalizatu txiki baten moduan:
Guretzat ustekabean, MVP lanean hasi zen eta Interneten publizitate kanpainen egungo estatistikak deskargatzen hasi zen. Sistema hainbat bezerotan inplementatu genuen, baina eskalatzen saiatzean arazo larriak aurkitu genituen:
- Arazo nagusia sisteman kargatzeko datuak prestatzearen konplexutasuna zen. Gainera, kokapen-datuak formatu zorrozki finko batera bihurtu behar ziren kargatu aurretik. Deskarga fitxategian gune ezberdinetako entitate-identifikatzaileak sartzea beharrezkoa zen. Teknikoki trebatu gabeko erabiltzaileentzat oso zaila dela gunean identifikatzaile horiek non aurkitu eta fitxategian non sartu behar diren azaltzea aurrean gaude. Guneetan kanpainak egiten ari diren sailetako langile kopurua eta fakturazioa kontuan hartuta, horrek laguntza izugarria ekarri zuen gure aldetik, eta ez gintuzten guztiz pozik.
- Beste arazo bat izan zen publizitate-plataforma guztiek ez zutela publizitate-kanpainetarako sarbidea beste kontu batzuei eskuordetzeko mekanismorik. Baina eskuordetze-mekanismo bat eskuragarri bazegoen ere, iragarle guztiak ez zeuden prest hirugarrenen kontuei euren kanpainetarako sarbidea emateko.
- Faktore garrantzitsu bat erabiltzaileen artean piztu zuen haserrea izan zen, dagoeneko gure 1C kontabilitate sisteman sartutako aurreikusitako adierazle eta kokapen xehetasun guztiak berriro sartu behar dituztelako. DANBo.
Honek kokatzeari buruzko informazio-iturri nagusia gure 1C sistema izan behar zela pentsatu zigun, zeinean datu guztiak zehaztasunez eta garaiz sartzen diren (kontua da fakturak 1C datuetan oinarrituta sortzen direla, beraz, datuak zuzen sartzea 1C-n). guztien lehentasuna da KPI). Horrela sortu zen sistemaren kontzeptu berri bat...
kontzeptua
Lehenik eta behin erabaki genuen Interneten publizitate-kanpainei buruzko estatistikak biltzeko sistema produktu bereizi batean bereiztea - D1.Digitala.
Kontzeptu berrian, kargatzea erabaki genuen D1.Digitala 1C-tik publizitate-kanpainei eta haien barneko kokapenei buruzko informazioa, eta, ondoren, igo guneetako eta AdServing sistemetako estatistikak kokapen horietara. Honek erabiltzaileen bizitza nabarmen erraztu behar zuen (eta, ohi bezala, garatzaileei lan gehiago gehitzea) eta laguntza kopurua murriztea.
Topatu genuen lehenengo arazoa antolakuntza-izaerakoa zen eta 1C-ko kanpainekin eta kokapenekin sistema ezberdinetako entitateak konparatzeko giltza edo zeinurik aurkitu ez genuela lotuta zegoen. Kontua da gure enpresan prozesua modu honetan diseinatuta dagoela publizitate kanpainak sistema ezberdinetan sartzen diren pertsona ezberdinek (media-planifikatzaileak, erosketak, etab.).
Arazo hau konpontzeko, hashed gako esklusibo bat asmatu behar izan dugu, DANBoID, sistema ezberdinetako entitateak elkarrekin lotuko lituzkeena eta deskargatutako datu-multzoetan nahiko erraz eta modu berezian identifikatu zitekeena. Identifikatzaile hori 1C barneko sisteman sortzen da kokapen indibidual bakoitzeko eta kanpainetara, kokapenetara eta kontagailuetara transferitzen da gune guztietako eta AdServing sistema guztietan. Lanpostu guztietan DANBoID jartzeko praktika ezartzeak denbora pixka bat behar izan du, baina lortu dugu :)
Orduan jakin genuen gune guztiek ez dutela estatistikak automatikoki biltzeko APIrik, eta API bat dutenek ere ez dutela beharrezko datu guztiak itzultzen.
Fase honetan, integraziorako plataformen zerrenda nabarmen murriztea eta publizitate-kanpaina gehienetan parte hartzen duten plataforma nagusietara bideratzea erabaki dugu. Zerrenda honek publizitate-merkatuko eragilerik handienak (Google, Yandex, Mail.ru), sare sozialak (VK, Facebook, Twitter), AdServing eta analisi-sistema nagusiak (DCM, Adriver, Weborama, Google Analytics) eta beste plataforma batzuk biltzen ditu.
Aukeratu genituen gune gehienek behar genituen neurketak ematen zituen API bat zuten. APIrik ez zegoen kasuetan edo beharrezko datuak ez zituen kasuetan, egunero gure bulegoko posta elektronikora bidalitako txostenak erabiltzen genituen datuak kargatzeko (sistema batzuetan posible da txosten horiek konfiguratzea, beste batzuetan txosten horien garapena adostu genuen. guretzat).
Gune ezberdinetako datuak aztertzean, jakin dugu entitateen hierarkia ez dela berdina sistema ezberdinetan. Gainera, informazioa xehetasun ezberdinetan deskargatu behar da sistema ezberdinetatik.
Arazo hau konpontzeko, SubDANBoID kontzeptua garatu zen. SubDANBoID-en ideia nahiko sinplea da, kanpainaren entitate nagusia webgunean markatzen dugu sortutako DANBoID-arekin, eta habiatutako entitate guztiak gune-identifikatzaile esklusiboekin kargatzen ditugu eta SubDANBoID osatzen dugu DANBoID printzipioaren + lehen mailako identifikatzailearen arabera. entitate habiaratua + bigarren mailako entitate habiaratuaren identifikatzailea +... Ikuspegi honi esker, publizitate kanpainak sistema ezberdinetan konektatu eta haiei buruzko estatistika zehatzak deskargatu ahal izan ditugu.
Plataforma ezberdinetako kanpainetara sartzeko arazoa ere konpondu behar izan dugu. Goian idatzi dugun bezala, kanpaina baterako sarbidea kontu tekniko bereizi batera uzteko mekanismoa ez da beti aplikagarria. Hori dela eta, OAuth bidez baimen automatikorako azpiegitura bat garatu behar izan dugu tokenak eta token horiek eguneratzeko mekanismoak erabiliz.
Artikuluan aurrerago, irtenbidearen arkitektura eta ezarpenaren xehetasun teknikoak zehatzago deskribatzen saiatuko gara.
Irtenbide arkitektura 1.0
Produktu berri bat inplementatzen hastean, gune berriak konektatzeko aukera berehala eman behar genuela ulertu genuen, beraz, mikrozerbitzuen arkitekturaren bideari jarraitzea erabaki genuen.
Arkitektura diseinatzerakoan, kanpoko sistema guztien konektoreak bereizi genituen - 1C, publizitate plataformak eta iragarki-sistemak - zerbitzu bereizietan.
Ideia nagusia da guneetarako konektore guztiek API bera dutela eta guneko APIa guretzat erosoa den interfaze batera eramaten duten moldagailuak direla.
Gure produktuaren erdigunean web aplikazio bat dago, hau da, zerbitzuetan erraz desmuntatu daitekeen moduan diseinatutako monolito bat da. Aplikazio hau deskargatutako datuak prozesatzeaz, sistema ezberdinetako estatistikak bilduz eta sistemaren erabiltzaileei aurkezteaz arduratzen da.
Konektoreen eta web aplikazioaren artean komunikatzeko, zerbitzu gehigarri bat sortu behar izan dugu, Connector Proxy deitu duguna. Zerbitzuen Aurkikuntza eta Zereginen Antolatzailearen funtzioak betetzen ditu. Zerbitzu honek konektore bakoitzaren datuak biltzeko zereginak exekutatzen ditu gauero. Zerbitzu-geruza bat idaztea errazagoa zen mezu-artekari bat konektatzea baino, eta guretzat garrantzitsua zen emaitza ahalik eta azkarren lortzea.
Sinpletasuna eta garapen-abiaduragatik, zerbitzu guztiak Web APIak izango direla erabaki dugu. Horri esker, kontzeptu-froga bat azkar muntatu eta diseinu osoak funtzionatzen duela egiaztatzea ahalbidetu zuen.
Kontu desberdinetako datuak biltzeko sarbidea konfiguratzea zen, eta, guk erabaki bezala, erabiltzaileek web interfazearen bidez egin beharko lukete. Bi urrats bereizi ditu: lehenik, erabiltzaileak token bat gehitzen du kontura OAuth bidez sartzeko, eta, ondoren, bezeroarentzako datu-bilketa kontu zehatz batetik konfiguratzen du. OAuth bidez token bat lortzea beharrezkoa da, zeren eta, idatzi dugun bezala, ez baita beti posible webgunean nahi duzun konturako sarbidea delegatzea.
Guneetatik kontu bat hautatzeko mekanismo unibertsala sortzeko, JSON Eskema itzultzen duen konektoreen APIari metodo bat gehitu behar izan diogu, JSONEditor osagai aldatu bat erabiliz inprimaki batean errendatzen dena. Horrela, erabiltzaileek datuak deskargatzeko kontuak hautatu ahal izan zituzten.
Guneetan dauden eskaera-mugak betetzeko, ezarpenen eskaerak konbinatzen ditugu token baten barruan, baina token desberdinak prozesatu ditzakegu paraleloan.
MongoDB aukeratu genuen kargatutako datuen biltegiratze gisa, bai web aplikaziorako bai konektoreetarako, eta horri esker, garapenaren hasierako faseetan datu-egituraz gehiegi kezkatu ez ginenean, aplikazioaren objektu-eredua egunero aldatzen denean.
Laster jakin genuen datu guztiak ez direla ondo sartzen MongoDB-n eta, adibidez, erosoagoa dela eguneroko estatistikak datu-base erlazional batean gordetzea. Hori dela eta, datu-egitura erlazional baterako egokiagoa den konektoreetarako, PostgreSQL edo MS SQL Server biltegiratze gisa erabiltzen hasi ginen.
Aukeratutako arkitektura eta teknologiek D1.Digital produktua nahiko azkar eraiki eta abiarazteko aukera eman ziguten. Produktuaren garapenean bi urtetan zehar, guneetarako 23 konektore garatu genituen, hirugarrenen APIekin lan egiten esperientzia eskerga lortu genuen, gune ezberdinen akatsak saihesten ikasi genuen, bakoitzak berea zeukaten, gutxienez 3 APIaren garapenean lagundu genuen. guneek, automatikoki deskargatu zuten ia 15 kanpainari buruzko informazioa eta 000 kokapen baino gehiagotan, erabiltzaileen iritzi asko bildu zituzten produktuaren funtzionamenduari buruz eta produktuaren prozesu nagusia hainbat aldiz aldatzea lortu zuten, iritzi horretan oinarrituta.
Irtenbide arkitektura 2.0
Bi urte igaro dira garapena hasi zenetik D1.Digitala. Sistemaren karga etengabe handitzeak eta gero eta datu-iturri berri gehiago agertzeak apurka-apurka lehendik zegoen soluzio-arkitekturako arazoak agerian utzi zituzten.
Lehenengo arazoa guneetatik deskargatutako datu kopuruarekin lotuta dago. Gune handienetako beharrezko datu guztiak biltzea eta eguneratzea denbora gehiegi eskatzen hasi zitzaigula aurrean genuen. Esaterako, AdRiver iragarki-zerbitzuaren sistemako datuak biltzea, zeinekin kokapen gehienen estatistiken jarraipena egiten dugun, 12 ordu inguru behar dira.
Arazo hau konpontzeko, guneetatik datuak deskargatzeko era guztietako txostenak erabiltzen hasi ginen, guneekin batera haien APIa garatzen saiatzen ari gara, funtzionamenduaren abiadura gure beharrei erantzuteko, eta datuen deskarga ahalik eta gehien paralelizatzeko.
Beste arazo bat deskargatutako datuen tratamenduari dagokio. Orain, kokapen-estatistika berriak iristen direnean, neurketak berriro kalkulatzeko fase anitzeko prozesu bat abiarazten da, eta, besteak beste, datu gordinak kargatu, gune bakoitzeko neurketa agregatuak kalkulatu, iturri ezberdinetako datuak elkarren artean alderatuz eta kanpainaren laburpen-neurriak kalkulatzen ditu. Horrek kalkulu guztiak egiten dituen web aplikazioan karga handia eragiten du. Hainbat aldiz, birkalkulatzeko prozesuan, aplikazioak zerbitzariko memoria guztia kontsumitzen zuen, 10-15 GB ingurukoa, eta horrek izan zuen eragin kaltegarriena erabiltzaileen sistemarekin lanean.
Identifikatutako arazoek eta produktua gehiago garatzeko asmo handiko planek aplikazioen arkitektura birplanteatu beharra ekarri gintuzten.
Konektoreekin hasi ginen.
Konektore guztiek eredu beraren arabera funtzionatzen dutela ohartu ginen, beraz, kanalizazio-esparru bat eraiki genuen eta bertan konektore bat sortzeko urratsen logika soilik programatu behar zen, gainerakoa unibertsala zen. Konektoreren batek hobekuntza behar badu, berehala marko berri batera transferituko dugu, konektorea hobetzen ari den aldi berean.
Aldi berean, Docker eta Kubernetes-en konektoreak zabaltzen hasi ginen.
Denbora luzez Kubernetesera mugitzea aurreikusi genuen, CI/CD ezarpenekin esperimentatu genuen, baina konektore batek akats baten ondorioz zerbitzarian 20 GB memoria baino gehiago jaten hasi zenean bakarrik hasi ginen mugitzen, beste prozesu batzuk ia hiltzen hasi zirenean. . Ikerketan zehar, konektorea Kubernetes kluster batera eraman zuten, azkenean bertan geratu zen, akatsa konpondu ondoren ere.
Azkar konturatu ginen Kubernetes erosoa zela, eta sei hilabeteren buruan baliabide gehien kontsumitzen dituzten 7 konektore eta konektore proxy transferitu genituen ekoizpen-klusterera.
Konektoreei jarraituz, gainerako aplikazioen arkitektura aldatzea erabaki dugu.
Arazo nagusia zen datuak lote handietan konektoreetatik proxyetara iristen direla, eta gero DANBoID-era jotzen dutela eta web aplikazio zentralera bidaltzen direla prozesatzeko. Metrikoen birkalkulatze kopuru handia dela eta, karga handia dago aplikazioan.
Era berean, nahiko zaila izan da datu-bilketa lanen egoera kontrolatzea eta konektoreen barruan gertatzen diren akatsak jakinaraztea web-aplikazio zentral batera, erabiltzaileek zer gertatzen ari zen eta datuak zergatik ez ziren biltzen ikus zezaten.
Arazo hauek konpontzeko, arkitektura 2.0 garatu dugu.
Arkitekturaren bertsio berriaren desberdintasun nagusia da Web APIaren ordez RabbitMQ eta MassTransit liburutegia erabiltzen ditugula zerbitzuen artean mezuak trukatzeko. Horretarako, Connectors Proxy ia guztiz berridatzi behar izan dugu, Connectors Hub bihurtuz. Izena aldatu egin zen, zerbitzuaren eginkizun nagusia jada ez baita konektoreetara eskaerak birbidaltzea eta atzera egitea, konektoreen neurketen bilketa kudeatzea baizik.
Web-aplikazio zentraletik, guneetako kokapenei eta estatistikei buruzko informazioa zerbitzu bereizietan banatu genuen, eta, horri esker, beharrezkoak ez diren birkalkulaketak kentzea eta lehendik kalkulatutako eta agregatutako estatistikak soilik gordetzea ahalbidetu zuen kokapen mailan. Era berean, datu gordinetan oinarritutako oinarrizko estatistikak kalkulatzeko logika berridatzi eta optimizatu dugu.
Aldi berean, zerbitzu eta aplikazio guztiak Docker eta Kubernetesera migratzen ari gara, irtenbidea eskalatzeko eta kudeatzeko erosoagoa izan dadin.
Non gaude orain
Proof-of-concept arkitektura 2.0 produktua D1.Digitala prest eta konektore multzo mugatu batekin proba-ingurunean lan egiteko. Egin behar dena da beste 20 konektore berridaztea plataforma berri batera, datuak behar bezala kargatuta daudela eta neurketa guztiak behar bezala kalkulatuta daudela probatzea eta diseinu osoa ekoizpenera zabaltzea.
Izan ere, prozesu hau pixkanaka-pixkanaka gertatuko da eta API zaharrekin atzerako bateragarritasuna utzi beharko dugu dena funtzionatzen jarraitzeko.
Gure berehalako planak konektore berrien garapena, sistema berriekin integratzea eta konektaturiko guneetatik eta iragarki-sistemetatik deskargatutako datu multzoari metrika gehigarriak gehitzea dira.
Gainera, aplikazio guztiak Docker eta Kubernetesera transferitzeko asmoa dugu, web aplikazio zentrala barne. Arkitektura berriarekin batera, kontsumitutako baliabideen hedapena, jarraipena eta kontrola nabarmen erraztuko dira.
Beste ideia bat estatistikak gordetzeko datu-basearen aukeraketarekin esperimentatzea da, gaur egun MongoDB-n gordetzen dena. Dagoeneko hainbat konektore berri transferitu ditugu SQL datu-baseetara, baina hor aldea ia nabariezina da, eta eguneko estatistika agregatuetarako, aldi arbitrario baterako eska daitezkeenak, irabazia nahiko larria izan daiteke.
Oro har, planak itzelak dira, goazen aurrera :)
I+D Dentsu Aegis Network Russia artikuluaren egileak: Georgy Ostapenko (), Mikhail Kotsik ()
Iturria: www.habr.com