Kurumsal web sitesi kişiselleştirmesi nadiren teknoloji yüzünden başarısız olur. Sahiplik yüzünden başarısız olur: Beş bölgesel ekip ayrı ayrı kural ekler, hangi kuralın kazanacağına kimse karar vermez, geçen yılki bir kampanya varyantı hâlâ üç dilde yayındadır, her etiketle sayfa yavaşlar ve hukuk birimi hepsini birden keşfeder. Bu kılavuz, tek bir web varlığında birkaç iş birimi, bölge veya markası olan kuruluşlar içindir. Kimin ne yaptığını, kuralların nasıl yönetildiğini, net giriş ve çıkış kriterleriyle pilottan bölgelere nasıl geçileceğini, site performansının ve onayın nasıl korunacağını ve örnek bir iki çeyreklik planı ele alıyor.
İş gerekçesini kapsamaz. Hâlâ bütçe onayına ihtiyacınız varsa, önce kontrol gruplarıyla kişiselleştirme ROI'sini ölçme yöntemini kullanın ve bir sponsorunuz olduğunda geri dönün.
Kurumsal Segmenti Farklı Kılan Nedir?
- Ortak alanlar. Ana sayfa ve gezinme menüsü herkese aittir; bu yüzden her iş birimi orada bir kural ister. Öncelik sırası önceden belirlenmezse siyasi bir meseleye dönüşür.
- Birden fazla hukuki rejim. Aynı sayfa GDPR, Birleşik Krallık kuralları ve ABD eyalet yasalarına tabi ziyaretçilere, farklı varsayılan onay ayarlarıyla sunulabilir.
- Birden fazla CMS ve etiket yöneticisi. Bunlara dağılmış kişiselleştirme mantığı denetlenemez.
- Çeviri varyantları katlar. Sekiz dilde üç segment, öğe başına her biri inceleme ve son kullanma tarihi gerektiren 24 varyant demektir.
- Performansın sorumlusu başkası. Core Web Vitals'tan web platformu ekibi sorumludur; betikleriniz onların sorunudur.
RACI: Kim Ne Yapar
R = sorumlu (responsible), A = hesap veren (accountable), C = danışılan (consulted), I = bilgilendirilen (informed). Her satırda bir A, istisnasız.
| Etkinlik | Merkezi web ekibi | İş birimi / bölgesel pazarlama | Marka ve içerik | Web mühendisliği | Hukuk ve gizlilik | Analitik | Satış operasyonları |
|---|---|---|---|---|---|---|---|
| Kural önceliği ve adlandırma standardı | Alacak hesapları | C | C | C | I | C | I |
| Segment tanımları | A | R | I | I | C | C | C |
| Varyant metni ve materyalleri | C | R | A | I | C | I | I |
| Çeviri ve yerelleştirme | I | R | A | I | I | I | I |
| Etiket dağıtımı ve performans bütçesi | C | I | I | Alacak hesapları | I | C | I |
| Bölgeye göre onay yapılandırması | R | C | I | R | A | C | I |
| Yayından önce kalite kontrol onayı | A | R | C | R | C | C | I |
| Kontrol grubu tasarımı ve sonuçları | C | I | I | I | I | Alacak hesapları | I |
| CRM ve hesap verisi senkronizasyonu | C | I | I | R | C | C | A |
| Üç aylık kural denetimi ve emekliye ayırma | Alacak hesapları | R | C | I | I | C | I |
Görüşümüz: İşin çoğunu iş birimleri yapsa da öncelik sırasından ve denetimden merkezi web ekibi sorumlu olmalıdır. İçeriğin dağıtık sahipliği işe yarar; kural setinin dağıtık sahipliği yaramaz.
Yönetişim
Kural önceliği
İki kural aynı ziyaretçi için aynı öğeyi hedeflediğinde, birinin belirleyici şekilde kazanması gerekir. Çoğu yapı için işe yarayan, en yüksekten başlayan bir öncelik sırası:
- Hukuki ve onay kuralları (örneğin onay olmadan tanımlayıcıya dayalı kural yok)
- CRM'den müşteri ve açık fırsat kuralları
- İsimli hesap (ABM) kuralları
- İş birimine ait sayfalarda iş birimi ürün kuralları
- Sektör veya segment kuralları
- Kampanya mesaj uyumu kuralları
- Bölgesel varsayılan
- Genel varsayılan
Ana sayfa gibi ortak sayfalarda her öğenin (hero alanı, kanıt çubuğu, birincil CTA) tek bir sorumlu ekibi olur. Diğer ekipler rakip kurallar eklemek yerine merkezi ekip aracılığıyla alan talep eder.
Adlandırma kuralları
Kural listesi, analitik raporları ve QA kayıtları aynı şekilde okunsun diye araçlar genelinde tek bir kalıp kullanın: region_bu_page_element_segment_vNN, örneğin emea_payments_home_hero_retail_v03. Son kullanma tarihini ve sorumluyu adda değil, kural meta verisi olarak ekleyin.
Herhangi bir kural yayına girmeden önce kalite kontrol listesi
- Varyant masaüstünde, mobilde ve desteklenen en yavaş tarayıcıda doğru oluşturuluyor
- Görünür titreme yok; değiştirilen öğeler için alan ayrılmış
- Rızayı reddeden ve tespit edilemeyen ziyaretçiler doğru varsayılanı görüyor
- Aynı öğe üzerinde daha yüksek öncelikli bir kuralla çakışma yok
- Kapsamdaki tüm diller anadili konuşan biri tarafından incelendi
- Hedef bölgede kullanılmak üzere onaylanmış iddialar, logolar ve vaka çalışmaları
- Kontrol grubu yapılandırıldı ve dönüşüm olayı her iki grup için de tetikleniyor
- Sorumlu ve sona erme tarihi kaydedildi
Yüzlerce kuralınız olduğunda çakışmaları yönetmek için ölçekte kişiselleştirme yazımıza bakın.
Giriş ve Çıkış Kriterleriyle Yaygınlaştırma Aşamaları
| Aşama | Kapsam | Giriş kriterleri | Çıkış kriterleri |
|---|---|---|---|
| 0. Temel | Yayında kural yok | Üst düzey sponsor belirlendi; RACI üzerinde anlaşıldı | Öncelik sırası, adlandırma standardı, kalite kontrol listesi ve performans bütçesi onaylandı; pilot bölge için onay yapılandırması hukuk tarafından onaylandı |
| 1. Pilot | Bir iş birimi, bir bölge, bir dil, yüksek trafikli sayfalarda 2-3 kural | 0. aşama tamamlandı; pilot trafik planlanan örneklem büyüklüğü için yeterli | En az bir kontrol grubu testi planlanan örneklem büyüklüğüne ulaşır; performans bütçesi korunur; çözülmemiş kalite hatası sıfırdır |
| 2. Bölgesel genişleme | Aynı iş birimi, ek bölgeler ve diller | Pilot çıkış kriterleri karşılandı; bölgesel onay ayarları gözden geçirildi; çeviri iş akışı test edildi | Her bölgenin adı belirli bir sorumlusu, bütçe dahilinde yayında olan kuralları ve kendi kontrol grubu ölçümü var |
| 3. İş birimi genişlemesi | Ek iş birimleri, ortak sayfalar | Ortak sayfalarda alan sahipliği üzerinde anlaşıldı; kalite kontrol için merkezi ekip kapasitesi | Tüm iş birimleri adlandırma ve sona erme kurallarına uyuyor; ilk üç aylık denetim tamamlandı |
| 4. Federe işleyiş | İş birimleri belirlenen sınırlar içinde kendi işlerini görür | Sorunsuz geçen iki üç aylık denetim | Sürekli: Her çeyrek denetim, bütçe sürekli takipte |
Çoğu ekibin yanlış yaptığı şey: Pilotu "işe yarıyor gibi görünüyor" diyerek bitirirler. Çıkış kriterlerini pilot başlamadan önce yazın ve karşılanmayan bir kriteri çıtayı düşürmek için değil, aşamayı uzatmak için bir neden olarak görün.
İçerik Operasyonları
Tüm site yapısı için ortak bir tabloda veya kişiselleştirme aracında tek bir varyant envanteri tutun ve her varyant için şu alanları ekleyin: kural adı, sayfa, öğe, segment, dil, sorumlu, yayın tarihi, sona erme tarihi, kontrol grubu durumu, en son sonuç ve kullanılan iddia veya kanıtın kaynağı.
- Varsayılan olarak 90 günlük geçerlilik süresi. Süre dolduğunda sorumlu kişi yeniler, revize eder veya kullanımdan kaldırır. Sorumlusu olmayan varyantlar otomatik olarak kapatılır.
- Kanıtların da son kullanma tarihi vardır. Müşteri logoları ve vaka çalışmaları izin gerektirir ve bu izin geri çekilebilir; her birini onay kaydına bağlayın.
- Çeviriyi testten önce değil, sonra yapın. Bir varyantı önce tek bir dilde kanıtlayın, ardından kazananı yerelleştirin. Kaybeden varyantları çevirmek, kurumsal programlardaki en yaygın israftır.
- Modüler metin. Varyantları ortak şablonların içinde alanlar (başlık, kanıt, CTA) olarak yazın; böylece yeni bir segment yeni bir sayfa değil, yeni alan içeriği anlamına gelir.
Kişiselleştirme taktik kitabı şablonu, uyarlayabileceğiniz bir varyant envanteri yapısı içeriyor.
Performans Bütçeleri
İstemci tarafı kişiselleştirme bir betik yükleyerek, bir varyanta karar vererek ve sayfayı değiştirerek çalışır. Her adım Core Web Vitals'a zarar verebilir. Google'ın iyi bir deneyim için belirlediği ve sayfa yüklemelerinin 75. yüzdeliğinde ölçülen eşikler şunlardır: 2,5 saniye içinde LCP, 200 milisaniye veya daha az INP ve 0,1 veya daha az CLS (web.dev, Web Vitals).
Kişiselleştirme bunları nasıl bozar:
- Titreme önleyici gizleme LCP'yi geciktirir. Birçok araç karar verilene kadar sayfayı veya hero alanını gizler. web.dev'in LCP optimizasyonu rehberi, bir A/B testi kütüphanesi tarafından gizlenen bir öğeyi görüntüleme gecikmesinin nedenlerinden biri olarak sayıyor.
- Değiştirilen içerik düzeni kaydırır. Dinamik olarak eklenen içerik kendisinden sonra gelenleri kaydırır ve görünüm alanının üstüne ne kadar yakınsa kayma o kadar büyük olur (web.dev, Optimize CLS).
- Kod ağırlığı ve ana iş parçacığı yükü. Her üçüncü taraf kod, etkileşimi etkileyen ana iş parçacığı için rekabet eder.
Pilottan önce yazılı bir bütçe belirleyin. Bunlar sektör standartları değil, önerdiğimiz başlangıç noktalarıdır; web mühendisliği ekibinizle birlikte ayarlayın:
| Bütçe kalemi | Önerilen sınır | Nasıl kontrol edilir |
|---|---|---|
| Kişiselleştirilmiş sayfalarda p75 LCP'deki değişim (kontrol grubuna göre) | En fazla 100 ms daha kötü | Kontrol grubuna göre ayrılmış saha verileri |
| Titreme önleme için azami gizleme süresi | Sabit zaman aşımı, ardından varsayılanı göster | Kısıtlanmış ağla laboratuvar testi |
| Değiştirilen öğelerin CLS katkısı | Sıfır: alan ayırın | Laboratuvar testlerinde düzen kayması atfı |
| Kişiselleştirme kodunun boyutu | Kararlaştırılan üst sınır, sıkıştırılmış | Her sürümde paket boyutu analizi |
| Kurallar her sayfada istemci tarafında değerlendirilir | Üzerinde anlaşılan üst sınır | Sayfa başına kural sayısı raporu |
Yapısal çözüm, kararları istemciden uzaklaştırmaktır: varyantı sunucuda veya uçta oluşturun, böylece tarayıcı son HTML'yi alır. Bu mümkün değilse, istemci tarafı kuralları ekranın alt kısmındaki öğelerle sınırlayın ve hero alanını sunucu tarafında oluşturun.
Bölgelere Göre Gizlilik ve Onay
Hukuki tavsiye değil, hukuk ekibiniz için bir yönlendirme:
| Bölge | Temel kurallar | Kişiselleştirme için varsayılan |
|---|---|---|
| AB / AEA | GDPR artı ePrivacy Direktifi'nin cihazda depolama ve erişime ilişkin kuralları (EDPB'nin Guidelines 2/2023 belgesinde geniş yorumlanır); rıza standartları için EDPB'nin Guidelines 05/2020 on consent belgesi | Tanımlayıcıya dayalı kurallar yalnızca onaydan sonra; şirket düzeyindeki ve kampanya kuralları meşru menfaat değerlendirmenize göre |
| Birleşik Krallık | UK GDPR ve PECR; bkz. ICO'nun çerezler ve benzeri teknolojilere ilişkin rehberi | AB'ye benzer; Birleşik Krallık kuralları geliştikçe yerel olarak teyit edin |
| Kaliforniya | Değişiklikleriyle CCPA; Global Privacy Control sinyalleri dahil, bilgi edinme ve satış veya paylaşımdan vazgeçme hakları (California Attorney General) | GPC'yi bir vazgeçme (opt-out) olarak dikkate alın; sağlayıcılara paylaşım sayılacak şekilde veri aktarılıp aktarılmadığını kontrol edin |
| Diğer bölgeler | Her pazar için hukuk danışmanıyla eşleştirin | Uygulanabilir en katı varsayılandan başlayın |
Üç operasyonel kural: onayı etiket bazında değil, bölge bazında tek bir yerden yapılandırın; onay verilmediğindeki deneyimi test edilmiş bir varyant yapın; ve profillemenizin GDPR Article 35 kapsamında bir veri koruma etki değerlendirmesi gerektirip gerektirmediğini hukuk ekibine erkenden sorun. CRM verilerini web davranışıyla ölçekte birleştirmek, bu sorunun gündeme geldiği türden bir işlemedir.
Kurumsal Dağıtımlarda Yaygın Hatalar
- Her bölgede aynı anda yayına geçmek. Bu durumda yanlış yapılandırılmış tek bir onay ayarı, aynı anda her pazarda sorun haline gelir. Operasyon modelini önce tek bir bölgede kanıtlayın.
- Her iş biriminin kendi aracını satın almasına izin vermek. Tek bir sayfada iki kişiselleştirme aracı; iki betik, iki kural seti ve tek bir öncelik sırasının olmaması demektir. 3. Aşama'dan önce tek bir karar katmanında standartlaşın.
- Yalnızca toplu ölçüm yapmak. Küresel bir dönüşüm artışı, varyantların kaybettiği bir bölgeyi gizleyebilir. Her bölge ve segmentin kendi kontrol grubu ölçümü olmalıdır.
- Denetimi isteğe bağlı görmek. Biri kaldırmadıkça varyant sayısı yalnızca artar. 90 günlük son kullanma kuralı fiilen üç aylık denetimde uygulanır.
- Performans karşılaştırmasını atlamak. Hızlı bir ofis bağlantısında yapılan laboratuvar testleri, orta segment telefonlardaki ziyaretçilerin deneyimini kaçırır. Kişiselleştirilmiş grup ile kontrol grubu arasındaki saha verilerini karşılaştırın; kontrol grubu aynı zamanda temiz performans referansınızdır.
- Test etmeden önce çevirmek. Yukarıda değinildi, ama bu listedeki en pahalı hata olduğu için tekrar etmeye değer.
Örnek İki Çeyreklik Uygulama Planı
| Haftalar | Aşama | Temel çıktılar | Sonunda karar |
|---|---|---|---|
| 1-3 | Temel | RACI, öncelik sırası, adlandırma standardı, kalite kontrol listesi, performans bütçesi, pilot onay yapılandırması | Sponsor yönetişim paketini onaylar |
| 4-5 | Pilot kurulumu | Tek bir iş biriminde ve bölgede 2-3 kural; kontrol grupları yapılandırılmış; örneklem büyüklüğü hesaplanmış | Kalite kontrolden geçti, laboratuvar testinde bütçe karşılandı |
| 6-11 | Pilot çalışma | Haftalık performans ve kural sağlığı kontrolleri; yeni kural eklenmez | Pilot çıkış kriterleri karşılandı veya aşama uzatıldı |
| 12-13 | Gözden geçirin ve planlayın | Sonuç sunumu, varyant envanteri incelemesi, bölgesel genişleme planı | 2. çeyrek için bölgeleri onaylayın |
| 14-18 | Bölgesel genişleme | Kazanan varyantları çevirin; bölgesel onay incelemesi; bölge sorumluları eğitildi | Her bölge bütçe dahilinde yayında |
| 19-24 | İş birimi genişleme hazırlığı ve ilk denetim | Ortak sayfa alanı anlaşmaları; ilk üç aylık denetim; süresi dolmuş varyantları kaldırın | Sonraki iş birimlerini onaylayın ya da durup düzeltin |
Pilot çalışmayı elinizdeki trafiğe göre boyutlandırın. Pilot sayfanın temel dönüşüm oranıyla A/B testi hesaplayıcısını kullanın; gereken örnekleme altı haftada ulaşılamıyorsa, takvimi süresiz uzatmak yerine daha fazla trafik alan bir sayfa veya daha yüksek hacimli bir dönüşüm olayı seçin. Pilotun dayandığı segment, varyant ve kontrol grubu temelleri için pratik web sitesi kişiselleştirme rehberine bakın.
Markettailor'ın A/B testi özelliği her kişiselleştirme kuralı için holdout grupları çalıştırır; bu da yukarıdaki her aşamadaki ölçüm adımını karşılar.
Sıkça Sorulan Sorular
Kurumsal web sitesi kişiselleştirme nedir?
Birkaç iş birimi, bölge, dil veya markaya sahip büyük bir web varlığında yürütülen web sitesi kişiselleştirmesidir. Teknikler daha küçük programlardakiyle aynıdır; fark yönetişimdedir: hangi kuralların sahibinin kim olduğu, çakışmaların nasıl çözüldüğü, onayın bölgeye göre nasıl farklılaştığı ve varyant sayısı arttıkça performans ile içerik kalitesinin nasıl kontrol altında tutulduğu.
Kurumsal bir kişiselleştirme uygulaması ne kadar sürer?
Yukarıdaki örnek planda olduğu gibi, yönetişim kurulumundan pilot uygulamaya ve ilk bölgesel genişlemeye kadar gerçekçi bir plan yaklaşık iki çeyrek sürer. Pilotun süresini trafik belirler: holdout testi planlanan örneklem büyüklüğüne ulaşana kadar devam etmelidir. İş birimleri genelinde tam yaygınlaştırma genellikle sonraki çeyreklerde sürer.
Web sitesi kişiselleştirme bir siteyi yavaşlatır mı?
Edebilir. İstemci taraflı araçlar genellikle bir varyant seçilene kadar içeriği gizler; bu da Largest Contentful Paint'i geciktirir ve değiştirilen öğeler düzen kaymalarına yol açabilir. Bir performans bütçesi belirleyin, kişiselleştirilmiş gruplar ile kontrol grupları arasında Core Web Vitals değerlerini karşılaştırın, değiştirilen öğeler için alan ayırın ve mümkün olduğunda varyantları sunucu tarafında veya uçta (edge) oluşturun.
Büyük bir şirkette web sitesi kişiselleştirmesinden kim sorumlu olmalı?
Kural setinin sahibi merkezi bir web veya dijital ekip olmalıdır: öncelik sırası, adlandırma, kalite kontrol ve üç aylık denetim. İş birimleri ve bölgeler kendi segmentlerinin ve varyant içeriklerinin, marka ekibi metin standartlarının, mühendislik performansın, hukuk ekibi ise onay yapılandırmasının sahibi olmalıdır. Kural sahipliğini ekipler arasında bölmek, çakışan ve bakımsız kurallar doğurur.