Kutuda ne var, nereden biliyoruz.

Bu sistem neyden yapıldı

Site Next.js ile statik olarak derleniyor ve Cloudflare üzerinden dağıtılıyor. WordPress ya da hazır tema altyapısı kullanmadık. Sayfalar ziyaretçi istediği anda üretilmiyor; önceden hazırlanmış HTML olarak sunuluyor. Böylece araya giren veritabanı sorgusu, sunucu tarafında render ve güncelleme bekleyen eklenti katmanı kalmıyor.

Arayüz tarafında da hazır bir CSS çatısı kullanmadık. Renk, tipografi ve aralık değerleri tek bir tasarım değişkeni dosyasından besleniyor; açık ve koyu tema ilk günden birlikte kuruldu. Bileşenler ortak bir iskeleti paylaşıyor, ama bu paylaşımı serbest bırakmadık: her yeni bağda ana sayfanın boyut farkı ölçülüp kayda geçiyor.

Bunun bedeli tahmin değil, ölçüm. Beyaz etiket tarafıyla form modülünü birbirine bağlama denemesi ana sayfayı 12.279 bayt ve 105 kural büyüttü. Ters yönü de ölçtük: yalnızca yan etkisi için duran bir import kaldırıldığında ana sayfa 5.580 bayt ham, 546 bayt sıkıştırılmış büyüdü. Değişiklik geri alındı ve kural yazıldı.

Gösterdiğimiz her sayının bir kaynağı var

Sitede bir bütçe simülatörü var. Kullandığı formülleri gizlemiyoruz: ayrı bir sayfada her formül, her katsayı ve her katsayının dayanağı açıkça yazıyor. O tablolar elle hazırlanmıyor, hesabın kendisiyle aynı kaynaktan üretiliyor. Yani ekranda gördüğünüz formülle arkada çalışan formülün ayrışması mümkün değil.

Katsayıları da biz üretmiyoruz; tasarım aşamasındaki kaynağından birebir alıyoruz. Yuvarlanmıyor, "iyileştirilmiyor". Dayanağını gösteremediğimiz bir sayıyı kullanıcıya hazır değer olarak sunmuyoruz.

Aynı yaklaşım teknik sinyaller için de geçerli. Tarayıcının arka planda veri gönderme çağrısı "başarılı" döndüğünde bu, verinin karşı tarafa ulaştığı anlamına gelmiyor; yalnızca gönderim sırasına alındığını gösteriyor. Biz de bunu teslim kanıtı saymıyoruz. Kullanıcı verisinden uygunluk skoru da üretmiyoruz: bunu tanımlayan gerçek bir kural olmadığı için o alanlar boş kalıyor.

Modelin kendisi sürümlü. Formül seti değiştiğinde bu bir kesim noktası oluyor; eski kayıtlarla yeni kayıtlar aynı grafikte birleştirilmiyor, çünkü artık aynı şeyi ölçmüyorlar.

Hesap kullanıcının tarayıcısında çalışıyor. Bu da bir ölçüm kararı: model sunucu tarafından istemciye veri olarak taşınsaydı aynı içerik sayfa yükünde iki kez ödenecekti — yalnızca hizmet listesi için 1.799 bayt veri ve 6.589 bayt işaretleme.

BU KATMANI KURAN HİZMETMeasurement & Data →

"Reddet" tek tıkla ulaşılabilir olmalı

Çerez tercihleri için hazır bir üçüncü taraf aracı kullanmadık; sistemi siteye özel kurduk. Kullanıcı "Kabul Et" ve "Reddet" seçeneklerine aynı kolaylıkla ulaşabiliyor. Daha ayrıntılı seçimler "Tercihleri Yönet" üzerinden yapılabiliyor ve "Kaydet" butonuyla uygulanıyor. Temel kuralımız basit: kabul etmeyi kolaylaştırırken reddetmeyi zorlaştıran bir arayüz kurmamak.

Ölçüm izinleri varsayılan olarak kapalı başlıyor: analitik ve reklamla ilgili dört izin, kullanıcı onay verene kadar reddedilmiş sayılıyor. Yalnızca sitenin çalışması ve güvenliği için gerekli olanlar açık. Ölçüm etiketleri de bu onayı bekleyecek şekilde kuruldu.

Ölçüm tarafına ne gönderildiği de dar tutuldu. Kayıt yalnızca kullanıcı bir seçim yaptığında oluşuyor; seçim değişmediyse hiçbir şey gönderilmiyor ve gönderilen kayıtlarda kişisel veri taşınmıyor. Sıra da sabit: önce tercih saklanıyor, sonra izin durumu güncelleniyor, kayıt en son gidiyor.

JavaScript kapalıyken çalışan ikinci bir ölçüm yolu da bilerek açılmadı. Böyle bir yol, rıza katmanının dışında çalışan ikinci bir ölçüm yolu oluştururdu.

Sitenin dışarıdan hangi kaynakları yükleyebileceği açıkça sınırlandırıldı: yalnız gerçekten ihtiyaç duyulan kaynaklara izin veriliyor, "belki lazım olur" diye açık bırakılmış bir alan yok. Bu izinler her zaman ölçüm etiketlerinden önce yayına alınıyor; tersi, etiketin sessizce çalışmadığı bir duruma yol açıyor.

Güvenlik başlıkları sitenin yayın durumundan bağımsız. Sitenin yayında olup olmaması yalnızca arama motorlarına açıklığını etkiliyor; güvenlik başlıkları her koşulda yerinde kalıyor.

Hukuki metinler de yalnızca gerçekten devrede olan sistemi anlatıyor. Kullanmadığımız bir reklam platformu çerez politikasında yer almıyor; kurulmamış bir veri aktarımı aktarım listesinde görünmüyor.

