Haruskah Anda menggunakan gudang data Anda sebagai CDP Anda?

Munculnya gudang data berbasis cloud (DWH) telah membawa penyebaran yang lebih sederhana, skala yang lebih besar, dan kinerja yang lebih baik ke serangkaian kasus penggunaan berbasis data yang terus berkembang. DWH menjadi lebih umum di tumpukan teknologi perusahaan, termasuk tumpukan martech.

Tak pelak, ini menimbulkan pertanyaan: haruskah Anda menggunakan DWH yang ada sebagai platform data pelanggan (CDP)? Lagi pula, saat Anda menggunakan kembali komponen yang ada di tumpukan, Anda dapat menghemat sumber daya dan menghindari risiko baru.

Tapi ceritanya tidak sesederhana itu, dan beberapa pola desain potensial menunggu. Pada akhirnya, ada kasus untuk dan menentang penggunaan DWH Anda sebagai CDP. Mari gali lebih dalam.

DWH sebagai CDP mungkin tidak cocok untuk Anda

Ada beberapa masalah yang melekat dengan menggunakan DWH sebagai CDP. Yang pertama jelas: tidak semua organisasi memiliki DWH. Terkadang, tim DWH perusahaan tidak memiliki waktu atau sumber daya untuk mendukung kasus penggunaan yang berpusat pada pelanggan. Perusahaan lain secara efektif menerapkan CDP sebagai gudang kuasi-data. (Tidak semua CDP dapat melakukan ini, tetapi Anda mengerti maksudnya.)

Katakanlah Anda memiliki sebagian besar atau semua data pelanggan Anda di DWH. Masalah bagi banyak, jika tidak sebagian besar, perusahaan adalah bahwa data tidak dapat diakses dengan cara yang ramah pemasar. Biasanya, DWH perusahaan dibuat untuk mendukung kasus penggunaan analitik, bukan kasus penggunaan aktivasi. Ini memengaruhi bagaimana data diberi label, dikelola, terkait, dan diatur secara internal.

Ingatlah bahwa DWH pada dasarnya untuk penyimpanan dan komputasi, yang berarti data disimpan dalam tabel database dengan nama kolom sebagai atribut. Anda kemudian menulis pernyataan SQL kompleks untuk mengakses data tersebut. Tidak realistis bagi pemasar Anda untuk mengingat nama tabel dan kolom sebelum mereka dapat membuat segmen untuk aktivasi. Atau dengan kata lain, DWH biasanya tidak mendukung swalayan pemasar seperti kebanyakan CDP.

Ini juga menyentuh masalah struktural yang lebih luas. DWH biasanya tidak dirancang untuk mendukung kasus penggunaan pemasaran real-time yang ditargetkan oleh banyak CDP. Itu dapat melakukan perhitungan cepat, dan Anda dapat menjadwalkan penyerapan dan pemrosesan untuk terjadi pada interval yang sering, tetapi masih belum real-time. Demikian pula, dengan beberapa pengecualian, DWH tidak ingin bertindak berdasarkan data mentah, sedangkan pemasar sering kali ingin menggunakan data mentah (biasanya peristiwa) untuk memicu aktivasi tertentu.

Terakhir, ingatlah bahwa data dan kemampuan untuk mengaksesnya tidak membuat CDP. Sebagian besar CDP menawarkan beberapa subset kemampuan tambahan yang tidak akan Anda temukan di DWH, seperti:

• Subsistem acara dengan pemicu.
• Resolusi identitas anonim.
• Antarmuka ramah pemasar untuk segmentasi.
• Profil aktivasi segmen dengan konektor.
• Layanan pengujian, personalisasi, dan rekomendasi yang berpotensi.

DWH saja tidak akan menyediakan kemampuan ini, jadi Anda perlu mencarinya di tempat lain. Tentu saja, vendor DWH memiliki pasar mitra yang cukup besar. Anda dapat menemukan banyak alternatif, tetapi itu bukan asli dan akan memerlukan upaya integrasi dan dukungan.

Maka tidak mengherankan, ada banyak obrolan tentang "CDP yang dapat disusun" dan potensi peran DWH dalam konteks itu. Saya telah berpendapat sebelumnya bahwa komposisi adalah spektrum, dan Anda mulai kehilangan manfaat di luar titik tertentu.

Setelah mengeluarkan semua peringatan ini, DWH dapat berperan sebagai bagian dari kumpulan data pelanggan, termasuk:

• Menghilangkan CDP dengan mengaktifkan langsung dari DWH.
• Menggunakan DWH sebagai kuasi-CDP dengan platform ETL terbalik.
• Hidup berdampingan dengan CDP.

Mari kita lihat ketiga pola desain ini.

1. Menghubungkan platform pemasaran langsung ke DWH Anda

