Çok kiracılı bir çözüm için fiyatlandırma modelleri

İyi bir fiyatlandırma modeli, kiracı sayısı arttıkça ve yeni özellikler ekledikçe kârlı kalmanızı sağlar. Ticari çok kiracılı bir çözüm geliştirirken dikkat edilmesi gereken önemli nokta, ürününüz için fiyatlandırma modelleri tasarlamadır. Bu sayfada, teknik karar alıcılara göz önünde bulundurabileceğiniz fiyatlandırma modelleri ve ilgili dezavantajlar hakkında rehberlik sağlıyoruz.

Ürününüz için fiyatlandırma modelini belirlerken, hizmeti sunmak için müşterileriniz için değer getirisini (ROV) satılan malların maliyetiyle (COGS) dengelemeniz gerekir. Daha esnek ticari modeller sunmak (bir çözüm için) müşteriler için ROV'yi artırabilir, ancak çözümün mimari ve ticari karmaşıklığını da artırabilir (ve bu nedenle COGS'lerinizi de artırabilir).

Bir çözüm için fiyatlandırma modelleri geliştirirken dikkate almanız gereken bazı önemli noktalar şunlardır:

• COGS, çözümden elde ettiğiniz kardan daha yüksek olacak mı?
• COGS'ler, kullanıcılardaki büyümeye veya kullanım desenlerindeki değişikliklere bağlı olarak zaman içinde değişebilir mi?
• Fiyatlandırma modelini çalıştırmak için gereken bilgileri ölçmek ve kaydetmek ne kadar zor? Örneğin, müşterilerinize yaptıkları API çağrılarının sayısına göre faturalamayı planlıyorsanız, her müşteri tarafından yapılan API çağrılarını nasıl ölçtüğünüzü belirlediniz mi?
• Kârlılığınız, müşterilerin çözümünüzü sınırlı bir şekilde kullanmasını sağlamaya bağlı mı?
• Bir müşteri çözümü aşırı kullanıyorsa, bu artık kârlı olmadığınız anlamına mı gelir?

Kârlılığınızı etkileyen bazı önemli faktörler vardır:

• Azure hizmeti fiyatlandırma modelleri. Çözümünüzü oluşturan Azure veya üçüncü taraf hizmetlerin fiyatlandırma modelleri, hangi modellerin karlı olduğunu etkileyebilir.
• Hizmet kullanım desenleri. Kullanıcıların yalnızca çalışma saatleri içinde çözümünüze erişmesi gerekebilir veya yüksek hacimli kullanıcıların yalnızca küçük bir yüzdesine sahip olabilir. Kullanımınız düşük olduğunda kullanılmayan kapasiteyi azaltarak COGS'nizi azaltabilir misiniz?
• Depolama büyümesi. Çözümlerin çoğu zaman içinde veri biriktirir. Daha fazla veri, depolama ve koruma maliyetlerinin daha yüksek olması ve kiracı başına kârlılığınızın azaltılması anlamına gelir. Depolama kotaları ayarlayabilir veya veri saklama süresini zorunlu kılabilir misiniz?
• Kiracı yalıtımı. Kullandığınız kiracı modeli, kiracılarınız arasında sahip olduğunuz yalıtım düzeyini etkiler. Kaynaklarınızı paylaşıyorsanız kiracıların hizmeti nasıl aşırı kullanabileceğini veya kötüye kullanabileceğini düşünmeniz gerekiyor mu? Kiracı yalıtımı düzeyi, COGS'lerinizi ve herkes için performansı nasıl etkiler? Kaynak ayırmayla ilgili ek denetimler olmadan bazı fiyatlandırma modelleri kârlı değildir. Örneğin, sabit fiyat fiyatlandırma modelini sürdürülebilir hale getirmek için hizmet azaltma uygulamanız gerekebilir.
• Kiracı yaşam döngüsü. Örneğin, yüksek müşteri değişim oranlarına sahip çözümler veya daha fazla biniş çabası gerektiren hizmetler, özellikle tüketime dayalı bir model kullanılarak fiyatlendiriliyorsa daha düşük kârlılık yaşayabilir.
• Hizmet düzeyi gereksinimleri. Daha yüksek düzeyde hizmet gerektiren kiracılar, çözümünüzün artık kârlı olmadığı anlamına gelebilir. Müşterilerinizin hizmet düzeyi beklentileri ve sahip olduğunuz tüm yükümlülükler konusunda net olmanız önemlidir, böylece fiyatlandırma modellerinizi buna göre planlayabilirsiniz.

Yaygın fiyatlandırma modelleri

