Gerçek zamanlı kişiselleştirme, bir web sayfasının gösterdiklerini ziyaretin kendisi sırasında elde edilen sinyallere göre değiştirmek demektir: ziyaretçinin şirketi, nereden geldiği, bu ve önceki oturumlarda neleri görüntülediği. Karar günler sonra bir e-posta akışında değil, sayfa yüklenirken veya ziyaretçi sayfalar arasında gezinirken verilir.
Örnek (temsili): hedef hesap listenizdeki büyük bir şirketten gelen bir ziyaretçi ana sayfaya ulaşıyor. Şirket tanımlama hesabı ilk istekte belirliyor; böylece başlık varsayılan mesaj yerine güvenlik ve yönetimden bahsediyor, kanıt bloğu aynı sektörden bir müşteri gösteriyor ve CTA "Daha fazla bilgi" yerine hesap ekibiyle bir görüşme öneriyor. Ziyaretçi oturum açmadı ya da hiçbir şey doldurmadı. Bu yazı, bunun daha yavaş kişiselleştirme biçimlerinden nasıl ayrıldığını, hangi sinyalleri kullanabileceğini, B2B örneklerini, ilk uygulamayı, teknik bileşenleri ve işe yarayıp yaramadığının nasıl ölçüleceğini ele alıyor.
Gerçek Zamanlı ve Gecikmeli Kişiselleştirme
Pazarlama kişiselleştirmesinin çoğu gecikmeli çalışır. Bir ziyaretçi bir teknik doküman indirir, bir CRM iş akışı onu etiketler ve birkaç gün sonra uygun bir e-posta gönderilir. Faydalıdır, ancak kişinin geçen hafta yaptığına yanıt verir.
Gerçek zamanlı kişiselleştirme, canlı sinyallere göre hareket eden bir dinamik içerik biçimidir: sistem her istekte ziyaretçi hakkında bildiklerine bakar, segment kurallarını değerlendirir ve bir varyant seçer. Bu önemlidir, çünkü B2B yolculukları düzensizdir. Bir potansiyel müşteri bir webinara katılabilir, üç ay sessiz kalabilir, sonra bir aramayla geri dönüp tek oturuşta beş vaka çalışması okuyabilir. Haftalık bir iş akışı bu geri dönüş ziyaretini çok geç görür; gerçek zamanlı bir kural ise ikinci sayfada yanıt verebilir.
| Gecikmeli (toplu) | Gerçek zamanlı | |
|---|---|---|
| Yanıtladığı soru | Bu kişi son zamanlarda ne yaptı? | Bu ziyaretçi şu anda ne yapıyor ve sayfa ona sırada ne göstermeli? |
| Tipik kanal | E-posta, reklamlar, satış görevleri | Web sitesi sayfaları, uygulama içi mesajlar |
| Gereken veri güncelliği | Saatlerden günlere | Talep sırasında mevcut |
| Ana teknik risk | Eskimiş segmentler | Yavaş kararlar ve titreme |
Ziyaret Sırasında Kullanabileceğiniz Sinyaller
- Firmografik veriler. Şirket, sektör, büyüklük ve konum; bir ziyaretçi tanımlama hizmeti tarafından ziyaretçinin IP'sinden çözümlenir. Ağı bir şirkete çözümlenen ziyaretçiler için ilk sayfa yüklemesinde kullanılabilir; bu da onu en yaygın B2B tetikleyicisi yapar. Kapsam kısmidir: Ev ve mobil bağlantılar çoğu zaman çözümlenemez.
- Oturum davranışı. Görüntülenen sayfalar, içerik kategorileri, kaydırma derinliği, site içi aramalar. Fiyatlandırma sayfasını ve ardından entegrasyonlar sayfasını okuyan bir ziyaretçi size çok spesifik bir şey anlatıyordur.
- Geçmiş. Ziyaretçi birinci taraf bir çerez, bir giriş veya izlenen bir e-posta bağlantısıyla tanındığında erişilebilen önceki ziyaretler, indirmeler ve webinar katılımları.
- Yönlendirme bağlamı. UTM parametreleri, yönlendiren alan adı ve kampanya. Finans yöneticilerine yönelik bir LinkedIn reklamından gelen bir tıklama, genel bir mesaja düşmemelidir.
- CRM durumu. Hesabın müşteri olup olmadığı, açık bir fırsatı olup olmadığı veya bir ABM listesinde yer alıp almadığı. CRM ile kişiselleştirme aracı arasında senkronizasyon gerektirir.
- Teknografik veriler. Üçüncü taraf verilerden, şirketin kullandığı araçlar. Doğru entegrasyonla öne çıkmak için faydalıdır ama doğruluğunu kontrol edin; bu veri çabuk eskir.
B2B Örnekleri
Aşağıdaki örnekler vaka çalışması değil, temsili kalıplardır.
Hesap seviyesine göre ana sayfa
1. Seviye hedef hesaplar başlıkta kendi sektörlerinin sorununu, ilgili bir vaka çalışmasını ve adı belirli müşteri temsilcileriyle görüşme CTA'sını görür. 2. Seviye hesaplar, self-servis demo CTA'sıyla birlikte sektöre özel mesajları görür. Diğer herkes varsayılanı görür. Bu, account-based marketing'i outbound e-postadan, hesapların zaten ziyaret ettiği web sitesine taşır.
Sektöre göre sosyal kanıt
Sabit bir logo duvarı yerine kanıt bloğu, ziyaretçinin sektörüne en yakın müşterileri ve benzer bir şirketten kısa bir alıntıyı gösterir. Bu yalnızca kişiselleştirme yaptığınız her sektörde gerçek müşterileriniz varsa işe yarar; hiç müşteriniz olmayan sektörler için varsayılanı yerinde bırakın.
Oturuma dayalı içerik önerileri
Üç analitik yazısı okumuş bir ziyaretçi, kenar çubuğunda varsayılan "en popüler" listesi yerine analitikle ilgili öneriler görür. Geçen sefer ürün demosunu izlemiş, geri dönen bir ziyaretçi ise yeni bir tanıtım yerine müşteri hikâyeleri görür.
Aşamaya göre CTA'lar
Bilinmeyen bir şirketten ilk kez gelen ziyaretçi: "Rehberi okuyun" veya "Nasıl çalıştığını görün". Ürün sayfalarını okumuş, hedef hesaptan geri dönen ziyaretçi: "Demo talep edin". Zaten demo talep etmiş biri: İkinci bir talep formu yerine gündem ve entegrasyon kontrol listesiyle "Demonuza hazırlanın". Veriye dayalı kişiselleştirilmiş CTA'lar yazımız bunların nasıl test edileceğini ele alıyor.
Şirket büyüklüğüne göre fiyatlandırma sayfası
50 kişilik bir şirket orta paketi önerilen olarak işaretlenmiş görür; 5.000 kişilik bir şirket ise satış CTA'sıyla vurgulanmış kurumsal kartı görür. Fiyatlar ve paketler herkes için aynı kalır; yalnızca vurgu değişir.
Beş Adımda İlk Uygulama
- Tek sayfa, tek segment. Genellikle ana sayfa veya ana açılış sayfası ve belirli bir büyüklük eşiğinin üzerindeki şirketler ya da tek bir sektör gibi güvenilir şekilde tanımlayabileceğiniz bir segment. Aynı anda birden fazla sayfa ve segment, bu projelerin tıkanma sebebidir.
- Önce varyantı yazın. Başlık, kanıt bloğu ve CTA. Segmentin neyi farklı duyması gerektiğini söyleyemiyorsanız, herhangi bir şeyi yapılandırmaya hazır değilsiniz.
- Tanımlamayı segmentasyona bağlayın. Kuralı yazın ("şirketin 500+ çalışanı var: kurumsal varyantı göster; aksi takdirde varsayılan") ve yayına almadan önce bilinen şirketlerden gelen ziyaretlerle test edin.
- Titreme olmadan sunun. Varyantı sunucuda veya uçta (edge) belirleyin ya da istemci tarafı betiğin, sayfanın geri kalanı yüklenirken yalnızca kişiselleştirilmiş bloğu değiştirmesini sağlayın. Ziyaretçiler varsayılan başlığın bir an görünüp değiştiğini görmemelidir.
- Bir kontrol grubuna karşı ölçün. Segmenti varsayılan ve varyant arasında bölün, örneklem büyüklüğüne yayından önce karar verin, ardından yalnızca varyant kazanırsa genişletin.
Teknik Parçalar
Veri katmanı. Ziyaretçi profilinin nereden geldiği: bir tanımlama hizmeti, bir CDP veya hızlı API'si olan bir CRM. Sorgu yavaşsa, karar gelmeden sayfa varsayılan hâliyle görüntülenir. Sorgunun yanıt süresini ofis bağlantınızda değil, gerçek trafik üzerinde ölçün.
Karar motoru. Kuralları değerlendirir ve bir varyant seçer. Çoğu B2B ekibi açık eğer/ise kurallarıyla başlar, çünkü bunları açıklamak ve hata ayıklamak kolaydır. Modele dayalı varyant seçimi, çoğu B2B sitesinin sahip olduğundan çok daha fazla segment başı trafik gerektirir.
Sunum. İstemci tarafı JavaScript en hızlı kurulan yöntemdir ama titreme riski taşır. Sunucu tarafı oluşturma titremeyi önler ama mühendislik zamanı gerektirir. Uç nokta sunumu (yanıtı CDN'de değiştirmek), CDN'iniz destekliyorsa her ikisini de önler.
Performans ve önbellekleme
Yayından önce ve sonra Core Web Vitals üzerindeki etkiyi kontrol edin; özellikle Largest Contentful Paint (hero genellikle LCP öğesidir) ve Cumulative Layout Shift (boyutu değişen bir blok sayfayı kaydırır). Kişiselleştirilmiş bloklar için yer ayırın ki içeriği aşağı itmesinler.
Ziyaretçiye göre değişen sayfalar önbellekleme konusunda dikkat gerektirir. Ya ortak bir sayfa iskeletini önbelleğe alıp yalnızca belirli blokları kişiselleştirin ya da kararı edge'de vererek her ziyaretçinin kendi sonucunu almasını sağlayın. Önbelleğe alınıp bir sonraki ziyaretçiye sunulan kişiselleştirilmiş bir yanıt yaygın bir hatadır ve arama motorlarının taradığı içerik haline de gelebilir; kişiselleştirmenin SEO'yu nasıl etkilediğine göz atın.
İşe Yarayıp Yaramadığını Ölçmek
Ana metrik, segment içindeki dönüşüm oranıdır: kişiselleştirilmiş deneyim ile aynı segmentten varsayılanı gören bir kontrol grubunun karşılaştırması. Kişiselleştirilmiş ziyaretçileri site ortalamasıyla karşılaştırmak işe yaramaz: Tanımlanmış hedef hesaplar zaten anonim trafikten farklı dönüşüm sağlar.
İkincil metrikler sonucu açıklamaya yardımcı olur: kişiselleştirilmiş öğeye yapılan tıklamalar, oturum başına sayfa ve geri dönüş ziyaretleri. Etkileşim artıyor ama dönüşümler artmıyorsa, varyant kararları değiştirmeden dikkat çekiyor demektir; onu daha yüksek niyetli bir sayfada deneyin.
Kişiselleştirmeyi trafiğe göre değerlendirmeyin. Kişiselleştirme, kaç ziyaretçinin geldiğini değil, geldikten sonra ne yaptıklarını değiştirir. Test sonuçlarını bir iş gerekçesine dönüştürmek için kişiselleştirme ROI'sini ölçme rehberimize bakın.
Tuzaklar
- Kötü verilerle kişiselleştirme yapmak. Tanımlama yanlış şirketlerle eşleşiyorsa veya CRM verileri eskiyse, sayfa rastgele görünür. Eşleşmelere dayanan kurallar oluşturmadan önce, bunları tanıdığınız hesaplarla karşılaştırarak rastgele kontrol edin.
- Aynı anda çok fazla değişiklik. Ziyaretçi verilerine dayanarak her öğeyi değiştirmek gözetim gibi hissettirebilir. Sayfa başına iki üç öğe yeterlidir: ziyaretçi sayfanın kendisi hakkında her şeyi bildiğini değil, alakalı olduğunu hissetmelidir.
- Ekipler arasında sorumlu yok. Pazarlama varyantları yazar, satışın hesap verilerine güvenmesi gerekir ve teknik biri veri akışından sorumludur. Bunlardan biri eksikse proje ilk testten sonra tıkanır.
- Kopuk yolculuklar. Genel bir sayfaya çıkan kişiselleştirilmiş bir reklam, verdiği sözü bozar. Aynı segment için reklamları, e-postaları ve sayfaları uyumlu hâle getirin; B2B web sitesi kişiselleştirmenin nasıl çalıştığı açıklayıcı yazımız uçtan uca kurulumu ele alıyor.
Nereden Başlamalı
Bir sayfa, güvenilir verisi olan bir segment ve değiştirilecek iki veya üç öğe seçin, ardından planlanan örnekleme ulaşılana kadar bir kontrol grubuna karşı yürütün. Kazanırsa bir sonraki segmenti ekleyin; kazanmazsa, tekrar denemeden önce değişikliğin yeterince büyük ve segmentin yeterince dar olup olmadığını kontrol edin. Bu ilk testi altyapıyı kendiniz kurmadan başlatmak isterseniz, Markettailor ziyaretçi tanımlamayı kural tabanlı hedeflemeyle sayfa içi değişikliklere bağlar.
