Aspek Teknis Segmentasi Pelanggan – Sinkronisasi Data

"Pengalaman luas menganalisis dan mensegmentasi basis data CRM," "Pegangan yang kuat tentang segmentasi audiens," "Memahami dan pengalaman segmentasi data dan menyajikan konten yang dipersonalisasi." Ini adalah contoh persyaratan paling umum yang ditempatkan dalam tawaran pekerjaan pemasaran CRM/siklus hidup. Meskipun konsep segmentasi pelanggan cukup sederhana dan mudah untuk dimulai, menjadi ahli segmentasi memerlukan penyelaman ke dalam detail teknis. Dengan artikel ini, kami ingin membantu Anda mengambil lompatan ini.

Daftar Isi:

1. Kompleksitas penyimpanan dan format
2. format data
3. Frekuensi sinkronisasi
4. Media sinkronisasi data
5. dunia pertama API
6. Pemicu sinkronisasi data
   

Segmentasi pelanggan dimulai dengan mengumpulkan data pelanggan di satu tempat terpusat dan membuatnya siap untuk dikelompokkan dan ditindaklanjuti. Kedengarannya mudah, tetapi semakin banyak sumber data menambah kompleksitas pengumpulan dan pengolahan data.

Itu sebabnya segmentasi yang efisien dimulai dengan memastikan aliran data yang konsisten dari beberapa sumber data ke satu server. Proses ini telah mendapatkan nama yang mungkin sering Anda dengar baru-baru ini — sinkronisasi data atau sekadar sinkronisasi data . Ini adalah proses membangun konsistensi di antara sistem dan pembaruan berkelanjutan berikutnya untuk menjaga keseragaman.

Banyak kata-kata pintar berarti bahwa itu terutama domain tim teknik. Tetapi membuat diri Anda terbiasa dengan konsep-konsep kunci sangat membantu. Berikut ikhtisarnya:

• Sinkronisasi data – di bagian ini kita akan mempelajari bagaimana data pelanggan disimpan, mengapa orang ingin memindahkannya, dan hambatan apa yang perlu diatasi oleh tim digital untuk melakukannya. Pada catatan yang lebih praktis, bab ini menjelaskan bagian dalam tentang bagaimana sistem CRM modern bertukar data melalui Internet dengan API.
• Integritas & keamanan data – bagian selanjutnya akan membantu Anda memahami apa yang diperlukan untuk menjaga data tetap konsisten setelah Anda menyinkronkannya. Kita akan mempelajari bagaimana Anda dapat menggunakan skema untuk menjaga keunikan data dan mencegah duplikasi data. Terakhir, kami akan membahas aspek teknis keamanan dan privasi data karena mereka telah menjadi warga negara kelas satu di masa pasca-GDPR dan CCPA.
• Penguraian data – terakhir, kami akan membantu Anda menjadi lancar dengan menunjukkan beberapa kiat tentang pemfilteran data dan membuat keputusan berdasarkan data secara umum.

Kompleksitas penyimpanan dan format

Karena perkembangan teknologi baru-baru ini, biaya penyimpanan data telah turun. Ini memungkinkan perusahaan untuk mengumpulkan sejumlah besar data.

Data ini dapat dibagi menjadi dua kategori: terstruktur dan tidak terstruktur . Agar segmentasi berhasil, tim digital perlu mencari cara untuk beralih dari tidak terstruktur ke terstruktur.

Yang kami maksud dengan penyimpanan data terstruktur adalah database SQL atau file Excel . Mereka adalah alat yang hebat dan serbaguna, tetapi juga memiliki kekurangan. SQL sulit dipelajari untuk orang tanpa latar belakang teknis, keunggulan utama Excel, fleksibilitas, menjadi mimpi buruk untuk pemeliharaan integritas data jangka panjang. Itulah sebabnya alat perangkat lunak serba guna ini telah disuperstruktur dengan alat yang lebih terfokus seperti CRM, CMS, ERP, atau alat analitik.

Meskipun alat berorientasi pekerjaan ini meningkatkan produktivitas di area tempat mereka dipekerjakan, alat ini sering menjadi masalah di tingkat departemen/perusahaan. Mengapa itu? Masing-masing alat ini biasanya menggunakan format datanya sendiri dan, kecuali jika kedua platform perangkat lunak terintegrasi satu sama lain, pertukaran data terhambat. Dan, pemasar modern menggunakan banyak sekali alat semacam itu.