Genellikle çok kiracılı çözümlerle kullanılan birçok yaygın fiyatlandırma modeli vardır. Bu fiyatlandırma modellerinin her birinin ticari avantajları ve riskleri vardır ve ek mimari konuları gerektirir. Çözümünüzün geliştikçe kârlı kalmasını sağlamak için bu fiyatlandırma modelleri arasındaki farkları anlamanız önemlidir.

Not

Bir çözüm için birden çok model sunabilir veya modelleri birlikte birleştirebilirsiniz. Örneğin, müşterileriniz için oldukça kararlı kullanıcı numaralarına sahip bir kullanıcı başına model sağlayabilir ve ayrıca dalgalanan kullanım desenleri olan müşteriler için bir tüketim modeli de sunabilirsiniz.

Tüketim tabanlı fiyatlandırma

Tüketim modeli bazen kullandıkça öde veya PAYG olarak adlandırılır. Hizmetinizin kullanımı arttıkça geliriniz de artar:

Tüketimi ölçerken çözüme eklenen veri miktarı gibi basit faktörleri göz önünde bulundurabilirsiniz. Alternatif olarak, kullanım özniteliklerinin bir birleşimini birlikte düşünebilirsiniz. Tüketim modelleri birçok avantaj sunar, ancak çok kiracılı bir çözümde uygulanması zor olabilir.

Avantajlar: Müşterilerinizin perspektifinden bakıldığında, çözümünüzü kullanmak için gereken minimum ön yatırım vardır, böylece bu modelde giriş engeli düşüktür. Hizmet operatörü olarak sizin bakış açınızdan, müşterilerinizin kullanımı ve geliriniz arttıkça barındırma ve yönetim maliyetleriniz artar. Bu artış, yüksek oranda ölçeklenebilir bir fiyatlandırma modeli olmasını sağlayabilir. Özellikle çözümde kullanılan Azure hizmetleri tüketim tabanlı olduğunda tüketim fiyatlandırma modelleri iyi çalışır.

Karmaşıklık ve operasyonel maliyet: Tüketim modelleri, doğru kullanım ölçümlerini ve bu kullanımı kiracıya bölmeyi temel alır. Bu, özellikle birçok dağıtılmış bileşeni olan bir çözümde zor olabilir. Faturalama ve denetim için ayrıntılı tüketim kayıtlarını tutmanın yanı sıra müşterilerin tüketim verilerine erişmesi için yöntemler sağlamanız gerekir.

Riskler: Tüketim fiyatlandırması, müşterilerinizi maliyetleri azaltmak için sisteminizin kullanımını azaltmaya teşvik edebilir. Buna ek olarak, tüketim modelleri öngörülemeyen gelir akışlarıyla sonuçlanır. Müşterilerin belirli bir tüketim düzeyi için peşin ödeme yaptığı kapasite rezervasyonları sunarak bunu azaltabilirsiniz. Hizmet sağlayıcısı olarak bu geliri kullanarak çözümdeki iyileştirmelere yatırım yapabilir, operasyonel maliyeti azaltabilir veya özellik ekleyerek değer getirisini artırabilirsiniz.

Not

Kapasite rezervasyonlarının uygulanması ve desteklenmesi, uygulamanızdaki faturalama işlemlerinin karmaşıklığını artırabilir. Ayrıca müşterilerin nasıl para iadesi alabileceğini veya kapasite rezervasyonlarını nasıl değiştirebileceğini de düşünmeniz gerekebilir ve bu süreçler ticari ve operasyonel zorluklar da ekleyebilir.

Kullanıcı başına fiyatlandırma

Kullanıcı başına fiyatlandırma modeli, aşağıdaki diyagramda gösterildiği gibi hizmetinizi kullanan kişi sayısına göre müşterilerinizi ücretlendirmeyi içerir.

Kullanıcı başına fiyatlandırma modelleri, çok kiracılı bir çözümde uygulanması kolaylığı nedeniyle çok yaygındır. Ancak bunlar çeşitli ticari risklerle ilişkilidir.

Avantajlar: Müşterilerinize her kullanıcı için faturalandırdığınızda, gelir akışınızı hesaplamak ve tahmin etmek kolaydır. Ayrıca, her kullanıcı için oldukça tutarlı kullanım desenleriniz olduğunu varsayarsak, gelir hizmet benimseme ile aynı oranda artar ve bu da ölçeklenebilir bir model olur.

Karmaşıklık ve operasyonel maliyet: Kullanıcı başına modellerin uygulanması kolay olma eğilimindedir. Ancak bazı durumlarda, tek bir kullanıcının COGS'lerinin karlı kalmasını sağlamanıza yardımcı olabilecek kullanıcı başına tüketimi ölçmeniz gerekir. Tüketimi ölçerek ve belirli bir kullanıcıyla ilişkilendirerek çözümünüzün operasyonel karmaşıklığını artırabilirsiniz.

