Sigana mah widang iklan online kudu jadi technologically canggih tur otomatis-gancang. Tangtosna, sabab raksasa sapertos sareng ahli dina widangna sapertos Yandex, Mail.Ru, Google sareng Facebook damel di dinya. Tapi, sakumaha tétéla, teu aya watesna pikeun kasampurnaan jeung sok aya hal pikeun ngajadikeun otomatis.
Grup komunikasi Dentsu Aegis Network Rusia nyaéta pamaén panggedéna di pasar iklan digital sareng aktip investasi dina téknologi, nyobian ngaoptimalkeun sareng ngajadikeun otomatis prosés bisnisna. Salah sahiji masalah anu teu kaungkab dina pasar iklan online nyaéta tugas ngumpulkeun statistik dina kampanye iklan tina platform Internét anu béda. Solusi pikeun masalah ieu pamustunganana nyababkeun nyiptakeun produk D1.Digital (dibaca salaku DiVan), pamekaran anu urang badé ngobrolkeun.
Kunaon?
1. Dina waktu mimiti proyek, teu aya hiji produk siap-dijieun tunggal dina pasaran anu direngsekeun masalah automating kumpulan statistik dina kampanye iklan. Ieu ngandung harti yén teu saurang ogé iwal diri urang bakal minuhan kaperluan urang.
Jasa sapertos Improvado, Roistat, Supermetrics, SegmentStream nawiskeun integrasi sareng platform, jaringan sosial sareng Google Analitycs, sareng ogé ngamungkinkeun pikeun ngawangun dasbor analitik pikeun analisa anu gampang sareng kontrol kampanye iklan. Sateuacan urang ngamimitian ngembangkeun produk urang, urang nyobian ngagunakeun sababaraha sistem ieu pikeun ngumpulkeun data tina situs, tapi hanjakalna, aranjeunna teu bisa ngajawab masalah urang.
Masalah utama nyaéta yén produk anu diuji dumasar kana sumber data, nunjukkeun statistik panempatan ku situs, sareng henteu masihan kamampuan pikeun ngahijikeun statistik dina kampanye iklan. Pendekatan ieu henteu ngamungkinkeun urang ningali statistik tina situs anu béda dina hiji tempat sareng nganalisis kaayaan kampanye sacara gembleng.
Faktor séjén nyaéta yén dina tahap awal produk ditujukeun ka pasar Kulon sareng henteu ngadukung integrasi sareng situs Rusia. Sareng pikeun situs-situs anu integrasi dilaksanakeun, sadaya métrik anu dipikabutuh henteu salawasna diunduh kalayan detil anu cukup, sareng integrasi henteu salawasna merenah sareng transparan, khususna nalika diperyogikeun pikeun kéngingkeun anu henteu aya dina antarmuka sistem.
Sacara umum, urang mutuskeun teu adaptasi jeung produk pihak katilu, tapi mimitian ngembangkeun sorangan ...
2. Pasar iklan online tumuwuh ti taun ka taun, sarta dina 2018, dina watesan budgets iklan, éta overtook pasar iklan TV tradisional panggedéna. Jadi aya skala.
3. Beda sareng pasar iklan TV, dimana penjualan iklan komersial dimonopoli, aya seueur pamilik individu tina inventaris iklan tina sababaraha ukuran anu beroperasi dina Internét sareng akun iklanna sorangan. Kusabab kampanye iklan, sakumaha aturan, dijalankeun dina sababaraha situs sakaligus, pikeun ngartos kaayaan kampanye iklan, perlu pikeun ngumpulkeun laporan ti sadaya situs sareng ngagabungkeun kana hiji laporan ageung anu bakal nunjukkeun sadayana gambar. Ieu ngandung harti aya potensi optimasi.
4. Ieu seemed urang nu boga inventory iklan dina Internet geus boga infrastruktur pikeun ngumpulkeun statistik tur mintonkeun eta dina akun iklan, sarta aranjeunna bakal tiasa nyadiakeun hiji API pikeun data ieu. Ieu ngandung harti yén éta téhnisna mungkin pikeun nerapkeun eta. Hayu urang langsung nyebutkeun yén tétéla teu jadi basajan.
Sacara umum, sagala prerequisites pikeun palaksanaan proyék éta atra ka urang, sarta kami lumpat mawa proyék pikeun hirup ...
Rencana Agung
Pikeun mimitian, urang ngawangun visi sistem idéal:
- Kampanye iklan tina sistem perusahaan 1C kedah otomatis dimuat kana nami, période, anggaran sareng panempatan dina sababaraha platform.
- Pikeun unggal panempatan dina kampanye iklan, sadaya statistik anu mungkin kedah diunduh sacara otomatis tina situs tempat panempatan lumangsung, sapertos jumlah tayangan, klik, pintonan, jsb.
- Sababaraha kampanye iklan dilacak nganggo ngawaskeun pihak katilu ku anu disebut sistem adserving sapertos Driver, Weborama, DCM, jsb. Aya ogé méteran Internét industri di Rusia - perusahaan Mediascope. Numutkeun rencana urang, data ti ngawaskeun bebas sarta industri ogé kudu otomatis dimuat kana kampanye iklan pakait.
- Kaseueuran kampanye iklan dina Internét ditujukeun pikeun tindakan target anu tangtu (meuli, nelepon, ngadaptarkeun test drive, jsb.), Anu dilacak nganggo Google Analytics, sareng statistik anu ogé penting pikeun ngartos status kampanye sareng kudu dimuat kana alat urang.
Pancake anu munggaran nyaéta lumpuh
Dibikeun komitmen urang kana prinsip fléksibel tina ngembangkeun software (lincah, sagala hal), urang mutuskeun pikeun mimiti ngembangkeun hiji MVP lajeng pindah ka tujuan dimaksudkeun iteratively.
Urang mutuskeun pikeun ngawangun MVP dumasar kana produk urang DANBo (Dewan Jaringan Dentsu Aegis), anu mangrupikeun aplikasi wéb kalayan inpormasi umum ngeunaan kampanye iklan klien kami.
Pikeun MVP, proyék ieu disederhanakeun saloba mungkin dina hal palaksanaan. Kami geus milih daptar kawates platform pikeun integrasi. Ieu mangrupikeun platform utama, sapertos Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, sareng sistem adserving utama Adriver sareng Weborama.
Pikeun ngakses statistik dina situs via API, kami dipaké hiji akun tunggal. Manajer grup klien anu hoyong nganggo koleksi statistik otomatis dina kampanye iklan kedah utusan heula aksés kana kampanye iklan anu diperyogikeun dina situs kana akun platform.
Salajengna nyaéta pamaké sistem DANBo kedah unggah file tina format anu tangtu kana sistem Excel, anu ngandung sadaya inpormasi ngeunaan panempatan (kampanye iklan, platform, format, jaman panempatan, indikator rencanana, anggaran, jsb.) situs na counters dina sistem adserving.
Éta katingali, terus terang, pikasieuneun:
Data nu diundeur ieu disimpen kana database a, lajeng jasa misah dikumpulkeun identifiers kampanye dina situs ti aranjeunna sarta diundeur statistik on aranjeunna.
Pikeun unggal situs, jasa jandéla misah ieu ditulis, nu sakali sapoé indit dina hiji akun layanan dina API situs na diundeur statistik keur ID kampanye husus. Hal anu sarua kajadian kalawan sistem adserving.
Data anu diunduh ditampilkeun dina antarmuka dina bentuk dasbor khusus leutik:
Teu disangka-sangka pikeun urang, MVP mimiti damel sareng mimiti ngaunduh statistik ayeuna ngeunaan kampanye iklan dina Internét. Kami nerapkeun sistem dina sababaraha klien, tapi nalika nyobian skala, kami mendakan masalah anu serius:
- Masalah utama nyaéta pajeulitna nyiapkeun data pikeun dimuat kana sistem. Ogé, data panempatan kedah dirobih kana format anu tetep leres sateuacan dimuat. Ieu diperlukeun pikeun ngawengku identifiers éntitas ti loka béda dina file undeuran. Urang Nyanghareupan kanyataan yén éta téh hésé pisan pikeun pamaké téhnis untrained ngajelaskeun dimana manggihan identifiers ieu dina situs jeung dimana dina file maranéhna kudu diasupkeun. Tempo jumlah karyawan di departemén ngajalankeun kampanye dina situs na elehan, ieu nyababkeun jumlah badag rojongan di sisi kami, nu urang kacida teu senang jeung.
- Masalah anu sanés nyaéta henteu sadayana platform iklan ngagaduhan mékanisme pikeun delegasi aksés ka kampanye iklan ka akun anu sanés. Tapi sanajan mékanisme delegasi éta sadia, teu kabeh advertisers éta daék méré aksés ka kampanye maranéhna pikeun rekening pihak katilu.
- Faktor anu penting nyaéta ambek-ambekan anu ngahudangkeun diantara pangguna ku kanyataan yén sadaya indikator anu direncanakeun sareng detil panempatan anu aranjeunna parantos lebet kana sistem akuntansi 1C urang, aranjeunna kedah asup deui kana DANBo.
Ieu masihan kami ide yén sumber utama inpormasi ngeunaan panempatan kedah janten sistem 1C urang, dimana sadaya data diasupkeun sacara akurat sareng dina waktosna (titik di dieu nyaéta yén invoice dibangkitkeun dumasar kana data 1C, janten éntri data anu leres kana 1C mangrupakeun prioritas pikeun sarerea KPI). Ieu kumaha konsép sistem anyar muncul ...
Konsep
Hal kahiji anu kami mutuskeun nyaéta pikeun misahkeun sistem pikeun ngumpulkeun statistik kampanye iklan dina Internét kana produk anu misah - D1.Digital.
Dina konsép anyar, urang mutuskeun pikeun muka kana D1.Digital inpormasi ngeunaan kampanye iklan sareng panempatan dina éta tina 1C, teras tarik statistik tina situs sareng sistem AdServing ka panempatan ieu. Ieu sakuduna dituju nyata nyederhanakeun kahirupan pikeun pangguna (sareng, sapertos biasa, nambihan langkung seueur padamelan pikeun pamekar) sareng ngirangan jumlah dukungan.
Masalah kahiji anu kami hadapi nyaéta sipat organisasi sareng aya hubunganana sareng kanyataan yén kami henteu tiasa mendakan konci atanapi tanda anu kami tiasa ngabandingkeun éntitas tina sistem anu béda sareng kampanye sareng panempatan ti 1C. Kanyataan yén prosés di parusahaan urang dirancang dina cara sapertos nu kampanye iklan diasupkeun kana sistem béda ku jalma béda (planners média, meuli, jsb).
Pikeun ngabéréskeun masalah ieu, urang kedah nyiptakeun konci hashed unik, DANBoID, anu bakal ngaitkeun éntitas dina sistem anu béda babarengan, sareng éta tiasa gampang sareng unik diidentifikasi dina set data anu diunduh. Identifier ieu dihasilkeun dina sistem 1C internal pikeun tiap panempatan individu jeung ditransfer ka kampanye, panempatan jeung counters on sadaya situs na dina sakabéh sistem AdServing. Nerapkeun prakték nempatkeun DANBoID dina sadaya panempatan nyandak sababaraha waktos, tapi urang junun ngalakukeunana :)
Teras we kapanggih kaluar yén teu sakabeh situs boga API pikeun otomatis ngumpulkeun statistik, komo nu boga API, teu balik kabeh data diperlukeun.
Dina tahap ieu, urang mutuskeun sacara signifikan ngurangan daptar platform keur integrasi jeung fokus kana platform utama nu kalibet dina Lolobana kampanye iklan. Daptar ieu kalebet sadaya pamaén panggedéna di pasar iklan (Google, Yandex, Mail.ru), jaringan sosial (VK, Facebook, Twitter), sistem AdServing sareng analytics utama (DCM, Driver, Weborama, Google Analytics) sareng platform anu sanés.
Mayoritas situs anu kami pilih ngagaduhan API anu nyayogikeun métrik anu kami butuhkeun. Dina kasus dimana teu aya API atanapi henteu ngandung data anu diperyogikeun, kami nganggo laporan anu dikirim unggal dinten ka email kantor kami pikeun ngamuat data (dina sababaraha sistem kamungkinan pikeun ngonpigurasikeun laporan sapertos kitu, di batur kami sapuk pikeun ngembangkeun laporan sapertos kitu. kanggo urang).
Nalika nganalisis data tina situs anu béda, kami mendakan yén hierarki éntitas henteu sami dina sistem anu béda. Leuwih ti éta, informasi perlu diundeur di jéntré béda ti sistem béda.
Pikeun ngajawab masalah ieu, konsép SubDANBoID dikembangkeun. Gagasan SubDANBoID cukup saderhana, kami nyirian éntitas utama kampanye dina situs kalayan DANBoID anu dihasilkeun, sareng kami unggah sadaya éntitas nested kalayan identifier situs unik sareng ngabentuk SubDANBoID dumasar kana prinsip DANBoID + identifier tingkat kahiji. éntitas nested + identifier sahiji éntitas nested tingkat kadua +... Pendekatan ieu ngamungkinkeun urang pikeun nyambungkeun kampanye iklan dina sistem béda tur ngundeur statistik lengkep dina éta.
Urang ogé kedah ngajawab masalah aksés ka kampanye dina platform anu béda. Salaku urang wrote luhur, mékanisme delegating aksés ka kampanye ka akun teknis misah teu salawasna lumaku. Ku alatan éta, urang kudu ngamekarkeun infrastruktur pikeun otorisasina otomatis via OAuth ngagunakeun tokens sarta mékanisme pikeun ngamutahirkeun tokens ieu.
Engké dina artikel urang bakal coba ngajelaskeun dina leuwih jéntré arsitektur solusi na rinci teknis palaksanaan.
Arsitéktur solusi 1.0
Nalika ngamimitian palaksanaan produk anyar, urang ngartos yen urang geuwat diperlukeun nyadiakeun kamungkinan nyambungkeun situs anyar, sangkan mutuskeun pikeun nuturkeun jalur arsitéktur microservice.
Nalika ngarancang arsitéktur, kami misahkeun konektor ka sadaya sistem éksternal - 1C, platform iklan sareng sistem iklan - kana jasa anu misah.
Gagasan utama nyaéta yén sadaya panyambungna kana situs gaduh API anu sami sareng adaptor anu mawa API situs ka antarmuka anu cocog pikeun urang.
Di tengah produk urang aya aplikasi wéb, nyaéta monolith anu dirarancang ku cara anu gampang dibongkar kana jasa. Aplikasi ieu tanggung jawab pikeun ngolah data anu diunduh, ngumpulkeun statistik tina sistem anu béda sareng nampilkeunana ka pangguna sistem.
Pikeun komunikasi antara panyambungna sareng aplikasi wéb, urang kedah nyiptakeun ladenan tambahan, anu disebat Connector Proxy. Éta ngalaksanakeun fungsi Papanggihan Layanan sareng Penjadwal Tugas. Ladenan ieu ngajalankeun tugas ngumpulkeun data pikeun tiap konektor unggal wengi. Nulis lapisan jasa éta gampang ti nyambungkeun hiji calo pesen, sarta pikeun urang éta penting pikeun meunangkeun hasil gancang-gancang.
Pikeun kesederhanaan sareng laju pangwangunan, kami ogé mutuskeun yén sadaya jasa bakal janten API Wéb. Hal ieu ngamungkinkeun pikeun gancang ngumpul bukti-of-konsép jeung pariksa yen sakabéh desain jalan.
Tugas anu misah, rada rumit nyaéta nyetél aksés pikeun ngumpulkeun data tina akun anu béda, anu, sakumaha anu diputuskeun, kedah dilaksanakeun ku pangguna ngalangkungan antarmuka wéb. Ieu diwangun ku dua hambalan misah: kahiji, pamaké nambahkeun token pikeun ngakses akun via OAuth, lajeng ngonpigurasikeun kumpulan data pikeun klien ti akun husus. Kéngingkeun token ngalangkungan OAuth diperyogikeun sabab, sakumaha anu kami parantos nyerat, henteu salawasna mungkin pikeun utusan aksés ka akun anu dipikahoyong dina situs éta.
Pikeun nyiptakeun mékanisme universal pikeun milih akun tina situs, urang kedah nambihan metode kana API panyambungna anu mulihkeun JSON Schema, anu didamel kana bentuk nganggo komponén JSONEditor anu dirobih. Ku cara ieu, pangguna tiasa milih akun pikeun ngaunduh data.
Pikeun matuh wates pamundut nu aya dina loka, urang ngagabungkeun requests pikeun setelan dina hiji token, tapi urang bisa ngolah tokens béda dina paralel.
Kami milih MongoDB salaku panyimpen data anu dimuat pikeun aplikasi wéb sareng konektor, anu ngamungkinkeun urang henteu hariwang teuing ngeunaan struktur data dina tahap awal pangwangunan, nalika modél obyék aplikasina robih unggal dinten.
Urang geura-giru manggihan yén teu sakabeh data fits well di MongoDB na, contona, leuwih merenah pikeun nyimpen statistik sapopoé dina database relational. Ku alatan éta, pikeun konektor anu struktur datana leuwih cocog pikeun database relational, urang mimitian ngagunakeun PostgreSQL atawa MS SQL Server salaku gudang.
Arsitéktur sareng téknologi anu dipilih ngamungkinkeun urang ngawangun sareng ngaluncurkeun produk D1.Digital rélatif gancang. Leuwih dua taun ngembangkeun produk, urang ngembangkeun 23 panyambungna kana situs, miboga pangalaman invaluable gawé bareng API pihak-katilu, diajar pikeun nyingkahan pitfalls tina situs béda, nu masing-masing miboga sorangan, nyumbang kana ngembangkeun API tina sahanteuna 3 situs, otomatis diundeur informasi dina ampir 15 kampanye jeung leuwih ti 000 panempatan, dikumpulkeun loba eupan balik ti pamaké on operasi produk jeung junun ngarobah prosés utama produk sababaraha kali, dumasar kana eupan balik ieu.
Arsitéktur solusi 2.0
Dua taun geus kaliwat ti mimiti pangwangunan D1.Digital. Kanaékan konstan dina beban dina sistem jeung mecenghulna beuki loba sumber data anyar laun ngungkabkeun masalah dina arsitektur solusi aya.
Masalah kahiji patali jeung jumlah data diundeur ti loka. Kami disanghareupan kanyataan yén ngumpulkeun sareng ngamutahirkeun sadaya data anu dipikabutuh tina situs-situs panggedéna mimiti nyandak waktos teuing. Contona, ngumpulkeun data tina sistem adserving AdRiver, nu urang ngalacak statistik keur paling panempatan, nyokot ngeunaan 12 jam.
Pikeun ngabéréskeun masalah ieu, urang mimitian nganggo sagala jinis laporan pikeun ngundeur data tina situs, urang narékahan pikeun ngembangkeun API maranéhanana babarengan jeung situs ambéh laju operasi na meets kaperluan urang, sarta parallelize download data saloba mungkin.
Masalah sanésna aya hubunganana sareng ngolah data anu diunduh. Ayeuna, nalika statistik panempatan anyar sumping, hiji prosés multi-tahap recalculating metrics dibuka, nu ngawengku loading data atah, ngitung metrics aggregated pikeun tiap situs, ngabandingkeun data tina sumber béda saling, sarta ngitung metrics kasimpulan pikeun kampanye. Ieu nyababkeun seueur beban dina aplikasi wéb anu ngalakukeun sadaya itungan. Sababaraha kali, salila prosés recalculation, aplikasi nu dihakan sakabeh memori dina server, ngeunaan 10-15 GB, nu miboga éfék paling detrimental on karya pamaké 'kalayan sistem.
Masalah anu diidentifikasi sareng rencana ambisius pikeun ngembangkeun produk salajengna nyababkeun urang kedah nimbangkeun deui arsitektur aplikasi.
Urang mimitian ku konektor.
Kami perhatikeun yén sadaya panyambungna tiasa dianggo dumasar kana modél anu sami, ku kituna kami ngawangun kerangka pipa pikeun nyiptakeun konektor anjeun ngan ukur kedah program logika léngkah-léngkah, sésana nyaéta universal. Lamun sababaraha konektor merlukeun perbaikan, lajeng urang langsung mindahkeun kana kerangka anyar dina waktos anu sareng salaku konektor keur ningkat.
Dina waktos anu sami, urang ngamimitian nyebarkeun konektor ka Docker sareng Kubernetes.
Kami ngarencanakeun pindah ka Kubernetes kanggo waktos anu lami, ékspérimén sareng setélan CI / CD, tapi ngan ukur ngalih nalika hiji konektor, kusabab kasalahan, mimiti tuang langkung ti 20 memori GB dina server, praktis maéhan prosés anu sanés. . Salila panalungtikan, konektor ieu dipindahkeun ka klaster Kubernetes, dimana eta pamustunganana tetep, malah sanggeus kasalahan dibereskeun.
Rada gancang urang sadar yén Kubernetes éta merenah, sarta dina genep bulan urang mindahkeun 7 panyambungna jeung Panyambung Proxy, nu meakeun paling sumberdaya, ka klaster produksi.
Saatos panyambungna, kami mutuskeun pikeun ngarobih arsitéktur sesa aplikasi.
Masalah utama éta data asalna tina panyambungna ka proxy dina bets badag, lajeng pencét DANBoID sarta dikirim ka aplikasi wéb sentral pikeun ngolah. Alatan jumlah badag metrics recalculations, aya beban badag dina aplikasi.
Éta ogé kabuktian rada hese pikeun ngawas status padamelan pendataan individu sareng ngalaporkeun kasalahan anu aya dina konektor ka aplikasi wéb sentral supados pangguna tiasa ningali naon anu lumangsung sareng kunaon data henteu dikumpulkeun.
Pikeun ngajawab masalah ieu, urang ngembangkeun arsitektur 2.0.
Beda utama antara versi anyar arsitéktur nyaéta yén tinimbang Web API, kami nganggo RabbitMQ sareng perpustakaan MassTransit pikeun tukeur pesen antara jasa. Jang ngalampahkeun ieu, urang kudu ampir sakabéhna nulis balik Connectors Proxy, sahingga Connectors Hub. Ngaranna diganti ku sabab peran utama jasa henteu deui dina neraskeun pamundut ka konektor sareng tukang, tapi dina ngatur kumpulan métrik tina konektor.
Tina aplikasi wéb sentral, kami misahkeun inpormasi ngeunaan panempatan sareng statistik tina situs kana jasa anu misah, anu ngamungkinkeun pikeun ngaleungitkeun pangitungan anu teu dipikabutuh sareng nyimpen ngan ukur statistik anu diitung sareng agrégat dina tingkat panempatan. Kami ogé nyerat sareng ngaoptimalkeun logika pikeun ngitung statistik dasar dumasar kana data atah.
Dina waktos anu sami, urang migrasi sadaya jasa sareng aplikasi ka Docker sareng Kubernetes pikeun ngajantenkeun solusina langkung gampang skala sareng langkung merenah pikeun ngatur.
Dimana urang ayeuna
Proof-of-konsép arsitéktur 2.0 produk D1.Digital siap tur digawé di lingkungan test ku set kawates panyambungna. Sadaya anu kedah dilakukeun nyaéta nyerat deui 20 panyambungna kana platform énggal, uji yén data dimuat leres sareng sadaya métrik diitung leres, sareng gulung sadayana desain kana produksi.
Nyatana, prosés ieu bakal kajantenan laun-laun sareng urang kedah ngantunkeun kasaluyuan mundur sareng API anu lami supados sadayana tiasa jalan.
Rencana langsung kami kalebet pamekaran konektor énggal, integrasi sareng sistem énggal sareng nambihan métrik tambahan kana set data anu diunduh tina situs anu nyambung sareng sistem iklan.
Kami ogé ngarencanakeun pikeun mindahkeun sadaya aplikasi, kalebet aplikasi wéb sentral, ka Docker sareng Kubernetes. Digabungkeun sareng arsitéktur énggal, ieu sacara signifikan bakal nyederhanakeun panyebaran, ngawaskeun sareng kontrol sumberdaya anu dikonsumsi.
Gagasan anu sanés nyaéta ékspérimén sareng pilihan database pikeun nyimpen statistik, anu ayeuna disimpen dina MongoDB. Kami parantos ngalihkeun sababaraha panyambung anyar kana pangkalan data SQL, tapi aya bédana ampir teu katingali, sareng pikeun statistik agrégat ku dinten, anu tiasa dipénta pikeun période sawenang-wenang, kauntungan tiasa rada serius.
Sacara umum, rencana anu muluk, hayu urang teraskeun :)
Panulis artikel R&D Dentsu Aegis Network Rusia: Georgy Ostapenko (), Mikhail Kotsik ()
sumber: www.habr.com