Ürün Deneyim Günlüğü için Web Sitesi Nasıl Oluşturulur

Bir Ürün Deneyim Günlüğü Web Sitesi Ne Yapar

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.

Takımlar neden kullanır

Ç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:

• Görünürlük: herkes şu anda neyin çalıştığını, neyin yayınlandığını, neyin durdurulduğunu ve neyin planlandığını araçlar arasında aramaya gerek kalmadan hızla görebilir.
• Tekrar edilebilirlik: takımlar deney şablonlarını yeniden kullanabilir, aynı hipotezi gereksiz yere tekrar test etmekten kaçınabilir ve kanıtlanmış yöntemleri (hedefleme, metrikler, süre) kopyalayabilir.
• Paylaşılan öğrenme: sonuçlar ve bağlam proje bittikten sonra bile erişilebilir kalır; yeni ekip üyeleri geçmiş kararları anlayıp üzerine inşa edebilir.

Bu rehberden ne alacaksınız

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.

Hedefleri, Hedef Kitleyi ve Erişim Düzeyini Tanımlayın

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.

Net hedefler koyun ("iyi"nin ne olduğuna karar verin)

Deney deposu için 2–4 ölçülebilir sonuç yazın. Yaygın başarı tanımları şunlardır:

• Daha hızlı keşif: insanlar ilgili A/B testi dokümantasyonunu dakikalar içinde bulabilsin, saatler değil.
• Daha az tekrar test: ekipler daha önce neyin denendiğini görsün ve aynı fikri yeniden test etmekten kaçınsın.
• Daha iyi kararlar: hipotezler, değişiklikler ve sonuçlar arasında daha net bağlantılarla daha tutarlı metrik ve sonuç raporlaması.

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 kullanıcıları ve ihtiyaçlarını belirleyin

Birincil kitlelerinizi ve ürün öğrenme günlüğünde ne yapmaları gerektiğini listeleyin:

• Ürün: geçmiş deneyleri taramak, sonuçları karşılaştırmak, başarılı kalıpları yeniden kullanmak.
• Tasarım: hangi değişikliklerin test edildiğini ve nedenini anlamak; ekran görüntüleri veya spesifikasyonları gözden geçirmek.
• Mühendislik: uygulama detaylarını, guardrail'ları ve teknik kısıtları doğrulamak.
• Liderlik: her detayı okumadan etkiyi ve öğrenmenin kalitesini gözden geçirmek.
• Destek/Müşteriyle İletişim Kurulan Ekipler: ne değiştiğini ve kullanıcılara ne söyleyeceklerini bilmek.

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.

Bir erişim modeli seçin: iç, herkese açık veya karışık

Başlangıçta CMS'inizin deney günlüğü için hangi erişim modelini kullanacağını belirleyin:

• Sadece iç: hassas metrikler, yol haritası detayları veya kullanıcı verileri için en uygunu.
• Herkese açık: şeffaflık ve işe alım için faydalı, fakat daha sıkı inceleme ve redaksiyon gerektirir.
• Karışık: özel bir iç günlük ve küratörlü bir halka açık alt küme.

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.

Site Yapısını ve Gezintiyi Planlayın

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.

Net üst düzey gezinme seçin

Ana gezinmeyi sınırlı ve öngörülebilir tutun. Pratik bir başlangıç noktası:

• Experiments (deney deponuz)
• Playbooks (nasıl yapılır rehberleri, deney şablonları, kontrol listeleri)
• Metrics (tanımlar, sahipler, izleme notları)
• Teams (kim neyi yürütüyor)

Eğer "Metrics" ağır geliyorsa, önce Experiments içinden bağlayabilir ve sonra genişletebilirsiniz.

Birincil düzenleme mantığını seçin

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:

• Ürün alanına göre (örn. Checkout, Search, Onboarding)
• Funnel aşamasına göre (Kazanım → Aktivasyon → Tutundurma)
• Takıma göre (Growth, Core, Mobile)

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, breadcrumb ve "listeye geri dön" yollarını planlayın

URL'leri okunabilir ve kararlı yapın ki insanlar bunları Slack veya ticket'larda paylaşabilsin:

• /experiments/2025-12-checkout-free-shipping-threshold

Experiments → Checkout → Free shipping threshold gibi breadcrumb'lar ekleyin; bu, çıkmaz sokakları engeller ve taramayı sezgisel tutar.

Hafif bir içerik envanteri oluşturun

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ı).

Deney Kayıt Veri Modelini Tasarlayın

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.

Temel içerik türleri (ne saklayacaksınız)

