Müşteri Segmentasyonunun Teknik Yönleri – Veri Senkronizasyonu

"CRM veritabanlarını analiz etme ve segmentlere ayırma konusunda kapsamlı deneyim", "İzleyici segmentasyonu konusunda güçlü kavrayış", "Veri segmentasyonunu anlama ve deneyimleme ve kişiselleştirilmiş içerik sunma." Bunlar, CRM/yaşam döngüsü pazarlama iş tekliflerine yerleştirilen en yaygın gereksinimlere örneklerdir. Müşteri segmentasyonu kavramı oldukça basit ve başlaması kolay olsa da, segmentasyon uzmanı olmak teknik ayrıntılara dalmayı gerektirir. Bu makale ile bu adımı atmanıza yardımcı olmak istiyoruz.

İçindekiler:

1. Depolama ve biçim karmaşıklığı
2. Veri biçimleri
3. senkronizasyon frekansı
4. Veri senkronizasyon ortamı
5. API öncelikli dünya
6. Veri senkronizasyonu tetikleyicileri
   

Müşteri segmentasyonu, müşteri verilerini tek bir merkezi yerde toplamak ve gruplandırmaya ve harekete geçmeye hazır hale getirmekle başlar. Kulağa kolay geliyor, ancak artan sayıda veri kaynağı, veri toplama ve işlemeyi karmaşık hale getiriyor.

Bu nedenle verimli segmentasyon, birkaç veri kaynağından tek bir sunucuya tutarlı veri akışının sağlanmasıyla başlar. Bu süreç, son zamanlarda çokça duymuş olabileceğiniz bir isim kazandı – veri senkronizasyonu veya sadece veri senkronizasyonu . Tekdüzeliği korumak için sistemler ve müteakip sürekli güncellemeler arasında tutarlılık oluşturma sürecidir.

Pek çok akıllı kelime, bunun öncelikle mühendislik ekibinin alanı olduğu anlamına gelir. Ancak kendinizi temel kavramlara alıştırmak çok yardımcı olur. İşte genel bir bakış:

• Veri senkronizasyonu – bu bölümde müşteri verilerinin nasıl saklandığını, insanların bunları neden taşımak istediğini ve dijital ekiplerin bunu yapmak için hangi engelleri aşması gerektiğini öğreneceğiz. Daha pratik bir not olarak, bu bölüm modern CRM sistemlerinin API'lerle İnternet üzerinden nasıl veri alışverişinde bulunduğunun iç kısımlarını açıklamaktadır.
• Veri bütünlüğü ve güvenliği – sonraki bölüm, senkronize ettikten sonra verileri tutarlı bir durumda tutmak için ne gerektiğini anlamanıza yardımcı olacaktır. Veri benzersizliği ile ilgilenmek ve veri tekrarını önlemek için şemayı nasıl kullanabileceğinizi öğreneceğiz. Son olarak, GDPR ve CCPA sonrası dönemlerde birinci sınıf vatandaşlar haline geldikleri için veri güvenliği ve gizliliğinin teknik yönleri üzerinde duracağız.
• Veri sıkıştırma – son olarak, size veri filtreleme ve genel olarak veriye dayalı kararlar alma konusunda bazı ipuçları göstererek akıcı olmanıza yardımcı olacağız.

Depolama ve biçim karmaşıklığı

Teknolojideki son gelişmeler nedeniyle, veri depolama maliyeti düşmüştür. Bu, işletmelerin çok büyük miktarda veri toplamasını sağladı.

Bu veriler iki kategoriye ayrılabilir: yapılandırılmış ve yapılandırılmamış . Segmentasyonun işe yaraması için dijital ekiplerin yapılandırılmamıştan yapılandırılmışa nasıl geçileceğini bulması gerekiyor.

Yapılandırılmış veri depoları ile çoğunlukla SQL veritabanlarını veya Excel dosyalarını kastediyoruz. Harika ve çok yönlü araçlardır, ancak dezavantajları da vardır. SQL'i teknik altyapıya sahip olmayan kişiler için öğrenmek zordur, Excel'in en büyük avantajı olan esnekliği, veri bütünlüğünün uzun vadeli bakımı için bir kabus haline gelir. Bu nedenle bu genel amaçlı yazılım araçları, CRM, CMS, ERP veya analitik araçları gibi daha odaklı olanlarla üstyapılandırılmıştır.

İşe yönelik bu araçlar işe alındıkları alanlarda verimliliği artırsa da, genellikle departman/şirket düzeyinde bir sorun haline gelir. Nedenmiş? Bu araçların her biri genellikle kendi veri formatını kullanır ve her iki yazılım platformu da birbiriyle entegre olmadıkça veri alışverişi engellenir. Ve modern bir pazarlamacı, bu tür araçlardan çok fazla kullanır.

