Veri ambarınızı CDP'niz olarak mı kullanmalısınız?

Bulut tabanlı veri ambarlarının (DWH'ler) ortaya çıkışı, giderek artan sayıda veriye dayalı kullanım durumlarına daha basit dağıtım, daha büyük ölçek ve daha iyi performans getirdi. DWH'ler, martech yığınları da dahil olmak üzere kurumsal teknoloji yığınlarında daha yaygın hale geldi.

Bu, kaçınılmaz olarak şu soruyu akla getiriyor: Mevcut DWH'nizi bir müşteri veri platformu (CDP) olarak kullanmalı mısınız? Sonuçta, yığınınızdaki mevcut bir bileşeni yeniden kullandığınızda, kaynakları koruyabilir ve yeni risklerden kaçınabilirsiniz.

Ancak hikaye o kadar basit değil ve birden fazla potansiyel tasarım modeli sizi bekliyor. Nihayetinde, DWH'nizi bir CDP olarak kullanmanın lehinde ve aleyhinde bir durum vardır. Daha derine inelim.

Bir CDP olarak DWH sizin için doğru olmayabilir

DWH'yi CDP olarak kullanmanın doğasında var olan birkaç sorun vardır. İlki açıktır: tüm kuruluşların yerinde bir DWH'si yoktur. Bazen bir kurumsal DWH ekibinin müşteri merkezli kullanım örneklerini destekleyecek zamanı veya kaynakları olmayabilir. Diğer kuruluşlar, bir CDP'yi yarı veri ambarı olarak etkili bir şekilde kullanır. (Tüm CDP'ler bunu yapamaz, ama siz anladınız.)

Diyelim ki müşteri verilerinizin çoğuna veya tamamına bir DWH'de sahipsiniz. Çoğu olmasa da çoğu işletme için sorun, verilere pazarlamacı dostu bir şekilde erişilememesidir. Tipik olarak, bir kurumsal DWH, etkinleştirme kullanım durumlarını değil analitik kullanım durumlarını desteklemek için oluşturulur. Bu, verilerin dahili olarak nasıl etiketlendiğini, yönetildiğini, ilişkilendirildiğini ve yönetildiğini etkiler.

Bir DWH'nin esas olarak depolama ve bilgi işlem için olduğunu hatırlayın; bu, verilerin, nitelikler olarak sütun adlarıyla birlikte veritabanı tablolarında saklandığı anlamına gelir. Daha sonra bu verilere erişmek için karmaşık SQL ifadeleri yazarsınız. Pazarlamacılarınızın etkinleştirme için segmentler oluşturmadan önce tablo ve sütun adlarını hatırlaması gerçekçi değildir. Veya başka bir deyişle, DWH'ler genellikle çoğu CDP'nin yaptığı gibi pazarlamacının kendi kendine hizmetini desteklemez.

Bu aynı zamanda daha geniş bir yapısal konuya da değiniyor. DWH'ler genellikle birçok CDP'nin hedeflediği gerçek zamanlı pazarlama kullanım durumlarını desteklemek için tasarlanmamıştır. Hızlı hesaplamalar yapabilir ve alımı ve işlemeyi sık aralıklarla gerçekleşecek şekilde planlayabilirsiniz, ancak yine de gerçek zamanlı değildir. Benzer şekilde, bazı istisnalar dışında, bir DWH ham verileri işlemek istemezken, pazarlamacılar genellikle belirli etkinleştirmeleri tetiklemek için ham verileri (tipik olarak olayları) kullanmak ister.

Son olarak, verilerin ve bunlara erişme yeteneğinin bir CDP oluşturmadığını unutmayın. Çoğu CDP, bir DWH'de bulamayacağınız bazı ek yetenekler alt kümesi sunar, örneğin:

• Tetiklemeli olay alt sistemi.
• Anonim kimlik çözümü.
• Segmentasyon için pazarlamacı dostu arayüz.
• Konnektörlü segment aktivasyon profilleri.
• Potansiyel olarak test etme, kişiselleştirme ve öneri hizmetleri.

Bir DWH tek başına bu yetenekleri sağlamaz, dolayısıyla bunları başka bir yerden temin etmeniz gerekecektir. Elbette, DWH satıcılarının oldukça büyük iş ortağı pazar yerleri vardır. Pek çok alternatif bulabilirsiniz, ancak bunlar yerel değildir ve entegrasyon ve destek çabası gerektirecektir.

O halde, şaşırtıcı olmayan bir şekilde, “biçimlendirilebilir CDP'ler” ve bu bağlamda bir DWH'nin potansiyel rolü hakkında çok fazla gevezelik var. Birleştirilebilirliğin bir spektrum olduğunu ve belirli bir noktadan sonra faydaları kaybetmeye başladığınızı daha önce tartışmıştım.

Tüm bu uyarıları yayınladıktan sonra bir DWH, aşağıdakiler de dahil olmak üzere bir müşteri veri yığınının parçası olarak rol oynayabilir:

• Doğrudan DWH'den etkinleştirerek bir CDP'den kurtulmak.
• DWH'yi ters ETL platformuyla yarı CDP olarak kullanmak.
• Bir CDP ile birlikte var olmak.

Bu üç tasarım modeline bakalım.

1. Pazarlama platformlarını doğrudan DWH'nize bağlama

