GDPR, yang mulai berlaku pada Mei tahun ini, telah sangat memengaruhi pasar pemasaran Internet. Pesertanya ingin membentuk audiens yang paling akurat untuk menampilkan iklan, tetapi sekarang untuk ini, perlu untuk mendapatkan persetujuan eksplisit dari pengguna, jika tidak, bahkan sumber daya niche kecil dapat mengalami denda jutaan. Beberapa sumber daya telah ditutup, tetapi banyak yang dikonversi untuk memenuhi persyaratan baru. Dan proyek kami tentang layanan manajemen kampanye iklan untuk klien dari AS adalah contoh yang bagus untuk ini.
Tentang layanan
Klien kami, sebuah perusahaan Amerika dari Los Angeles, berfokus pada pemasaran di industri musik. Layanannya menyediakan dukungan untuk kampanye periklanan yang rumit untuk tim dengan berbagai ukuran - mulai dari geng di tikungan hingga bintang-bintang di panggung dunia.
Pada dasarnya, layanan pelanggan kami adalah startup yang mengembangkan platform pemasaran khusus yang berhasil mengumpulkan investasi dari perusahaan rekaman, karena mempertimbangkan perilaku perilaku audiens yang spesifik dalam industri tertentu. Platform ini memungkinkan Anda untuk menargetkan iklan dengan menganalisis perilaku pengguna yang pernah menunjukkan minat pada tim tertentu. Pengguna utama sumber daya adalah musisi dan pekerja industri (manajer, karyawan perusahaan rekaman, penyelenggara konser dan banyak lainnya).
Pada saat proyek kami dimulai, layanan sudah berfungsi dan berhasil mendapatkan posisi tertentu di pasar. Namun, itu lebih merupakan prototipe yang menguji hipotesis dasar suatu bisnis, terutama karena bagian dari fungsi diimplementasikan melalui layanan mitra. Kami terhubung ke pengembangan untuk menciptakan arsitektur yang lengkap, dan GDPR adalah dorongan yang meluncurkan semua transformasi. Tugas kami bukan hanya memperbarui layanan yang ada, tetapi membangunnya kembali dengan undang-undang baru, untuk menyegarkan dan membawa ke antarmuka pengguna yang lebih seragam.
Implementasi
Seluruh proyek dibagi menjadi beberapa tahap.
Pada tahap pertama, kami menulis ulang dari awal bagian yang sebelumnya bekerja di PHP - penyingkat tautan dan layanan otorisasi.
Link shortener adalah bagian dari fungsionalitas yang tersedia secara gratis untuk semua pengguna terdaftar dan digunakan untuk menarik pelanggan ke layanan berbayar perusahaan. Layanan ini memungkinkan Anda untuk membawa tautan panjang ke formulir pendek untuk mempublikasikannya di jejaring sosial. Pada saat yang sama, Anda dapat mengubahsuaikan tautan dengan menetapkan, misalnya, penargetan geografis: tergantung pada negara asal pengguna, ia dapat ditampilkan laman landas berbeda.
Memperbarui backend, kami menggunakan OpenJDK 1.8, Kotlin dan Spring boot / data / web - kerangka kerja standar untuk proyek yang tidak mengharapkan beban tinggi. Ngomong-ngomong, dalam proyek inilah kami mencoba Kotlin "dalam pertempuran" untuk pertama kalinya, dan karena sintaksnya, itu memungkinkan kami untuk mempercepat pembangunan secara signifikan. Tentunya, kami akan menggunakannya dalam proyek lain.
Basis data layanan otorisasi dan pemendek yang diimplementasikan pada tahap pertama dibangun berdasarkan PostgreSQL - model penyimpanan data relasional sangat cocok untuk menyelesaikan masalah ini.
Pada tahap kedua, kami mengambil pengelolaan kampanye iklan. Fungsionalitas ini pada platform klien juga ada sebelumnya, tetapi melalui layanan mitra, yang harus Anda bayar. Sekarang platform pelanggan telah berkembang ke titik di mana diperlukan untuk menjaga infrastrukturnya. Layanan sendiri, tidak seperti pihak ketiga, jauh lebih mudah untuk dikembangkan ke arah yang benar, dengan cepat membuat perubahan yang diperlukan.
Di bagian proyek ini, kami hanya menerapkan API eksternal untuk manajer kampanye. Tetapi pada tahap ketiga kami mengembangkan modul ini - kami menyelesaikan API dan membuat UI lengkap untuk manajer kampanye.
Secara paralel, kami mengembangkan DMP kecil (platform manajemen data) yang mengelola pengumpulan data pengunjung. Data DMP disimpan dalam MongoDB, karena kami memutuskan untuk meninggalkan dasar untuk penskalaan horizontal masa depan dari database ini. Sekarang DMP melayani hingga 2 ribu permintaan per detik (dalam puncak), sementara kami fokus untuk menyimpan sekitar satu terabyte data. Volume seperti itu bisa saja disimpan dalam PostgreSQL, tetapi dalam jangka panjang akan diperlukan untuk menggunakan upaya besar untuk penskalaan.
MongoDB yang sama digunakan dalam database manajer kampanye (DB Kampanye) - di sini model basis data yang berorientasi pada dokumen mendekati kami dengan baik. Kampanye berjalan sebagai entitas tunggal dan dapat diperluas.
Semua cache bekerja pada Redis.
Frontend: Angular 5, TypeScript, HTML5, Sass, Node.js, npm, CLI sudut.
Selama tahap terakhir proyek, kami menyelesaikan integrasi sistem pelanggan dan layanan dari mitra utama, membuka akses ke sejumlah besar musisi untuk perusahaan, yang akan memastikan peningkatan jumlah pengguna.
Ada beberapa kesulitan dalam proyek ini. Pelanggan ingin menyimpan data pengguna dan pendaftaran yang terakumulasi selama pengoperasian layanan, sementara sedikit mengubah model. Sejalan dengan perubahan arsitektur, kami mentransfer pendaftaran dan mengubah prinsipnya - dari nama pengguna ke email sebagai info masuk, yang membuat kami tidak bisa tidur karena pembatasan jumlah pengguna dengan alamat email yang sama. Model hak dalam sistem telah berubah. Sebelumnya, layanan bekerja berdasarkan model dua tingkat, tetapi kami menerapkan model hak tanpa batasan (termasuk kemampuan untuk mengeluarkan hak terbatas).
Pada saat yang sama, fungsionalitas diperluas. Misalnya, pada satu tahap multistore muncul, dengan bantuan yang untuk pengunjung akhir yang mengklik tautan pendek ke komposisi tertentu, Anda dapat mengatur halaman dengan daftar layanan di mana komposisi ini tersedia untuk pembelian atau mendengarkan yang sah.
Layak dikatakan secara terpisah tentang GDPR
Pasar utama klien kami adalah Amerika Serikat, tetapi sekitar 10% dari lalu lintas yang perusahaan tidak ingin kehilangan berasal dari Eropa. Sejak peraturan baru ini mulai berlaku (25 Mei 2018), penargetannya telah dinonaktifkan. Setelah berkonsultasi dengan pengacara, kami membangun layanan sedemikian rupa sehingga tidak bertentangan dengan GDPR, dan mulai 16 Agustus kami mulai menargetkan kembali.
Jujur, kami mempelajari seluk-beluk peraturan selama dua minggu. Kesulitan pada tahap ini adalah bahwa, dengan ketidakjelasan umum kata-kata, sejauh ini tidak ada praktik penegakan hukum - kasus nyata yang dapat menunjukkan bagaimana melakukannya dengan benar dan apa yang salah. Namun, sekarang (setelah penelitian dan konsultasi kami sendiri dengan pengacara), kami yakin akan arsitektur solusi yang diterapkan.
Logika layanan ini menyiratkan menambahkan pengguna yang mengikuti tautan singkat ke audiens tertentu, sehingga nantinya ia dapat ditampilkan iklan. Dalam hal GDPR, ini tidak dapat dilakukan tanpa persetujuan eksplisit dari pengguna. Dan kami menerapkan permintaan persetujuan - ketika Anda mengklik tautan di bagian bawah halaman, sebuah piring muncul dengan sebuah pertanyaan dan dua tombol. Permintaan dibuka untuk pengguna yang IP-nya milik Eropa, dan respons mereka disimpan dalam bentuk cookie, sehingga pengunjung tidak perlu menekan tombol setiap kali.
Jika tidak ada persetujuan pengguna (mis. Cookie), kami tidak menunjukkannya dalam pixel, mis. dalam statistik umum layanan, fakta kunjungan akan dihitung, tetapi data pengguna tidak akan dikumpulkan dan diperhitungkan.
GDPR memberlakukan batasan arsitektur - data pribadi tidak hanya harus dikumpulkan dengan benar, tetapi juga disimpan dengan aman. Dalam kasus kami, pembatasan ini berlaku untuk DMP yang diterapkan (terlepas dari kenyataan bahwa itu menyimpan data anonim dengan pengidentifikasi anonim yang hanya secara hipotesis memungkinkan mereka untuk melakukan deanonimisasi) dan basis data layanan otorisasi. Dalam arsitektur kami, pangkalan-pangkalan ini jelas dialokasikan dalam blok-blok terpisah. Sesuai dengan peraturan, akses pihak ketiga ke modul "sensitif" ini secara alami terbatas.
Hanya layanan terkait yang memiliki akses ke database otorisasi. Semua layanan lain tidak tahu apa-apa tentang data pribadi pengguna platform - mereka hanya perlu validasi dari layanan otorisasi.
Basis data DMP juga hanya mencakup layanan eponymous. Pada saat yang sama, hanya agregat data audiens yang dikembalikan dari database, tetapi bukan data itu sendiri. Agregat ini membentuk dasar analitik yang diterima pengguna layanan dari industri musik di akun pribadi mereka.
Kami juga memiliki prosedur wajib untuk mengunggah dan menghapus data pengguna. Ada pertanyaan tentang cara memverifikasi bahwa pengguna benar-benar meminta datanya. Dan kami menggunakan cookie yang disimpan oleh pengguna sebagai faktor untuk verifikasi.
Proyek ini selesai baru-baru ini, jadi masih terlalu dini untuk membicarakan hasil numerik apa pun.
Penulis artikel: Nikolay Eremin
PS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di
VK ,
FB atau
saluran Telegram untuk mencari tahu tentang semua publikasi kami dan berita Maxilect lainnya.