Inilah sebabnya mengapa sebagian besar proses sinkronisasi data memerlukan perantara . Ini menyesuaikan format data yang dihasilkan oleh perangkat lunak pembuat (disebut "sumber" di dunia TI) ke format tujuan ("target"). Proses adaptasi tersebut disebut ETL. Ini adalah singkatan dari Extract (data dari sumber), Transform (dengan cara yang dikenali dan diterima oleh target), Load (ke target menjaga konsistensi data).

Format data seperti apa yang dapat Anda temui di industri segmentasi pelanggan?

format data

Saat ini, perangkat lunak segmentasi menggunakan dua format terbuka untuk tujuan sinkronisasi data dalam banyak kasus. Tapi apa sih "format data" itu? Ini tidak lebih dari teks yang terstruktur dengan cara yang dapat dimengerti oleh komputer. Mari kita mulai dengan yang pertama, yang lebih sederhana.

CSV – Nilai yang Dipisahkan Koma. Bayangkan Anda mengambil meja. Tabel biasa dari MS Word baik-baik saja. Sekarang mari kita hapus batas eksternal dan ganti batas internal dengan koma. Voila, Anda baru saja membuat file CSV.

Keuntungan terbesar? Kesederhanaan dan kekompakan. Pengembang dapat dengan mudah mengekspor data dalam format ini karena database SQL dan Excel menyimpan data dalam tabel.

Di sisi lain, CSV memiliki dua kelemahan utama. Pertama, dalam file CSV, Anda tidak dapat merepresentasikan hierarki. Misalnya, Anda tidak dapat menunjukkan bahwa satu nilai terkait dengan nilai lainnya. Kelemahan terpenting kedua adalah bahwa CSV adalah format tetap. Ini memungkinkan Anda untuk bertukar data sesuai dengan jumlah dan jenis kolom yang Anda tentukan di awal. Jika Anda menambahkan kolom yang diperlukan untuk sistem target lain atau hanya menghapus kolom, itu akan menyebabkan kesalahan pada upaya impor. Dalam kasus seperti itu, pengembang perlu menyesuaikan kode untuk mencerminkan perubahan struktural.

Karena dinamika yang diperoleh teknologi pemasaran dalam beberapa tahun terakhir, keterbatasan ini ternyata menjadi penghalang utama.

Untuk alasan ini, sistem modern mulai bertukar data dengan data XML dan JSON . Keduanya didasarkan pada konsep representasi data yang sama. Kami akan menjelaskan yang terakhir karena lebih populer.

Ini adalah contoh file JSON. Saat kami membandingkan file JSON kami dengan rekan CSV, kami akan segera menemukan kesamaan — kami dapat melihat bahwa file ini menyimpan data yang sama persis.

Perbedaan mencolok adalah bahwa nama kolom dari file CSV diulang. Meskipun ini mungkin tampak berlebihan dan menghalangi keterbacaan manusia, pengulanganlah yang memberikan fleksibilitas JSON – hal ini membuat urutan item menjadi tidak relevan. Ini berguna jika Anda perlu menambahkan properti baru (kolom) ke file yang dipertukarkan. Perangkat lunak target yang mengharapkan properti baru akan mengkonsumsinya, sedangkan target yang memproses file sebelum penambahan kolom, akan mengabaikan properti baru dan akan bekerja tanpa gangguan.

Fitur ini menjamin bahwa jika Anda menambahkan lebih banyak bidang ke format data yang dikirim oleh aplikasi sumber, itu tidak akan merusak target. Inilah sebabnya mengapa format JSON dikatakan lebih terukur dan lebih fleksibel daripada CSV .

Anda dapat membaca lebih lanjut tentang file JSON di sini.

Frekuensi sinkronisasi

Persyaratan umum saat ini adalah bahwa sistem e-niaga bersifat real-time . Pelanggan ingin melihat status pesanan mereka, pelacakan paket real-time, atau saldo saat ini di akun mereka. Selain itu, pemasar ingin bereaksi cepat, mereka ingin menjalankan kampanye waktu nyata yang menciptakan pengalaman belanja tepat waktu.

Untuk mencapai itu, penyimpanan data yang mendasarinya telah mengadopsi sinkronisasi waktu-nyata .

Namun, ada dua tantangan dengan sinkronisasi waktu nyata yang harus diperhatikan.