Ini mungkin kasus paling ekstrem yang saya kritik di atas, tetapi beberapa perusahaan telah membuat ini berfungsi, terutama di era pra-CDP dan platform (seperti Snowflake dengan ekosistemnya yang luas) mencoba menyelesaikannya.

Idenya di sini adalah platform keterlibatan Anda langsung terhubung ke data push-pull dengan DWH. Banyak email dewasa dan platform otomasi pemasaran terhubung secara bawaan untuk melakukan ini, meskipun biasanya melalui push batch. Pemasar Anda kemudian menggunakan platform perpesanan untuk membuat segmen dan mengirim pesan ke segmen tersebut dalam kasus pemasaran keluar.

Bayangkan Anda memiliki platform pemasaran atau keterlibatan lain, situs web atau platform e-niaga yang dipersonalisasi. Sekali lagi Anda mengambil data dari DWH, lalu menggunakan platform aplikasi web untuk membuat kumpulan segmen lain untuk keterlibatan yang lebih bertarget.

Apakah Anda sudah melihat masalahnya? Sudah ada dua set antarmuka segmentasi. Apa yang terjadi jika Anda memiliki 10 platform pemasaran? 20? Anda akan terus membuat segmen di mana saja, sehingga janji omnichannel Anda menghilang.

Terakhir, bagaimana jika Anda harus menambahkan platform pemasaran lain yang tidak mendukung penyerapan langsung dari DWH?

2. Gunakan DWH dengan alat reverse-ETL

Pendekatan ini memecahkan beberapa masalah dengan pola pertama di atas. Khususnya, ini memungkinkan (secara teori) spesialis non-DWH untuk membuat segmen universal secara virtual di atas DWH dan mengaktifkan banyak platform. Dengan transformasi dan kerangka kerja konektor yang lebih baik, Anda dapat menerapkan pemetaan label yang berbeda dan struktur data yang ramah pemasar ke titik akhir yang berbeda.

Begini cara kerjanya. Platform Reverse ETL menarik data dari DWH dan mengirimkannya ke platform pemasaran setelah transformasi apa pun. Anda dapat melakukan beberapa transformasi dan mengirimkan data tersebut ke beberapa tujuan secara bersamaan. Anda bahkan dapat mengotomatiskannya dan menjalankan ekspor secara teratur pada jadwal yang telah ditentukan sebelumnya.

Tetapi salinan data itu (atau sebagian darinya) sebenarnya disalin ke platform target, jadi Anda benar-benar tidak hanya memiliki satu salinan data. Karena platform reverse-ETL tidak memiliki salinan data, segmen atau audiens yang Anda perlukan selalu dihasilkan pada waktu kueri (biasanya dalam batch). Kemudian Anda mengekspornya ke tujuan.

Ini bukan pendekatan yang cocok jika Anda ingin memiliki pemicu waktu nyata atau kampanye yang selalu aktif berdasarkan peristiwa. Tentu, Anda dapat mengotomatiskan ekspor pada frekuensi tinggi, tetapi itu tidak dalam waktu nyata. Saat Anda meningkatkan frekuensi ekspor, biaya Anda akan meningkat secara eksponensial.

Juga, sementara alat reverse-ETL menyediakan antarmuka segmentasi, mereka cenderung lebih teknis dan berfokus pada DataOps daripada berfokus pada MOps. Sebelum menyatakan ini sebagai solusi "ramah bisnis" yang cocok untuk swalayan pemasar, Anda harus mengujinya dengan cermat.

3. DWH berdampingan dengan CDP

DWH perusahaan Anda berfungsi sebagai lapisan infrastruktur data pelanggan yang memasok data ke CDP Anda (di antara titik akhir lainnya). Banyak, jika tidak sebagian besar, CDP kini menawarkan beberapa kemampuan untuk menyinkronkan dari platform DWH, terutama Snowflake.

Ada variasi bagaimana CDP ini dapat hidup berdampingan dengan DWH. Sebagian besar CDP menyinkronkan dan menggandakan data ke dalam repositori mereka, sedangkan yang lain (termasuk vendor reverse-ETL) tidak membuat salinan. Namun, mungkin ada trade-off yang perlu Anda pertimbangkan sebelum menyelesaikan apa yang cocok untuk Anda.

Secara umum, kami cenderung melihat perusahaan yang lebih besar lebih memilih pola desain ini, meskipun dengan variasi yang luas di mana layanan penting seperti resolusi identitas pelanggan pada akhirnya berada.

Gali lebih dalam: Di mana CDP harus pas di tumpukan martech Anda?

Bungkus

Platform DWH memainkan peran yang semakin penting dalam tumpukan martech. Namun, Anda tetap memiliki banyak pilihan arsitektur tentang layanan mana yang Anda render dalam ekosistem data Anda.

Saya pikir terlalu dini untuk mengesampingkan CDP di masa depan Anda. Setiap pola memiliki trade-off untuk diingat saat mengevaluasi opsi Anda.