10 Kas 2025·8 dk
Ürün Deneyim Günlüğü için Web Sitesi Nasıl Oluşturulur
Deney kayıtlarını tutan; tutarlı girişler, etiketleme, arama ve açık sonuçlar sağlayan bir web sitesini nasıl planlayıp, tasarlayıp yayına alacağınızı öğrenin.
Deney kayıtlarını tutan; tutarlı girişler, etiketleme, arama ve açık sonuçlar sağlayan bir web sitesini nasıl planlayıp, tasarlayıp yayına alacağınızı öğrenin.
Bir ürün deneyim günlüğü web sitesi, ekibinizin yürüttüğü her deneyi—A/B testleri, fiyatlandırma denemeleri, onboarding ayarları, feature-flag'ler, e-posta testleri ve hatta hâlâ bir şey öğreten "başarısız" fikirleri—belgelemek için paylaşılan bir yerdir. Bunu bir deney deposu ve ürün öğrenme günlüğünün birleşimi gibi düşünün: ne denediğinizin, neden denediğinizin, ne olduğunu ve sonraki kararları kaydeden bir arşiv.
Çoğu takım deney takibini dokümanlarda, panolarda ve sohbet dizilerinde parçalanmış biçimde zaten tutar. Özel bir deney takip web sitesi bu parçaları tek, gezilebilir bir tarihe çeker.
Pratik sonuçlar şunlardır:
Bu rehber, deney dokümantasyonunu oluşturmayı ve kullanmayı kolaylaştıran bir web sitesi kurmayı nasıl planlayacağınızı, yapacağınızı ve yayınlayacağınızı anlatır. Yapıyı ve gezinmeyi planlamayı, deney girdileri veri modelini tanımlamayı (kayıtların tutarlı kalması için), okunaklı sayfa şablonları oluşturmayı, hızlı keşif için etiketleme ve arama kurmayı ve doğru uygulama yaklaşımını (CMS vs. özel uygulama) seçmeyi ele alacağız.
Sonunda, hipotezleri, metrikleri, sonuç raporlamasını ve kararları aramaya uygun, güvenilir ve zaman içinde işe yarar şekilde yakalayacak bir A/B test dokümantasyon sitesi için net bir planınız olacak.
Araçları seçmeden veya deney şablonlarını tasarlamadan önce, bu deney takip sitesinin neden var olduğunu ve kime hizmet ettiğini netleştirin. Bir ürün deneyim günlüğü, ekiplerinizin gerçekten nasıl karar verdiğiyle örtüşmüyorsa kullanışlı olmaz.
Deney deposu için 2–4 ölçülebilir sonuç yazın. Yaygın başarı tanımları şunlardır:
Bu hedefler sonraki her şeyi etkilemelidir: her kayıtta hangi alanların gerekli olduğu, iş akışınızın ne kadar sıkı olduğu ve etiketleme/arama ihtiyaçlarınızın ne kadar gelişmiş olması gerektiği.
Birincil kitlelerinizi ve ürün öğrenme günlüğünde ne yapmaları gerektiğini listeleyin:
Bunu doğrulamanın basit bir yolu: her gruba "30 saniyede hangi sorunun yanıtlanmasını istersiniz?" diye sorun. Sonra deney şablonlarınızın ve sayfa düzeninizin bunun için uygun olduğundan emin olun.
Başlangıçta CMS'inizin deney günlüğü için hangi erişim modelini kullanacağını belirleyin:
Karışık tercih ederseniz, halka açık girdilerde nelerin izinli olduğunu (ör. ham metrik yok, anonimleştirilmiş segmentler, yayımlanmamış özellik adları yok) ve yayımlamayı kimin onayladığını tanımlayın. Bu, ileride ekibiniz dışa öğrenim paylaşmak istediğinde yeniden çalışmayı önler.
Bir ürün deneyim günlüğü ancak insanlar doğru deneyi bir dakikadan kısa sürede bulabiliyorsa işe yarar. Araçları seçmeden veya ekranları tasarlamadan önce, birinin ne aradığını bilmediği durumda deney takip sitenizde nasıl gezineceğine karar verin.
Ana gezinmeyi sınırlı ve öngörülebilir tutun. Pratik bir başlangıç noktası:
Eğer "Metrics" ağır geliyorsa, önce Experiments içinden bağlayabilir ve sonra genişletebilirsiniz.
Gezinmenin ana "şekli"ne karar verin. Çoğu ürün öğrenme günlüğü birincil bir görünümle ve geri kalanını filtrelerle halleder:
Paydaşlarınızın konuşmalarında zaten kullandığı olanı seçin. Diğer her şey etiketler (örn. platform, hipotez teması, segment, deney türü) olabilir.
URL'leri okunabilir ve kararlı yapın ki insanlar bunları Slack veya ticket'larda paylaşabilsin:
/experiments/2025-12-checkout-free-shipping-thresholdExperiments → Checkout → Free shipping threshold gibi breadcrumb'lar ekleyin; bu, çıkmaz sokakları engeller ve taramayı sezgisel tutar.
Yayınlayacaklarınızı "gün bir" ve sonraki dönemler olarak listeleyin: son deneyler, öne çıkan playbook'lar, temel metrik sözlüğü ve takım sayfaları. Sık başvurulan girdilere öncelik verin (yüksek etkili testler, kanonik deney şablonları ve sonuç raporlamasında kullanılan metrik tanımları).
Kullanışlı bir ürün deney günlüğü sadece bağlantı listesinden ibaret değildir—o, öğrenimlerin bir veritabanıdır. Veri modeli, veritabanının "şekli"dir: ne sakladığınız, girdilerin nasıl ilişkilendiği ve kayıtların zaman içinde karşılaştırılabilir kalması için hangi alanların gerekli olduğu.
Takımlarin gerçekten nasıl çalıştığına uyan küçük bir içerik türü setiyle başlayın:
Bunları ayrı tutmak, her deneye yeni metrik isimleri uydurulmasını veya kararların serbest metinde gömülmesini engeller.
"Minimum uygulanabilir kayıt"ı doldurmayı kolay yapın. En azından şu alanları zorunlu kılın:
İsteğe bağlı ama değerli alanlar: hedef kitle, trafik dağılımı, test türü (A/B, multivariate) ve ticket veya tasarım bağlantıları.
Sonuçlar genellikle günlüklerin bozulduğu yerdir; bu yüzden bunları standartlaştırın:
Ek dosya eki kabul ediyorsanız, okuyucuların nerede bakacağını bilmeleri için ekran görüntüleri için tutarlı bir alan tutun.
Keşif ve raporlama ileride işe yarasın diye ilişkileri açık modelleyin:
Sıralama ve panoların anlamlı kalması için statüleri standartlaştırın: proposed, running, concluded, shipped, archived. Bu, “done”, “complete” ve “finished” gibi üç farklı duruma dönüşmeyi engeller.
İyi şablonlar "birinin notları"nı tüm şirketin tarayabileceği, güvenebileceği ve yeniden kullanabileceği paylaşılan bir kayda çevirir. Amaç, yazarlara evrak işi gibi hissettirmeden tutarlılıktır.
Okuyucunun okumaya devam edip etmemeye karar vermesi için gereken bilgiden başlayın.
/docs/...) ve birincil metrik.Index sayfanız bir pano gibi davranmalıdır. Statü, ekip, etiket, tarih aralığı ve platform için filtreler; son güncellenen, başlangıç tarihi ve (mümkünse) etki ile sıralama; ve hızlı tarama alanları olarak statü, sahip, başlangıç/bitiş tarihleri ve tek satırlık bir sonuç gösterin.
Bir varsayılan şablon ve opsiyonel varyantlar (örn. “A/B testi”, “Fiyat testi”, “Onboarding deneyi”) oluşturun. Başlıkları, örnek metni ve zorunlu alanları önyükleyin ki yazarlar sıfırdan başlamasın.
Tek sütunlu düzen, geniş satır aralığı ve net tipografi kullanın. Anahtar bilgileri yapışkan bir özet bloğunda tutun (mantıklıysa) ve tabloları yatay kaydırılabilir yapın ki sonuçlar telefonda da okunabilir kalsın.
Deney günlüğü, insanlar hızlıca ilgili öğrenimleri bulabildiğinde işe yarar. Etiketleme ve taksonomi, bir yığın deney sayfasını gezinilebilir, filtrelenebilir ve yeniden kullanılabilir hâle getirir.
Ekiplerin doğal olarak nasıl aradığına uygun birkaç etiket grubu tanımlayın. Pratik bir temel:
Grup sayısını sınırlı tutun. Çok fazla boyut filtrelemeyi kafa karıştırıcı hale getirir ve tutarsız etiketlemeyi teşvik eder.
Kontrolsüz etiketler hızla "signup", "sign-up" ve "registration" gibi çeşitlenir. Kontrollü bir sözlük oluşturun:
Basit bir yaklaşım, takımın sürdürdüğü bir “etiket kaydı” sayfası (örn. /experiment-tags) ve deney yazımı sırasında hafif bir incelemedir.
Etiketler keşif için iyidir, ama bazı öznitelikler tutarlı kalmak için yapılandırılmış alan olmalıdır:
Yapılandırılmış alanlar güvenilir filtreler ve panolar sağlar; etiketler ise nüans yakalar.
Okuyucuların bağlantılı çalışmalara atlamasını kolaylaştırın. Related experiments (aynı özellik veya metrik) ve Similar hypotheses (başka yerde test edilmiş aynı varsayım) gibi bölümler ekleyin. İlk aşamada bunlar manuel bağlantılar olabilir, sonra ortak etiket kurallarıyla otomatik öneriler yapılabilir.
Bu karar, ürün deneyim günlüğünüzün ulaşabileceği sınırı belirler. Bir CMS hızlı yayınlama sağlar; özel bir uygulama ise günlüğü karar alma için sıkı entegre bir sisteme dönüştürebilir.
Eğer ana ihtiyacınız tutarlı, okunabilir A/B testi dokümantasyonu ve hafif yapı ise CMS uygundur.
CMS kullanın eğer isterseniz:
Tipik desen: headless CMS (içerik CMS'te saklanır, siteniz tarafından sunulur) ile static site generator kombinasyonu. Bu, deney deposunu hızlı, kolay barındırılabilir ve teknik olmayan katkıda bulunanlar için dostça tutar.
Günlük, ürün verileriniz ve dahili araçlarla doğrudan bağlanmalıysa özel uygulama mantıklıdır.
Aşağıdaki durumlarda özel uygulamayı düşünün:
Hızlı prototip için, Koder.ai gibi bir vibe-coding platformu pratik bir kestirme olabilir: veri modelini (experiments, metrics, decisions), sayfa şablonlarını ve iş akışlarını sohbette tarif edebilir, ardından React + Go + PostgreSQL uygulamasını çalışır hâlde üretebilirsiniz; dağıtım/barındırma, kaynak dışa aktarımı ve snapshot/geri alma desteğiyle güvenli değişiklikler yapabilirsiniz.
Deney verilerinin nerede tutulduğunu açıkça belirleyin.
Bunu baştan yazın—aksi halde ekipler dokümanlarda, tablolar ve araçlarda çakışan girdilerle güveni yitirir.
Deney günlüğünüz egzotik teknolojiye ihtiyaç duymaz. En iyi yığın, ekibinizin güvenle işletip güvenli tutabileceği ve sürdürmeye zorlanmayacağı yığındır.
Bir static site (önceden üretilmiş sayfalar) sıklıkla en basit seçenektir: hızlı, ucuz barındırma ve düşük bakım. Deneyler çoğunlukla salt-okunur ve güncellemeler bir CMS veya pull request ile yapılıyorsa iyi çalışır.
Server-rendered app, daha güçlü erişim kontrolü, dinamik filtreler veya ekip görünümleri gerektiğinde uygundur. Sunucu seviyesinde izinleri uygulamak da daha kolaydır.
Single-page app (SPA) filtrleme ve panolar için çok duyarlı gelebilir, ama SEO, kimlik doğrulama ve ilk yük performansı açısından ek karmaşıklık getirir. Gerçekten uygulama benzeri etkileşimler gerekirliyse seçin.
Eğer özel uygulama inşa ediyorsanız, geleneksel bir build pipeline mı yoksa hızlandırılmış bir yaklaşım mı istediğinize karar verin. Örneğin, Koder.ai çekirdek iskelet (React UI, Go API, PostgreSQL şema) yazılı bir spesifikasyondan üretebilir; bu, şablonlar ve iş akışları üzerinde paydaşlarla iterasyon yaparken faydalıdır.
Güvenilirlik (çalışırlık, izleme, uyarılar) ve yedeklemeler (otomatik, test edilmiş geri yüklemeler) önceliğiniz olsun. Ortam ayrımına dikkat edin: en azından üretim öncesi bir staging ortamı, taksonomi değişikliklerini, şablon güncellemelerini ve izin kurallarını prod'a almadan denemek için gereklidir.
Çoğu takım eninde sonunda SSO (Okta, Google Workspace, Azure AD) ve roller (viewer, editor, admin) ile özel alanlara ihtiyaç duyar. Hassas öğrenimler (gelir, kullanıcı verisi, yasal notlar) için bunu baştan planlayın ki daha sonra yeniden mimari yapmanız gerekmesin.
Caching (CDN ve tarayıcı önbelleği), sayfaları hafif tutma ve medyayı optimize etme (sıkıştırılmış görseller, uygun durumlarda lazy loading) kullanın. Hızlı sayfa yükü önemlidir; insanlar toplantı sırasında geçmiş bir testi bulmaya çalışırken yavaş bir günlük kullanmaz.
Bir ürün deney günlüğü, insanlar "o testi" saniyeler içinde bulabildiğinde gerçekten işe yarar—tam başlık bilinmese bile.
Site içi arama (CMS veya uygulama veritabanına entegre) birkaç yüz deney, küçük takım ve başlık/özet/etiket aramalarında genellikle yeterlidir. Bakımı daha kolaydır ve ekstra vendor kurulumu gerektirmez.
Binlerce kayıt, yıldırım hızında sonuç, yazım hatası toleransı veya ileri sıralama gerekiyorsa bir dış arama servisi (Algolia/Elastic/OpenSearch gibi) değerlidir. Dış arama, içerik birden fazla kaynaktaysa (doküman + günlük + wiki) da faydalıdır.
Aramanın yanında şu filtreleri ekleyin:
Filtrelerin birleştirilebilir olmasını sağlayın (örn. "Concluded + Son 90 gün + Growth ekibi + Aktivasyon metrik").
Kaydedilmiş görünümler tekrar eden soruları tek tıkla cevaplar:
Takımların paylaşılan görünümleri gezinmeye sabitlemesine izin verin ve bireylerin kişisel görünümler kaydetmesine olanak tanıyın.
Arama sonuçlarında kısa bir sonuç snippet'i gösterin: hipotez, varyant, kitle ve başlık sonucu. Eşleşen anahtar kelimeleri başlık ve özetten vurgulayın ve birkaç kilit alanı (statü, sahip, birincil metrik) sergileyin ki kullanıcılar birden fazla sayfa açmadan doğru deneyi seçebilsin.
Harika bir deney takip sitesi sadece sayfalar ve etiketler değildir—paylaşılan bir süreçtir. Net sahiplik ve hafif bir iş akışı yarım kalmış girdileri, eksik sonuçları ve aylar sonra belirsiz kararları önler.
Kimlerin deney girişi oluşturabileceğini, düzenleyebileceğini, onaylayabileceğini ve yayınlayabileceğini belirleyin. Basit bir model çoğu ekip için yeterlidir:
Erişim seviyelerini (public vs internal vs restricted) kararlarınıza göre tutarlı yapın. Özel deneyleri destekliyorsanız, her kayıtta açık bir sahibi zorunlu kılın.
Her deney yayınlanmadan önce kısa bir kontrol listesi tanımlayın:
Bu kontrol listesi deney şablonlarında zorunlu bir form bölümü olabilir.
Kayıtları yaşayan dokümanlar gibi ele alın. Versiyon geçmişi etkinleştirin ve önemli güncellemeler için kısa değişiklik notları zorunlu kılın (metrik düzeltmesi, analiz düzeltmesi, karar geri alma). Bu güveni yüksek tutar ve denetimleri kolaylaştırır.
Hassas bilgileri nasıl saklayacağınızı önceden belirleyin:
Yönetişim ağır olmak zorunda değil; sadece açık olması yeterlidir.
Deney takip sitesi, içindekilerin bulunabilir, güvenilir ve yeniden kullanılabilir olmasını sağladığında işe yarar. Hafif analitik, sitenin nerede çalıştığını ve nerede sessizce başarısız olduğunu görmenize yardımcı olur—siteyi bir gözetim aracına dönüştürmeden.
Başlangıç için birkaç pratik gösterge yeterlidir:
Eğer analitik aracı destekliyorsa, IP kaydını devre dışı bırakın ve kullanıcı düzeyinde tanımlayıcıdan kaçının. Tercihen toplu, sayfa düzeyinde raporlama kullanın.
Kullanım metrikleri girişlerin tam olup olmadığını söylemez. Depoyu takip eden "içerik sağlığı" kontrolleri ekleyin:
Bu, CMS/veritabanından haftalık rapor veya basit bir script ile yapılabilir. Amaç gaps'leri görünür kılmak ve sahiplerin düzeltmesini sağlamaktır.
Deney yazımları neredeyse hiçbir zaman kişisel kullanıcı verisi içermemelidir. Kayıtları şu içeriklerden arındırın:
Ham veri setleri yerine toplanmış panolara bağlanın ve hassas analizleri onaylı sistemlerde saklayın.
A/B testi sonuçları bağlam dışında kolayca yanlış okunur. Deney şablonuna (veya footer'a) kısa bir feragatname ekleyin:
Bu, günlüğü dürüst tutar ve geçmiş sonuçların körü körüne yeniden kullanılmasını azaltır.
Harika bir deney günlüğü site canlıya alındığında “bitmiş” sayılmaz. Gerçek değer, ekipler günlüğe güvenip onu güncel tuttuğunda ve altı ay sonra bile öğrenimleri bulabildiğinde ortaya çıkar.
Çoğu takım tablolar, slayt destesleri veya dağınık dokümanlarla başlar. Küçük bir pilot parti seçin (örn. geçen çeyreğin deneyleri) ve her kaynak alanı yeni şablona eşleyin.
Mümkünse toplu içe aktarım yapın: tabloları CSV'ye aktarın, sonra script veya CMS içe aktarıcısıyla yeni formatta girdiler oluşturun. Dokümanlar için önce özet alanlarını (hedef, değişiklik, sonuç, karar) taşıyın ve destekleyici detay için orijinal dosyaya bağlantı bırakın.
Mükemmellik değil tutarlılık odaklı bir geçiş yapın. Sık karşılaşılan sorunlar:
Ayrıca tamamlandı işaretlenen her şey için gerekli alanları netleştirmek için iyi bir zamandır.
Duyurmadan önce şunları doğrulayın:
Hafif bir rutin belirleyin: aylık temizlik (bayat taslaklar, eksik sonuçlar) ve çeyreklik taksonomi incelemesi (etiketleri birleştirme, yeni kategoriler ekleme). Bu işleri dikkatle ve sınırlı tutun.
Temel işler stabil olduktan sonra entegrasyonlar düşünün: deneyleri issue tracker'a otomatik bağlamak veya her girdide kullanılan tam panoya işaret eden analitik bağları çekmek. Özel uygulamaya evrilmeyi düşünüyorsanız, önce planlama modunda iş akışlarını, gerekli alanları ve onay kurallarını yazın, sonra uygulamaya geçin. Koder.ai gibi platformlar bu tür iteratif inşa ve yineleme döngülerini (deploys, snapshot'lar, geri alma) destekleyerek günlüğünüzün ağır bir yeniden inşa gerektirmeden olgunlaşmasını sağlar.
Bir ürün deneyim günlüğü web sitesi, deneyleri (A/B testleri, fiyatlandırma denemeleri, onboarding değişiklikleri, feature-flag dağıtımları, e-posta testleri) belgelemek için paylaşılan, aranabilir bir depodur. Her kayıt, ne denediğinizi, neden denediğinizi, ne olduğunu ve bir sonraki kararı yakalar—böylece öğrenimler dokümanlarda, panolarda veya sohbetlerde kaybolmaz.
2–4 ölçülebilir sonuçtan başlayın; örneğin:
Bu hedefler, zorunlu alanları, iş akışının sıkılığını ve taksonomi/aramanın ne kadar gelişmiş olması gerektiğini belirlemelidir.
Ana hedef kitlelerinizi ve her birinin 30 saniyede yanıtlamak istediği "soru"yu listeleyin. Yaygın ihtiyaçlar:
Sonra şablonları ve sayfa düzenini bu cevapları hemen görünür kılacak şekilde tasarlayın.
Üç modelden birini seçin:
Eğer mixed seçerseniz, halka açık kayıtlar için nelerin izinli olduğunu (ör. ham metrik yok, anonimleştirilmiş segmentler, yayımlanmamış özellik adları yok) ve yayına kimlerin onay verdiğini tanımlayın; bu, takımınız dışa öğrenim paylaşmak istediğinde yeniden çalışmayı önler.
Üst düzey gezinmeyi basit ve öngörülebilir tutun, örneğin:
Ardından birincil gezinme boyutunu seçin (ürün alanı, funnel aşaması veya ekip) ve diğer her şeyi filtre/etiketlerle halledin.
Her deney kaydını tutarlı kılmak için minimum gerekli alanları belirleyin:
Sonuçlar için standartlaştırın:
Pratik bir varsayılan sıra:
İnsanların aradığı şekilde eşleşecek birkaç etiket grubuna öncelik verin, örneğin:
Etiket çoğalmasını önlemek için kontrollü bir sözlük kullanın (adlandırma kuralları, yeni etiket oluşturma yetkisi, kısa açıklamalar). Temel özellikleri (, , ) serbest metin etiket yerine yapılandırılmış alanlar olarak tutun.
Bir CMS kullanın eğer çoğunlukla okunabilir A/B testi dokümantasyonu, izinler ve temel etiketleme istiyorsanız ve editör deneyiminin ekip üyeleri için tanıdık olmasını istiyorsanız.
Öte yandan özel bir uygulama düşünün eğer şu ihtiyaçlarınız varsa:
Başlık, özet ve etiketlerde tam metin arama ile başlayın ve şu filtreleri ekleyin: statü, tarih aralığı, sahip/ekip, etiketler, birincil metrik. Ayrıca “Şu anda çalışanlar”, “Sonuçlanmış (son 30 gün)”, “Yüksek etki” gibi kaydedilmiş görünümler sağlayın.
Arama sonuçlarında kısa bir sonuç özeti gösterin: hipotez, varyant, kitle ve başlıca sonuç. Eşleşen anahtar kelimeleri vurgulayın ve birkaç temel alanı (statü, sahip, birincil metrik) görünür kılın.
Bu, notları zaman içinde karşılaştırılabilir kayıtlara dönüştürür.
Bu, sayfaları taranabilir kılar ve derinlik yine de ulaşılabilir olur.
Hangi yolu seçerseniz seçin, gerçeğin kaynağını (CMS mi yoksa veri tabanı/uygulama mı) baştan yazın ki tekrar eden veya çakışan kayıtlar oluşmasın.