Kişiselleştirme Piramidi: Katmanlar ve Ölçüm Maliyeti
Kişiselleştirme piramidi, kullanıcı verisiyle tasarım yapmayı katmanlara bölen bir çerçeve. Fikir basit, uygulaması pahalı: çoğu ekip alt katmanları atlayıp doğrudan "kullanıcıya özel içerik" aşamasına atladığı için tıkanıyor. Aşağıda katmanları sırayla kuruyorum, sonunda da çerçevenin pek konuşmadığı iki şeyi: sıralamadaki mantık hatası ve segment sayısının ölçüme çıkardığı fatura.
Piramit neyi sıraya koyuyor
Kişiselleştirme denince akla önce çıktı gelir: ana sayfada kullanıcının adının görünmesi, ilgi alanına göre dizilmiş ürün listesi. Piramit bunun tersini yapar, çıktıyı en sona koyar. Altında sırayla şunlar durur: neden kişiselleştirdiğin, nerede kişiselleştirdiğin, kimi kişiselleştirdiğin, elinde gerçekten hangi verinin olduğu. Bir katman eksik kalırsa üstündeki katman tahmine döner. Tahminle yapılan kişiselleştirme ise kullanıcı tarafından rastgele içerikten ayırt edilemez, üstelik yanlış tahmin nötr bir deneyimden daha rahatsız edicidir.
Katmanlar
Neden: ölçülebilir tek bir hedef
En üstte kurumun bu programdan ne beklediği var. "Daha iyi deneyim" bir hedef değil, temenni. Hedef, kişiselleştirme açıkken ve kapalıyken farklı okuma veren bir sayı olmalı: sepete ekleme oranı, ikinci ziyaret oranı, destek talebi sayısı. Kişiselleştirme burada araçtır; hedefe bir tık daha yakın götüren başka bir yol varsa (mesela arama kutusunu düzeltmek) o yol seçilir.
Nerede: temas noktaları
Temas noktası, kullanıcıya farklı bir şey gösterebildiğin her yer demek. Ana sayfa modülü, kategori sıralaması, e-posta konu satırı, uygulama açılış ekranı, destek penceresinin karşılama mesajı. Hepsini birden kişiselleştirmeye kalkmak yaygın hata. Tek bir temas noktası seçip orada çalıştığını kanıtlamak, beş noktada aynı anda yarım uygulamaktan daha hızlı sonuç verir.
Kim: segmentler
Segment, aynı içeriği göstereceğin kullanıcı kümesi. İki türlü kurulur. Kural tabanlı segment açık bir koşula bakar: oturum açmış mı, daha önce sipariş vermiş mi, hangi kampanyadan geldi. Model tabanlı segment ise davranış verisinden kümeler çıkarır. Başlangıç için kural tabanlı olan yeterlidir ve büyük avantajı vardır: neden o içeriği gördüğünü açıklayabilirsin. Model çıkardığı kümeyi açıklamaz, sadece verir.
Ne ile: veri
Birinci parti veri, kullanıcının senin ürününde bıraktığı iz: ne aradı, neye tıkladı, formda ne yazdı, neyi yarıda bıraktı. Kişiselleştirmenin işe yarayan kısmının neredeyse tamamı bununla kurulur (üçüncü parti veri satıcılarının vaat ettiği eşleşme doğruluklarına pek inanmıyorum). Toplarken de KVKK tarafını sonradan yamamak yerine baştan kurmak gerekir; izin metnini sonradan eklemek, çoğunlukla toplanmış verinin tamamını çöpe atmak anlamına gelir.
Ne gösterilecek: bağlam ve içerik tipi
Aynı kullanıcıya aynı gün iki farklı şey göstermen gerekebilir, çünkü bağlam değişmiştir. Ürüne ilk kez bakan biriyle sepeti dolu olan biri farklı ihtiyaçtadır. İçerik tipini de dörde ayırmak işi kolaylaştırır: uyarı (stok azaldı), kolaylaştırıcı (kaldığın yerden devam et), çapraz öneri (bunu alanlar şunu da aldı), zenginleştirici (nasıl kullanılır rehberi). Bağlamla içerik tipi eşleşmediğinde kişiselleştirme kullanıcıya yardım değil, satış baskısı gibi görünür.
Sıralamada bir mantık hatası var
Çerçevenin yaygın anlatımında segmentler veriden önce gelir. Kural tabanlı segmentler için bu sorun değil, çünkü "oturum açmış kullanıcı" bilgisi zaten sistemde vardır. Ama davranış temelli bir segment tanımlamak, o davranışı ölçen veriyi çoktan topluyor olmayı gerektirir. Sırayı olduğu gibi izleyen ekip, elinde olmayan veriye dayanan segmentler tasarlar ve iki ay sonra hepsini yeniden yazar. Doğrusu şu: önce hangi olayları kaydettiğini çıkar, segment tanımlarını o listenin üstüne kur, eksik olan olayları da bir sonraki sürümde ölçmeye başla.
Segment sayısı ölçüm maliyetini çarpar
Katmanlar birbiriyle çarpılır. Beş temas noktası, altı segment ve dört içerik tipi, tasarlanacak ve yazılacak 120 varyant demek. İçerik üretimi zaten ağır, asıl sıkışma ölçmede yaşanıyor.
Bir sayfanın haftada 10.000 ziyaret aldığını ve anlamlı bir A/B testi için varyant başına 8.000 ziyaret gerektiğini varsay. Kişiselleştirme yokken test bir haftada biter. Trafiği altı segmente böldüğünde ortalama segment haftada 1.700 ziyaret alır, yani aynı test yaklaşık beş haftaya çıkar. Üstelik segmentler eşit büyüklükte değildir; trafiğin yüzde beşini tutan segmentte test süresi aylara uzar.
Buradan çıkan pratik kural, segment sayısını hedefe göre değil trafiğe göre belirlemek. Küçük segmentlerde varyantı test etmeye çalışmak yerine ya birleştirin ya da o segmenti kural bazlı, ölçmeden kabul edilen bir iyileştirmeyle geçin. Ölçemeyeceğin bir kişiselleştirmeyi kurmak, sonucunu asla bilemeyeceğin bir bakım yükü satın almaktır.
Nereden başlanır
Tek temas noktası, iki segment, tek metrik. Dört hafta çalıştır, farkı ölç. Fark yoksa segment tanımı yanlıştır ya da o temas noktası kararı etkilemiyordur; ikisi de piramidi yukarı tırmanmadan önce öğrenilmesi gereken bilgiler.
Kaynak