Contact Property Nedir?

Sayılarla ne demek?

CRM sistemindeki her kişi kaydı, bir dizi özellikten oluşur. Ad ve e-posta adresi gibi temel bilgiler bunların yalnızca başlangıcıdır; toplam harcama, son sipariş tarihi, tercih edilen kanal ya da en çok alınan kategori gibi değerler, segmentasyon ve kişiselleştirmenin ham maddesidir.

Özellik ile olay aynı şey değildir. Olay, belirli bir anda gerçekleşen bir eylemdir: "12 Mart'ta sipariş verdi", "dün ürün sayfasını görüntüledi". Özellik ise kişinin bugünkü durumunu özetler: "toplam 5 sipariş", "son sipariş 14 gün önce". Olaylar geçmişi kaydeder, özellikler bu geçmişten türetilen özet bilgiyi tutar.

Bu ayrım otomasyonun hızını belirler. Bir segmentin "son 90 günde en az iki sipariş" kuralını her seferinde binlerce olayı tarayarak hesaplaması yavaş olabilir; aynı bilgi bir özellik olarak güncel tutulduğunda karar anında verilir.

Özellik türleri

"Hesaplanan" satırı en çok hata üreten tür. Sipariş sistemiyle senkronizasyon bozulduğunda toplam harcama ya da son sipariş tarihi eskiyor; bu özelliklere dayanan bütün segmentler de sessizce yanlışlaşıyor.

Özellikleri düzenlerken

1. Kullanım amacını yazın. Hangi segment ya da mesaj için gerekli?
2. Tek bir kaynak belirleyin. Her özelliğin sahibi bir sistem olsun.
3. Güncelleme sıklığını bilin. Anlık mı, günlük mü?
4. Veri türünü doğru seçin. Tarih tarih, sayı sayı olarak.
5. Kullanılmayanları temizleyin. Yılda bir gözden geçirin.

Uygulamada ne oluyor?

En sık durum, özelliklerin amaçsız birikmesi. Her entegrasyon kendi alanlarını ekliyor; birkaç yıl sonra kişi kaydında yüzlerce özellik var ama hangisinin güncel ve güvenilir olduğunu kimse bilmiyor.

İkinci gözlem, aynı bilginin birden fazla alanda tutulması. "Şehir", "il" ve "teslimat şehri" ayrı alanlar olarak duruyor ve farklı değerler taşıyor; segment kurarken hangisinin kullanılacağı belirsiz.

Üçüncüsü, tarih bilgisinin metin olarak saklanması. Son sipariş tarihi bir metin alanında tutulunca "son 30 gün" gibi kurallar çalışmıyor ya da yanlış sonuç veriyor.

Dördüncüsü, izin durumunun tek bir alanda karıştırılması. E-posta, SMS ve WhatsApp onayları ayrı tutulmadığında, bir kanalda onay veren kişiye başka bir kanaldan mesaj gidebiliyor; bu, İYS açısından ciddi bir risk.

Beşincisi, kişiselleştirme etiketi ile boş özelliğin buluşması. "Merhaba [ad]" etiketi kullanılıyor ama kayıtların bir kısmında ad alanı boş; mesaj "Merhaba ," diye başlıyor. Her etikete bir varsayılan değer tanımlanmalı.

Altıncısı, hesaplanan özelliklerin kaynakla uyumsuz kalması. Sipariş iptal edildi ama toplam harcama alanı düşmedi; kişi VIP segmentinde kalmaya devam ediyor ve hak etmediği bir ayrıcalık alıyor.

Yedincisi, ürün tavsiyesi için gereken özelliklerin hiç tutulmaması. Favori kategori, beden ya da son görüntülenen marka gibi bilgiler olmadan dinamik içerik yalnızca genel öneriler gösterebiliyor.

Sekizincisi, özellik adlarının anlaşılmaz olması. "fld_23" ya da "x_score" gibi adlar, alanı oluşturan kişi ayrıldığında anlamını yitiriyor; açık ve tutarlı adlandırma bir sözlük gibi çalışıyor.

Dokuzuncusu, kişisel veri minimizasyonunun gözetilmemesi. KVKK açısından yalnızca amaca uygun veri tutulmalı; "belki bir gün lazım olur" diye toplanan hassas bilgiler hem risk hem de yük oluşturuyor.

Onuncusu, tahmin özelliklerinin gerçek veri gibi kullanılması. Model çıktısı olan "kayıp riski" alanı, kesin bir bilgi gibi segmentlere konuyor; bu değerin bir olasılık olduğu ve düzenli yenilenmesi gerektiği unutuluyor.

On birincisi, mağaza ve çevrim içi verilerin ayrı kişi kayıtlarında kalması. Aynı müşteri iki kayıt olarak duruyor ve her birinde yarım bilgi var; birleştirme kuralı olmadan özellikler gerçeği yansıtmıyor.

On ikincisi, özellik değişikliklerinin tetikleyici olarak kullanılmaması. Yolculuk aşaması "sadık"tan "risk altında"ya döndüğünde bir akış başlatmak, olay beklemekten çok daha erken bir müdahale imkanı veriyor.

Neyi göstermez?

Kişi özelliği, kişinin geçmişini ayrıntısıyla göstermez. Bugünkü durumu özetler; neyin, ne zaman ve hangi sırayla olduğunu görmek için olay geçmişine bakmak gerekir.

Sıkça sorulan sorular

Özellik ile olay arasındaki fark ne?

Olay belirli bir anda gerçekleşen eylemdir; özellik kişinin bugünkü durumunu tek bir değerle özetler.

Kaç özellik gerekir?

Segmentasyon ve kişiselleştirmede gerçekten kullanılan kadar; kullanılmayan alanlar yük oluşturur.

İzin bilgisi nasıl tutulmalı?

Her kanal için ayrı bir alanda, onay tarihi ve kaynağıyla birlikte. Yakından ilişkili bir kavram olan Contact, CRM sistemindeki bir kişi kaydıdır; abone olsun olmasın, iletişim bilgisi tutulan tüm kişileri kapsar.

Bu kavramın bütün resim içindeki yerini Retention Pazarlama Rehberi içinde ayrıntılı anlattım.