Cara membuat lembar kerja CDP dari kasus penggunaan Anda

Dunia teknologi pemasaran seringkali merupakan kekacauan yang membingungkan. Layanan yang ditawarkan oleh platform data pelanggan, platform pengelolaan data, platform otomasi pemasaran, dan penyedia layanan email sering tumpang tindih, dan mungkin sulit untuk memutuskan apa yang Anda butuhkan.

Jika Anda mempertimbangkan CDP, ada banyak pilihan, dan tersedia dalam beberapa rasa berbeda. Keunikan unik dari setiap CDP biasanya ditentukan oleh cerita asalnya. Sebagian besar CDP dimulai sebagai sesuatu yang lain dan menggunakan layanan tambahan untuk menjadi CDP yang lengkap. Yang dimulai sebagai penyedia layanan email (ESP) akan menjadi hewan yang berbeda dari yang dimulai sebagai mesin rekomendasi. Mereka juga berbeda apakah mereka lebih fokus pada B2B, B2C, ritel, penerbitan, dll.

Salah satu cara untuk menembus kabut adalah dengan membedakan layanan ini dengan komponen back-end dan front-end mereka.

Back-end vs front-end

Komponen back-end meliputi infrastruktur teknis dan proses yang digunakan untuk mengumpulkan, menyimpan, menyelaraskan, dan mengelola data pelanggan. Kategori ini biasanya mencakup integrasi data, pergudangan, tata kelola, dan fitur keamanan. Komponen back-end bertanggung jawab untuk memastikan bahwa data pelanggan akurat, lengkap, dan dapat diakses, dengan tujuan menggabungkan rekaman yang berbeda dari berbagai sumber untuk membuat satu tampilan pelanggan.

Komponen front-end CDP dapat dibagi menjadi fitur yang menghadap ke pemasar dan menghadap ke pelanggan. Sisi yang dihadapi pemasar akan mencakup visualisasi dan pelaporan data, sedangkan sisi yang dihadapi pelanggan mungkin mencakup mesin rekomendasi, manajemen paywall, dan tampilan konten khusus.

Beberapa CDP hampir secara eksklusif merupakan back-end, dengan hampir tidak ada fitur front-end yang menghadap ke pelanggan. CDP lain menyertakan banyak "aktivasi" front-end. Untuk membuatnya lebih rumit, semua fungsi ini tersedia dari layanan khusus yang berdiri sendiri.

Trik untuk mengevaluasi CDP adalah dengan mencari tahu komponen mana yang diperlukan untuk kasus penggunaan Anda, dan mana yang harus menjadi bagian dari CDP itu sendiri.

Misalnya, CDP mungkin memiliki ESP bawaan. Itu mungkin atau mungkin bukan hal yang baik untuk Anda. Jika salah satu kasus penggunaan Anda mengharuskan Anda mengirim email saat pengguna mengambil tindakan di situs web Anda, Anda memerlukan CDP agar dapat mengirim email, atau Anda memerlukan koneksi waktu nyata ke ESP eksternal.

Sangat membantu untuk memikirkan CDP seperti yang Anda pikirkan tentang resor liburan. Pemilik resor ingin dapat mengatakan bahwa resor tersebut memiliki beberapa aktivitas, seperti seluncuran air, sehingga mereka membangun seluncuran air token di properti tersebut. Ini tidak akan sebagus seluncuran air khusus di jalan, tetapi juga tidak di jalan. Itu ada di resor.

Dengan cara yang sama, ESP yang dibangun ke dalam CDP mungkin tidak akan memiliki fitur sebanyak ESP khusus, tetapi itu tidak masalah. Yang penting adalah solusi mana yang memenuhi persyaratan kasus penggunaan Anda.

Untuk membuatnya lebih rumit, ada banyak layanan “mirip CDP” yang melakukan beberapa pekerjaan CDP.

Untuk mengatasi kekacauan yang membingungkan ini, pertimbangkan beberapa kasus penggunaan dan lihat bagaimana metrik back-end vs. front-end dapat membantu.

Mesin rekomendasi untuk konten

Menambahkan rekomendasi yang disesuaikan ke artikel di situs web Anda dapat meningkatkan pengalaman pengunjung dengan merek Anda dan meningkatkan tampilan halaman.

Fungsionalitas yang diperlukan oleh kasus penggunaan tersebut bergantung pada data apa yang akan digunakan oleh mesin rekomendasi.