Takımlarin gerçekten nasıl çalıştığına uyan küçük bir içerik türü setiyle başlayın:

• Experiment: ana kayıt (ne test ettiniz ve ne oldu)
• Metric: deneyler arasında yeniden kullanacağınız tanımlı ölçüm (ör. aktivasyon oranı, churn, kullanıcı başına gelir)
• Insight: tek bir testi aşan yeniden kullanılabilir öğrenim (örn. “adım 2’de sürtünmeyi kaldırmak tamamlamayı artırır”)
• Decision: sonuç sonrası aldığınız karar (ship, iterate, rollback veya archive)

Bunları ayrı tutmak, her deneye yeni metrik isimleri uydurulmasını veya kararların serbest metinde gömülmesini engeller.

Her deney kaydı için asgari alanlar

"Minimum uygulanabilir kayıt"ı doldurmayı kolay yapın. En azından şu alanları zorunlu kılın:

• Başlık (net, spesifik)
• Hipotez (ne beklediğiniz ve neden)
• Sahip (tek sorumlu kişi)
• Başlangıç tarihi / Bitiş tarihi (veya planlanan tarihler)
• Statü (standart bir setten)

İ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ı.

Öğrenimi yakalayan sonuç alanları

Sonuçlar genellikle günlüklerin bozulduğu yerdir; bu yüzden bunları standartlaştırın:

• Birincil metrik (Metric listenizden seçilen)
• Etkisi (yön + büyüklük; birimler dahil)
• Güven notları (dilin sadeliğiyle belirsizlik, caveat'lar, veri kalitesi açıklaması)
• Destekleyici kanıt (ekran görüntüleri, grafikler veya baktığınız şeyin kısa özeti)

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.

İlişkiler ve statüler

Keşif ve raporlama ileride işe yarasın diye ilişkileri açık modelleyin:

• Experiments ↔ Metrics (birincil + ikincil metrikler)
• Experiments ↔ Features/Areas (ürünün hangi kısmı değişti)
• Experiments ↔ Owners/Teams (sorumluluk ve yönlendirme)

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.

Deneyleri Okunaklı Kılan Sayfa Şablonları Oluşturun

İ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.

Deney detay sayfası: önerilen bölümler (sıralı)

Okuyucunun okumaya devam edip etmemeye karar vermesi için gereken bilgiden başlayın.

1. Özet (TL;DR): bir paragraf: neyi değiştirdiniz, kimi etkiledi ve sonuç ne oldu.
2. Statü ve temel meta veriler: statü, sahip, ekip, başlangıç/bitiş tarihler, PRD/ticket bağlantısı (/docs/...) ve birincil metrik.
3. Hipotez: tek, test edilebilir bir ifade ("etkileşimi artırmak" gibi belirsiz hedeflerden kaçının).
4. Tasarım: varyantlar, hedefleme, dağılım, guardrail'lar ve süre varsayımları.
5. Sonuçlar: önce birincil metrik, sonra ikincil/guardrail metrikleri; düz dilde yorum.
6. Karar: ship/iterate/rollback, artı üründe ne değişti.
7. Öğrenimler ve takipler: ne öğrendiniz, açık sorular ve sonraki deneyler.
8. Ek: ekran görüntüleri, SQL parçacıkları, ham grafikler ve bağlantılar.

Liste sayfası: hızlı tarama alanları ve kontroller

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.

Takımlar arasında tutarlılık için şablonlar

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.

Uzun notlar için mobil uyumlu, okunaklı tasarım

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.

Hızlı Keşif İçin Etiketleme ve Taksonomi Kurun

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.

Küçük, öngörülebilir bir etiketleme stratejisiyle başlayın

Ekiplerin doğal olarak nasıl aradığına uygun birkaç etiket grubu tanımlayın. Pratik bir temel:

• Ürün alanı (örn. Onboarding, Checkout, Notifications)
• Hipotez türü (örn. Sürtünmeyi azaltma, Fiyat duyarlılığı, Güven sinyali)
• Birincil metrik (örn. Aktivasyon oranı, Dönüşüm oranı, Retansiyon)
• Segment (örn. Yeni kullanıcılar, KOBİ, Yalnızca mobil)

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.

Etiket çoğalmasını adlandırma kurallarıyla önleyin

Kontrolsüz etiketler hızla "signup", "sign-up" ve "registration" gibi çeşitlenir. Kontrollü bir sözlük oluşturun:

• Bir format seçin (tekil vs çoğul, büyük/küçük harf, kısaltma kullanımı)
• Yeni etiket oluşturabilecek kişileri ve onay sürecini tanımlayın
• Belirsiz etiketler için kısa açıklamalar ekleyin (ne anlama geldiği, ne zaman kullanılacağı)

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.

Serbest metin olmaması gerekenler için yapılandırılmış alanlar kullanın

Etiketler keşif için iyidir, ama bazı öznitelikler tutarlı kalmak için yapılandırılmış alan olmalıdır:

• Statü (Proposed, Running, Shipped, Stopped)
• Takım/Sahip (listeden seç)
• Deney türü (A/B, multivariate, holdout)

Yapılandırılmış alanlar güvenilir filtreler ve panolar sağlar; etiketler ise nüans yakalar.

Çapraz bağlantıları destekleyin: ilgili ve benzer deneyler

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.

CMS ile Özel Uygulama Arasında Karar Verin

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.

CMS yeterli olduğunda

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:

• Basit yayınlama: deney girişlerini makale gibi oluşturun, düzenleyin, gözden geçirin ve yayınlayın
• PM'ler, tasarımcılar ve pazarlamacılar için tanıdık bir editör deneyimi
• Yerleşik izinler (kim taslak oluşturabilir, kim onaylayabilir, kim yayınlayabilir)
• Karmaşık kurallar gerektirmeyen temel etiketleme ve kategoriler

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.

Özel yapı ne zaman uygun

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:

• Derin entegrasyonlar (feature flags, analytics araçları, veri ambarı, ticketing)
• Gelişmiş arama ve filtreleme (takım/metrik/platform/güven düzeyi bazlı kaydedilmiş görünümler)
• İş akışı kuralları (zorunlu alanlar, alan sahibi onayları, otomatik statü değişiklikleri)
• Otomatik metrik ve sonuç raporlaması (sonuçları kopyalamak yerine çekmek)

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.

"Gerçek kaynağı"na karar verin

Deney verilerinin nerede tutulduğunu açıkça belirleyin.

• Eğer CMS gerçek kaynağıysa, analiz bağlantıları ve sonuç özetleri CMS girdisine işaret etmelidir.
• Eğer veritabanı/uygulama gerçek kaynağıysa, web sitesi yapılandırılmış kayıtların sadece görüntü katmanı olmalı, anlatısal yorumlar ayrı (isteğe bağlı olarak bir CMS'te) saklanabilir.

Bunu baştan yazın—aksi halde ekipler dokümanlarda, tablolar ve araçlarda çakışan girdilerle güveni yitirir.

Teknoloji Yığını ve Barındırma Yaklaşımını Seçin

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.

Static site vs. server-rendered vs. single-page app

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.

Barındırma temelleri

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.

Kimlik doğrulama ve özel alanlar

Ç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.

Performans temel kuralları

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.

Arama, Filtreler ve Kaydedilmiş Görünümleri Uygulayın

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 vs. dış arama servisi

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.

Takımların kullandığı filtreler

Aramanın yanında şu filtreleri ekleyin:

• Statü: proposed, running, paused, concluded, shipped, invalidated
• Tarih aralığı: başlama, bitiş ve son güncelleme
• Sahip ve ekip
• Etiketler: özellik alanı, kitle segmenti, hipotez türü
• Birincil metrik (opsiyonel guardrail'lar dahil)

Filtrelerin birleştirilebilir olmasını sağlayın (örn. "Concluded + Son 90 gün + Growth ekibi + Aktivasyon metrik").

İnsanların tekrar kullandığı kaydedilmiş görünümler

Kaydedilmiş görünümler tekrar eden soruları tek tıkla cevaplar:

• Şu anda çalışanlar (status = running)
• Yüksek etki (lift eşik üzerinde veya karar = ship)
• Sonuçlanmış (yakın) (son 30 günde sona erenler)

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.

Liste görünümünü taranabilir yapı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.

İş Akışı, Sahiplik ve Yönetişimi Tanımlayın

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.

Roller ve izinler

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:

• Yazarlar (PM'ler, analistler, tasarımcılar): taslak oluşturma ve sonuçları güncelleme
• Gözden Geçirenler (data/analitik, araştırma, mühendislik): metrikleri, enstrumentasyonu ve yorumu doğrulama
• Onaylayanlar (ürün lideri veya deneyim konseyi): karar ve rollout planını teyit etme
• Yayıncılar (opsiyonel): biçimlendirme ve redaksiyon için son kontrol

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.

Editoryal kontrol listesi ("bitti" ne demek)

Her deney yayınlanmadan önce kısa bir kontrol listesi tanımlayın:

• Hipotez spesifik ve yanlışlanabilir (ne değişiyor, kim için, beklenen yön)
• Birincil metrik tanımlı (tam ad, kaynak, hesaplama penceresi)
• Guardrail'lar listelenmiş (örn. gelir, hata oranı, destek ticket'ları)
• Rollout kararı belgelenmiş (ship, iterate, stop) ve gerekçesi

Bu kontrol listesi deney şablonlarında zorunlu bir form bölümü olabilir.

Versiyon geçmişi ve değişiklik notları

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 bilgilerin yönetimi

Hassas bilgileri nasıl saklayacağınızı önceden belirleyin:

• Redaksiyonlar: müşteri isimleri, partner şartları veya güvenlik detayları için
• Özel notlar: sadece sınırlı grup tarafından görülebilir
• Ayrılmış sayfalar: halka açık özet + kısıtlı "analiz ve veri" sayfası

Yönetişim ağır olmak zorunda değil; sadece açık olması yeterlidir.

Analitik ve Gizlilik-Dostu Ölçüm Ekleyin

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.

Aşırı veri toplamadan kullanım takibi yapın

Başlangıç için birkaç pratik gösterge yeterlidir:

• En çok yapılan aramalar ve sıfır sonuçlu aramalar: insanlar sürekli "fiyatlandırma testi" arayıp sonuç bulamıyorsa, taksonomi veya adlandırma sorunludur.
• En çok görüntülenen deneyler ve en popüler etiketler: hangi alanların ekibin ilgisini çektiğini gösterir.
• Kırık linkler ve 404'ler: deney günlükleri genellikle spes'lere, panolara veya ticket'lara bağlanır; kırık linkler güveni hızlıca azaltır.

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.

İçerik sağlığı ölçün (tıklama değil, kalite)

Kullanım metrikleri girişlerin tam olup olmadığını söylemez. Depoyu takip eden "içerik sağlığı" kontrolleri ekleyin:

• Eksik zorunlu alanlar (örn. hipotez, birincil metrik, karar, sahip)
• Bayat statüler (örn. 90+ gündür running)
• Güncellenmemiş sonuçlar (karar tarihinden sonra hala TBD olanlar)

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 girdileri için gizlilik temelleri

Deney yazımları neredeyse hiçbir zaman kişisel kullanıcı verisi içermemelidir. Kayıtları şu içeriklerden arındırın:

• isimler, e-postalar, kullanıcı ID'leri, oturum tekrarları, ham event log'lar
• kişisel bilgi içeren ekran görüntüleri

Ham veri setleri yerine toplanmış panolara bağlanın ve hassas analizleri onaylı sistemlerde saklayın.

Açık yorumlama feragatnamesi ekleyin

A/B testi sonuçları bağlam dışında kolayca yanlış okunur. Deney şablonuna (veya footer'a) kısa bir feragatname ekleyin:

• sonuçların tanımlanan popülasyon, zaman dilimi ve enstrumentasyona bağlı olduğu
• güven/istatistiksel anlamlılık eşiklerinin ekipler arasında değişebileceği
• kararların belgelenmiş birincil metrik ve guardrail'lara referans vermesi gerektiği

Bu, günlüğü dürüst tutar ve geçmiş sonuçların körü körüne yeniden kullanılmasını azaltır.

Lansman, Geçiş ve Sürekli Bakım İçin Hazırlanın

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.

Mevcut deneyleri kaosa sokmadan taşıma

Ç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.

Lansmandan önce kalite kontrolü yapın

Mükemmellik değil tutarlılık odaklı bir geçiş yapın. Sık karşılaşılan sorunlar:

• Yinelenen veya neredeyse aynı etiketler (örn. onboarding vs. on-boarding)
• Eksik sahipler (her deney isim belirtilmeli, "team" yerine) ve eksik tarihler
• Tutarsız statüler (draft, running, stopped, shipped, invalidated) ve belirsiz sonuçlar

Ayrıca tamamlandı işaretlenen her şey için gerekli alanları netleştirmek için iyi bir zamandır.

Lansman kontrol listesi

Duyurmadan önce şunları doğrulayın:

• İzinler: kim görüntüleyebilir, kim düzenleyebilir, kim yayınlayabilir
• Arama indeksleme: ana deney sayfaları ve etiketler bulunabilir olmalı
• Yönlendirmeler: eski wiki alanını değiştiriyorsanız linklerin çalışması için yönlendirmeler ayarlayın
• Yedekler: otomatik yedeklemeler ve basit bir geri yükleme testi (en azından bir test) onaylayın

Yayın sonrası bakım rutini

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.

Opsiyonel sonraki adımlar

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.