Pertama, aturan umum — semakin tepat waktu yang Anda inginkan, semakin mahal biayanya . Biaya ini terwujud dalam waktu pengembang tetapi juga dengan perangkat keras yang menjalankan server (saat ini sebagian besar solusi cloud), Anda perlu menjaga sistem sinkronisasi data tetap berjalan. Jadi, tugas pertama Anda sebelum menetapkan persyaratan "waktu nyata" saat berbicara dengan teknisi adalah mempertimbangkan jenis frekuensi sinkronisasi data yang benar-benar Anda butuhkan. Mungkin, pembaruan yang dikirim satu jam sekali atau sekali sehari sudah cukup untuk memastikan pengalaman pelanggan yang luar biasa sekaligus mengurangi pekerjaan pengembang dan menghemat anggaran.

Tantangan lainnya adalah kemampuan ekstraksi data dari penyimpanan data yang Anda gunakan. Terkadang sinkronisasi waktu nyata mungkin terhambat saat salah satu sistem tidak menyediakan cara mudah untuk mengekstrak data. Mudah artinya ramah pengembang. Mari kita analisis masalah ini secara mendetail dengan mempelajari cara pengembang memindahkan data di sekitar sistem.

Media sinkronisasi data

Kami telah mempelajari bagaimana data disimpan, format apa yang digunakan untuk pertukaran, dan bagaimana frekuensi sinkronisasi dapat memengaruhi upaya pengaturan seluruh sistem sinkronisasi. Tapi apa yang sebenarnya diperlukan untuk mentransfer data dari satu database ke database lainnya? Nah, Anda membutuhkan media.

Ini bisa berupa penyimpanan fisik seperti DVD, drive USB, atau sinkronisasi berbasis perangkat keras lainnya, tetapi dengan jumlah data yang sangat besar dan persyaratan sinkronisasi waktu nyata, hanya sedikit yang melakukannya hari ini. Dalam sebagian besar kasus, semuanya dilakukan melalui kabel, atau sebenarnya banyak kabel yang saling terhubung oleh komputer di seluruh dunia — yang disebut Internet.

Untuk lebih spesifik, platform perangkat lunak modern menggunakan Hypertext Transfer Protocol (HTTP) yang merupakan dasar dari World Wide Web.

Jika Anda tertarik (dan sebaiknya!) tentang bagaimana server berbicara satu sama lain melalui Internet, kami sangat menyarankan untuk beralih ke panduan non-teknisi ke server ini.

Singkatnya, Anda dapat memperlakukan protokol HTTP seperti pedoman yang memberi tahu pengembang bagaimana mereka mengirim data melalui Internet. Di atas HTTP, pengembang membuat Antarmuka Pemrograman Aplikasi (API) yang merupakan deskripsi spesifik tentang data apa dan dalam urutan apa yang dapat dipertukarkan antara dua sistem.

Perangkat lunak yang membuat API tersedia di Internet dan membuatnya dapat diakses oleh sistem lain (mirip dengan cara Anda mengunjungi halaman web biasa) disebut server aplikasi. Semua yang dilakukannya adalah mendengarkan dan menanggapi permintaan yang datang dari server aplikasi lain, dan tergantung pada permintaan itu menambahkan atau mendapatkan informasi dari database yang mendasarinya. Informasi yang berguna: ketika orang menyebut API, itu sering kali merupakan jalan pintas untuk server aplikasi yang memaparkan API ke Internet.

Mari kita bermain dengan API.

dunia pertama API

API telah menjadi lingua franca pemasaran digital saat ini. Sebagian besar pekerjaan sinkronisasi data saat ini adalah mempelajari API agar dapat mengekstrak data darinya. Ini seperti mempelajari kumpulan kata lain dari bahasa asing, dengan asumsi Anda mengetahui tata bahasanya, yang dalam hal ini didefinisikan oleh HTTP.

Meskipun ini adalah tugas pengembang, menyelami topik ini dapat membantu Anda menavigasi dunia teknologi pemasaran.

Kami telah membuat artikel khusus dengan beberapa contoh praktis tentang memahami API, jadi jika Anda ingin menguasainya (dan sekali lagi, Anda harus), bacalah di sini .

Ini adalah kutipan terpenting darinya:

“Jika Anda pergi ke restoran sebagai pelanggan, Anda tidak diperbolehkan masuk ke dapur. Anda perlu tahu apa yang tersedia. Untuk itu, Anda memiliki menu. Setelah melihat menu, Anda membuat pesanan ke pelayan, yang menyerahkannya ke dapur dan yang kemudian akan mengantarkan apa yang Anda minta. Pelayan hanya bisa mengantarkan apa yang bisa disediakan dapur.

