Katon yen bidang iklan online kudu maju kanthi teknologi lan otomatis sabisa. Mesthine, amarga raksasa lan ahli ing lapangan kaya Yandex, Mail.Ru, Google lan Facebook kerja ing kana. Nanging, ternyata, ora ana watesan kanggo kesempurnaan lan mesthi ana sing bisa diotomatisasi.
Grup komunikasi Dentsu Aegis Network Rusia minangka pemain paling gedhe ing pasar iklan digital lan aktif nandur modal ing teknologi, nyoba ngoptimalake lan ngotomatisasi proses bisnis. Salah sawijining masalah pasar iklan online sing durung rampung yaiku tugas ngumpulake statistik kampanye iklan saka platform Internet sing beda-beda. Solusi kanggo masalah iki pungkasane nyebabake nggawe produk D1. Digital (diwaca minangka DiVan), pangembangan sing arep dirembug.
Kenapa?
1. Ing wektu wiwitan proyek, ora ana siji-sijine produk sing wis siap ing pasar sing ngrampungake masalah ngotomatisasi koleksi statistik ing kampanye iklan. Iki tegese ora ana wong liya kajaba awake dhewe sing bakal nyukupi kabutuhan kita.
Layanan kayata Improvado, Roistat, Supermetrics, SegmentStream nawakake integrasi karo platform, jaringan sosial lan Google Analitycs, lan uga nggawe dashboard analitis kanggo analisis sing trep lan kontrol kampanye iklan. Sadurunge miwiti ngembangake produk, kita nyoba nggunakake sawetara sistem kasebut kanggo ngumpulake data saka situs, nanging, sayangé, ora bisa ngatasi masalah kita.
Masalah utama yaiku produk sing diuji gumantung ing sumber data, nampilake statistik penempatan miturut situs, lan ora nyedhiyakake kemampuan kanggo nggabungake statistik ing kampanye iklan. Pendekatan iki ora ngidini kita ndeleng statistik saka macem-macem situs ing sak panggonan lan nganalisa kahanan kampanye kanthi sakabehe.
Faktor liyane yaiku yen ing tahap awal produk kasebut dituju ing pasar Kulon lan ora ndhukung integrasi karo situs Rusia. Lan kanggo situs sing integrasi wis dileksanakake, kabeh metrik sing dibutuhake ora tansah diundhuh kanthi rinci sing cukup, lan integrasi ora tansah trep lan transparan, utamane yen perlu kanggo njaluk soko sing ora ana ing antarmuka sistem.
Umumé, kita mutusake ora adaptasi karo produk pihak katelu, nanging wiwit ngembangake produk kita dhewe ...
2. Pasar pariwara online tuwuh saka taun-taun, lan ing taun 2018, ing babagan anggaran pariwara, ngluwihi pasar iklan TV sing paling gedhe sacara tradisional. Dadi ana skala.
3. Ora kaya pasar iklan TV, ing ngendi dodolan iklan komersial dimonopoli, ana akeh pamilik individu saka inventarisasi iklan saka macem-macem ukuran sing beroperasi ing Internet kanthi akun iklan dhewe. Wiwit kampanye iklan, minangka aturan, mlaku ing sawetara situs bebarengan, kanggo mangerteni kahanan kampanye iklan, perlu kanggo ngumpulake laporan saka kabeh situs lan gabungke dadi siji laporan gedhe sing bakal nuduhake kabeh gambar. Iki tegese ana potensial kanggo optimasi.
4. Iku ketoke kanggo kita sing nduweni inventarisasi iklan ing Internet wis duwe infrastruktur kanggo ngumpulake statistik lan nampilake ing akun iklan, lan padha bakal bisa kanggo nyedhiyani API kanggo data iki. Iki tegese teknis bisa ditindakake. Ayo langsung ngomong yen ternyata ora gampang banget.
Umumé, kabeh prasyarat kanggo implementasine proyek kasebut jelas kanggo kita, lan kita mlayu supaya proyek kasebut bisa urip ...
Rencana gedhe
Kanggo miwiti, kita nggawe visi sistem ideal:
- Kampanye iklan saka sistem perusahaan 1C kudu diisi kanthi otomatis kanthi jeneng, periode, anggaran lan penempatan ing macem-macem platform.
- Kanggo saben panggonan ing kampanye iklan, kabeh statistik sing bisa diundhuh kanthi otomatis saka situs ing ngendi panggonan kasebut ditindakake, kayata jumlah tayangan, klik, tampilan, lsp.
- Sawetara kampanye iklan dilacak nggunakake pemantauan pihak katelu kanthi sistem adserving kayata Adriver, Weborama, DCM, lsp. Ana uga meter Internet industri ing Rusia - perusahaan Mediascope. Miturut rencana kita, data saka pemantauan independen lan industri uga kudu dimuat kanthi otomatis menyang kampanye iklan sing cocog.
- Umume kampanye iklan ing Internet ngarahake tumindak target tartamtu (tuku, nelpon, ndhaptar test drive, lan liya-liyane), sing dilacak nggunakake Google Analytics, lan statistik sing uga penting kanggo mangerteni status kampanye lan kudu dimuat menyang alat kita.
Kaping pisanan yaiku gumpalan
Amarga komitmen kita marang prinsip pangembangan piranti lunak sing fleksibel (lincah, kabeh perkara), kita mutusake kanggo ngembangake MVP dhisik lan banjur pindhah menyang tujuan sing dituju kanthi iteratif.
Kita mutusake kanggo mbangun MVP adhedhasar produk kita DANBo (Papan Jaringan Dentsu Aegis), yaiku aplikasi web kanthi informasi umum babagan kampanye iklan klien kita.
Kanggo MVP, proyek kasebut disederhanakake sabisa ing babagan implementasine. Kita wis milih dhaptar platform winates kanggo integrasi. Iki minangka platform utama, kayata Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, lan sistem iklan utama Adriver lan Weborama.
Kanggo ngakses statistik ing situs liwat API, kita nggunakake akun siji. Manajer grup klien sing pengin nggunakake koleksi statistik otomatis ing kampanye iklan kudu utusan akses menyang kampanye iklan sing dibutuhake ing situs menyang akun platform.
Sabanjure yaiku pangguna sistem DANBo kudu ngunggah file kanthi format tartamtu menyang sistem Excel, sing ngemot kabeh informasi babagan penempatan (kampanye iklan, platform, format, periode penempatan, indikator sing direncanakake, anggaran, lan sapiturute) lan pengenal kampanye iklan sing cocog ing situs lan counter ing sistem iklan.
Iku katon, terus terang, medeni:
Data sing diundhuh disimpen ing basis data, banjur layanan kapisah nglumpukake pengenal kampanye ing situs kasebut lan ndownload statistik kasebut.
Kanggo saben situs, layanan windows sing kapisah ditulis, sing sapisan dina mlebu ing siji akun layanan ing API situs lan ndownload statistik kanggo ID kampanye sing ditemtokake. Bab sing padha kedadeyan karo sistem iklan.
Data sing diundhuh ditampilake ing antarmuka ing wangun dashboard khusus cilik:
Ora sengaja kanggo kita, MVP wiwit kerja lan wiwit ngundhuh statistik saiki babagan kampanye iklan ing Internet. Kita ngetrapake sistem kasebut ing sawetara klien, nanging nalika nyoba skala, kita nemoni masalah serius:
- Masalah utama yaiku kerumitan nyiapake data kanggo dimuat menyang sistem. Uga, data panggonan kudu diowahi dadi format sing tetep sadurunge dimuat. Sampeyan kudu nyakup pengenal entitas saka macem-macem situs ing file undhuhan. Kita ngadhepi kasunyatan sing angel banget kanggo pangguna sing ora dilatih kanthi teknis kanggo nerangake ngendi nemokake pengenal kasebut ing situs kasebut lan ing ngendi file kasebut kudu dilebokake. Ngelingi jumlah karyawan ing departemen sing mbukak kampanye ing situs lan turnover, iki ngasilake akeh dhukungan ing sisih kita, sing pancen ora seneng.
- Masalah liyane yaiku ora kabeh platform iklan duwe mekanisme kanggo delegasi akses menyang kampanye iklan menyang akun liyane. Nanging sanajan mekanisme delegasi kasedhiya, ora kabeh pengiklan gelem menehi akses menyang kampanye menyang akun pihak katelu.
- Faktor penting yaiku nesu sing nyebabake para pangguna amarga kabeh indikator sing direncanakake lan rincian penempatan sing wis dilebokake ing sistem akuntansi 1C kita, kudu dilebokake maneh. DANBo.
Iki menehi kita idea yen sumber utama informasi babagan panggonan kudu sistem 1C kita, kang kabeh data wis ngetik kanthi akurat lan ing wektu (titik ing kene iku invoice sing digawe adhedhasar data 1C, supaya bener entri data menyang 1C. minangka prioritas kanggo kabeh KPI). Iki carane konsep anyar sistem muncul ...
Konsep
Babagan pisanan sing kita mutusake yaiku misahake sistem kanggo ngumpulake statistik kampanye iklan ing Internet dadi produk sing kapisah - D1. Digital.
Ing konsep anyar, kita mutusaké kanggo mbukak menyang D1. Digital informasi babagan kampanye iklan lan penempatan ing njero saka 1C, banjur tarik munggah statistik saka situs lan sistem AdServing menyang panggonan iki. Iki mesthine bakal nyederhanakake urip pangguna kanthi signifikan (lan, kaya biasane, nambah karya liyane kanggo pangembang) lan nyuda jumlah dhukungan.
Masalah pisanan sing ditemoni yaiku sifat organisasi lan ana hubungane karo kasunyatan sing ora bisa nemokake kunci utawa tandha sing bisa mbandhingake entitas saka sistem sing beda karo kampanye lan penempatan saka 1C. Kasunyatane yaiku proses ing perusahaan kita dirancang kanthi cara supaya kampanye iklan dilebokake ing sistem sing beda dening wong sing beda-beda (perencana media, tuku, lan liya-liyane).
Kanggo ngatasi masalah iki, kita kudu nggawe kunci hash unik, DANBoID, sing bakal ngubungake entitas ing sistem sing beda-beda bebarengan, lan bisa gampang diidentifikasi kanthi unik ing set data sing diundhuh. Pengenal iki digawe ing sistem 1C internal kanggo saben panggonan individu lan ditransfer menyang kampanye, panggonan lan counter ing kabeh situs lan ing kabeh sistem AdServing. Ngleksanakake praktik masang DANBoID ing kabeh penempatan butuh sawetara wektu, nanging kita bisa nindakake :)
Banjur kita ketemu metu sing ora kabeh situs duwe API kanggo otomatis ngumpulake statistik, lan malah sing duwe API, iku ora bali kabeh data perlu.
Ing tahap iki, kita mutusake kanggo nyuda kanthi signifikan dhaptar platform kanggo integrasi lan fokus ing platform utama sing melu ing mayoritas kampanye iklan. Dhaptar iki kalebu kabeh pemain paling gedhe ing pasar pariwara (Google, Yandex, Mail.ru), jaringan sosial (VK, Facebook, Twitter), sistem AdServing lan analytics utama (DCM, Adriver, Weborama, Google Analytics) lan platform liyane.
Mayoritas situs sing dipilih duwe API sing nyedhiyakake metrik sing dibutuhake. Ing kasus nalika ora ana API utawa ora ngemot data sing dibutuhake, kita nggunakake laporan sing dikirim saben dina menyang email kantor kanggo mbukak data (ing sawetara sistem bisa ngatur laporan kasebut, ing liyane kita setuju babagan pangembangan laporan kuwi kanggo kita).
Nalika nganalisa data saka macem-macem situs, kita nemokake manawa hierarki entitas ora padha ing sistem sing beda. Kajaba iku, informasi kudu diundhuh kanthi rinci saka macem-macem sistem.
Kanggo ngatasi masalah iki, konsep SubDANBoID dikembangake. Gagasan SubDANBoID cukup prasaja, kita menehi tandha entitas utama kampanye ing situs kasebut kanthi DANBoID sing digawe, lan kita ngunggah kabeh entitas nested kanthi pengenal situs unik lan mbentuk SubDANBoID miturut prinsip DANBoID + pengenal tingkat pertama. entitas bersarang + pengenal saka entitas bersarang tingkat kapindho +... Pendekatan iki ngidini kita nyambungake kampanye iklan ing sistem sing beda-beda lan ngundhuh statistik rinci babagan kasebut.
Kita uga kudu ngatasi masalah akses menyang kampanye ing macem-macem platform. Kaya sing kita tulis ing ndhuwur, mekanisme delegasi akses menyang kampanye menyang akun teknis sing kapisah ora mesthi ditrapake. Mulane, kita kudu ngembangake infrastruktur kanggo wewenang otomatis liwat OAuth nggunakake token lan mekanisme kanggo nganyari token kasebut.
Mengko ing artikel kita bakal nyoba kanggo njlèntrèhaké luwih rinci arsitektur solusi lan rincian technical saka implementasine.
Arsitektur solusi 1.0
Nalika miwiti implementasine saka produk anyar, kita mangertos bilih kita langsung perlu kanggo nyedhiyani kamungkinan kanggo nyambungake situs anyar, supaya kita mutusaké kanggo tindakake path arsitektur microservice.
Nalika ngrancang arsitektur, kita misahake konektor menyang kabeh sistem eksternal - 1C, platform iklan lan sistem iklan - dadi layanan sing kapisah.
Ide utama yaiku kabeh konektor menyang situs duwe API sing padha lan minangka adaptor sing nggawa API situs menyang antarmuka sing trep kanggo kita.
Ing tengah produk kita ana aplikasi web, yaiku monolit sing dirancang kanthi cara sing bisa gampang dibongkar dadi layanan. Aplikasi iki tanggung jawab kanggo ngolah data sing diundhuh, nglumpukake statistik saka macem-macem sistem lan nampilake menyang pangguna sistem.
Kanggo komunikasi antarane konektor lan aplikasi web, kita kudu nggawe layanan tambahan, sing disebut Connector Proxy. Iku nindakake fungsi Service Discovery lan Task Scheduler. Layanan iki nindakake tugas nglumpukake data kanggo saben konektor saben wengi. Nulis lapisan layanan luwih gampang tinimbang nyambungake makelar pesen, lan kanggo kita penting kanggo entuk asil kanthi cepet.
Kanggo kesederhanaan lan kacepetan pangembangan, kita uga mutusake yen kabeh layanan bakal dadi API Web. Iki ndadekake iku bisa kanggo cepet ngumpul bukti-of-konsep lan verifikasi sing kabeh desain bisa.
Tugas sing kapisah, rada rumit yaiku nyetel akses kanggo ngumpulake data saka akun sing beda-beda, sing, kaya sing kita mutusake, kudu ditindakake pangguna liwat antarmuka web. Iku kasusun saka rong langkah kapisah: pisanan, pangguna nambah token kanggo ngakses akun liwat OAuth, lan banjur ngatur koleksi data kanggo klien saka akun tartamtu. Entuk token liwat OAuth perlu amarga, kaya sing wis ditulis, ora mesthi bisa utusan akses menyang akun sing dikarepake ing situs kasebut.
Kanggo nggawe mekanisme universal kanggo milih akun saka situs, kita kudu nambah cara kanggo konektor API sing ngasilake JSON Schema, kang render menyang wangun nggunakake komponen JSONEditor dipunéwahi. Kanthi cara iki, pangguna bisa milih akun kanggo ngundhuh data.
Kanggo tundhuk karo watesan request sing ana ing situs, kita gabungke panjalukan kanggo setelan ing siji token, nanging kita bisa proses token beda podo karo.
Kita milih MongoDB minangka panyimpenan kanggo data sing dimuat kanggo aplikasi web lan konektor, sing ngidini kita ora kuwatir banget babagan struktur data ing tahap wiwitan pangembangan, nalika model obyek aplikasi diganti saben dina.
Kita langsung ngerteni manawa ora kabeh data cocog karo MongoDB lan, contone, luwih trep kanggo nyimpen statistik saben dina ing basis data relasional. Mulane, kanggo konektor sing struktur data luwih cocok kanggo database relasional, kita miwiti nggunakake PostgreSQL utawa MS SQL Server minangka panyimpenan.
Arsitektur lan teknologi sing dipilih ngidini kita mbangun lan ngluncurake produk D1.Digital kanthi cepet. Swara rong taun pangembangan produk, kita dikembangaké 23 konektor kanggo situs, gained pengalaman invaluable nggarap API pihak katelu, sinau kanggo ngindhari pitfalls situs beda, kang saben duwe dhewe, nyumbang kanggo pangembangan API saka paling 3 situs, kanthi otomatis ndownload informasi babagan meh 15 kampanye lan luwih saka 000 penempatan, ngumpulake akeh umpan balik saka pangguna babagan operasi produk lan bisa ngganti proses utama produk kaping pirang-pirang, adhedhasar umpan balik iki.
Arsitektur solusi 2.0
Rong taun wis liwati wiwit wiwitan pembangunan D1. Digital. Tambah terus-terusan ing beban ing sistem lan munculé sumber data sing luwih anyar mboko sithik mbukak masalah ing arsitektur solusi sing ana.
Masalah pisanan ana hubungane karo jumlah data sing diundhuh saka situs kasebut. Kita ngadhepi kasunyatan manawa ngumpulake lan nganyari kabeh data sing dibutuhake saka situs paling gedhe wiwit njupuk wektu akeh. Contone, ngempalaken data saka sistem adserving AdRiver, karo kang kita nglacak statistik kanggo paling panggonan, njupuk bab 12 jam.
Kanggo ngatasi masalah iki, kita miwiti nggunakake kabeh jinis laporan kanggo ngundhuh data saka situs, kita nyoba kanggo berkembang API bebarengan karo situs supaya kacepetan operasi meets kabutuhan kita, lan parallelize download data sabisa.
Masalah liyane ana hubungane karo pangolahan data sing diundhuh. Saiki, nalika statistik penempatan anyar teka, proses multi-tahap ngetung ulang metrik diluncurake, sing kalebu ngemot data mentah, ngitung metrik agregat kanggo saben situs, mbandhingake data saka sumber sing beda-beda, lan ngitung metrik ringkesan kanggo kampanye. Iki nyebabake akeh beban ing aplikasi web sing nindakake kabeh petungan. Kaping pirang-pirang, sajrone proses recalculation, aplikasi nggunakake kabeh memori ing server, kira-kira 10-15 GB, sing duweni efek paling ngrugekake ing karya pangguna karo sistem kasebut.
Masalah sing diidentifikasi lan rencana ambisius kanggo pangembangan produk kasebut nyebabake kita kudu nimbang maneh arsitektur aplikasi.
Kita miwiti karo konektor.
We ngeweruhi sing kabeh konektor dianggo miturut model padha, supaya kita mbangun framework pipo kanggo nggawe konektor mung kudu program logika langkah, liyane iku universal. Yen sawetara konektor mbutuhake dandan, banjur kita langsung nransfer menyang framework anyar ing wektu sing padha konektor lagi apik.
Ing wektu sing padha, kita miwiti masang konektor menyang Docker lan Kubernetes.
We ngrancang pamindhahan kanggo Kubernetes kanggo dangu, experimented karo setelan CI / CD, nanging wiwit obah mung nalika siji konektor, amarga kesalahan, wiwit mangan nganti luwih saka 20 GB memori ing server, sacoro prakteke mateni pangolahan liyane. . Sajrone diselidiki, konektor kasebut dipindhah menyang kluster Kubernetes, sing pungkasane tetep, sanajan kesalahan kasebut didandani.
Cukup cepet kita temen maujud sing Kubernetes trep, lan ing nem sasi kita nransfer 7 konektor lan Konektor Proxy, kang nganggo paling sumber daya, kanggo kluster produksi.
Sawise konektor, kita mutusake kanggo ngganti arsitektur aplikasi liyane.
Masalah utama yaiku data sing teka saka konektor menyang proxy ing batch gedhe, banjur kenek DANBoID lan dikirim menyang aplikasi web tengah kanggo diproses. Amarga nomer akeh recalculations metrik, ana beban gedhe ing aplikasi.
Iku uga mbuktekaken cukup angel kanggo ngawasi status proyek pangumpulan data individu lan laporan kasalahan sing kedadeyan ing konektor menyang aplikasi web pusat supaya pangguna bisa ndeleng apa sing kedadeyan lan ngapa data ora diklumpukake.
Kanggo ngatasi masalah kasebut, kita ngembangake arsitektur 2.0.
Bentenipun utama antarane versi anyar saka arsitektur iku tinimbang Web API, kita nggunakake RabbitMQ lan perpustakaan MassTransit kanggo ijol-ijolan pesen antarane layanan. Kanggo nindakake iki, kita kudu meh rampung nulis ulang Konektor Proxy, nggawe Connectors Hub. Jeneng iki diganti amarga peran utama layanan ora maneh ing nerusake panjalukan kanggo konektor lan mburi, nanging ngatur koleksi metrik saka konektor.
Saka aplikasi web pusat, kita misahake informasi babagan penempatan lan statistik saka situs menyang layanan sing kapisah, sing ndadekake bisa nyisihake recalculations sing ora perlu lan mung nyimpen statistik sing wis diwilang lan dikumpulake ing tingkat panggonan. Kita uga nulis ulang lan ngoptimalake logika kanggo ngitung statistik dhasar adhedhasar data mentah.
Ing wektu sing padha, kita migrasi kabeh layanan lan aplikasi menyang Docker lan Kubernetes kanggo nggawe solusi luwih gampang kanggo skala lan luwih trep kanggo ngatur.
Ing ngendi kita saiki
Proof-of-concept arsitektur 2.0 produk D1. Digital siap lan digunakake ing lingkungan test karo pesawat winates saka konektor. Kabeh sing kudu ditindakake yaiku nulis ulang 20 konektor liyane menyang platform anyar, nyoba manawa data dimuat kanthi bener lan kabeh metrik diwilang kanthi bener, lan gulung kabeh desain menyang produksi.
Nyatane, proses iki bakal kedadeyan kanthi bertahap lan kita kudu ninggalake kompatibilitas mundur karo API lawas supaya kabeh bisa digunakake.
Rencana langsung kita kalebu pangembangan konektor anyar, integrasi karo sistem anyar lan nambah metrik tambahan menyang set data sing diundhuh saka situs sing disambungake lan sistem adserving.
Kita uga rencana nransfer kabeh aplikasi, kalebu aplikasi web pusat, menyang Docker lan Kubernetes. Digabungake karo arsitektur anyar, iki bakal luwih gampang nyebarake, ngawasi lan ngontrol sumber daya sing dikonsumsi.
Ide liyane yaiku eksperimen karo pilihan database kanggo nyimpen statistik, sing saiki disimpen ing MongoDB. Kita wis ditransfer sawetara konektor anyar kanggo database SQL, nanging ana prabédan meh unnoticeable, lan kanggo statistik dikumpulake dening dina, kang bisa dijaluk kanggo periode kasepakatan, gain bisa cukup serius.
Umumé, rencana kasebut muluk-muluk, ayo maju :)
Penulis artikel R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Source: www.habr.com