Bu belki de yukarıda eleştirdiğim en aşırı durum, ancak özellikle CDP öncesi dönemde bazı işletmeler bunu başardı ve platformlar (geniş ekosistemiyle Snowflake gibi) bunu çözmeye çalışıyor.

Buradaki fikir, etkileşim platformunuzun bir DWH ile doğrudan itme-çekme verilerine bağlanmasıdır. Pek çok gelişmiş e-posta ve pazarlama otomasyonu platformu, genellikle toplu itme yoluyla olsa da, yerel olarak bunu yapmak için kablolanmıştır. Pazarlama uzmanlarınız daha sonra segmentler oluşturmak ve giden pazarlama durumunda bu segmentlere mesajlar göndermek için mesajlaşma platformunu kullanır.

Başka bir pazarlama veya katılım platformunuz, kişiselleştirilmiş bir web siteniz veya e-ticaret platformunuz olduğunu hayal edin. Yine DWH'den veri çekersiniz, ardından daha hedefli etkileşim için başka bir segment seti oluşturmak üzere web uygulama platformunu kullanırsınız.

Sorunu henüz görmedin mi? Halihazırda iki set segmentasyon arayüzü var. 10 pazarlama platformunuz olsa ne olur? 20? Her yerde segment oluşturmaya devam edeceksiniz, bu nedenle çok kanallı vaadiniz ortadan kalkar.

Son olarak, bir DWH'den doğrudan alımı desteklemeyen başka bir pazarlama platformu eklemek zorunda kalsanız ne olur?

2. DWH'yi ters ETL araçlarıyla kullanın

Bu yaklaşım, yukarıdaki ilk modelle ilgili birkaç sorunu çözer. Özellikle, (teoride) DWH uzmanı olmayan bir kişinin, neredeyse DWH'nin üzerinde evrensel segmentler oluşturmasına ve birden çok platformu etkinleştirmesine izin verir. Dönüşüm ve daha iyi bir bağlayıcı çerçevesiyle, farklı uç noktalara farklı etiket eşlemeleri ve pazarlamacı dostu veri yapıları uygulayabilirsiniz.

İşte nasıl çalıştığı. Ters ETL platformları, DWH'den veri çeker ve herhangi bir dönüşümden sonra pazarlama platformlarına gönderir. Birden çok dönüşüm gerçekleştirebilir ve bu verileri aynı anda birkaç hedefe gönderebilirsiniz. Hatta bunu otomatikleştirebilir ve dışa aktarma işlemlerinin önceden tanımlanmış bir programa göre düzenli olarak çalışmasını sağlayabilirsiniz.

Ancak bu verilerin bir kopyası (veya bir alt kümesi) aslında hedef platformlara kopyalanır, bu nedenle gerçekten tek bir veri kopyasına sahip değilsiniz. Ters-ETL platformunda verilerin bir kopyası bulunmadığından, gerekli segmentleriniz veya hedef kitleleriniz her zaman sorgulama zamanında (genellikle gruplar halinde) oluşturulur. Ardından bunları hedeflere aktarırsınız.

Olaylara dayalı olarak gerçek zamanlı tetikleyicilere veya her zaman açık kampanyalara sahip olmak istiyorsanız bu uygun bir yaklaşım değildir. Elbette dışa aktarma işlemlerinizi yüksek sıklıkta otomatikleştirebilirsiniz, ancak bu gerçek zamanlı değildir. İhracat sıklığınızı artırdıkça maliyetleriniz de katlanarak artacaktır.

Ayrıca, ters ETL araçları bir segmentasyon arabirimi sağlarken, MOps odaklı olmaktan çok daha teknik ve DataOps odaklı olma eğilimindedirler. Bunu, pazarlamacının kendi kendine hizmetine uygun "iş dostu" bir çözüm olarak ilan etmeden önce, dikkatli bir şekilde test etmelisiniz.

3. DWH, CDP ile birlikte var olur

Kurumsal DWH'niz, CDP'nize (diğer uç noktaların yanı sıra) veri sağlayan bir müşteri veri altyapısı katmanı olarak hizmet eder. Pek çoğu olmasa da CDP'lerin çoğu artık DWH platformlarından, özellikle de Snowflake'ten eşitleme yapmak için bazı yetenekler sunuyor.

Bu CDP'lerin DWH ile nasıl bir arada var olabileceği konusunda farklılıklar vardır. Çoğu CDP, verileri depolarında senkronize eder ve çoğaltır, oysa diğerleri (ters ETL sağlayıcıları dahil) bir kopya oluşturmaz. Ancak, sizin için neyin işe yaradığına karar vermeden önce göz önünde bulundurmanız gereken ödünleşimler olabilir.

Genel olarak, müşteri kimlik çözümlemesi gibi kritik hizmetlerin nerede olduğu konusunda büyük farklılıklar olsa da, daha büyük kuruluşların bu tasarım modelini tercih ettiğini görme eğilimindeyiz.

Daha derine inin: Bir CDP, martech yığınınızda nereye sığmalı?

Sarmak

DWH platformları, martech yığınlarında giderek daha önemli roller oynamaktadır. Ancak, veri ekosisteminizde hangi hizmetleri sunacağınız konusunda birden çok mimari seçeneğiniz olmaya devam eder.

Geleceğinizde CDP'leri elemek için erken olduğunu düşünüyorum. Seçeneklerinizi değerlendirirken her modelin akılda tutulması gereken ödünleşimleri vardır.