Jika Anda ingin merekomendasikan artikel berdasarkan (setidaknya sebagian) buletin elektronik yang diterima pelanggan, atau produk langganan pelanggan, Anda memerlukan koneksi back-end dengan ESP dan/atau sistem pemenuhan, dan Anda memerlukan kemampuan untuk menggabungkan profil online pengguna dengan data tersebut. Namun jika Anda hanya ingin membuat rekomendasi berdasarkan perilaku web pengguna, Anda tidak memerlukan fungsi back-end tersebut, dan Anda bahkan mungkin tidak memerlukan CDP. Banyak mesin rekomendasi yang berdiri sendiri dapat mengatasinya.

Pertanyaan untuk ditanyakan:

• Apakah kasus penggunaan ini memerlukan manajemen data back-end?
• Apakah fungsi front-end CDP cukup baik, atau apakah saya memerlukan layanan khusus?
• Apakah CDP terintegrasi dengan layanan khusus tersebut?

“Pelanggan yang membeli ini…”

Di ruang ritel, vendor ingin memberikan rekomendasi produk yang dapat meningkatkan nilai setiap pesanan.

Jika rekomendasi didasarkan (setidaknya sebagian) pada riwayat pesanan pelanggan, mesin rekomendasi memerlukan data back-end tersebut. Jika rekomendasi hanya berdasarkan rata-rata dari semua pelanggan, informasi spesifik tentang riwayat pembelian pelanggan tidak relevan.

Mengelola paywall

Penayang yang tidak ingin bergantung secara eksklusif pada pendapatan iklan untuk mendanai pembuatan kontennya dapat menawarkan akses ke konten premium dengan biaya tertentu. Ini membutuhkan pembuatan dan pemeliharaan akun untuk mengelola akses ke konten ini.

Dalam banyak kasus, akun tersebut perlu dikoordinasikan dengan akun lain, seperti langganan majalah. Misalnya, pelanggan majalah dapat melewati paywall secara gratis, atau dengan tarif diskon. Dalam hal ini, sistem manajemen paywall harus berintegrasi dengan data back-end dari sistem pemenuhan majalah.

Optimasi halaman arahan

Pengujian laman landas A/B atau multivarian dapat secara dramatis meningkatkan keberhasilan toko online, formulir online, dan halaman pendaftaran buletin elektronik. Layanan yang memfasilitasi pembuatan dan penerapan pengujian semacam itu biasanya tidak membedakan antara pelanggan dan non-pelanggan, dan tampaknya berfungsi untuk sebagian besar situasi. Dalam kasus tersebut, Anda tidak memerlukan CDP.

Namun, jika Anda memiliki alasan untuk meyakini bahwa pelanggan Anda sangat berbeda dari rata-rata pengunjung web, Anda mungkin memerlukan perhitungan pengoptimalan halaman arahan untuk menampilkan statistik yang berbeda untuk grup yang berbeda.

Misalnya, situs web dengan konten medis mungkin memiliki pemirsa terpisah yang mencakup profesional medis dan warga negara biasa. Anda tidak ingin hasil pengujian A/B pada laman landas untuk laporan yang ditulis untuk dokter menyertakan statistik tentang tanggapan orang lain. Dalam hal ini, informasi back-end tentang audiens mungkin sangat penting.

Gali lebih dalam: Apa itu a CDP dan bagaimana hal itu memberi pemasar 'pandangan tunggal' yang didambakan pelanggan mereka?

Survei

Survei dapat membantu Anda memahami pelanggan, yang dapat membantu Anda memberikan layanan yang lebih baik. Banyak CDP dapat mengelola survei, tetapi sangat sedikit CDP yang dapat bersaing dengan fungsionalitas platform survei khusus. Bagaimana hal ini memengaruhi evaluasi Anda terhadap vendor CDP potensial?

Pertanyaan untuk ditanyakan:

• Apakah survei saya akan ditingkatkan dengan menggabungkan data pelanggan back-end? (Misalnya, tidak menanyakan hal-hal yang sudah Anda ketahui, atau mengajukan pertanyaan yang berbeda kepada audiens yang berbeda.)
• Apakah penting untuk dapat memperpanjang proses survei dari waktu ke waktu melalui pembuatan profil progresif?

Membuat lembar kerja

Saya harap contoh-contoh ini mendorong Anda untuk membayangkan lembar kerja seperti ini.

Ini adalah contoh yang terlalu sederhana, tapi Anda bisa menggunakan ide umum ini untuk mengkustomisasi lembar kerja untuk kebutuhan khusus Anda.

Kuncinya adalah memulai dengan kasus penggunaan dan memikirkannya dalam hal fungsi front-end dan back-end, juga mempertimbangkan alternatif pihak ketiga. Semakin banyak kasus penggunaan Anda memerlukan fungsi back-end, semakin besar kemungkinan Anda membutuhkan CDP. Dan setelah Anda membuat dokumen ini, itu akan membuat proses RFP/penemuan jauh lebih mudah.