Riskler: Farklı kullanıcı tüketimi desenleri kârlılığın azalmasına neden olabilir. Örneğin, çözümün ağır kullanıcılarının hizmet verme maliyeti hafif kullanıcılara kıyasla daha fazla olabilir. Buna ek olarak, çözüm için gerçek değer getirisi (ROV), satın alınan gerçek kullanıcı lisansı sayısına yansıtılamaz.

Etkin kullanıcı başına fiyatlandırma

Bu model kullanıcı başına fiyatlandırmaya benzer, ancak müşteriden beklenen kullanıcı sayısıyla ilgili ön taahhüt gerektirmek yerine, müşteri yalnızca belirli bir süre boyunca (aşağıdaki diyagramda gösterildiği gibi) gerçekten oturum açan ve çözümü kullanan kullanıcılar için ücretlendirilir.

Bunu ne zaman mantıklı olursa olsun ölçebilirsiniz. Aylık dönemler yaygındır ve bu ölçüm genellikle aylık etkin kullanıcılar veya MAU olarak kaydedilir.

Avantajlar: Müşterilerinizin bakış açısından bakıldığında, bu model düşük bir yatırım ve risk gerektirir, çünkü çok az israf vardır; kullanılmayan lisanslar faturalandırılamaz. Bu, çözümü pazarlama veya daha büyük kurumsal müşteriler için çözümü büyütme konusunda özellikle cazip hale getirir. Hizmet sahibi olarak sizin bakış açınızdan, ROV'nuz aylık etkin kullanıcı sayısına göre müşteriye daha doğru yansıtılır.

Karmaşıklık ve işlem maliyeti: Etkin kullanıcı başına modeller gerçek kullanımı kaydetmenizi ve faturanın bir parçası olarak bir müşterinin kullanımına sunmanızı gerektirir. Kullanıcı başına tüketimin ölçülmesi, tek bir kullanıcı için COGS ile kârlılığın korunmasına yardımcı olur, ancak yine de her kullanıcının tüketimini ölçmek için ek çalışma gerektirir.

Riskler: Kullanıcı başına fiyatlandırma gibi, tek tek kullanıcıların farklı tüketim düzenlerinin kârlılığınızı etkileme riski vardır. Kullanıcı başına fiyatlandırmayla karşılaştırıldığında, etkin kullanıcı başına modellerde daha az tahmin edilebilir bir gelir akışı vardır. Buna ek olarak, indirim fiyatlandırması büyümeyi teşvik etmek için kullanışlı bir yol sağlamaz.

Birim başına fiyatlandırma

Birçok sistemde kullanıcı sayısı, genel COGS üzerinde en büyük etkiye sahip olan öğe değildir. Örneğin, nesnelerin interneti veya IoT olarak da adlandırılan cihaz odaklı çözümlerde cihaz sayısı genellikle COGS üzerinde en büyük etkiye sahiptir. Bu sistemlerde birim başına fiyatlandırma modeli kullanılabilir ve burada cihaz gibi bir birimi tanımlarsınız. Aşağıdaki diyagrama bakın.

Ayrıca, bazı çözümlerin çok az sayıda kullanıcının COGS üzerinde orantısız bir etkisi olduğu yüksek oranda değişken kullanım desenleri vardır. Örneğin, tuğla ve harç perakendecilerine satılan bir çözümde mağaza başına fiyatlandırma modeli uygun olabilir.

Avantajlar: Tek tek kullanıcıların COGS üzerinde önemli bir etkiye sahip olmadığı sistemlerde birim başına fiyatlandırma, sistemin ölçeklendirilmesinin gerçekliğini ve COGS'ye olan etkisini göstermenin daha iyi bir yoludur. Ayrıca, bir müşterinin gerçek kullanım desenlerine uyumu da geliştirebilir. Her cihazın tahmin edilebilir ve sabit bir tüketim miktarı oluşturduğu birçok IoT çözümü için bu, çözümünüzün büyümesini ölçeklendirmek için etkili bir model olabilir.

Karmaşıklık ve operasyonel maliyet: Genel olarak birim başına fiyatlandırmanın uygulanması kolaydır ve oldukça düşük bir işletim maliyetine sahiptir. Ancak kullanımı cihazlar veya perakende mağazaları gibi tek tek birimlere göre ayırt etmeniz ve izlemeniz gerekiyorsa operasyonel maliyet daha yüksek olabilir. Birim başına tüketimin ölçülmesi, tek bir ünite için SGS'leri belirleyebildiğiniz için kârlılığınızın korunmasına yardımcı olur.

