Kullanım Ölçümü ve Fiyatlandırma: Mühendislik ve Finans Karşılaştırması

Giriş

Kullanım tabanlı ve hibrit fiyatlandırma nadiren sabittir. Fiyatlandırma mantığı sabit kodlanmışsa, bir kademede veya kredi limitinde yapılan her küçük değişiklik bir mühendislik biletine dönüşür. Bu durum finans departmanı için yavaşlık, geliştiriciler için ise sinir bozucu bir durumdur. Peki, kullanım ölçümü ve bunun üzerine kurulu fiyatlandırma kimin sorumluluğunda olmalıdır? Gelin bunu açıklığa kavuşturalım.

Fiyatlandırma Değişiklikleri Neden Artık Sık Görülen Bir Durum Haline Geldi?

Fiyatlandırma artık “bir kez ayarla ve unut” türünde bir karar değildir. Danışmanlık şirketi hy ve OMR Reviews’un Growth Unhinged verilerine dayanan SaaS ve AI Fiyatlandırma Raporu’na göre, ABD’deki yazılım şirketlerinin dörtte üçü geçtiğimiz yıl fiyatlandırmalarını değiştirdi. Bu, oldukça büyük bir hareketliliktir.

Modeller de değişiyor. hy’nin 180 yazılım şirketiyle yaptığı ankete göre, %37’si halihazırda kullanıma dayalı modeller kullanıyor ve %59’u, kullanıcı başına faturalandırma ile API hacmi gibi birden fazla fiyatlandırma ölçütünü birleştiriyor. Krediler ekleyin, denemeler yapın, paketleri ayarlayın; böylece değişiklik, istisna olmaktan çıkıp norm haline gelir.

Fiyatlandırma Mantığı Nasıl Mühendisliğin Eline Geçer?

Bu genellikle tesadüfen olur. Başlangıçta bir geliştirici bir ölçütü sabit olarak kodlar: API çağrılarını sayar, bir ücret oranı uygular ve toplam tutarı faturaya gönderir. İşe yaradığı için kimse bunu sorgulamaz.

Sonra fiyatlandırma gelişir. Yeni bir kademenin, ücretsiz bir kotanın veya farklı bir aşım oranının eklenmesi, birisinin bir bilet açması, sprint sırasını beklemesi ve sürümün faturalandırmayı aksatmamasını umması anlamına gelir. Hazırlık süresi uzar ve her sürüm bir miktar risk taşır. Finans ekibi, kontrol edemediği bir kuyrukta beklemek zorunda kalır.

Hibrit modeller bu durumu daha da kötüleştirir. Bir fiyatın bileşenleri ne kadar fazla olursa, kodda bir değişikliğin gizlenebileceği yerler de o kadar artar.

Mühendislik Ekibinin Sorumluluğundaki Fiyatlandırmanın Maliyeti

Bu maliyetler, bunları kanıtlayacak bir hesap tablosu olmasa bile gerçektir.

• Yavaş lansmanlar: Bir fiyatlandırma fikri, ürün geliştirme çalışmalarının gerisinde haftalarca bekleyebilir.
• Hatalar: Kodun içine gömülü mantığı finans ekibinin okuması zordur, bu nedenle faturalarda hatalar ortaya çıkma eğilimindedir.
• Finansın kör noktaları: Finans ekibi bir rakamın nasıl hesaplandığını göremezse, anlaşmazlıkların çözülmesi daha uzun sürer.
• Fırsat maliyeti: Mühendisler, ürünü geliştirmek yerine faturalandırma kodunu güncellemekle meşgul olur.

Benim görüşüm şudur: Bir fiyat değişikliği kod dağıtımı gerektiriyorsa, fiyatlandırmanız piyasanın hızında değil, sürüm takviminizin hızında ilerler.

Finansın Sorumluluğunda Olması Gerekenler ve Mühendisliğin Sorumluluğunda Olması Gerekenler

Sorumluluk, ya bu ya da o şeklinde değildir. Kararın türüne göre bölünmelidir.

Mühendislik ekibi, olay izleme, veri boru hatları ve kaynakta kullanım verilerinin doğruluğundansorumludur.

Finans ve ürün ekipleri ise metrik tanımlarını, fiyat noktalarını, paketlemeyi ve kredileriyönetir.

İşte basit bir test: Değişiklik, neyin kaydedildiğiyle ilgiliyse mühendisliğin sorumluluğundadır. Kaydedilen kullanımın nasıl paraya dönüştürüldüğüyle ilgiliyse, finans ve ürün ekibinin sorumluluğundadır. Örneğin, bir planın 1.000 yerine 1.500 API çağrısı içermesine karar vermek bir fiyatlandırma kararındandır. Her çağrının tam olarak bir kez kaydedildiğinden emin olmak ise mühendislik görevidir.

Fiyatlandırma Değişiklikleri için Yönetişim

Koruyucu önlemler olmadan kontrolü devretmek kaosa yol açar. Aşağıdakiler, herhangi bir araca bağlı olmayan genel en iyi uygulamalardır:

• Onaylar: Bir değişikliğin devreye girmeden önce finans ve ürün ekiplerinden isimli onay alınması gerekir.
• Test: Canlıya geçmeden önce gerçek kullanım verileri üzerindeki etkisini önizleyin.
• Sürümleme: Sürümleri karşılaştırabilmek veya geri alabilmek için her fiyatlandırma yapılandırmasının sürümünü tutun.
• Yürürlük tarihleri: Bir değişikliğin ne zaman geçerli olacağını ve döngü ortasında halihazırda kaydedilmiş kullanımların nasıl ele alınacağını tanımlayın.
• Denetim izi: Kimin neyi ne zaman değiştirdiğini kaydedin.

Bunu fiyatlandırma için kod incelemesi olarak düşünün. Kimse bir başkasının gözden geçirmeden kod yayınlamaz; fiyatlar da aynı özeni hak eder.

Finans Odaklı Fiyatlandırma için Ön Koşullar

Finans, güvenemediği şeyin sorumluluğunu üstlenemez. Öncelikle üç temel unsur gelir.

Temiz kullanım verileri. Yinelenen veya eksik olaylar, bunların üzerine belirlediğiniz herhangi bir fiyatı zayıflatır.

Üzerinde anlaşmaya varılmış metrik tanımları. Ürün departmanı “aktif kullanıcı”yı bir şekilde tanımlarken finans departmanı başka bir şekilde tanımlarsa, faturalarınız bu tartışmayı sizin yerinize çözer ve sonuç pek de hoş olmaz.

Güvenilir kaynaklar. Kullanım verileri genellikle bir veri ambarında, bir API’nin arkasında veya dosyalarda bulunur. Her metrik için tek bir kayıt sistemi seçin ve buna sadık kalın.

Fiyatlandırma Sorumluluğunu Devretmeden Önce Sorulması Gereken Sorular

CFO’yu, ürün liderini ve mühendislik liderini bir odada toplayın ve şu konuları ele alın:

1. Geçen yıl hangi fiyatlandırma değişikliklerini yaptık ve her birinin uygulamaya geçirilmesi ne kadar sürdü?
2. Faturalandırılabilir her metrik için üzerinde anlaşmaya varılmış tek bir tanım var mı?
3. Finans departmanı, bir kullanım rakamının nasıl fatura satırına dönüştüğünü izleyebiliyor mu?
4. Bir değişikliği kim onaylar ve canlıya geçmeden önce nasıl test ederiz?
5. Kullanım verileri nerede saklanıyor ve doğruluğundan kim sorumlu?

Bunlardan iki veya üçüne cevap veremiyorsanız, işte başlangıç noktanız budur.

Ölçüm Sistemini Yeniden Oluşturmadan Fiyatlandırmayı Değiştirmek

İşte bu noktada araçlar yardımcı olabilir. Zenskar’ın Kullanım Ölçümü sayfasına göre, ekipler faturalandırılabilir metrikleri sade bir dille tanımlayabilir ve toplama mantığını yapay zekanın yazmasına izin verebilir veya karmaşık mantıklar için özel SQL kodları yazabilir. Kullanım verileri Postgres, Athena ve MySQL gibi kaynaklardan alınabilir, bir API aracılığıyla aktarılabilir veya CSV dosyası olarak yüklenebilir. Aynı metrik, ürünler, sözleşmeler ve satır öğeleri arasında yeniden kullanılabilir.

Sahiplik açısından önemli olan nokta, kullanıma dayalı faturalandırma yazılımının, kademelerin, aşımların ve faturalandırma sıklığının kullanımdan bağımsız olarak değiştirilmesine izin vermesidir. Faturalandırma mantığı, veri boru hattını kesintiye uğratmadan döngü ortasında da değiştirilebilir. Tek bir metrik, sözleşmeler genelinde farklı fiyatlandırma modellerini destekleyebilir ve fiyatlandırma geliştikçe ölçümlemeyi istikrarlı tutar.

Sonuç

En sağlıklı model, ortaklaşa yürütülen modeldir. Mühendislik ekibi, kullanım verilerinin doğruluğunu ve akışını sağlar. Finans ve ürün ekipleri ise net bir yönetişim çerçevesi içinde bu verilerin değerini belirler. Şu anda mühendislik kuyruğunuzda hangi fiyatlandırma değişikliği bekliyor?

Önemli Noktalar:

• Sabit kodlanmış fiyatlandırma, her kademede veya kredide yapılan her küçük değişikliği bir mühendislik talebine dönüştürür.
• Sorumluluğu karar türüne göre bölün: mühendislik ekibi kullanım verilerinin toplanmasından ve doğruluğundan sorumluyken, finans ve ürün ekipleri metrik tanımlarından, fiyat noktalarından, paketlerden ve kredilerden sorumludur.
• Öncelikle güvenlik önlemlerini alın: onaylar, testler, sürümleme, yürürlük tarihleri ve denetim izi.
• Finans departmanı tarafından yönetilen fiyatlandırma, temiz kullanım verilerine, üzerinde anlaşmaya varılmış metrik tanımlarına ve her metrik için tek bir kayıt sistemine ihtiyaç duyar.
• Başlangıç noktanızı belirlemek için devir öncesi beş soruyu kullanın.
• Ölçüm sistemini yeniden kurmaya gerek kalmadan fiyatlandırma değişikliklerine izin veren araçları seçin.