Form gönderildikten sonra ne oluyor

Ad ve soyad ayrı alanlarda alınıyor ve ayrı kaydediliyor. Tek bir "ad soyad" alanını sonradan güvenilir biçimde ikiye ayırmanın bir yolu yok.

Form gönderildiğinde yalnızca sunucudan bir yanıt gelmiş olması bizim için yeterli değil. Sistem, kaydın gerçekten işlendiğini doğrulayan yanıtı bekliyor. Bu doğrulama gelmezse kullanıcıya yanıltıcı bir "başarılı" mesajı göstermiyoruz; formda girdiği bilgiler de korunuyor.

Ortaklık formunda bot koruması doğrulama üretmeden gönderim yapılmıyor. Koruma devre dışıyken formu açık tutmak yerine kapalı kalmasını tercih ediyoruz.

Otomasyon tarafında her markanın ve her ürün hattının akışları birbirinden ayrı tutuluyor. Amaç basit: bir formdan gelen verinin yanlış hesaba düşmesi yapısal olarak mümkün olmasın.

Formun hangi seçenekleri kabul ettiği ve hangi eşikleri kullandığı arayüzde değil, ortak bir tanımda tutuluyor. Arayüz bu tanımı uyguluyor, kendi başına kural üretmiyor. Tanım ile otomasyon tarafı birlikte güncelleniyor; biri güncellenip diğeri unutulursa gönderim kabul edilmiyor.

BU KATMANI KURAN HİZMETAI Automation & Operations →

Yanıldığımızda bizi ne yakalıyor

Yukarıdaki katmanların hepsi doğru kurulmuş olabilir ve zamanla sessizce bozulabilir. Asıl soru, bozulduğunda bunu kimin fark ettiği.

Ölçüm aracının kendi arızası ile ürünün kusuru da birbirine karıştırılmıyor; ikisi ayrı ayrı raporlanıyor. Hiç örnek toplanamamış bir ölçüme dayanarak "kusur bulunamadı" demiyoruz.

Kararlar nasıl saklanıyor

Projenin kalıcı kararları ayrı bir kayıt sisteminde tutuluyor ve bu kayıt bütünlük kontrolünden geçiyor. Kayıt güncelliğini yitirdiğinde yeni iş başlatılmıyor. Durum bilgisi de elle değiştirilemiyor: araç beklediği yapıyı bulamazsa hata veriyor ve güncel kaydı hiç üretmiyor.

Her karar; kimliği, kaynağı ve son doğrulama tarihiyle birlikte duruyor. Bir işin yapıldığını söylemek yeterli değil, kanıtı isteniyor. Kaynaklar birbiriyle çelişirse arada kalan boşluk tahminle doldurulmuyor; çelişki işaretleniyor ve o karara bağlı iş duruyor. Bilinmeyen bir şey varsa "bilinmiyor" diye yazılıyor.

İçerik tarafında da tek kaynak disiplini var. Hizmet listesi tek bir yerde tutuluyor; menü, sayfa altı, ana sayfa ve görüşme formu aynı kaynaktan okuyor. Taksonominin üç katmanı birbirine karıştırılmıyor: hizmet ne yaptığımızı, çözüm hangi sonucu ürettiğimizi, beyaz etiket ise kimin için çalıştığımızı tanımlıyor.

Devraldığımız miras da kayıtla taşındı. Eski WordPress sitesinin arşivden çıkarılan iki yüz otuz üç kaydı tek tek değerlendirildi; her adres için yönlendirme mi yapılacağı, adresin korunacağı mı yoksa doğal olarak kaybolacağı mı ayrı ayrı karara bağlandı. Sonuçta yirmi üç kalıcı yönlendirme yazıldı. Karşılığı olmayan adresleri ana sayfaya toplamadık; karşılığı olmayan bir adresin dürüst cevabı "bulunamadı". Yayın öncesi kontrolde otuz dokuz maddenin tamamı geçti.

Modelin ürettiği sayı, kanıt değildir

Bu sayfanın en dürüst bölümü burası.

Bütçe simülatörü ilk kurulduğunda, seçilen reklam paneline bağlı varsayılan tıklama maliyetleri taşıyordu. Kullanıcı panelini seçiyor, sistem o panele ait bir değeri hesaba koyuyordu. Sayılar makul görünüyordu ve hesap çalışıyordu.

Sorun şuydu: o değerlerin nereden geldiğini gösteremiyorduk. Ölçülmüş bir veri setinden gelmiyorlardı, hazır bir kaynaktan taşınmamışlardı; üretilmişlerdi. Hesap doğru çalışıyor olabilirdi ama çıktısı, dayanağı olmayan bir girdiye oturuyordu.

Bu yüzden kaldırdık. Panel seçimi artık yalnızca anonim havuz için toplanıyor ve tıklama maliyetine hiç dokunmuyor; o değeri kullanıcı kendi verisinden giriyor.

İkinci bir gerekçe de ortaya çıktı: kanalları yalnızca tıklama maliyeti üzerinden karşılaştırmak zaten yanıltıcı. Bir kanalda tıklama daha pahalı olabilir; buna karşılık o kanaldaki kullanıcı niyeti ve dönüşüm davranışı farklı olabilir. Tek başına maliyet karşılaştırması bu farkı gizler.

Bunu anlatıyoruz, çünkü yapay zekâ destekli araçlarla çalışan herkes er ya da geç aynı durumla karşılaşıyor: sistem bir sayı üretiyor, sayı makul görünüyor, hesap da çalışıyor. Dayanağını gösteremediğimiz bir sayı üründe kalmaz — bize avantaj sağlıyor olsa bile.

Model bir değer üretebilir; dayanağı yoksa o değer kanıt değildir.