Riskler: Birim başına fiyatlandırma modelinin riskleri, kullanıcı başına fiyatlandırmaya benzer. Bazı birimlere göre farklı tüketim desenleri, bazı cihazların veya mağazaların çözümün diğerlerinden çok daha ağır kullanıcıları olması gibi kârlılığı azalttığınız anlamına gelebilir.

Özellik ve hizmet düzeyi tabanlı fiyatlandırma

Çözümünüzü farklı fiyat noktalarında farklı işlev katmanlarıyla sunmayı seçebilirsiniz. Örneğin, biri kullanılabilir özelliklerin bir alt kümesini içeren temel bir teklif, diğeri ise çözümünüzün özelliklerinin kapsamlı kümesini sunan iki aylık sabit fiyat veya birim başına fiyat sağlayabilirsiniz. Aşağıdaki diyagrama bakın.

Bu model, farklı katmanlar için farklı hizmet düzeyi sözleşmeleri de sunabilir. Örneğin, temel katmanınız %99,9 çalışma süresi sunabilirken premium katman %99,99 sunabilir. Daha yüksek hizmet düzeyi sözleşmesi (SLA), daha yüksek kullanılabilirlik hedefleri sağlayan hizmetler ve özellikler kullanılarak uygulanabilir.

Bu model ticari açıdan faydalı olsa da, iyi iş yapmak için olgun mühendislik uygulamaları gerektirir. Dikkatli bir şekilde ele alındığında, bu model çok etkili olabilir.

Avantajlar: Özellik tabanlı fiyatlandırma genellikle müşteriler için caziptir çünkü ihtiyaç duydukları özellik kümesine veya hizmet düzeyine göre bir katman seçebilirler. Ayrıca, müşterilerinize ek özellikler veya ihtiyaç duyanlar için daha yüksek dayanıklılıkla satış yapmak için net bir yol sağlar.

Karmaşıklık ve operasyonel maliyet: Özellik tabanlı fiyatlandırma modellerinin uygulanması karmaşık olabilir çünkü çözümünüzün her fiyat katmanında kullanılabilen özelliklerden haberdar olmasını gerektirir. Özellik geçişleri, belirli işlev alt kümelerine erişim sağlamanın etkili bir yolu olabilir, ancak bunun için sürekli bakım gerekir. Ayrıca, test edilecek daha fazla kod yolu olacağı için özellik geçişleri yüksek kaliteyi sağlamak için ek yükü artırır. Bazı katmanlarda daha yüksek hizmet kullanılabilirliği hedeflerinin etkinleştirilmesi, her katman için doğru altyapı kümesinin kullanıldığından emin olmak için ek mimari karmaşıklık gerektirebilir ve bu işlem çözümün işletim maliyetini artırabilir.

Riskler: Çok fazla katman veya seçenek varsa özellik tabanlı fiyatlandırma modelleri karmaşık ve kafa karıştırıcı hale gelebilir. Ayrıca, dinamik olarak geçiş özellikleriyle ilgili ek yük, ek özellikler sunma hızınızı yavaşlatabilir.

Freemium fiyatlandırması

Hizmetinizin temel işlevleri ve hizmet düzeyi garantileri olmadan ücretsiz bir katmanını sunmayı tercih edebilirsiniz. Daha sonra ek özellikler ve resmi hizmet düzeyi sözleşmesi (aşağıdaki diyagramda gösterildiği gibi) ile ayrı bir ücretli katman sunabilirsiniz.

Ücretsiz katman, zaman sınırlı bir deneme sürümü olarak da sunulabilir ve deneme süresi boyunca müşterileriniz tam veya sınırlı işlevlere sahip olabilir. Bu, özellik tabanlı fiyatlandırma modelinin etkili bir uzantısı olan freemium modeli olarak adlandırılır.

Avantajlar: Ücretsiz olduğunda bir çözümü pazarlamak çok kolaydır.

Karmaşıklık ve operasyonel maliyet: Karmaşıklık ve operasyonel maliyet sorunlarının tümü, özellik tabanlı fiyatlandırma modelinden geçerlidir. Ancak, ücretsiz kiracıları yönetmeye yönelik operasyonel maliyeti de göz önünde bulundurmanız gerekir. Eski kiracıların kapalı olduğundan veya kaldırıldığından emin olmanız ve özellikle ücretsiz kiracılar için net bir bekletme ilkeniz olması gerekebilir. Bir kiracıyı ücretli bir katmana yükseltme yaparken, daha yüksek SLA'lar elde etmek için kiracıyı Azure hizmetleri arasında taşımanız gerekebilir. Ücretli bir katmana geçerken kiracının verilerini ve yapılandırmasını korumak da önemlidir.

