Nampaknya bidang pengiklanan dalam talian harus maju dari segi teknologi dan automatik yang mungkin. Sudah tentu, kerana gergasi dan pakar dalam bidang mereka seperti Yandex, Mail.Ru, Google dan Facebook bekerja di sana. Tetapi, ternyata, tiada had untuk kesempurnaan dan sentiasa ada sesuatu untuk diautomasikan.
Kumpulan komunikasi Dentsu Aegis Network Russia ialah pemain terbesar dalam pasaran pengiklanan digital dan sedang melabur secara aktif dalam teknologi, cuba mengoptimumkan dan mengautomasikan proses perniagaannya. Salah satu masalah pasaran pengiklanan dalam talian yang tidak dapat diselesaikan ialah tugas mengumpul statistik mengenai kempen pengiklanan daripada platform Internet yang berbeza. Penyelesaian kepada masalah ini akhirnya menghasilkan penciptaan produk D1.Digital (dibaca sebagai DiVan), perkembangan yang ingin kita bincangkan.
Mengapa?
1. Pada masa permulaan projek, tidak ada satu pun produk siap pakai di pasaran yang menyelesaikan masalah mengautomasikan pengumpulan statistik pada kempen pengiklanan. Ini bermakna tiada siapa melainkan diri kita sendiri yang akan memenuhi keperluan kita.
Perkhidmatan seperti Improvado, Roistat, Supermetrics, SegmentStream menawarkan penyepaduan dengan platform, rangkaian sosial dan Google Analitycs, dan juga memungkinkan untuk membina papan pemuka analitikal untuk analisis mudah dan kawalan kempen pengiklanan. Sebelum kami mula membangunkan produk kami, kami cuba menggunakan beberapa sistem ini untuk mengumpul data daripada tapak, tetapi, malangnya, mereka tidak dapat menyelesaikan masalah kami.
Masalah utama ialah produk yang diuji adalah berdasarkan sumber data, memaparkan statistik peletakan mengikut tapak dan tidak menyediakan keupayaan untuk mengagregat statistik pada kempen pengiklanan. Pendekatan ini tidak membenarkan kami melihat statistik daripada tapak yang berbeza di satu tempat dan menganalisis keadaan kempen secara keseluruhan.
Faktor lain ialah pada peringkat awal produk itu ditujukan kepada pasaran Barat dan tidak menyokong integrasi dengan tapak Rusia. Dan bagi tapak yang penyepaduan dilaksanakan, semua metrik yang diperlukan tidak selalu dimuat turun dengan perincian yang mencukupi, dan penyepaduan tidak sentiasa mudah dan telus, terutamanya apabila perlu untuk mendapatkan sesuatu yang tidak terdapat dalam antara muka sistem.
Secara umum, kami memutuskan untuk tidak menyesuaikan diri dengan produk pihak ketiga, tetapi mula membangunkan produk kami sendiri...
2. Pasaran pengiklanan dalam talian berkembang dari tahun ke tahun, dan pada tahun 2018, dari segi belanjawan pengiklanan, ia mengatasi pasaran pengiklanan TV terbesar secara tradisinya. Jadi ada skala.
3. Tidak seperti pasaran pengiklanan TV, di mana penjualan pengiklanan komersial dimonopoli, terdapat banyak pemilik individu inventori pengiklanan pelbagai saiz yang beroperasi di Internet dengan akaun pengiklanan mereka sendiri. Memandangkan kempen pengiklanan, sebagai peraturan, berjalan di beberapa tapak sekaligus, untuk memahami keadaan kempen pengiklanan, adalah perlu untuk mengumpul laporan dari semua tapak dan menggabungkannya menjadi satu laporan besar yang akan menunjukkan keseluruhan gambar. Ini bermakna terdapat potensi untuk pengoptimuman.
4. Nampaknya kami pemilik inventori pengiklanan di Internet sudah mempunyai infrastruktur untuk mengumpul statistik dan memaparkannya dalam akaun pengiklanan, dan mereka akan dapat menyediakan API untuk data ini. Ini bermakna secara teknikalnya mungkin untuk melaksanakannya. Katakan segera bahawa ia ternyata tidak begitu mudah.
Secara umum, semua prasyarat untuk pelaksanaan projek itu jelas kepada kami, dan kami berlari untuk menghidupkan projek itu...
Rancangan besar
Sebagai permulaan, kami membentuk visi sistem yang ideal:
- Kempen pengiklanan daripada sistem korporat 1C harus dimuatkan secara automatik ke dalamnya dengan nama, tempoh, belanjawan dan peletakan pada pelbagai platform.
- Untuk setiap peletakan dalam kempen pengiklanan, semua statistik yang mungkin perlu dimuat turun secara automatik daripada tapak tempat peletakan itu berlaku, seperti bilangan tera, klik, paparan, dsb.
- Sesetengah kempen pengiklanan dijejak menggunakan pemantauan pihak ketiga oleh apa yang dipanggil sistem penyajian iklan seperti Adriver, Weborama, DCM, dsb. Terdapat juga meter Internet industri di Rusia - syarikat Mediascope. Mengikut rancangan kami, data daripada pemantauan bebas dan industri juga harus dimuatkan secara automatik ke dalam kempen pengiklanan yang sepadan.
- Kebanyakan kempen pengiklanan di Internet ditujukan kepada tindakan sasaran tertentu (pembelian, panggilan, mendaftar untuk pandu uji, dsb.), yang dijejak menggunakan Google Analitis dan statistik yang juga penting untuk memahami status kempen dan harus dimuatkan ke dalam alat kami.
Lempeng pertama adalah kental
Memandangkan komitmen kami terhadap prinsip fleksibel pembangunan perisian (tangkas, semua perkara), kami memutuskan untuk membangunkan MVP dahulu dan kemudian bergerak ke arah matlamat yang dimaksudkan secara berulang.
Kami memutuskan untuk membina MVP berdasarkan produk kami DANBo (Lembaga Rangkaian Dentsu Aegis), iaitu aplikasi web dengan maklumat umum tentang kempen pengiklanan pelanggan kami.
Bagi MVP, projek itu dipermudahkan sebaik mungkin dari segi pelaksanaan. Kami telah memilih senarai terhad platform untuk penyepaduan. Ini adalah platform utama, seperti Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB dan sistem penyampaian iklan utama Adriver dan Weborama.
Untuk mengakses statistik pada tapak melalui API, kami menggunakan satu akaun. Pengurus kumpulan pelanggan yang ingin menggunakan pengumpulan statistik automatik pada kempen pengiklanan perlu terlebih dahulu mewakilkan akses kepada kempen pengiklanan yang diperlukan di tapak kepada akaun platform.
Seterusnya ialah pengguna sistem DANBo terpaksa memuat naik fail dalam format tertentu ke dalam sistem Excel, yang mengandungi semua maklumat tentang peletakan (kempen pengiklanan, platform, format, tempoh peletakan, penunjuk terancang, belanjawan, dll.) dan pengecam kempen pengiklanan yang sepadan pada tapak dan kaunter dalam sistem pengiklanan.
Ia kelihatan, terus terang, menakutkan:
Data yang dimuat turun telah disimpan ke dalam pangkalan data, dan kemudian perkhidmatan berasingan mengumpul pengecam kempen di tapak daripada mereka dan memuat turun statistik padanya.
Untuk setiap tapak, perkhidmatan tingkap yang berasingan telah ditulis, yang sekali sehari berada di bawah satu akaun perkhidmatan dalam API tapak dan memuat turun statistik untuk ID kempen yang ditentukan. Perkara yang sama berlaku dengan sistem penyajian iklan.
Data yang dimuat turun telah dipaparkan pada antara muka dalam bentuk papan pemuka tersuai kecil:
Tanpa diduga bagi kami, MVP mula bekerja dan mula memuat turun statistik semasa mengenai kempen pengiklanan di Internet. Kami melaksanakan sistem pada beberapa pelanggan, tetapi apabila cuba membuat skala, kami menghadapi masalah yang serius:
- Masalah utama ialah kerumitan menyediakan data untuk dimuatkan ke dalam sistem. Selain itu, data peletakan perlu ditukar kepada format yang ditetapkan dengan ketat sebelum dimuatkan. Ia adalah perlu untuk memasukkan pengecam entiti daripada tapak yang berbeza dalam fail muat turun. Kami berhadapan dengan hakikat bahawa adalah sangat sukar bagi pengguna yang tidak terlatih secara teknikal untuk menerangkan tempat untuk mencari pengecam ini di tapak dan di mana dalam fail ia perlu dimasukkan. Memandangkan bilangan pekerja di jabatan yang menjalankan kempen di tapak dan perolehan, ini menghasilkan sejumlah besar sokongan di pihak kami, yang kami benar-benar tidak berpuas hati dengannya.
- Masalah lain ialah tidak semua platform pengiklanan mempunyai mekanisme untuk mewakilkan akses kepada kempen pengiklanan kepada akaun lain. Tetapi walaupun mekanisme perwakilan tersedia, tidak semua pengiklan bersedia memberikan akses kepada kempen mereka kepada akaun pihak ketiga.
- Faktor penting ialah kemarahan yang ditimbulkan di kalangan pengguna oleh fakta bahawa semua penunjuk yang dirancang dan butiran penempatan yang telah mereka masukkan ke dalam sistem perakaunan 1C kami, mereka mesti memasukkan semula DANBo.
Ini memberi kami idea bahawa sumber utama maklumat tentang peletakan mestilah sistem 1C kami, di mana semua data dimasukkan dengan tepat dan tepat pada masanya (perkara di sini ialah invois dijana berdasarkan data 1C, jadi kemasukan data yang betul ke dalam 1C adalah keutamaan untuk semua KPI). Ini adalah bagaimana konsep baru sistem muncul...
Konsep
Perkara pertama yang kami putuskan untuk lakukan ialah memisahkan sistem untuk mengumpul statistik kempen pengiklanan di Internet kepada produk yang berasingan - D1.Digital.
Dalam konsep baharu, kami memutuskan untuk memuatkan D1.Digital maklumat tentang kempen pengiklanan dan peletakan di dalamnya daripada 1C, dan kemudian tarik statistik daripada tapak dan sistem AdServing ke peletakan ini. Ini sepatutnya memudahkan kehidupan pengguna dengan ketara (dan, seperti biasa, menambah lebih banyak kerja kepada pembangun) dan mengurangkan jumlah sokongan.
Masalah pertama yang kami hadapi adalah bersifat organisasi dan berkaitan dengan fakta bahawa kami tidak dapat mencari kunci atau tanda yang kami boleh membandingkan entiti daripada sistem yang berbeza dengan kempen dan peletakan daripada 1C. Hakikatnya ialah proses dalam syarikat kami direka sedemikian rupa sehingga kempen pengiklanan dimasukkan ke dalam sistem yang berbeza oleh orang yang berbeza (perancang media, pembelian, dll.).
Untuk menyelesaikan masalah ini, kami perlu mencipta kunci cincang unik, DANBoID, yang akan memautkan entiti dalam sistem yang berbeza bersama-sama, dan yang boleh dikenal pasti dengan mudah dan unik dalam set data yang dimuat turun. Pengecam ini dijana dalam sistem 1C dalaman untuk setiap peletakan individu dan dipindahkan ke kempen, peletakan dan kaunter di semua tapak dan dalam semua sistem AdServing. Melaksanakan amalan meletakkan DANBoID dalam semua penempatan mengambil sedikit masa, tetapi kami berjaya melakukannya :)
Kemudian kami mendapati bahawa tidak semua tapak mempunyai API untuk mengumpul statistik secara automatik, malah tapak yang mempunyai API, ia tidak mengembalikan semua data yang diperlukan.
Pada peringkat ini, kami memutuskan untuk mengurangkan dengan ketara senarai platform untuk penyepaduan dan menumpukan pada platform utama yang terlibat dalam sebahagian besar kempen pengiklanan. Senarai ini termasuk semua pemain terbesar dalam pasaran pengiklanan (Google, Yandex, Mail.ru), rangkaian sosial (VK, Facebook, Twitter), sistem AdServing dan analitik utama (DCM, Adriver, Weborama, Google Analytics) dan platform lain.
Majoriti tapak yang kami pilih mempunyai API yang menyediakan metrik yang kami perlukan. Dalam kes di mana tiada API atau ia tidak mengandungi data yang diperlukan, kami menggunakan laporan yang dihantar setiap hari ke e-mel pejabat kami untuk memuatkan data (dalam sesetengah sistem adalah mungkin untuk mengkonfigurasi laporan sedemikian, dalam yang lain kami bersetuju dengan pembangunan laporan tersebut. untuk kami).
Apabila menganalisis data dari tapak yang berbeza, kami mendapati bahawa hierarki entiti tidak sama dalam sistem yang berbeza. Selain itu, maklumat perlu dimuat turun secara terperinci berbeza daripada sistem yang berbeza.
Untuk menyelesaikan masalah ini, konsep SubDANBoID telah dibangunkan. Idea SubDANBoID agak mudah, kami menandakan entiti utama kempen di tapak dengan DANBoID yang dijana, dan kami memuat naik semua entiti bersarang dengan pengecam tapak unik dan membentuk SubDANBoID mengikut prinsip DANBoID + pengecam peringkat pertama entiti bersarang + pengecam entiti bersarang tahap kedua +... Pendekatan ini membolehkan kami menyambungkan kempen pengiklanan dalam sistem yang berbeza dan memuat turun statistik terperinci mengenainya.
Kami juga terpaksa menyelesaikan masalah akses kepada kempen pada platform yang berbeza. Seperti yang kami tulis di atas, mekanisme mewakilkan akses kepada kempen kepada akaun teknikal yang berasingan tidak selalunya terpakai. Oleh itu, kami perlu membangunkan infrastruktur untuk kebenaran automatik melalui OAuth menggunakan token dan mekanisme untuk mengemas kini token ini.
Kemudian dalam artikel kami akan cuba menerangkan dengan lebih terperinci seni bina penyelesaian dan butiran teknikal pelaksanaan.
Seni bina penyelesaian 1.0
Apabila memulakan pelaksanaan produk baharu, kami memahami bahawa kami perlu segera menyediakan kemungkinan menyambungkan tapak baharu, jadi kami memutuskan untuk mengikuti laluan seni bina perkhidmatan mikro.
Semasa mereka bentuk seni bina, kami mengasingkan penyambung kepada semua sistem luaran - 1C, platform pengiklanan dan sistem iklan - kepada perkhidmatan yang berasingan.
Idea utama ialah semua penyambung ke tapak mempunyai API yang sama dan merupakan penyesuai yang membawa API tapak kepada antara muka yang sesuai untuk kami.
Di tengah-tengah produk kami ialah aplikasi web, iaitu monolit yang direka bentuk sedemikian rupa sehingga ia boleh dibongkar dengan mudah ke dalam perkhidmatan. Aplikasi ini bertanggungjawab untuk memproses data yang dimuat turun, mengumpul statistik daripada sistem yang berbeza dan membentangkannya kepada pengguna sistem.
Untuk berkomunikasi antara penyambung dan aplikasi web, kami perlu mencipta perkhidmatan tambahan, yang kami panggil Proksi Penyambung. Ia melaksanakan fungsi Penemuan Perkhidmatan dan Penjadual Tugas. Perkhidmatan ini menjalankan tugas pengumpulan data untuk setiap penyambung setiap malam. Menulis lapisan perkhidmatan adalah lebih mudah daripada menyambungkan broker mesej, dan bagi kami adalah penting untuk mendapatkan hasilnya secepat mungkin.
Untuk kesederhanaan dan kelajuan pembangunan, kami juga memutuskan bahawa semua perkhidmatan akan menjadi API Web. Ini memungkinkan untuk memasang bukti konsep dengan cepat dan mengesahkan bahawa keseluruhan reka bentuk berfungsi.
Tugas yang berasingan dan agak rumit ialah menyediakan akses untuk mengumpul data daripada akaun yang berbeza, yang, seperti yang kami putuskan, harus dijalankan oleh pengguna melalui antara muka web. Ia terdiri daripada dua langkah berasingan: pertama, pengguna menambah token untuk mengakses akaun melalui OAuth, dan kemudian mengkonfigurasi pengumpulan data untuk pelanggan daripada akaun tertentu. Mendapatkan token melalui OAuth adalah perlu kerana, seperti yang telah kami tulis, tidak selalu mungkin untuk mewakilkan akses kepada akaun yang diingini di tapak.
Untuk mencipta mekanisme universal untuk memilih akaun daripada tapak, kami perlu menambahkan kaedah pada API penyambung yang mengembalikan Skema JSON, yang dipaparkan ke dalam borang menggunakan komponen JSONEditor yang diubah suai. Dengan cara ini, pengguna dapat memilih akaun untuk memuat turun data.
Untuk mematuhi had permintaan yang wujud di tapak, kami menggabungkan permintaan untuk tetapan dalam satu token, tetapi kami boleh memproses token yang berbeza secara selari.
Kami memilih MongoDB sebagai storan untuk data yang dimuatkan untuk aplikasi web dan penyambung, yang membolehkan kami tidak terlalu risau tentang struktur data pada peringkat awal pembangunan, apabila model objek aplikasi berubah setiap hari.
Kami tidak lama lagi mendapati bahawa tidak semua data sesuai dengan baik dalam MongoDB dan, sebagai contoh, adalah lebih mudah untuk menyimpan statistik harian dalam pangkalan data hubungan. Oleh itu, untuk penyambung yang struktur datanya lebih sesuai untuk pangkalan data hubungan, kami mula menggunakan PostgreSQL atau MS SQL Server sebagai storan.
Seni bina dan teknologi yang dipilih membolehkan kami membina dan melancarkan produk D1.Digital dengan agak cepat. Sepanjang dua tahun pembangunan produk, kami membangunkan 23 penyambung ke tapak, memperoleh pengalaman yang tidak ternilai bekerja dengan API pihak ketiga, belajar untuk mengelakkan perangkap tapak yang berbeza, yang masing-masing mempunyai tapak sendiri, menyumbang kepada pembangunan API sekurang-kurangnya 3 laman web, memuat turun maklumat secara automatik pada hampir 15 kempen dan untuk lebih daripada 000 peletakan, mengumpulkan banyak maklum balas daripada pengguna mengenai operasi produk dan berjaya mengubah proses utama produk beberapa kali, berdasarkan maklum balas ini.
Seni bina penyelesaian 2.0
Dua tahun telah berlalu sejak permulaan pembangunan D1.Digital. Peningkatan berterusan dalam beban pada sistem dan kemunculan lebih banyak sumber data baharu secara beransur-ansur mendedahkan masalah dalam seni bina penyelesaian sedia ada.
Masalah pertama adalah berkaitan dengan jumlah data yang dimuat turun dari tapak. Kami berhadapan dengan hakikat bahawa mengumpul dan mengemas kini semua data yang diperlukan dari tapak terbesar mula mengambil terlalu banyak masa. Contohnya, mengumpul data daripada sistem penyajian AdRiver, yang dengannya kami menjejaki statistik untuk kebanyakan peletakan, mengambil masa kira-kira 12 jam.
Untuk menyelesaikan masalah ini, kami mula menggunakan semua jenis laporan untuk memuat turun data dari tapak, kami cuba membangunkan API mereka bersama-sama dengan tapak supaya kelajuan operasinya memenuhi keperluan kami, dan menyelaraskan muat turun data sebanyak mungkin.
Masalah lain berkaitan dengan pemprosesan data yang dimuat turun. Kini, apabila statistik peletakan baharu tiba, proses berbilang peringkat pengiraan semula metrik dilancarkan, yang termasuk memuatkan data mentah, mengira metrik agregat untuk setiap tapak, membandingkan data daripada sumber yang berbeza antara satu sama lain dan mengira metrik ringkasan untuk kempen. Ini menyebabkan banyak beban pada aplikasi web yang melakukan semua pengiraan. Beberapa kali, semasa proses pengiraan semula, aplikasi menggunakan semua memori pada pelayan, kira-kira 10-15 GB, yang mempunyai kesan paling buruk terhadap kerja pengguna dengan sistem.
Masalah yang dikenal pasti dan rancangan bercita-cita tinggi untuk pembangunan selanjutnya produk membawa kami kepada keperluan untuk mempertimbangkan semula seni bina aplikasi.
Kami bermula dengan penyambung.
Kami mendapati bahawa semua penyambung berfungsi mengikut model yang sama, jadi kami membina rangka kerja saluran paip di mana untuk mencipta penyambung anda hanya perlu memprogramkan logik langkah-langkah, selebihnya adalah universal. Jika sesetengah penyambung memerlukan penambahbaikan, maka kami segera memindahkannya ke rangka kerja baharu pada masa yang sama semasa penyambung sedang diperbaiki.
Pada masa yang sama, kami mula menggunakan penyambung ke Docker dan Kubernetes.
Kami merancang perpindahan ke Kubernetes untuk masa yang agak lama, bereksperimen dengan tetapan CI/CD, tetapi mula bergerak hanya apabila satu penyambung, disebabkan ralat, mula memakan lebih daripada 20 GB memori pada pelayan, secara praktikal membunuh proses lain . Semasa penyiasatan, penyambung telah dialihkan ke gugusan Kubernetes, di mana ia akhirnya kekal, walaupun selepas ralat telah dibetulkan.
Dengan cepat kami menyedari bahawa Kubernetes adalah mudah, dan dalam masa enam bulan kami memindahkan 7 penyambung dan Proksi Penyambung, yang menggunakan paling banyak sumber, kepada kelompok pengeluaran.
Mengikuti penyambung, kami memutuskan untuk menukar seni bina aplikasi yang lain.
Masalah utama ialah data datang daripada penyambung kepada proksi dalam kelompok besar, dan kemudian memukul DANBoID dan dihantar ke aplikasi web pusat untuk diproses. Disebabkan bilangan pengiraan semula metrik yang banyak, terdapat beban yang besar pada aplikasi.
Ia juga terbukti agak sukar untuk memantau status kerja pengumpulan data individu dan melaporkan ralat yang berlaku dalam penyambung kepada aplikasi web pusat supaya pengguna dapat melihat apa yang berlaku dan sebab data tidak dikumpul.
Untuk menyelesaikan masalah ini, kami membangunkan seni bina 2.0.
Perbezaan utama antara versi baharu seni bina ialah bukannya API Web, kami menggunakan RabbitMQ dan perpustakaan MassTransit untuk bertukar-tukar mesej antara perkhidmatan. Untuk melakukan ini, kami terpaksa menulis semula hampir sepenuhnya Proksi Penyambung, menjadikannya Hub Penyambung. Nama telah ditukar kerana peranan utama perkhidmatan bukan lagi dalam memajukan permintaan kepada penyambung dan belakang, tetapi dalam mengurus pengumpulan metrik daripada penyambung.
Daripada aplikasi web pusat, kami mengasingkan maklumat tentang peletakan dan statistik daripada tapak kepada perkhidmatan yang berasingan, yang membolehkan anda menyingkirkan pengiraan semula yang tidak perlu dan hanya menyimpan statistik yang telah dikira dan agregat pada peringkat peletakan. Kami juga menulis semula dan mengoptimumkan logik untuk mengira statistik asas berdasarkan data mentah.
Pada masa yang sama, kami memindahkan semua perkhidmatan dan aplikasi ke Docker dan Kubernetes untuk menjadikan penyelesaian lebih mudah untuk skala dan lebih mudah untuk diurus.
Di manakah kita sekarang
Produk seni bina bukti konsep 2.0 D1.Digital bersedia dan bekerja dalam persekitaran ujian dengan set penyambung terhad. Apa yang perlu dilakukan ialah menulis semula 20 penyambung lain ke platform baharu, menguji bahawa data dimuatkan dengan betul dan semua metrik dikira dengan betul, dan melancarkan keseluruhan reka bentuk ke dalam pengeluaran.
Malah, proses ini akan berlaku secara beransur-ansur dan kami perlu meninggalkan keserasian ke belakang dengan API lama untuk memastikan semuanya berfungsi.
Pelan segera kami termasuk pembangunan penyambung baharu, penyepaduan dengan sistem baharu dan menambah metrik tambahan pada set data yang dimuat turun daripada tapak bersambung dan sistem penyajian.
Kami juga merancang untuk memindahkan semua aplikasi, termasuk aplikasi web pusat, ke Docker dan Kubernetes. Digabungkan dengan seni bina baharu, ini akan memudahkan penggunaan, pemantauan dan kawalan sumber yang digunakan dengan ketara.
Idea lain adalah untuk bereksperimen dengan pilihan pangkalan data untuk menyimpan statistik, yang kini disimpan dalam MongoDB. Kami telah pun memindahkan beberapa penyambung baharu ke pangkalan data SQL, tetapi di sana perbezaannya hampir tidak dapat dilihat, dan untuk statistik agregat mengikut hari, yang boleh diminta untuk tempoh sewenang-wenangnya, keuntungan boleh menjadi agak serius.
Secara umum, rancangan itu hebat, mari teruskan :)
Pengarang artikel R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Sumber: www.habr.com