Bu nedenle çoğu veri eşitleme işlemi bir aracıya ihtiyaç duyar. Yazma yazılımı tarafından oluşturulan veri biçimini (BT dünyasında "kaynak" olarak adlandırılır) hedef biçimine ("hedef") uyarlar. Böyle bir adaptasyon sürecine ETL denir. Bu, Extract (kaynaktan gelen veriler), Transform (hedef tarafından tanınan ve kabul edilen bir şekilde), Load (veri tutarlılığını koruyan hedefe) kısaltmasıdır.

Müşteri segmentasyonu sektöründe ne tür veri formatlarıyla karşılaşabilirsiniz?

Veri biçimleri

Günümüzde, segmentasyon yazılımı çoğu durumda veri senkronizasyonu amacıyla iki açık format kullanır. Ama yine de “veri formatı” nedir? Bu, bilgisayarların anlayabileceği şekilde yapılandırılmış bir metinden başka bir şey değildir. İlk, daha basit olanla başlayalım.

CSV – Virgülle Ayrılmış Değerler. Bir masaya oturduğunuzu hayal edin. MS Word'den normal bir tablo gayet iyi. Şimdi dış sınırları kaldıralım ve iç sınırları virgülle değiştirelim. Voila, az önce bir CSV dosyası oluşturdunuz.

En büyük avantaj? Basitlik ve kompaktlık. SQL ve Excel veritabanları verileri tablolarda sakladığından, geliştiriciler verileri bu biçimde kolayca dışa aktarabilir.

Öte yandan, CSV'nin iki büyük kusuru vardır. İlk olarak, bir CSV dosyası içinde hiyerarşiyi temsil edemezsiniz. Örneğin, bir değerin diğeriyle ilişkili olduğunu gösteremezsiniz. İkinci en önemli dezavantaj, CSV'nin sabit bir format olmasıdır. Başlangıçta tanımladığınız sütunların tam sayısı ve türüne göre veri alışverişi yapmanızı sağlar. Başka bir hedef sistem için gerekli bir sütunu eklerseniz veya bir sütunu basitçe kaldırırsanız, içe aktarma girişiminde bir hataya neden olur. Böyle bir durumda, geliştiricilerin kodu yapısal değişiklikleri yansıtacak şekilde ayarlamaları gerekecektir.

Pazarlama teknolojisinin son yıllarda kazandığı dinamikler nedeniyle, bu sınırlama büyük bir barikat haline geldi.

Bu nedenle modern sistemler bir XML ve JSON verisi ile veri alışverişi yapmaya başlamıştır. Her ikisi de aynı veri temsili kavramına dayanmaktadır. Daha popüler olduğu için ikincisini anlatacağız.

Bu bir JSON dosyası örneğidir. JSON dosyamızı CSV karşılığıyla karşılaştırdığımızda hemen benzerlikler bulacağız - bu dosyanın tamamen aynı verileri depoladığını görebiliriz.

Çarpıcı fark, CSV dosyalarındaki sütun adlarının tekrarlanmasıdır. Bu, insanlar için gereksiz ve okunabilirliği engelliyor gibi görünse de, JSON'a esneklik sağlayan şey tekrardır – öğelerin sırasını alakasız hale getirir. Bu, değiş tokuş edilen bir dosyaya yeni bir özellik (sütun) eklemeniz gerektiğinde yararlıdır. Yeni özelliği bekleyen hedef yazılım onu ​​tüketirken, dosyayı sütun eklemeden önce işleyen hedefler yeni özelliği görmezden gelecek ve rahatsız edilmeden çalışacaktır.

Bu özellik, kaynak uygulama tarafından gönderilen veri formatına daha fazla alan eklerseniz hedefi bozmamasını garanti eder. Bu nedenle JSON formatının CSV'den daha ölçeklenebilir ve daha esnek olduğu söylenir .

JSON dosyaları hakkında daha fazlasını buradan okuyabilirsiniz.

senkronizasyon frekansı

Günümüzde ortak gereksinim, e-ticaret sistemlerinin gerçek zamanlı olmasıdır. Müşteriler, siparişlerinin durumunu, gerçek zamanlı kargo takibini veya hesaplarındaki mevcut bakiyenin ne olduğunu görmek ister. Ayrıca pazarlamacılar hızlı tepki vermek, zamanında alışveriş deneyimleri yaratan gerçek zamanlı kampanyalar yürütmek istiyorlar.

Bunu başarmak için, temel veri depoları gerçek zamanlı senkronizasyonu benimsemiştir.

Ancak, gerçek zamanlı senkronizasyonda dikkat edilmesi gereken iki zorluk vardır.