Riskler: Kiracıların ücretli bir katmana geçmeyi düşünebilmesi için yeterince yüksek bir ROV sağladığınıza emin olmanız gerekir. Buna ek olarak, çözümünüzü müşterilere ücretsiz katmanda sağlamanın maliyeti, ücretli katmanlarda bulunanların kar marjı kapsamında olmalıdır.

Satılan malların maliyeti fiyatlandırması

Çözümünüzün fiyatını, her kiracının yalnızca Azure hizmetlerindeki payını işletme maliyetini ek kar marjı olmadan ödemesini seçebilirsiniz. Geçiş maliyeti veya fiyatlandırma olarak da adlandırılan bu model bazen kâr merkezi olarak tasarlanmamış çok kiracılı çözümler için kullanılır.

Satılan malların maliyeti modeli, dahili olarak karşı karşıya olan çok kiracılı çözümler için uygundur. Her kuruluş birimi bir kiracıya karşılık gelir ve Azure kaynaklarınızın maliyetlerinin bunlar arasında yayılması gerekir. Gelirin çok kiracılı çözümü kullanan veya genişleten diğer ürün ve hizmetlerin satışından elde edilmesi de uygun olabilir.

Avantajlar: Bu model kar için eklenen kar marjı içermediğinden kiracıların maliyeti daha düşük olacaktır.

Karmaşıklık ve operasyonel maliyet: Tüketim modeline benzer şekilde, satılan malların fiyatlandırma maliyeti de doğru kullanım ölçümlerine ve bu kullanımın kiracıya bölünmesine bağlıdır. Özellikle birçok dağıtılmış bileşeni olan bir çözümde tüketimi izleme zor olabilir. Faturalama ve denetim için ayrıntılı tüketim kayıtlarını tutmanın yanı sıra müşterilerin tüketim verilerine erişmesi için yöntemler sağlamanız gerekir.

Şirket içinde çok kiracılı çözümler için kiracılar yaklaşık maliyet tahminlerini kabul edebilir ve daha rahat faturalama denetimi gereksinimlerine sahip olabilir. Bu gevşek gereksinimler çözümünüzü çalıştırmanın karmaşıklığını ve maliyetini azaltır.

Riskler: Satılan malların maliyeti fiyatlandırması, kiracılarınızı, maliyetlerini azaltmak için sisteminizin kullanımını azaltmaya teşvik edebilir. Ancak, bu model kar merkezi olmayan uygulamalar için kullanıldığından, bu sorun olmayabilir.

Sabit fiyat fiyatlandırması

Bu modelde, belirli bir süre boyunca çözümünüz için bir kiracıya erişim için sabit bir ücret ödersiniz. Hizmeti ne kadar kullandıklarından, kullanıcı sayısından, bağlandıkları cihaz sayısından veya diğer ölçümlerden bağımsız olarak aynı fiyatlandırma geçerlidir. Aşağıdaki diyagrama bakın.

Bu, uygulanması ve müşterilerin anlaması için en basit modeldir ve genellikle kurumsal müşteriler tarafından istenir. Ancak, yeni özellikler eklemeye devam etmeniz gerekiyorsa veya kiracı tüketimi ek gelir olmadan artarsa kolayca kârsız hale gelebilir.

Avantajlar: Sabit fiyat fiyatlandırması kolayca satılır ve müşterilerinizin anlaması ve bütçesi kolaydır.

Karmaşıklık ve operasyonel maliyet: Faturalama müşterileri herhangi bir ölçüm veya izleme tüketimi gerektirmediğinden düz fiyat fiyatlandırma modellerini uygulamak kolay olabilir. Ancak gerekli olmasa da, COGS'leri doğru bir şekilde ölçtünüzden emin olmak ve kârlılığınızın korunmasını sağlamak için kiracı başına tüketimi ölçmeniz önerilir.

Riskler: Çözümünüzden yoğun bir şekilde yararlanan kiracılarınız varsa bu fiyatlandırma modelinin uygun olmayan hale gelmesi kolaydır.

İndirim fiyatlandırması

Fiyatlandırma modelinizi tanımladıktan sonra, indirim fiyatlandırması aracılığıyla büyümeyi teşvik etmek için ticari stratejiler uygulamayı seçebilirsiniz. İndirim fiyatlandırması tüketim, kullanıcı başına ve birim başına fiyatlandırma modelleriyle kullanılabilir.

Not

