Úgy tűnik, hogy az online reklámozásnak technológiailag a lehető legfejlettebbnek és automatizáltabbnak kell lennie. Persze, mert olyan óriások és szakterületük szakértői dolgoznak ott, mint a Yandex, a Mail.Ru, a Google és a Facebook. De mint kiderült, a tökéletességnek nincs határa, és mindig van mit automatizálni.
Kommunikációs csoport Dentsu Aegis Network Oroszország a digitális hirdetési piac legnagyobb szereplője, és aktívan fektet be a technológiába, igyekszik optimalizálni és automatizálni üzleti folyamatait. Az online hirdetési piac egyik megoldatlan problémája a különböző internetes platformokon zajló reklámkampányok statisztikai gyűjtése. A probléma megoldása végül egy termék létrehozását eredményezte D1.Digitális (olvasható: DiVan), amelynek fejlesztéséről szeretnénk beszélni.
Miért?
1. A projekt indulásakor egyetlen olyan kész termék sem volt a piacon, amely megoldotta volna a reklámkampányokra vonatkozó statisztikai adatok gyűjtésének automatizálását. Ez azt jelenti, hogy rajtunk kívül senki sem fogja kielégíteni szükségleteinket.
Az olyan szolgáltatások, mint az Improvado, a Roistat, a Supermetrics, a SegmentStream integrációt kínálnak a platformokkal, a közösségi hálózatokkal és a Google Analitycs szolgáltatással, valamint lehetővé teszik analitikai irányítópultok létrehozását a hirdetési kampányok kényelmes elemzéséhez és vezérléséhez. Mielőtt elkezdtük volna termékünket fejleszteni, megpróbáltunk ezen rendszerek némelyikével adatokat gyűjteni az oldalakról, de sajnos nem tudták megoldani a problémáinkat.
A fő probléma az volt, hogy a tesztelt termékek adatforrásokra épültek, webhelyenként jelenítették meg az elhelyezési statisztikákat, és nem biztosítottak a reklámkampányok összesítésének lehetőségét. Ez a megközelítés nem tette lehetővé, hogy egy helyen lássuk a különböző oldalak statisztikáit, és elemezzük a kampány egészének állapotát.
További tényező volt, hogy a termékek kezdeti szakaszában a nyugati piacra irányultak, és nem támogatták az oroszországi telephelyekkel való integrációt. Azokon a webhelyeken, amelyekkel az integrációt megvalósították, nem mindig töltötték le kellő részletességgel az összes szükséges mérőszámot, és az integráció sem volt mindig kényelmes és átlátható, különösen akkor, ha olyat kellett szerezni, ami nincs a rendszer felületén.
Általában úgy döntöttünk, hogy nem alkalmazkodunk harmadik fél termékeihez, hanem elkezdtük fejleszteni a saját...
2. Az online hirdetési piac évről évre növekszik, és 2018-ban a hirdetési költségvetéseket tekintve megelőzte a hagyományosan legnagyobb tévés reklámpiacot. Tehát van mérleg.
3. A televíziós reklámpiactól eltérően, ahol a kereskedelmi reklámok értékesítése monopolhelyzetben van, az interneten sok különböző méretű reklámkészlet egyéni tulajdonosa működik saját hirdetési fiókkal. Mivel egy hirdetési kampány általában több webhelyen fut egyszerre, a hirdetési kampány állapotának megértéséhez jelentéseket kell gyűjteni az összes webhelyről, és össze kell őket foglalni egy nagy jelentésben, amely megmutatja a teljes képet. Ez azt jelenti, hogy van lehetőség az optimalizálásra.
4. Számunkra úgy tűnt, hogy az internetes hirdetési készletek tulajdonosai már rendelkeznek a statisztikák gyűjtéséhez és hirdetési fiókokban való megjelenítéséhez szükséges infrastruktúrával, és ezekhez az adatokhoz API-t tudnak majd biztosítani. Ez azt jelenti, hogy technikailag megvalósítható. Mondjuk rögtön, hogy kiderült, nem is olyan egyszerű.
Általánosságban elmondható, hogy a projekt megvalósításának minden előfeltétele nyilvánvaló volt számunkra, és rohantunk, hogy életre keltsük a projektet...
Nagy terv
Először egy ideális rendszer vízióját alkottuk meg:
- Az 1C vállalati rendszerből származó reklámkampányokat automatikusan be kell tölteni nevükkel, időszakaikkal, költségvetésükkel és elhelyezéseikkel a különböző platformokon.
- A hirdetési kampányon belüli minden egyes elhelyezéshez automatikusan le kell tölteni az összes lehetséges statisztikát azokról a webhelyekről, ahol az elhelyezés történik, például a megjelenítések, kattintások, megtekintések száma stb.
- Egyes reklámkampányokat harmadik fél általi megfigyeléssel követnek nyomon úgynevezett hirdetőrendszerek, mint például az Adriver, a Weborama, a DCM stb. Oroszországban is van ipari internetmérő - a Mediascope cég. Terveink szerint a független és ipari monitoring adatait is automatikusan be kell tölteni a megfelelő reklámkampányokba.
- A legtöbb internetes hirdetési kampány bizonyos célműveletekre irányul (vásárlás, hívás, regisztráció próbaútra stb.), amelyeket a Google Analytics segítségével nyomon követnek, és amelyek statisztikái szintén fontosak a kampány állapotának megértéséhez, ill. be kell tölteni az eszközünkbe.
Az első palacsinta lumpy
Tekintettel a szoftverfejlesztés rugalmas elvei iránti elkötelezettségünkre (agilis, minden), úgy döntöttünk, hogy először egy MVP-t fejlesztünk, majd ismételten haladunk a kitűzött cél felé.
Úgy döntöttünk, hogy a termékünk alapján építjük meg az MVP-t DANBo (Dentsu Aegis hálózati tábla), amely egy webes alkalmazás, amely általános információkat tartalmaz ügyfeleink hirdetési kampányairól.
Az MVP esetében a projekt a lehető legnagyobb mértékben leegyszerűsödött a megvalósítás szempontjából. A platformok korlátozott listáját választottuk ki az integrációhoz. Ezek voltak a fő platformok, mint például a Yandex.Direct, a Yandex.Display, az RB.Mail, a MyTarget, az Adwords, a DBM, a VK, az FB, valamint a fő hirdetési rendszerek, az Adriver és a Weborama.
A webhelyek statisztikáinak API-n keresztüli eléréséhez egyetlen fiókot használtunk. Egy ügyfélcsoport-menedzsernek, aki egy hirdetési kampányra vonatkozóan automatikus statisztikagyűjtést akart használni, először delegálnia kellett a platformfiók számára a webhelyek szükséges hirdetési kampányaihoz való hozzáférést.
A következő a rendszer felhasználója DANBo fel kellett töltenie egy bizonyos formátumú fájlt az Excel rendszerbe, amely minden információt tartalmazott az elhelyezésről (reklámkampány, platform, formátum, elhelyezési időszak, tervezett indikátorok, költségvetés stb.) és a megfelelő reklámkampányok azonosítóit. helyek és pultok a hirdetőrendszerekben.
Őszintén szólva ijesztően nézett ki:
A letöltött adatok adatbázisba kerültek, majd külön szolgáltatások gyűjtötték be róluk az oldalakon a kampányazonosítókat, és töltöttek le róluk statisztikákat.
Minden oldalhoz külön windows szolgáltatást írtak, amely naponta egyszer egy szolgáltatás fiók alá ment az oldal API-jában és letöltötte a statisztikát a megadott kampányazonosítókhoz. Ugyanez történt a hirdetőrendszerekkel is.
A letöltött adatok egy kis egyedi műszerfal formájában jelennek meg a felületen:
Számunkra váratlanul az MVP elkezdett dolgozni, és elkezdte letölteni az internetes hirdetési kampányok aktuális statisztikáit. A rendszert több kliensre is telepítettük, de a méretezés során komoly problémákba ütköztünk:
- A fő probléma az adatok rendszerbe történő betöltésére való előkészítésének bonyolultsága volt. Ezenkívül az elhelyezési adatokat szigorúan rögzített formátumba kellett konvertálni a betöltés előtt. Szükséges volt a különböző webhelyekről származó entitásazonosítók szerepeltetése a letöltési fájlban. Szembesülünk azzal a ténnyel, hogy a technikailag képzetlen felhasználók nagyon nehezen tudják megmagyarázni, hogy az oldalon hol találják meg ezeket az azonosítókat, és hova kell a fájlba bevinni. Figyelembe véve a telephelyeken kampányoló részlegek létszámát és a forgalmat, ez óriási támogatást eredményezett oldalunkon, amivel egyáltalán nem voltunk elégedettek.
- A másik probléma az volt, hogy nem minden hirdetési platform rendelkezik olyan mechanizmussal, amely a hirdetési kampányokhoz való hozzáférést más fiókokra ruházta át. De még ha rendelkezésre is állt volna a delegálási mechanizmus, nem minden hirdető volt hajlandó hozzáférést adni kampányaihoz harmadik felek fiókjainak.
- Fontos tényező volt a felhasználók felháborodása, amelyet az a tény váltott ki, hogy minden tervezett mutatót és elhelyezési részletet, amelyet már bevezetnek az 1C könyvelési rendszerünkbe, újra be kell írniuk. DANBo.
Ez adta az ötletet, hogy az elhelyezéssel kapcsolatos elsődleges információforrás az 1C rendszerünk legyen, amelybe minden adat pontosan és időben kerül be (a lényeg itt az, hogy a számlák az 1C adatok alapján készülnek, tehát az adatok helyes bevitele az 1C-be mindenki számára kiemelt fontosságú KPI). Így alakult ki a rendszer új koncepciója...
koncepció
Az első dolog, amit megtettünk, az volt, hogy az internetes reklámkampányok statisztikáit gyűjtő rendszert külön termékre különítjük el - D1.Digitális.
Az új koncepcióban úgy döntöttünk, hogy betöltünk D1.Digitális információkat kaphat a hirdetési kampányokról és az azokon belüli elhelyezésekről az 1C-ből, majd lekérheti a statisztikákat a webhelyekről és az AdServing rendszerekről ezekre az elhelyezésekre. Ennek az volt a célja, hogy jelentősen leegyszerűsítse a felhasználók életét (és szokás szerint több munkát adjon a fejlesztőknek), és csökkentse a támogatás mértékét.
Az első probléma, amellyel találkoztunk, szervezeti jellegű volt, és azzal kapcsolatos, hogy nem találtunk kulcsot vagy jelet, amellyel összehasonlíthatnánk a különböző rendszerek entitásait az 1C kampányaival és elhelyezéseivel. Az a helyzet, hogy cégünknél a folyamat úgy van kialakítva, hogy a reklámkampányokat más-más rendszerbe más-más emberek (médiatervezők, vásárlás stb.) viszik be.
A probléma megoldásához fel kellett találnunk egy egyedi kivonatolt kulcsot, a DANBoID-t, amely összekapcsolja a különböző rendszerek entitásait, és amely meglehetősen könnyen és egyedileg azonosítható a letöltött adatkészletekben. Ez az azonosító a belső 1C rendszerben jön létre minden egyes elhelyezéshez, és átkerül a kampányokhoz, elhelyezésekhez és számlálókhoz az összes webhelyen és az összes hirdetéskiszolgáló rendszerben. Annak a gyakorlatnak a megvalósítása, hogy a DANBoID minden elhelyezésre kerüljön, eltartott egy ideig, de sikerült :)
Aztán rájöttünk, hogy nem minden webhely rendelkezik API-val az automatikus statisztikai adatok gyűjtésére, és még azokon sem, amelyeknek van API, az nem ad vissza minden szükséges adatot.
Ebben a szakaszban úgy döntöttünk, hogy jelentősen csökkentjük az integrációs platformok listáját, és azokra a fő platformokra összpontosítunk, amelyek a hirdetési kampányok túlnyomó többségében részt vesznek. Ezen a listán megtalálhatók a hirdetési piac (Google, Yandex, Mail.ru), a közösségi hálózatok (VK, Facebook, Twitter), a fő AdServing és elemző rendszerek (DCM, Adriver, Weborama, Google Analytics) és más platformok összes legnagyobb szereplője.
Az általunk kiválasztott webhelyek többsége rendelkezett olyan API-val, amely biztosította a szükséges mutatókat. Azokban az esetekben, amikor nem volt API, vagy nem tartalmazta a szükséges adatokat, az irodai e-mailünkre naponta küldött jelentéseket használtuk az adatok betöltésére (egyes rendszerekben lehetőség van ilyen riportok konfigurálására, másokban megegyeztünk ilyen riportok kidolgozásában nekünk).
A különböző helyekről származó adatok elemzésekor azt találtuk, hogy az entitások hierarchiája nem azonos a különböző rendszerekben. Sőt, a különböző rendszerekről eltérő részletességgel kell letölteni az információkat.
A probléma megoldására fejlesztették ki a SubDANBoID koncepciót. A SubDANBoID ötlete meglehetősen egyszerű, a generált DANBoID-vel megjelöljük a kampány fő entitását az oldalon, és az összes beágyazott entitást egyedi webhelyazonosítókkal feltöltjük, és a DANBoID elv + első szint azonosítója szerint SubDANBoID-t alkotunk. beágyazott entitás + a második szintű beágyazott entitás azonosítója +... Ez a megközelítés lehetővé tette, hogy különböző rendszerekben összekapcsoljuk a hirdetési kampányokat, és részletes statisztikákat töltsünk le azokról.
Meg kellett oldanunk a különböző platformokon folyó kampányokhoz való hozzáférés problémáját is. Ahogy fentebb írtuk, a kampányhoz való hozzáférés külön technikai fiókra delegálásának mechanizmusa nem mindig alkalmazható. Ezért ki kellett fejlesztenünk egy infrastruktúrát az OAuth-on keresztüli automatikus engedélyezéshez, tokenekkel és a tokenek frissítésére szolgáló mechanizmusokkal.
A cikk későbbi részében megpróbáljuk részletesebben leírni a megoldás architektúráját és a megvalósítás technikai részleteit.
Megoldás architektúra 1.0
Egy új termék bevezetésének megkezdésekor megértettük, hogy azonnal biztosítani kell az új telephelyek összekapcsolásának lehetőségét, ezért úgy döntöttünk, hogy a mikroszolgáltatási architektúra útját követjük.
Az architektúra kialakítása során az összes külső rendszerhez – 1C, reklámplatformokhoz és hirdetési rendszerekhez – kapcsolódó csatlakozókat külön szolgáltatásokba különítettük el.
A fő ötlet az, hogy a webhelyekhez vezető összes csatlakozó ugyanazzal az API-val rendelkezik, és olyan adapterek, amelyek a webhely API-t egy számunkra kényelmes felületre hozzák.
Termékünk középpontjában egy webes alkalmazás áll, amely egy olyan monolit, amelyet úgy alakítottak ki, hogy könnyen szétszedhető legyen szolgáltatásokká. Ez az alkalmazás felelős a letöltött adatok feldolgozásáért, a különböző rendszerek statisztikáinak összegyűjtéséért és a rendszer felhasználóinak történő bemutatásáért.
A csatlakozók és a webalkalmazás közötti kommunikációhoz egy kiegészítő szolgáltatást kellett létrehoznunk, amit Connector Proxynak neveztünk el. Ellátja a szolgáltatáskeresés és a feladatütemező funkcióit. Ez a szolgáltatás minden egyes csatlakozóhoz adatgyűjtési feladatokat futtat minden este. A szolgáltatási réteg megírása egyszerűbb volt, mint egy üzenetközvetítő csatlakoztatása, és számunkra fontos volt, hogy a lehető leggyorsabban megkapjuk az eredményt.
Az egyszerűség és a fejlesztés gyorsasága érdekében úgy döntöttünk, hogy minden szolgáltatás webes API lesz. Ez lehetővé tette, hogy gyorsan összeállítsunk egy koncepciót, és ellenőrizzük, hogy a teljes terv működik.
Külön, meglehetősen összetett feladatot jelentett a hozzáférés beállítása a különböző fiókokról történő adatgyűjtéshez, amelyet döntésünk szerint a felhasználóknak a webes felületen keresztül kell végrehajtaniuk. Ez két külön lépésből áll: először a felhasználó egy tokent ad hozzá a fiókhoz az OAuth-on keresztül történő hozzáféréshez, majd konfigurálja az ügyfél adatgyűjtését egy adott fiókból. Az OAuth-on keresztüli token beszerzése azért szükséges, mert ahogy már írtuk, nem mindig lehet a kívánt fiókhoz hozzáférést delegálni az oldalon.
Ahhoz, hogy egy univerzális mechanizmust hozzunk létre a fiókok webhelyek közül való kiválasztásához, hozzá kellett adnunk egy metódust az összekötők API-jához, amely visszaadja a JSON-sémát, amelyet egy módosított JSONEditor komponens használatával űrlapmá renderelünk. Így a felhasználók kiválaszthatták, hogy melyik fiókból töltsék le az adatokat.
A webhelyeken meglévő kérési korlátok betartása érdekében a beállításokra vonatkozó kéréseket egy tokenen belül egyesítjük, de párhuzamosan különböző tokeneket is feldolgozhatunk.
A MongoDB-t választottuk a webalkalmazás és a csatlakozók betöltött adatainak tárolására, ami lehetővé tette, hogy ne aggódjunk túl sokat az adatszerkezet miatt a fejlesztés kezdeti szakaszában, amikor az alkalmazás objektummodellje kétnaponta változik.
Hamar rájöttünk, hogy nem minden adat fér el jól a MongoDB-ben, és például kényelmesebb a napi statisztikákat relációs adatbázisban tárolni. Ezért azoknál a csatlakozóknál, amelyek adatstruktúrája alkalmasabb relációs adatbázishoz, elkezdtük a PostgreSQL vagy az MS SQL Server használatát tárolóként.
A választott architektúra és technológiák lehetővé tették a D1.Digital termék viszonylag gyors megépítését és elindítását. A két év termékfejlesztés során 23 webhelyhez vezető összekötőt fejlesztettünk ki, felbecsülhetetlen tapasztalatot szereztünk a harmadik fél API-kkal való munka során, megtanultuk elkerülni a különböző webhelyek buktatóit, amelyek mindegyikének megvolt a maga sajátja, hozzájárultunk a legalább 3 API fejlesztéséhez. oldalak, csaknem 15 000 kampányról és több mint 80 000 elhelyezésről töltöttek le automatikusan információkat, rengeteg visszajelzést gyűjtöttek be a felhasználóktól a termék működéséről, és e visszajelzések alapján sikerült többször megváltoztatni a termék fő folyamatát.
Megoldás architektúra 2.0
Két év telt el a fejlesztés kezdete óta D1.Digitális. A rendszer terhelésének folyamatos növekedése és az egyre több új adatforrás megjelenése fokozatosan feltárta a meglévő megoldási architektúra problémáit.
Az első probléma az oldalakról letöltött adatok mennyiségével kapcsolatos. Szembesültünk azzal a ténnyel, hogy az összes szükséges adat összegyűjtése és frissítése a legnagyobb oldalakról túl sok időt vett igénybe. Például az AdRiver hirdetési rendszerből való adatgyűjtés, amellyel a legtöbb elhelyezés statisztikáit követjük, körülbelül 12 órát vesz igénybe.
Ennek a problémának a megoldására elkezdtünk mindenféle riportot használni az oldalak adatainak letöltésére, igyekszünk az oldalakkal együtt fejleszteni azok API-ját, hogy működési sebessége megfeleljen az igényeinknek, illetve az adatletöltést lehetőség szerint párhuzamosítani.
Egy másik probléma a letöltött adatok feldolgozásával kapcsolatos. Most, amikor új elhelyezési statisztikák érkeznek, elindul a mutatók újraszámításának többlépcsős folyamata, amely magában foglalja a nyers adatok betöltését, az egyes webhelyek összesített mutatóinak kiszámítását, a különböző forrásokból származó adatok összehasonlítását és a kampány összesítő mutatóinak kiszámítását. Ez nagy terhelést okoz az összes számítást elvégző webalkalmazáson. Az újraszámítás során többször előfordult, hogy az alkalmazás a szerver teljes memóriáját, körülbelül 10-15 GB-ot felemésztette, ami a felhasználók rendszerrel végzett munkájára volt a legrosszabb.
Az azonosított problémák és a termék továbbfejlesztésére vonatkozó ambiciózus tervek arra késztettek bennünket, hogy átgondoljuk az alkalmazás architektúráját.
A csatlakozókkal kezdtük.
Észrevettük, hogy minden csatlakozó ugyanazon modell szerint működik, ezért építettünk egy pipeline keretrendszert, amelyben a csatlakozó létrehozásához csak a lépések logikáját kellett programozni, a többi univerzális volt. Ha valamelyik csatlakozó fejlesztésre szorul, akkor a csatlakozó fejlesztésével egy időben azonnal átvisszük egy új keretrendszerbe.
Ezzel egy időben megkezdtük a csatlakozók telepítését a Docker és a Kubernetes számára.
Elég sokáig terveztük a Kubernetesre való átállást, kísérleteztünk a CI/CD beállításokkal, de csak akkor indultunk el, amikor az egyik csatlakozó egy hiba miatt több mint 20 GB memóriát kezdett felemészteni a szerveren, gyakorlatilag megölve a többi folyamatot. . A vizsgálat során a csatlakozó egy Kubernetes-fürtbe került, ahol végül a hiba kijavítása után is megmaradt.
Elég hamar rájöttünk, hogy a Kubernetes kényelmes, és hat hónapon belül 7 csatlakozót és a legtöbb erőforrást fogyasztó Connectors Proxyt átvittük a termelési klaszterbe.
A csatlakozókat követően úgy döntöttünk, hogy megváltoztatjuk az alkalmazás többi részének architektúráját.
A fő probléma az volt, hogy az adatok nagy kötegekben érkeznek a csatlakozóktól a proxykhoz, majd elérik a DANBoID-t, és a központi webalkalmazásba kerülnek feldolgozásra. A mérőszámok újraszámításainak nagy száma miatt az alkalmazás nagy terhelést jelent.
Meglehetősen nehéznek bizonyult az egyes adatgyűjtési feladatok állapotának nyomon követése és a csatlakozókon belül fellépő hibák jelentése egy központi webes alkalmazásnak, hogy a felhasználók láthassák, mi történik, és miért nem gyűjtenek adatokat.
E problémák megoldására kifejlesztettük a 2.0 architektúrát.
A fő különbség az architektúra új verziója között, hogy a webes API helyett a RabbitMQ-t és a MassTransit könyvtárat használjuk a szolgáltatások közötti üzenetváltásra. Ehhez szinte teljesen át kellett írnunk a Connectors Proxyt, így lett Connectors Hub. A név azért változott meg, mert a szolgáltatás fő szerepe már nem a kérések továbbítása a csatlakozókra és vissza, hanem az összekötőktől származó metrikák gyűjtésének kezelése.
A központi webalkalmazásból külön szolgáltatásokba különítettük el az oldalak elhelyezési és statisztikai adatait, ami lehetővé tette, hogy megszabaduljunk a felesleges újraszámításoktól, és elhelyezési szinten csak a már kiszámított és összesített statisztikákat tároljuk. Átírtuk és optimalizáltuk a nyers adatokon alapuló alapvető statisztikák kiszámításának logikáját is.
Ezzel egyidejűleg minden szolgáltatást és alkalmazást áttelepítünk a Docker és a Kubernetes rendszerbe, hogy a megoldást könnyebben méretezhető és kényelmesebben kezelhető legyen.
Hol tartunk most
Proof-of-concept architektúra 2.0 termék D1.Digitális készen áll és működik tesztkörnyezetben korlátozott számú csatlakozóval. Nem kell mást tenni, mint átírni további 20 csatlakozót egy új platformra, tesztelni, hogy az adatok megfelelően vannak-e betöltve, és minden mérőszám helyesen van-e kiszámítva, és a teljes tervet gyártásba kell helyezni.
Valójában ez a folyamat fokozatosan fog megtörténni, és meg kell hagynunk a visszafelé kompatibilitást a régi API-kkal, hogy minden működjön.
Közvetlen terveink között szerepel új csatlakozók fejlesztése, új rendszerekkel való integráció, valamint további mérőszámok hozzáadása a kapcsolódó oldalakról és hirdetőrendszerekről letöltött adatokhoz.
Terveink szerint az összes alkalmazást, beleértve a központi webalkalmazást is, áthelyezzük a Docker és a Kubernetes rendszerbe. Az új architektúrával kombinálva ez jelentősen leegyszerűsíti az elhasznált erőforrások telepítését, felügyeletét és ellenőrzését.
Egy másik ötlet az, hogy kísérletezzen a statisztikák tárolására szolgáló adatbázis kiválasztásával, amelyet jelenleg a MongoDB tárol. Több új csatlakozót is átvittünk már SQL adatbázisokba, de ott szinte észrevehetetlen a különbség, és a napi összesített, tetszőleges időszakra kérhető statisztikánál igen komoly lehet a nyereség.
Összességében nagyszabásúak a tervek, menjünk tovább :)
A cikk szerzői: K+F Dentsu Aegis Network Russia: Georgij Ostapenko (), Mikhail Kotsik ()
Forrás: will.com