İlk olarak, genel bir kural - ne kadar gerçek zamanlılık elde etmek isterseniz, o kadar pahalı olur . Bu maliyet, geliştiricilerin zamanında kendini gösterir, aynı zamanda sunucuları çalıştıran donanımla (bugün çoğunlukla bulut çözümleridir) veri senkronizasyon sistemlerini çalışır durumda tutmanız gerekir. Bu nedenle, mühendislerle konuşurken "gerçek zamanlı" bir gereksinim belirlemeden önceki ilk göreviniz, gerçekten ne tür bir veri senkronizasyon frekansına ihtiyacınız olduğunu düşünmektir. Belki de saatte bir veya günde bir kez gönderilen güncellemeler, geliştiricilerin işini azaltırken ve bütçeden tasarruf ederken mükemmel bir müşteri deneyimi sağlamak için yeterlidir.

Diğer zorluk, birlikte çalıştığınız veri depolarının veri çıkarma yetenekleridir. Bazen, sistemlerden biri veri çıkarmak için kolay bir yol sağlamadığında gerçek zamanlı senkronizasyon engellenebilir. Kolay anlamı geliştirici dostu. Geliştiricilerin verileri sistemler arasında nasıl taşıdıklarını inceleyerek bu sorunu ayrıntılı olarak analiz edelim.

Veri senkronizasyon ortamı

Verilerin nasıl saklandığını, değişim için hangi formatların kullanıldığını ve senkronizasyon sıklığının tüm senkronizasyon sistemini kurma çabalarını nasıl etkileyebileceğini öğrendik. Ancak bir veri tabanından diğerine veri aktarmak için gerçekte ne gerekiyor? Bir ortama ihtiyacın var.

DVD, USB sürücü veya diğer donanım tabanlı senkronizasyon gibi fiziksel bir depolama olabilir, ancak çok büyük miktarda veri ve gerçek zamanlı senkronizasyon gereksinimleri ile bugün çok azı bunu yapıyor. Çoğu durumda, her şey kablo aracılığıyla yapılır veya aslında İnternet olarak adlandırılan dünya çapındaki bilgisayarlar tarafından birbirine bağlanan birçok kablo ile yapılır.

Daha spesifik olmak gerekirse, modern yazılım platformları, World Wide Web'in temeli olan Köprü Metni Aktarım Protokolünü (HTTP) kullanır.

Sunucuların İnternet üzerinden birbirleriyle nasıl konuştuğuyla ilgileniyorsanız (ve öyle olsanız iyi olur!), bu teknoloji uzmanı olmayan sunucular kılavuzuna atlamanızı şiddetle tavsiye ederiz.

Özetle, HTTP protokolüne geliştiricilere İnternet üzerinden nasıl veri gönderdiklerini söyleyen yönergeler gibi davranabilirsiniz. HTTP'nin yanı sıra geliştiriciler, iki sistem arasında hangi verilerin ve hangi sırayla değiş tokuş edilebileceğinin özel açıklamaları olan Uygulama Programlama Arayüzleri (API'ler) oluşturur.

Bir API'yi İnternette kullanılabilir hale getiren ve diğer sistemler tarafından erişilebilir olmasını sağlayan yazılıma (normal bir web sayfasını ziyaret etme şeklinize benzer şekilde) uygulama sunucusu denir. Tek yaptığı, diğer uygulama sunucularından gelen istekleri dinlemek ve bunlara yanıt vermek ve isteğe bağlı olarak temel veritabanından bilgi eklemek veya ondan bilgi almaktır. Yararlı bilgi: İnsanlar API'den bahsettiğinde, genellikle API'yi İnternet'e sunan uygulama sunucusu için bir kısayoldur.

API'lerle oynayalım o zaman.

API öncelikli dünya

API'ler, günümüzün dijital pazarlamasının ortak dili haline geldi. Bugün veri senkronizasyonu çalışmalarının çoğu, ondan veri çıkarabilmek için bir API öğreniyor. Bu, bu durumda HTTP tarafından tanımlanan dilbilgisini bildiğinizi varsayarsak, yabancı bir dilden başka bir kelime grubu öğrenmek gibidir.

Bu bir geliştiricinin işi olmasına rağmen, bu konuya dalmak pazarlama teknolojisi dünyasında gezinmenize yardımcı olabilir.

API'leri anlama konusunda bazı pratik örnekler içeren özel bir makale oluşturduk, bu nedenle bu konuda uzmanlaşmak istiyorsanız (ve yine yapmalısınız), burayı okuyun .

Bu ondan en önemli alıntıdır:

“Bir restorana müşteri olarak giderseniz, mutfağa girmenize izin verilmez. Neyin mevcut olduğunu bilmeniz gerekir. Bunun için menünüz var. Menüye baktıktan sonra, bir garsona sipariş veriyorsunuz, garson onu mutfağa iletiyor ve daha sonra istediğinizi teslim edecek. Garson sadece mutfağın sağlayabileceği kadarını teslim edebilir.