daha karmaşık bir faturalama yapısı için destek eklemenin ötesinde, indirim fiyatlandırması genellikle mimari konuları gerektirmez. İndirimin ticari avantajlarına ilişkin eksiksiz bir tartışma, bu belgenin kapsamı dışındadır.

Yaygın indirim fiyatlandırma desenleri şunlardır:

• Sabit fiyatlandırma. Ne kadar satın alınır veya tüketilirse kullansın, her kullanıcı, birim veya tüketim miktarı için aynı maliyete sahip olursunuz. Bu en basit yaklaşımdır. Ancak çözümünüzü yoğun bir şekilde kullanan müşteriler, indirim yaparak ölçek ekonomilerinden yararlanmaları gerektiğini düşünebilir.
• Digressive fiyatlandırması. Müşteriler daha fazla birim satın aldıkçe veya tükettikçe birim başına maliyeti azaltırsınız. Bu, müşteriler için ticari olarak daha çekicidir.
• Adım fiyatlandırması. Müşteriler daha fazla satın aldıkçe birim başına maliyeti azaltırsınız. Ancak, önceden tanımlanmış miktar aralıklarına göre adım değişikliklerinde bunu yaparsınız. Örneğin, ilk 100 kullanıcı için daha yüksek bir fiyat, ardından 101. ve 200. kullanıcılar için daha düşük bir fiyat ve daha sonra tekrar daha düşük bir fiyat alabilirsiniz. Bu daha karlı olabilir.

Aşağıdaki diyagramda bu fiyatlandırma desenleri gösterilmektedir.

Üretim dışı ortam indirimleri

Çoğu durumda müşteriler test, eğitim veya kendi iç belgelerini oluşturmak için kullanabilecekleri üretim dışı bir ortama erişime ihtiyaç duyar. Üretim dışı ortamlar genellikle daha düşük tüketim gereksinimlerine ve çalışma maliyetlerine sahiptir. Örneğin, üretim dışı ortamlar genellikle hizmet düzeyi sözleşmelerine (SLA) tabi değildir ve hız sınırları daha düşük değerlerle ayarlanabilir. Azure hizmetlerinizde daha agresif otomatik ölçeklendirmeyi de göz önünde bulundurabilirsiniz.

Aynı şekilde, müşteriler genellikle üretim dışı ortamların üretim ortamlarından önemli ölçüde daha ucuz olmasını bekler. Üretim dışı ortamlar sağladığınızda uygun olabilecek birkaç alternatif vardır:

• Ücretli müşteriler için zaten yapmış olabileceğiniz gibi bir freemium katmanı teklif edin. Bazı kuruluşlar çalışmak için ek kaynaklar kullanacak birçok test ve eğitim ortamı oluşturabileceğinden bu dikkatle izlenmelidir.

  Not

  Freemium katmanlarını kullanan zaman sınırlı denemeler genellikle test ve eğitim ortamları için uygun değildir. Müşterilerin genellikle üretim hizmeti kullanım ömrü boyunca üretim dışı ortamlarının kullanılabilir olması gerekir.

• Daha düşük kullanım sınırlarıyla hizmetinizin test veya eğitim katmanını sunun. Bu katmanın kullanılabilirliğini mevcut ücretli kiracısı olan müşterilerle kısıtlamayı seçebilirsiniz.
• Hizmet düzeyi sözleşmesi daha düşük veya hiç olmayan üretim dışı kiracılar için kullanıcı başına, etkin kullanıcı başına veya birim başına indirimli fiyatlandırma teklifinde bulunun.
• Sabit fiyat fiyatlandırması kullanan kiracılar için, sözleşme kapsamında üretim dışı ortamlar müzakere edilebilir.

Not

Sunulan özellikler üretim ortamının sunduğu özelliklerle aynı olmadığı sürece, özellik tabanlı fiyatlandırma genellikle üretim dışı ortamlar için iyi bir seçenek değildir. Bunun nedeni, kiracıların genellikle üretimde kendilerine sağlanan tüm özellikleri test etmek ve eğitim sağlamak istemeleridir.

Verimsiz fiyatlandırma modelleri

Kârlı olmayan bir fiyatlandırma modeli, hizmeti sunmanın maliyeti, kazandığınız gelirden daha fazladır. Örneğin, hizmetiniz için herhangi bir sınır olmadan kiracı başına sabit bir ücretlendirmeniz gerekebilir, ancak ardından hizmetinizi tüketim tabanlı Azure kaynaklarıyla ve kiracı başına kullanım sınırları olmadan derleyebilirsiniz. Bu durumda, kiracılarınızın hizmetinizi aşırı kullanma riskiyle karşı karşıya olabilirsiniz ve bu nedenle onlara hizmet vermenin uygun olmayabileceği bir durumdur.

