Fiyat deneyi kaydını kullanarak hipotezleri, varyantları, tarihleri ve sonuçları kaydedin; böylece ekibiniz başarıyı tekrar edebilir ve başarısız testleri yeniden çalıştırmayı bırakır.
Fiyat testleri, fikir kötü olduğu için değil, ekipler ne yaptıklarını unuttuğu için daha sık başarısız olur. Bir ekip bir planı değiştirir, bir artış (veya düşüş) görür ve devam eder. Altı ay sonra aynı soru tekrar sorulur. Detaylar slaytlar, sohbetler, analiz ekran görüntüleri ve yarım kalmış dokümanlar arasında dağınıktır; test yeniden çalıştırılır.
Fiyat deneyi kaydı, yaptığınız her plan ve özellik testinin paylaşılan bir kaydıdır. Hipotezi, neyi değiştirdiğinizi, ne zaman çalıştığını, neyi ölçtüğünüzü ve ne olduğunu yakalar. Fiyatlama için yazılmış bir laboratuvar defteri gibidir; herkesin anlayacağı sade bir dille yazılır.
Getiri basit: yeni sorular geldiğinde zaten neyi denediğinizi, hangi koşullar altında denediğinizi ve neden işe yarayıp yaramadığını hızlıca görebilirsiniz. Bu daha hızlı kararlar, daha az tekrar edilen hata ve "gerçekten ne oldu" konusunda daha az tartışma demektir.
Ayrıca benzer görünen ama farklı olan testleri karşılaştırmanıza yardımcı olur. “Fiyatı %10 artırdık” ifadesi, bunun yalnızca yeni kullanıcılara, yalnızca bir bölgeye veya mevsimsel bir artış sırasında uygulandığında farklı bir deneydir.
Her test sonrası bilimsel bir makale yazmak zorunda değilsiniz. Ama temiz bir iz bırakmak önemlidir: neye inanmıştınız, neyi değiştirdiniz, ne gördünüz ve bir dahaki sefere neyi farklı yapardınız.
Fiyat deneyi, insanların ne ödediğini, hangi planı seçtiğini veya ne zaman yükselteceklerini etkileyebilecek kontrollü her değişikliktir. Eğer gelir, dönüşüm veya retenksiyonu etkileyebiliyorsa, fiyat deneyi kaydınıza aittir.
Bu, sadece fiyat etiketindeki sayıyı değiştirmekle sınırlı değildir. Fiyat değişikliği açıktır: $29 $39 olur. Ama algılanan değer değişiklikleri de önemlidir: aynı fiyatı tutar, bir planın adını değiştirir, faydaları yeniden çerçeveler, nelerin dahil olduğunu değiştirir veya "en popüler" seçeneğini tanıtırsınız. Müşteriler her ikisine de tepki verir.
Kayda değer yaygın fiyat deneyleri şunları içerir: fiyat noktaları (aylık/yıllık oranlar, indirimler, denemeler, kurulum ücretleri), paketleme (katmanlar ve hangi özelliklerin hangi katmanda olduğu), limitler (kullanıcı sayısı, kullanım kotaları, ekstra ücretler), eklentiler (ücretli ekstralar, paketler, premium destek) ve yükseltme yolları (yükseltme çağrılarının ne zaman ve nasıl gösterildiği).
Sayılmayanlar: checkout hatasını düzeltmek, plan sayfasındaki yazım hatasını düzeltmek veya dahil olanları veya ödemeyi değiştirmeyen onboarding metnini güncellemek. Bunlar ürün veya pazarlama değişiklikleridir; fiyat deneyi değildir.
Çoğu fiyat deneyi birkaç yerde görünür: fiyat sayfası, ödeme akışı ve uygulama içi yükseltme ekranları. Herhangi bir test çalıştırmadan önce tek bir soru sorun: "Bunu kim şaşırabilir?" Eğer müşteriler kendini kandırılmış, kafası karışmış veya dışlanmış hissedebilecekse, teste daha net mesaj ve dikkatli bir dağıtım gerekir.
Plan testleri, teklifinizi paketleme ve sunma şeklini değiştirir: katmanlar, paketler, plan isimleri ve her katmanın neleri içerdiği. Burada insanların seçenekler arasında nasıl karar verdiğini test ediyorsunuz; tek bir yeteneğin ücretlendirilmeye değer olup olmadığını değil.
Özellik testleri ise tek bir yetkiye erişimi değiştirir. Bu, bir özelliği daha yüksek bir katmanın arkasına almak, bir kullanım limiti eklemek, ücretli bir eklenti sunmak veya biri kullanmaya çalıştığında bir ödeme duvarı göstermek olabilir. Burada belirli bir değere ödeme yapma (veya yükseltme) istekliliğini test ediyorsunuz.
Fiyat deneyi kaydınıza, ileride karşılaştırmayı kolaylaştıracak şekilde birkaç ayrıntı ekleyin:
Plan ve özellik değişikliklerini bir testte karıştırmaktan kaçının. Bir anda katman isimlerini değiştirir, özellikleri taşırsanız ve yeni bir limit eklerseniz, sonuçlar okumayı zorlaştırır. Yükseltmelerde görülen artış paketlemeden mi yoksa limit baskısından mı kaynaklandı, belli olmaz.
Hızlı bir örnek: “Exports” özelliğini Basic'ten Pro'ya taşımak bir özellik testidir. “Basic”i “Starter” olarak yeniden adlandırmak ve üçüncü bir katman eklemek plan testidir. Bunları ayrı çalıştırın (veya en azından ayrı varyantlar olarak kaydedin) ki işe yarayanı tekrarlamak karışıklık yaratmasın.
Fiyat deneyi kaydı, hipotez açık ve metrikler tutarlı olduğunda yeniden kullanılabilir hale gelir. Girdi belirsiz bir umut gibi görünüyorsa, sonraki kişi yeni testi karşılaştıramaz.
Hipotezleri neden-sonuç ilişkisi olarak yazın. Değişiklikle davranış değişikliğini ve ölçülebilir sonucu bağlayan tek cümle kullanın. Örnek: “Özellik X'i Pro'dan Business'a taşırsak, ekipler rollout'ta X'e ihtiyaç duyduğu için daha fazla Business seçecek ve iadeler artmadan Business yükseltmeleri artacaktır.”
Değişikliğin arkasındaki nedeni sade kelimelerle ekleyin. “Kullanıcılar birinci haftada limite takıldı” demek “Monetizasyonu iyileştirmek” demekten daha faydalıdır. Neden, plan ve özellik deneyleri arasında desenleri fark etmenize yardımcı olur.
Metrikler için birincil başarı metriğini seçin: “Bu işe yaradı mı?” sorusunu cevaplasın. Ardından kazanımı zarar etmeyecek şekilde 1–2 korunma metrik ekleyin.
Yaygın, karşılaştırılabilir bir kurulum:
Karar kuralını başlamadan önce belirleyin. Yayınla, geri al veya yeniden test et için kesin eşikleri yazın. Örnek: “Yükseltmeler %8+ artarsa ve iadeler 1 puandan fazla artmazsa yayınla. Sonuçlar karışıksa yeniden test et. Churn artarsa geri al.”
Eğer log'u küçük bir dahili araç olarak kurarsanız, bu alanları zorunlu yaparak girdilerin temiz ve karşılaştırılabilir kalmasını sağlayabilirsiniz.
Bir fiyat deneyi kaydı ancak ileride güvenilir ayrıntılar içeriyorsa faydalıdır. Testten habersiz biri iki dakika içinde ne olduğunu anlamalı, eski sohbetlerde arama yapmak zorunda kalmamalı.
Önce kimlik ve zaman çizelgesiyle başlayın ki birden fazla test karışmasın:
Sonra sonucu zaman içinde karşılaştırmayı sağlayacak kurulum ayrıntılarını kaydedin. Testi kimlerin gördüğünü (yeni vs mevcut), nerede görüldüğünü (fiyat sayfası, ödeme akışı, uygulama içi istem), ve trafiğin nasıl bölündüğünü not edin. Davranışı etkileyebilecek cihaz ve platformu (mobil web vs masaüstü, iOS vs Android) ekleyin.
Varyantlar için kontrol ve her varyantı sade bir dille yazın. Nelerin değiştiğine özgü olun: plan isimleri, dahil edilen özellikler, limitler, fiyat noktaları, faturalandırma dönemi ve sayfadaki herhangi bir metin. Görseller önemliyse, ekran görüntüsünde ne görüneceğini tarif edin (ör. “Varyant B yıllık geçişini plan kartlarının üstüne taşıdı ve düğünt metnini ‘Başlangıç ücretsiz deneme’ olarak değiştirdi”).
Sonuçlar sadece kazanandı etiketiyle kalmamalı. Rakamları, zaman aralığını ve onlar hakkında ne düşündüğünüzü saklayın:
Son olarak, sürprizleri açıklayan bağlam ekleyin: yakın sürümler, mevsimsellik (tatiller, çeyrek sonları), pazarlama kampanyaları ve destek olayları. Haftanın ikinci haftasındaki bir ödeme kesintisi “kötü” görünen bir varyantı olduğundan daha kötü gösterebilir.
Fiyat deneyi kaydı, insanlar doğru girdiyi daha sonra bulabiliyorsa zaman kazandırır. Kimse “Test #12”yi hatırlamaz. Ekranı, değişikliği ve kimi etkilediğini hatırlarlar.
Ekip genelinde tutarlı kalan bir adlandırma şablonu kullanın:
Örnek adlar:
Sonra filtrelemeyi hızlandırmak için birkaç etiket ekleyin. Etiketleri kısa ve öngörülebilir tutun. Kısa, kontrollü bir liste yaratıcı ifadelerden daha iyidir.
Pratik bir başlangıç seti:
Her giriş için sahip atayın. Bir “sahip” (tek isim) girdiyi güncel tutmaktan ve sonrasında soruları yanıtlamaktan sorumlu olmalıdır. Girdi ayrıca verinin nerede saklandığını ve testin tekrar çalıştırılmasının güvenli olup olmadığını söylemelidir.
Fiyat deneyi kaydınız için tek bir ev seçin. Erken ekipler için paylaşılan bir tablo yeterlidir. Zaten bir veritabanı veya dahili yönetim aracı varsa onu kullanın. Amaç, herkesin hızla bulabileceği tek bir gerçek kaynağa sahip olmaktır.
Karar vermenize yetecek alanları içeren tek sayfalık bir şablon oluşturun. Formun ödev gibi hissettirmesi insanların atlamasına yol açar.
Sık tutulan bir kurulum:
Kuralları uygulanabilir kılın. Örneğin: “Hiçbir deney yayın bileti almadan önce log entry ID'si olmaz.” Bu alışkanlık, eksik başlangıç tarihlerini, belirsiz varyantları ve “bunu test ettiğimizi sanıyoruz” tartışmalarını önler.
Bir fiyat testi, notlarınız gerçekliğe ne kadar yakınsa o kadar öğreticidir. Kilit, küçük değişiklikleri oldukları gibi yakalamak ve log'u ikinci bir iş haline getirmemektir.
Kesin zaman damgalarıyla başlayın. Sadece tarihi değil, başlangıç ve bitiş zamanını (zaman dilimiyle birlikte) yazın. Sonradan reklam harcaması, e-posta gönderimleri veya bir sürümle karşılaştırırken “salı sabahı” yeterli olmayabilir.
Sonuçları etkileyebilecek her şeyi kısa bir değişiklik günlüğüyle kaydedin. Fiyat testleri nadiren tamamen sabit bir üründe çalışır: kopya değişiklikleri, hata düzeltmeleri (özellikle ödeme veya deneme akışıyla ilgili), hedefleme güncellemeleri (bölgeler, segmentler, trafik karışımı), uygunluk kuralları ve satış/destek süreç değişikliklerini takip edin.
Ayrıca sayıları çarpabilecek anomalileri kaydedin. Kesinti, ödeme sağlayıcı sorunu veya alışılmadık bir trafik kaynağından gelen ani artış dönüşümü ve iadeleri etkileyebilir. Ne olduğunu, ne zaman gerçekleştiğini, ne kadar sürdüğünü ve o dönemi analizden hariç tutup tutmadığınızı not edin.
Müşteri geri bildirimi verinin bir parçasıdır. "En sık görülen 3 ticket teması" veya "satıştaki en yaygın itiraz" gibi kısa notlar ekleyin ki daha sonra okuyacaklar bir varyantın neden işe yaradığını (veya yaramadığını) grafikten öte anlayabilsin.
Bir testi erkenden kim durdurabilir ve bu karar nasıl kaydedilir belirleyin. Genellikle deney sahibi bu karardan sorumlu olur; izin verilen nedenleri listeleyin (güvenlik, yasal, ciddi gelir düşüşü, bozulan checkout) ve durdurma kararını zaman, neden ve onayla kaydedin.
Birçok fiyat deneyi temiz bir galibiyetle bitmez. Sonuçlar karışıksa ne yapacağınızı önceden belirleyin ki veriyi gördükten sonra kuralları yeniden yazmak zorunda kalmayın (yayınla, geri al, iterasyon gibi).
Karar kuralınızı lansmandan önce belirlediğiniz kuralla karşılaştırın; gördüğünüz sayılara göre yeni bir kural icat etmeyin. Eğer kuralınız “denemeden ödeye geçenler %8 artarsa ve aktivasyon %2'den fazla düşmezse yayınla” idiyse, gerçek sayıları bu kuralın yanına yazın ve geçip geçmediğini işaretleyin.
Sonuçları dikkatlice segmentlere ayırın ve neden o kesimleri seçtiğinizi kaydedin. Bir fiyat değişikliği yeni müşterilere yardımcı olurken yenilemeleri zedeleyebilir. Küçük ekipler için işe yarayıp büyük hesaplarda başarısız olabilir. Yaygın segmentler: yeni vs dönen müşteriler, küçük vs büyük müşteriler, self-serve vs satış destekli ve bölge/döviz.
Girdiyi bir kısa sonuçla kapatın: ne işe yaradı, ne yaramadı ve bir sonraki test ne olmalı. Örnek: “Yıllık plan demetlemesi yeni müşterilerde yükseltmeleri artırdı ama dönen müşterilerde iadeleri yükseltti. Sonraki test: demeti koru, yenilemeler için iptal politikası mesajını netleştir.”
Bir kullanılabilir çıkarım cümlesi ekleyin. Örnek: “Yıllık fiyatla ankraj yapmak kazanımı destekledi, ama yalnızca fiyat gösterilmeden önce uygulama içi değer kanıtı sunulduğunda.”
Fiyat deneyi kaydı, sonraki soruyu yanıtlayabilmelidir: “Ne denedik ve tekrar etmeli miyiz?” Çoğu öğrenme hatası gösterişli analizden değil, temel bilgilerin eksikliğinden kaynaklanır.
En yaygın hatalar:
Basit bir örnek: bir ekip %10 fiyat artışı yaptı, birinci haftada dönüşüm düştü ve durdu. Altı ay sonra biri aynı artışı tekrar önerir çünkü eski kayıt sadece “fiyat artışı başarısız oldu” diyor. Eğer log “ödeme sayfası hatası yüzünden erken durduruldu ve o hafta Black Friday indirimleri vardı” diye not düşseydi, ekip aynı karışık kurulumla tekrar denemezdi.
Fiyat log'unuzu laboratuvar notları gibi ele alın: neyi değiştirdiniz, ne beklediniz, ne ölçtünüz ve başka neler oluyordu.
Fiyat deneyi kaydı yalnızca hızlı doldurulup tutarlıysa işe yarar.
Lansman öncesi: girişin ilk kullanıcı görmeden önce var olduğundan emin olun, hipotez tek cümle halinde olsun, başarı metrikleri ve veri kaynakları açık olsun, varyantlar sade sözlerle (kim neyi nerede görüyor) tanımlansın ve başlangıç tarih/zaman/zaman dilimi kaydedilsin. Yeni bir test planlıyorsanız, kickoff sırasında “ilgili 3 eski girdiyi oku” kuralı ekleyin — aynı işi tekrar etmemeyi ve işe yarayan varyantları yeniden kullanmayı sağlar.
Testi durdurduktan sonra: durma tarih/saatini ve nedenini kaydedin, sonuçları sayılarla girin (sezgiler değil), kararı belirtin (yayınla, geri al, yeniden çalıştır veya rafa kaldır), kilit öğrenmeyi bir cümleyle yazın ve bir takip atayın (sahip + tarih).
Aşağıda bir mini şablon var; bunu bir dokumana, hesap tablosuna, Notion sayfasına veya dahili araca kopyalayabilirsiniz.
Experiment name:
Owner:
Date created:
Status: planned / running / stopped
Hypothesis (one sentence):
Type: plan test / feature test
Audience + location (where shown):
Variants (A, B, C):
Start (date/time/timezone):
Stop (date/time/timezone) + reason:
Primary metric(s):
Guardrail metric(s):
Data source:
Results (numbers + notes):
Decision:
Key learning (one sentence):
Follow-up action + owner + due date:
Tags:
Bir SaaS ekibi yardım masası ürünü satıyordu ve geçen çeyrekte Pro planı için bir fiyat testi çalıştırdı. Hipotez, tam ödeme duvarı kopyası, tarihler ve sonuçlarla birlikte fiyat deneyi kaydına kaydedildi.
Test A (6 Mayıs - 27 Mayıs):
Pro'yu kişi başı $49'dan $59'a çıkardılar ve şu satırı eklediler: “Gelişen ekipler için en iyi; gelişmiş otomasyonlar içerir.” Hedef kitle tüm yeni web sitesi ziyaretçileriydi.
Sonuçlar açıktı: deneme başlangıçları sabit kaldı, ancak ücretli dönüşüm %6.2'den %4.9'a düştü ve “fiyat artışı” hakkında destek sohbetleri iki katına çıktı. Karar: $49'a geri dönüldü.
İki ay sonra Ürün yeniden Pro'yu yükseltmek istedi. Log olmasaydı aynı hamle tekrar edilebilirdi. Ancak ekip geçmiş girdiyi buldu ve düşüşün küçük takımlarda yoğunlaştığını gördü.
Böylece işe yarayanı farklı bir segmentte yeniden kullandılar.
Test B (12 Ağu - 2 Eyl):
Self-serve kayıtlar için $49'u korudular, ama fiyat hesaplayıcıda “10+ koltuk” seçeneği belirlenmiş ziyaretçilere $59 gösterdiler. Kopya şu şekilde değişti: “10+ koltuklu ekipler için Pro. Onboarding ve öncelikli destek içerir.”
Bu sefer 10+ segmentinde ücretli dönüşüm sabit kaldı (5.8% -> 5.9%) ve hesap başına gelir %14 arttı. Ekip segmentli fiyat kuralını yayınladı ve küçük takımlar için daha düşük giriş fiyatını korudu.
Tekrarlanabilir çıkarım: sadece “fiyat yukarı/aşağı” yazmayın. Kimi gördüğünü, tam ifadeyi ve etkinin nerede oluştuğunu kaydedin ki bir sonraki test daha akıllıca başlasın.
Fiyat deneyi kaydı bir doküman olmaktan çıkıp net bir iş akışına sahip küçük bir iç araç haline geldiğinde en iyi çalışır. Böylece girdiler tam, tutarlı ve güvenilir kalır.
Form tabanlı bir kurulum yardımcı olur. İnsanları temel bilgileri (hipotez, varyantlar, başlangıç/bitiş tarihleri) eklemeye zorlar ve boş alanları azaltır. Hafif bir onay adımı da testin yayınlanmadan önce tanımlandığından emin olmak için işe yarar.
Birkaç görünüm genellikle yeterlidir: durum bazlı (taslak, çalışıyor, tamamlandı), plan veya eklenti bazlı, yüzey (fiyat sayfası, ödeme akışı, uygulama içi) ve sahip bazlı.
Mühendislik beklemeden bunu inşa etmek isterseniz, AppMaster (appmaster.io) bir seçenek olabilir. Bu, PostgreSQL veri modeline sahip, form ve filtrelenmiş görünümler için web UI sunan, required alanlarla deneylerin yarım kaydedilmesini engelleyen no-code bir platformdur.
What is a pricing experiment log?Fiyat deneyi kaydı, her fiyatla ilgili testi paylaşılan şekilde kaydeden bir yerdir: hipotez, ne değişti, kim gördü, ne zaman çalıştı, hangi ölçümler alındı ve sonuç. Bu, detayların slaytlarda, sohbetlerde veya ekran görüntülerinde kaybolup testlerin tekrarlanmasını önlemeye yardımcı olur.
Why do pricing tests get repeated or misremembered so often?Çünkü hafıza güvenilir değil ve ekipler değişiyor. Varyant detaylarını ve zamanlamayı tek bir yerde yakalamazsanız, aynı testleri tekrar çalıştırırsınız, ne olduğu hakkında tartışırsınız ve kararları tüm bağlam yerine parçalanmış kanıtlara göre alırsınız.
What changes should be logged as a pricing test?İnsanların ne ödediğini, hangi planı seçtiğini veya ne zaman yükselttiğini etkileyebilecek kontrollü her değişikliği kaydedin. Buna fiyat noktaları, indirimler, denemeler, paketleme, özellik kilitleri, kullanım limitleri, eklentiler ve yükseltme çağrıları dahildir.
What doesn’t count as a pricing experiment?Müşterilerin ne ödediğini veya bir plan için ne aldıklarını değiştirmiyorsa genellikle fiyat deneyi sayılmaz. Bir ödeme hatasını düzeltmek veya sayfadaki yazım hatasını gidermek genelde fiyat kaydına girmez, ama fiyat uygunluğunu veya plan içeriğini etkiliyorsa o zaman kayda eklenmelidir.
How do I tell a plan test from a feature test?Plan testi, teklifinizin yapısını ve sunumunu değiştirir: katmanlar, paketler ve plan isimleri. Özellik testi ise belirli bir yetkiye erişimi değiştirir: bir özelliği daha yüksek bir katmana koymak, kullanım limiti eklemek veya bir tetikleyici sonrası ödeme duvarı göstermek gibi.
How do I write a useful hypothesis for a pricing experiment?Bir cümlede değişikliği, davranış değişikliğini ve ölçülebilir sonucu bağlayın. Örnek: “Özellik X'i daha yüksek bir katmana taşırsak, dağıtım sırasında X'e ihtiyacı olan daha fazla ekip Business'ı seçecek ve Business yükseltmeleri artarken iadeler artmayacak.”
What metrics should we track for pricing experiments?Birincil metrik olarak “işe yaradı mı” sorusuna cevap veren bir ölçü seçin: ücretli dönüşüm, yükseltme oranı veya ziyaretçi başına gelir gibi. Ardından 1–2 korunma metriği ekleyin: churn, iadeler veya destek talepleri gibi; böylece kısa vadeli kazanımı uzun vadeli zarara çevirmemiş olursunuz.
What fields are essential in each log entry?En azından test adı, sahibi, durum, başlama ve bitiş zamanları, hedef kitle ve gösterim yüzeyi, trafik bölüşümü, kontrol ve varyant açıklamaları, birincil ve korunma metrikleriyle sayılar, karar ve kısa çıkarım ile bağlam bilgisini saklayın (kampanyalar, kesintiler, mevsimsellik vb.).
How do we make the log easy to search and maintain?Tutarlı bir adlandırma düzeni kullanın; yüzey, değişiklik ve hedef kitleyi içeren kısa bir kalıp insanların hatırladıklarıyla arama yapmayı kolaylaştırır. Küçük ve öngörülebilir etiketler kullanın (test türü, bölge, yüzey) ve her giriş için tek bir sahip atayın.
Can we run the log as a simple internal tool instead of a document?Evet — hafif tutun ve birkaç alışkanlığı zorunlu kılın. Bir yaklaşım: yayın öncesi kayıt zorunlu, durdurduktan sonraki 48 saat içinde sonuç girme zorunluluğu koymak. Form tabanlı bir iç araç, kritik alanların atlanmasını engeller; ekipler genellikle bunu AppMaster gibi no-code platformlarda küçük bir dahili uygulama olarak kurar.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