Bunun bir API ile nasıl bir ilgisi var? Garson API'dir. Sen hizmet isteyen birisin. Başka bir deyişle, bir API müşterisi veya tüketicisisiniz. Menü, API'den ne isteyebileceğinizi açıklayan belgelerdir. Mutfak, örneğin bir sunucudur; alıcının restoran için malzeme olarak ne satın aldığı ve şefin ne sunacağına karar verdiği ve aşçıların nasıl hazırlanacağını bildikleri yalnızca belirli türde verileri tutan bir veri tabanı.

• Mutfak – Veritabanı, hiçbir müşterinin veri bütünlüğünü korumasına izin verilmez.
• Garson – Veritabanından verinin işleyişini bozmadan nasıl sunulacağını bilen bir aracı olan API.
• Müşteri – Verilerini almak isteyen harici bir sistem.
• Menü – Harici sistemlerin işlemlerini gerçekleştirmek için kullanmaları gereken veri formatı referansı.
• Sipariş – Gerçek bir tek API çağrısı.

Senkronizasyona geri dönersek, şimdi geriye kalan soru, iki sistemin hangi koşullar altında veri alışverişi yapması gerektiğini bulmaktır.

Veri senkronizasyonu tetikleyicileri

Bilgi alışverişi yapmaya hazır iki uygulama sunucumuz olduğunu varsayalım. Daha açık olmak gerekirse, e-posta servis sağlayıcınızın ( ESP ) onuncu siparişten sonra onlara bir promosyon kuponu göndermek için müşteri siparişlerinin (e-mağaza) sayısını bilmek istediğini düşünelim. Şimdi bu senaryoyu gerçekleştirmek için ne tür bir veri akışı uygulayabiliriz? ESP tarafında e-posta kupon makinesini başlatabilecek üç "tetikleyiciyi" ayırt edebiliriz.

a) Veri yoklama – bu durumda ESP e-shop API'sinden tekrar tekrar soruyor: "Jane Doe için toplam sipariş miktarını bana bildirin". Bunu her dakika, saatte veya günde bir vb. yapar. ESP bilgiyi aldığında, her API isteğinde kupon gönderme koşullarını yeniden hesaplar. Verileri bu şekilde çağırmak ve işlemek için bunun yetersiz olabileceğini düşünüyorsanız, içgüdüleriniz doğrudur. Alternatif nedir?

b) Veri gönderme – ya bir e-mağaza, Jane 10. siparişini verdiği anda ESP başvurusunu bildirebilseydi? Bu doğru. Modern e-ticaret platformları bu eksiklikleri fark etti ve bu tür bildirimleri özellik setlerine dahil etti. Bunlara genellikle web kancaları veya çağrılar denir. Bu basit ama güçlü bir işlevdir. Belirli koşullar altında hangi uygulamaların ne zaman bildirilmesi gerektiğini tanımlamanıza olanak tanır. Bir bildirimin ne tür bilgileri içermesi gerektiğini de tanımlayabilirsiniz - bazen tam bilgi göndermek mantıklıdır, ancak çoğu zaman yalnızca değiştirilen bir özellik yeterlidir.

c) Toplu işleme – bazen isteklerin sayısı o kadar fazladır ki bu iki yöntemden hiçbiri makul değildir. Yükü işlemek için gereken işlem gücü miktarı, taraflardan birine (hatta her ikisine) zarar verebilir. Bu durumda, geliştiriciler tüm bilgileri bir "parti" halinde gruplandırır ve veri alışverişini gece veya daha genel olarak sunucuların günlük trafikle meşgul olmadığı zamanlarda planlar. Bu, uygulamalara gelen trafiği kontrol etmeye yardımcı olur ve sunucunuzdaki olası baskıyı önler.

Yararlı terimler: Bir sunucuya çok fazla istek gönderilmesini önlemek için uygulama geliştiricileri uygulamalarına hız sınırlayıcıları uygular. Belirli bir dönemdeki API çağrılarının sayısını sınırlar, örneğin, dakikada 5000 çağrı. Genellikle kotayı aşan çağrılar kısılır . Bu, sonunda (tamamen bırakmak yerine) ancak biraz gecikmeyle servis edilecekleri anlamına gelir.

Şimdiye kadar müşteri verilerinin nasıl senkronize edildiğini öğrendik. Ancak gerçek müşteri segmentasyonu gerçekleşmeden önce, verileri veritabanınızda nasıl tutarlı tutacağımızı anlamamız gerekir. Sonraki bölümde, iyi performans gösteren kampanyalar elde etmek için veri bütünlüğünün ve güvenliğinin nasıl sağlanacağını açıklayacağız.