Genellikle, verimsiz fiyatlandırma modellerinden kaçınmak istersiniz. Ancak, aşağıdakiler de dahil olmak üzere, verimsiz bir fiyatlandırma modelini benimsemeyi seçebileceğiniz durumlar vardır:

• Büyümeyi sağlamak için ücretsiz bir hizmet sunulmaktadır.
• Ek gelir akışları hizmetler veya eklenti özellikleri tarafından sağlanır.
• Belirli bir kiracıyı barındırmak, bunları yeni bir pazarda yer işareti kiracısı olarak kullanmak gibi başka bir ticari değer sağlar.

Yanlışlıkla doğrulanamayan bir fiyatlandırma modeli oluşturmanız durumunda, bunlarla ilişkili riskleri azaltmanın bazı yolları vardır, örneğin:

• Hizmet kullanımını kullanım sınırlarıyla sınırlayın.
• Kapasite rezervasyonlarının kullanılmasını zorunlu kılar.
• Kiracının daha yüksek bir özelliğe veya hizmet katmanına taşınmasını isteyin.

Riskli fiyatlandırma modelleri

Bir çözüm için fiyatlandırma modeli uygularken genellikle bunun nasıl kullanılacağı hakkında varsayımlarda bulunmanız gerekir. Bu varsayımların yanlış olduğu ortaya çıkarsa veya kullanım düzenleri zaman içinde değişirse fiyatlandırma modeliniz verimsiz hale gelebilir. Verimsiz olma riski olan fiyatlandırma modelleri riskli fiyatlandırma modelleri olarak bilinir. Örneğin, kullanıcıların çözümünüzü kullandıkları miktarı kendi kendine sınırlamalarını bekleyen bir fiyatlandırma modeli benimsediyseniz riskli bir fiyatlandırma modeli uygulamış olabilirsiniz.

SaaS çözümlerinin çoğu düzenli olarak yeni özellikler ekler. Bu, ROV'yi kullanıcılara yükseltir ve bu da çözümün kullanıldığı miktarın artmasına neden olabilir. Bu durum, yeni özelliklerin kullanılması kullanımı yönlendiriyorsa ancak fiyatlandırma modeli bunu dikkate almazsa, bu bir çözümün sağlamaz hale gelmesiyle sonuçlanabilir.

Örneğin, çözümünüzde tüketim tabanlı bir kaynak kullanan yeni bir video yükleme özelliği eklerseniz ve özelliğin kullanıcı tarafından alınması beklenenden yüksekse kullanım sınırları ile özellik ve hizmet düzeyi fiyatlandırmasının bir birleşimini göz önünde bulundurun.

Kullanım sınırları

Kullanım sınırları , fiyatlandırma modellerinizin sağlanamaz hale gelmesini önlemek veya tek bir kiracının hizmetinizin kapasitesinin orantısız bir miktarını kullanmasını önlemek için hizmetinizin kullanımını kısıtlamanıza olanak tanır. Bu özellikle çok kiracılı hizmetlerde önemli olabilir; burada tek bir kiracı, kaynakları aşırı tüketerek diğer kiracıların deneyimini etkileyebilir.

Not

Müşterilerinizin kullanım sınırlarını uyguladığınızı fark etmelerini sağlamak önemlidir. Müşterilerinizi sınırdan haberdar etmeden kullanım sınırları uygularsanız müşteri memnuniyetsizliği ortaya çıkar. Bu, kullanım sınırlarını önceden tanımlamanın ve planlamanın önemli olduğu anlamına gelir. Amaç, sınırı planlamak ve gerekli hale gelmeden önce sınırları müşterilere iletmek olmalıdır.

Kullanım sınırları genellikle daha yüksek katmanlarda daha yüksek miktarda kullanım sağlamak için özellik ve hizmet düzeyi fiyatlandırmasıyla birlikte kullanılır. Limitler, aşırı tüketilen sistem performans sorunlarına veya performans sorunlarına neden olacak temel bileşenleri korumak için de yaygın olarak kullanılır.

Hız sınırları

Kullanım sınırı uygulamanın yaygın bir yolu, API'lere veya belirli uygulama işlevlerine hız sınırları eklemektir. Buna azaltma da denir. Hız sınırları sürekli aşırı kullanımı önler. Bunlar genellikle tanımlı bir zaman aralığı boyunca API'ye yapılan çağrı sayısını sınırlamak için kullanılır. Örneğin, bir API dakikada yalnızca 20 kez çağrılabilir ve bundan daha sık çağrılırsa HTTP 429 hatası döndürür.