Bagaimana hubungannya dengan API? Pelayan adalah API. Anda adalah seseorang yang meminta layanan. Dengan kata lain, Anda adalah pelanggan atau konsumen API. Menu adalah dokumentasi yang menjelaskan apa yang dapat Anda minta dari API. Dapur adalah, misalnya, sebuah server; database yang hanya menyimpan jenis data tertentu — apa pun yang dibeli pembeli untuk restoran sebagai bahan dan apa yang telah diputuskan oleh koki untuk mereka tawarkan dan apa yang diketahui oleh juru masak untuk menyiapkannya.”

• Dapur – Basis data, tidak ada pelanggan yang diizinkan untuk melindungi integritas data.
• Waiter – API, perantara yang tahu cara menyajikan data dari database tanpa mengganggu fungsinya.
• Pelanggan – Sistem eksternal yang ingin mendapatkan data mereka.
• Menu – Referensi format data yang harus digunakan sistem eksternal untuk menjalankan operasinya.
• Pesanan – Panggilan API tunggal yang sebenarnya.

Kembali ke sinkronisasi, pertanyaan yang tersisa sekarang adalah mencari tahu dalam kondisi apa dua sistem harus bertukar data.

Pemicu sinkronisasi data

Mari kita asumsikan kita memiliki dua server aplikasi yang siap untuk bertukar informasi. Untuk lebih spesifik, bayangkan penyedia layanan email ( ESP ) Anda ingin mengetahui jumlah pesanan pelanggan (e-shop) untuk mengirimi mereka kupon promo setelah pesanan kesepuluh. Sekarang, aliran data seperti apa yang dapat kita terapkan untuk mencapai skenario ini? Kita dapat membedakan tiga "pemicu" yang dapat memulai mesin kupon email di sisi ESP.

a) Data polling – dalam hal ini ESP meminta API e-shop berulang kali: “Beri tahu saya total jumlah pesanan untuk Jane Doe”. Ia melakukannya setiap menit, satu jam, atau sehari, dll. Ketika ESP menerima informasi, ia akan menghitung ulang kondisi pengiriman kupon setiap permintaan API. Firasat Anda benar jika Anda berpikir ini mungkin kurang optimal untuk memanggil dan memproses data dengan cara ini. Apa alternatifnya?

b) Data push – bagaimana jika e-shop dapat memberitahu aplikasi ESP saat Jane melakukan pemesanan ke-10? Betul sekali. Platform e-niaga modern telah menyadari kekurangan ini dan memasukkan pemberitahuan tersebut ke dalam rangkaian fitur mereka. Mereka biasanya disebut webhook atau call-out. Ini adalah fungsi yang sederhana namun kuat. Ini memungkinkan Anda untuk menentukan kapan dan aplikasi mana yang harus diberi tahu dalam kondisi tertentu. Anda juga dapat menentukan jenis informasi apa yang harus disertakan dalam pemberitahuan — kadang-kadang wajar untuk mengirim informasi lengkap, tetapi seringkali hanya properti yang diubah saja yang cukup.

c) Pemrosesan batch – terkadang, jumlah permintaan sangat besar sehingga tidak satu pun dari kedua metode ini yang masuk akal. Jumlah daya pemrosesan yang diperlukan untuk menangani beban akan merugikan salah satu (atau bahkan keduanya) pihak. Dalam hal ini, pengembang mengelompokkan semua informasi dalam "batch" dan menjadwalkan pertukaran data di malam hari atau, lebih umum, ketika server tidak sibuk dengan lalu lintas harian. Ini membantu mengontrol lalu lintas ke aplikasi dan mencegah potensi ketegangan pada server Anda.

Istilah yang berguna: untuk mencegah pengiriman terlalu banyak permintaan ke server, pengembang aplikasi menerapkan pembatas kecepatan pada aplikasi mereka. Ini membatasi jumlah panggilan API dalam periode tertentu, misalnya 5000 panggilan per menit. Seringkali, panggilan yang melebihi kuota dibatasi . Ini berarti bahwa mereka akan dilayani pada akhirnya (alih-alih menjatuhkannya sama sekali) tetapi dengan beberapa penundaan.

Sejauh ini, kita telah mempelajari bagaimana data pelanggan disinkronkan. Namun sebelum segmentasi pelanggan yang sebenarnya dapat terjadi, kita perlu memahami bagaimana menjaga data tetap konsisten dalam database Anda. Di bagian selanjutnya, kami akan menjelaskan cara memastikan integritas dan keamanan data untuk mencapai kampanye yang berkinerja baik.