Hız sınırlamanın sıklıkla kullanıldığı bazı durumlar şunlardır:

• REST API'leri.
• Zaman uyumsuz görevler.
• Zamana duyarlı olmayan görevler.
• Yürütülmesi yüksek maliyete neden olan eylemler.
• Rapor oluşturma.

Hız sınırlaması uygulamak çözüm karmaşıklığını artırabilir, ancak Azure API Management gibi hizmetler hız sınırı ilkeleri uygulayarak bunu daha basit hale getirebilir.

Fiyatlandırma modeli yaşam döngüsü

Çözümünüzün diğer bölümlerinde olduğu gibi fiyatlandırma modellerinin de bir yaşam döngüsü vardır. Uygulamanız zaman içinde geliştikçe fiyatlandırma modellerinizi değiştirmeniz gerekebilir. Bu, müşteri gereksinimlerini, ticari gereksinimleri veya uygulamanızdaki işlevlerdeki değişiklikleri değiştirerek yönlendirilebilir. Bazı yaygın fiyatlandırma yaşam döngüsü değişiklikleri şunlardır:

• Tamamen yeni bir fiyatlandırma modeli ekleme. Örneğin, şu anda sabit fiyat modeli sunan bir çözüme tüketim fiyatlandırma modeli ekleme.
• Mevcut fiyatlandırma modelinin kullanıma sunulması.
• Mevcut fiyatlandırma modeline katman ekleme.
• Mevcut fiyatlandırma modelindeki bir katmanı kullanımdan kaldırma.
• Fiyatlandırma modelindeki bir özelliğin kullanım sınırlarını değiştirme.
• Özellik ve hizmet düzeyi fiyatlandırma modeline özellik ekleme veya kaldırma.
• İşletmeden tüketiciye (B2C) ticari modelden işletmeden işletmeye (B2B) ticari modele değiştirme. Bu değişiklik, işletme müşterileriniz için yeni fiyatlandırma yapılarını zorunlu kılmaktadır.

Aynı anda birçok farklı fiyatlandırma modeli uygulamak ve yönetmek genellikle karmaşıktır. Müşterileriniz için de kafa karıştırıcıdır. Bu nedenle, az sayıda katmana sahip yalnızca bir veya iki model uygulamak daha iyidir. Bu, çözümünüzü daha erişilebilir ve daha kolay yönetilebilir hale getirir.

Not

Fiyatlandırma modelleri ve faturalama işlevleri, sisteminizin diğer bölümlerinde olduğu gibi ideal olarak otomatik test kullanılarak test edilmelidir. Fiyatlandırma modelleri ne kadar karmaşık olursa o kadar fazla test yapılması gerekir ve bu nedenle geliştirme ve yeni özelliklerin maliyeti artar.

Fiyatlandırma modellerini değiştirirken aşağıdaki faktörleri dikkate almanız gerekir:

• Kiracılar yeni modele geçmek ister mi?
• Kiracıların yeni modele geçişi kolay mı?
• Yeni fiyatlandırma modelleri hizmetinizi riske atacak mı? Örneğin, şu anda kritik kaynakları aşırı kullanıma karşı koruyan hız sınırlarını kaldırıyor musunuz?
• Kiracıların yeni fiyatlandırma modeline geçiş için net bir yolu var mı?
• Kiracıların eski fiyatlandırma modellerini kullanmasını nasıl önleyeceksiniz? Böylece bunları devre dışı bırakabilirsiniz.
• Kiracılar, fiyatlandırma modellerini değiştirirken fatura şoku (beklenmeyen faturaya olumsuz tepki) alma olasılığı var mı?
• Sürekli kârlılığı güvence altına alabilmeniz için yeni veya değiştirilmiş fiyatlandırma modelleri için hizmetlerinizin performansını ve kullanımını mı izliyorsunuz?
• Yeni fiyatlandırma modelleri için ROV'yi mevcut kiracılarınıza açıkça iletebiliyor musunuz?

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

• Daniel Scott-Raynsford | İş Ortağı Teknoloji Stratejisti

Diğer katkıda bulunanlar:

• Bohdan Çerçilik | Kıdemli Müşteri Mühendisi, Azure için FastTrack
• John Downs | Baş Müşteri Mühendisi, Azure için FastTrack
• Chad Kittel | Baş Yazılım Mühendisi
• Paolo Salvatori | Baş Müşteri Mühendisi, Azure için FastTrack
• Arsen Vladimirskiy | Baş Müşteri Mühendisi, Azure için FastTrack

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

Çözümünüzdeki kiracılara göre tüketimi nasıl ölçtünüzü düşünün.