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

İyi bir fiyatlandırma modeli, kiracının sayısı büyüdükçe ve yeni özellikler eklerken karkalabilmenizi sağlar. Ticari çok kiracılı bir çözüm geliştirilirken önemli bir göz önünde bulundurmanız gereken, ürün için fiyatlandırma modellerini nasıl tasarlayaöğreneceksiniz. Bu sayfada, göz önünde bulundurmanız gereken fiyatlandırma modelleriyle ilgili teknik karar mekanizmalarının yanı sıra söz konusu avantajları sunuyoruz.

Ürününüz için fiyatlandırma modelini belirlediğinizde, hizmeti teslim etmek üzere satılan malların (SMM) maliyetlerine sahip müşterilerinize ait değer (ROV) değerini dengelemenize gerek duyarsınız. Daha esnek ticari modeller (bir çözüm için) sunmak, müşteriler için ROV 'yi artırabilir, ancak çözümün mimari ve ticari karmaşıklığını da artırabilir (ve bu nedenle, SMM 'nizi de artırır).

Bir çözüme yönelik fiyatlandırma modellerini geliştirirken dikkate almanız gereken bazı önemli noktalar aşağıdaki gibidir:

• SMM, çözümden kazandığınız karın daha yüksek olacak mı?
• Kullanıcı veya kullanım desenlerindeki değişikliklere göre, SMM zaman içinde değişiklik yapabilir mi?
• Fiyatlandırma modelini çalıştırmak için gereken bilgileri ölçmek ve kaydetmekne kadar zordur? Örneğin, müşterilerinizin yaptıkları API çağrılarının sayısına göre faturalandırılmaları planlanıyorsa, her müşteri tarafından yapılan API çağrılarını nasıl ölçtireceksiniz tanımladınız mı?
• Kârlarınız, müşterilerin çözümünüzü sınırlı bir şekilde kullanmasına olanak sağlar mi?
• Bir müşteri çözümü daha fazla kullandığında, artık bu kadar heyecanlıyordu demektir mi?

Kârları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 karara olacağını etkileyebilir.
• Hizmet kullanım desenleri. Kullanıcıların yalnızca çalışma saatleri sırasında çözümünüze erişmesi veya yalnızca küçük bir yüksek hacimli Kullanıcı yüzdesi olabilir. Kullanımınız azaldığında, kullanılmayan kapasiteyi azaltarak SMM 'nizi azaltabilirsiniz misiniz?
• Depolama büyüme. Çoğu çözüm verileri zaman içinde biriktirir. Daha fazla veri depolamak ve korumak, kiracı başına karlılığını azaltmak için daha yüksek bir maliyet anlamına gelir. Depolama kotaları ayarlayabilir veya bir veri saklama süresi uygulayabilir miyim?
• Kiracı yalıtımı. Kullandığınız kiracı modeli , kiracılar arasında sahip olduğunuz yalıtımın düzeyini etkiler. Kaynaklarınızı paylaşıyorsanız, kiracının hizmeti nasıl aşırı kullanacağınızı veya kötüye kullanım dışı olduğunu göz önünde bulundurmanız gerekir mi? Bu, SMM 'nizi ve herkes için performansı nasıl etkiler? Bazı fiyatlandırma modelleri, kaynak ayırma etrafında ek denetimler olmadan karlı değildir. Örneğin, bir düz hızlı fiyatlandırma modelinin sürdürülebilmesini sağlamak için hizmet azaltma uygulamanız gerekebilir.
• Kiracı yaşam döngüsü. Örneğin, yüksek müşteri dalgalanmasına sahip çözümler veya daha büyük bir taslak çaba gerektiren hizmetler, daha düşük olan ve özellikle de tüketim tabanlı bir model kullanılarak fiyatlandırıldıklarında kârlığına zarar verebilir.
• Hizmet düzeyi gereksinimleri. Daha yüksek düzeyde hizmet gerektiren kiracılar, çözümünüzün artık karara olmadığı anlamına gelebilir. Fiyatlandırma modellerinizi uygun şekilde planlayabilmeniz için müşterilerinizin hizmet düzeyi beklentileri ve sahip olduğunuz yükümlülüklerle ilgili net bir önemi vardır.

Ortak fiyatlandırma modelleri

Çok kiracılı çözümlerle yaygın olarak kullanılan birkaç genel fiyatlandırma modeli vardır. Bu fiyatlandırma modellerinin her biri, ticari avantajlar ve riskler içerir ve ek mimari hususlar gerektirir. Bu fiyatlandırma modelleri arasındaki farklılıkları anlamak önemlidir. böylece, çözümünüzün geliştikçe daha fazla kalabilmesini sağlayabilirsiniz.

Tüketim tabanlı fiyatlandırma

Tüketim modeli bazen Kullandıkça Ödeveya PAYGolarak adlandırılır. Hizmetinizin kullanımı arttıkça, gelirinizi artırır:

Tüketimi ölçmenizde, çözüme eklenen veri miktarı gibi basit faktörleri düşünebilirsiniz. Alternatif olarak, kullanım özniteliklerinin bir bileş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, bu modelin girişe düşük bir engeli olması için çözümünüzü kullanmak için gereken en az ön yatırım vardır. Hizmet operatörü olan perspektifinizden, barındırma ve yönetim maliyetleriniz müşterilerinizin kullanımı ve gelirinizi artmış olarak artar. Bu artış, yüksek oranda ölçeklenebilir bir fiyatlandırma modeli yapabilir. Tüketim fiyatlandırma modelleri, çözümde kullanılan Azure Hizmetleri tüketim tabanlı olduğunda özellikle iyi çalışır.

Karmaşıklık ve operasyonel maliyet: Tüketim modelleri, kullanımın doğru ölçülerine ve bu kullanımı kiracının bölünmesini kullanır. Bu, özellikle birden çok dağıtılmış bileşeni olan bir çözümde bu zor olabilir. Faturalandırma ve denetim için ayrıntılı tüketim kayıtları tutmanız gerekir.

Riskler: Tüketim fiyatlandırması, maliyetleri azaltmak için müşterilerinizi sisteminizin kullanımını azaltmak için kullanabilir. Ayrıca, tüketim modelleri öngörülemeyen gelir akışlarına yol açabilir. Müşterilerin belirli bir tüketim düzeyi için ödeme yaptığı Kapasite ayırmalarısunarak bunu azaltabilirsiniz. Hizmet sağlayıcısı olarak, işletimsel maliyeti azaltmak ya da özellikler ekleyerek değerin döndürdüğü değeri artırmak için bu geliri, çözümdeki geliştirmeleri yatırım için kullanabilir.

Kullanıcı başına fiyatlandırma

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

Kullanıcı başına fiyatlandırma modelleri, çok kiracılı bir çözümde uygulanması açısından kolaylık olması nedeniyle oldukça yaygındır. Ancak, bunlar çeşitli ticari risklerle ilişkilendirilir.

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

Karmaşıklık ve operasyonel maliyet: Kullanıcı başına modellerin uygulanması çok kolay. Ancak bazı durumlarda, tek bir kullanıcı için SMM 'nin karlı kalmasını sağlamanıza yardımcı olabilecek Kullanıcı başına tüketimi ölçmenize gerek duyarsınız. Tüketimi ölçerek ve belirli bir kullanıcıyla ilişkilendirerek, çözümünüzün işletimsel karmaşıklığını artırabilirsiniz.

Riskler: Farklı Kullanıcı tüketimi desenleri, azaltılan karlılık oluşmasına neden olabilirler. Örneğin, çözümün ağır kullanıcıları, hafif kullanıcılardan daha fazla ücret verebilir. Ayrıca, çözüme yönelik gerçek dönüş değeri (ROV), satın alınan gerçek kullanıcı lisansı sayısına yansıtılmaz.

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

Bu model, Kullanıcı başına fiyatlandırmayabenzer, ancak müşterinin beklenen kullanıcı sayısına göre ön taahhüt gerektirmesi yerine, müşterinin yalnızca bir dönem içinde (Aşağıdaki diyagramda gösterildiği gibi) çözümü kullanması için ücret ödersiniz.

Bunu, herhangi bir dönemde mantıklı hale getirebilirsiniz. Aylık dönemler yaygındır ve bu ölçüm genellikle aylık etkin kullanıcılar veya Mauolarak kaydedilir.

Avantajlar: Müşterilerinizin perspektifinden, bu model düşük bir yatırım ve risk gerektirir; çünkü en az atık olabilir. kullanılmayan lisanslar faturalandırılabilir değildir. Bu, çözümü pazarlama veya daha büyük kurumsal müşterilere yönelik çözümü büyümekte oldukça çekici hale getirir. Hizmet sahibi olarak bakıldığında, ROV 'niz, aylık etkin kullanıcı sayısına göre müşteriye daha doğru yansıtılır.

Karmaşıklık ve operasyonel maliyet: Etkin Kullanıcı modelleri, gerçek kullanımı kaydetmenize ve faturanın bir parçası olarak bir müşteri tarafından kullanılabilmesini sağlamak için gereklidir. Kullanıcı başına tüketimi ölçmek, karlılık tek bir kullanıcı için SMM ile korunmasını sağlamaya yardımcı olur, ancak yeniden her bir kullanıcı için tüketimi ölçmek üzere ek iş gerektirir.

Riskler: Kullanıcı başına fiyatlandırma gibi, bireysel kullanıcıların farklı tüketim desenlerinin kârlarınızı etkileyebileceğini bir risk vardır. Kullanıcı başına fiyatlandırmayla karşılaştırıldığında, etkin kullanıcı modelleriyle daha az öngörülebilir bir gelir akışı vardır. Ayrıca, indirimli fiyatlandırma , büyüme artışına yönelik kullanışlı bir yol sağlamaz.

Birim başına fiyatlandırma

Birçok sistemde Kullanıcı sayısı, genel SMM üzerinde en büyük etkiye sahip olan öğe değildir. Örneğin, nesnelerin interneti veya IoTolarak da adlandırılan cihaz odaklı çözümlerde, cihazların sayısı genellikle SMM üzerinde en büyük etkiye sahiptir. Bu sistemlerde, bir birimin ne olduğunu bir cihaz gibi tanımladığınız birim başına fiyatlandırma modeli kullanılabilir. Aşağıdaki diyagrama bakın.

Ayrıca, bazı çözümlerin çok sayıda kullanıcının SMM üzerinde orantısız etkisi olduğu büyük ölçüde değişken kullanım desenleri vardır. Örneğin, blok ve Mortar perakendecilere satılan bir çözümde, mağaza başına fiyatlandırma modeli uygun olabilir.

Avantajlar: Bireysel kullanıcıların SMM üzerinde önemli bir etkisi olmadığı sistemlerde, birim başına fiyatlandırma, sistemin nasıl ölçeklendirilediğinin ve SMM 'nin ortaya çıkan etkisini göstermek için daha iyi bir yoldur. Ayrıca, bir müşteri için gerçek kullanım desenlerinin hizalamasını iyileştirebilir. Her cihazın öngörülebilir 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: Genellikle, birim başına fiyatlandırmanın uygulanması kolaydır ve oldukça düşük bir işlem maliyetine sahiptir. Ancak, kullanım maliyeti, cihazları veya perakende mağazaları gibi ayrı birimlere göre ayrım yapmak ve bunları izlemek gerektiğinde daha yüksek hale gelebilir. Birim başına tüketim ölçme, tek bir birim için SMM belirleyebileceğinizden, karlarınızın korunduğundan emin olmanıza yardımcı olur.

Riskler: Birim başına fiyatlandırma modelinin riskleri, Kullanıcı başına fiyatlandırmayla benzerdir. Bazı birimlere göre farklı tüketim desenleri, bazı cihazlar ya da mağazaların çözüme göre çok daha ağır olması gibi azaldığı anlamına gelebilir.

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

Çözümünüzü farklı fiyat noktalarında farklı işlevsellik katmanlarında sunmayı tercih edebilirsiniz. Örneğin, biri kullanılabilir özelliklerin bir alt kümesiyle birlikte temel bir teklif olmak üzere iki aylık sabit fiyat veya birim başına fiyat sağlayabilir ve diğer bir deyişle çözüm özelliklerinin kapsamlı kümesini sunar. 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 sunabilir, ancak Premium bir katman% 99,99 sağlayabilir. Daha yüksek hizmet düzeyi sözleşmesi (SLA), daha yüksek kullanılabilirlik hedeflerinietkinleştiren hizmetler ve özellikler kullanılarak uygulanabilir.

Bu model ticari açıdan yararlı olsa da, yetişkinlere yönelik mühendislik uygulamalarının iyi bir şekilde yapılmasını gerektirir. Dikkatli bir göz önünde bulundurarak bu model çok etkili olabilir.

Avantajlar: Özellik tabanlı fiyatlandırma genellikle müşterilere göre çekici olduğundan, ihtiyaç duydukları özellik kümesi veya hizmet düzeyine göre bir katman seçiyor. Ayrıca, müşterilerinize ihtiyaç duyan yeni özelliklerle veya daha yüksek dayanıklılık sağlayan açık bir yol sağlar.

Karmaşıklık ve operasyonel maliyet: Özellik tabanlı fiyatlandırma modelleri, çözümünüzün her bir fiyat katmanında kullanılabilen özelliklerden haberdar olmasını gerektirdiğinden, uygulanması karmaşık olabilir. Özellik geçiş işlevleri, bazı işlevsellik alt kümelerine erişim sağlamak için etkili bir yol olabilir, ancak bu devam eden bakım gerektirir. Ayrıca, test etmek için daha fazla kod yolu olacağı için, geçiş, yüksek kaliteli güvence 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şletimsel 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 değiştirme özellikleriyle ilgili ek yük, ek özellikler sunma hızını düşürebilir.

Freemıum fiyatlandırması

Temel işlevsellikten ve hizmet düzeyi garantisi olmadan hizmetinizin ücretsiz bir katmanını sunmayı tercih edebilirsiniz. Daha sonra ek özellikler ve resmi bir hizmet düzeyi sözleşmesi (Aşağıdaki diyagramda gösterildiği gibi) ile ayrı ücretli bir katman sağlayabilirsiniz.

Ücretsiz katman, zaman sınırlı bir deneme sürümü olarak da sunulabilir ve deneme süresinde müşterileriniz tam veya sınırlı işlevlere sahip olabilir. Bu, özellik tabanlı fiyatlandırma modelininuzantısı etkin bir şekilde olan freemıum modeli olarak adlandırılır.

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

Karmaşıklık ve operasyonel maliyet: Tüm karmaşıklık ve operasyonel maliyet sorunları, özellik tabanlı fiyatlandırma modelinden geçerlidir. Ancak, ücretsiz kiracıların yönetilmesi ile ilgili operasyonel maliyeti de göz önünde bulundurmanız gerekir. Eski kiracıların offboarded veya kaldırılmış olduğundan emin olmanız gerekebilir ve özellikle de ücretsiz kiracılar için açık bir bekletme ilkeniz olması gerekir. Bir kiracıyı ücretli bir katmana yükseltirken, daha yüksek SLA 'Ları elde etmek için kiracıyı Azure hizmetleri arasında taşımanız gerekebilir.

Riskler: Kiracılar için, ücretli bir katmana geçiş yapmak üzere yeterince yüksek sayıda ROV sağladığınızdan emin olmanız gerekir. Ayrıca, çözümünüzü ücretsiz katmanda müşterilere sağlama maliyeti, ücretli katmanlarda olan kar marjına göre ele alınması gerekir.

Düz hızlı fiyatlandırma

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

Bu en basit modeldir ve müşterilerin anlaşılması ve genellikle kurumsal müşteriler tarafından istenir. Ancak, yeni özellikler eklemeye devam etmeniz veya kiracı tüketimi ek bir gelir olmadan artıyorsa, bu, kolayca karlı hale gelebilir.

Avantajlar: Sabit hızlı fiyatlandırma, satış için kolaydır ve müşterilerinizin için anlaşılması ve bütçesini kolayca sağlar.

Karmaşıklık ve operasyonel maliyet: Faturalandırma müşterileri herhangi bir ölçüm veya izleme tüketimi gerektirmediğinden, düz hızlı fiyatlandırma modelleri kolayca uygulanabilir. Ancak, gerekli olmasa da, SMM 'nin doğru şekilde ölçülmesini ve karlarınızın korunduğundan emin olmak için kiracı başına tüketimi ölçmenize önerilir.

Riskler: Çözümünüzü yoğun olarak kullanan kiracılar varsa, bu fiyatlandırma modelinin karlı olması kolaylaşır.

İndirim fiyatlandırması

Fiyatlandırma modelinizi tanımladıktan sonra, incentivize için indirim fiyatlandırması aracılığıyla ticari stratejiler uygulamayı tercih edebilirsiniz. İndirim fiyatlandırması tüketim, Kullanıcı başına ve birim başına fiyatlandırma modelleriyle kullanılabilir.

Genel indirim fiyatlandırma desenleri şunları içerir:

• Sabit fiyatlandırma. Satın alınan veya tüketilen her bir Kullanıcı, birim veya tüketim miktarı için aynı maliyetiniz vardır. Bu en basit yaklaşımdır. Bununla birlikte, çözümünüzü yoğun olarak kullanan müşteriler bir indirim yaparak ölçeklendirmenin ekonomisinden faydalanmaları gibi bir fikir olabilir.
• Digressive fiyatlandırması. Müşteriler daha fazla birim satın alarak veya tükettiği sürece birim başına maliyeti azaltmış olursunuz. Bu, müşterilere daha ticari açıdan etkileyici.
• Adım fiyatlandırması. Müşteriler daha fazla satın alarak birim başına maliyeti azaltmış olursunuz. Ancak, bu şekilde, önceden tanımlanmış miktar aralıklarına göre adım değişikliklerini yapabilirsiniz. Örneğin, ilk 100 Kullanıcı için daha yüksek bir fiyat ücreti, daha sonra 101-200th kullanıcısına daha düşük bir fiyat üzerinden ücretlendiriyorsunuz ve bundan sonra daha düşük bir fiyata sahip olabilirsiniz. Bu, daha fazla 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 bir üretim dışı ortama erişim gerektirir. Üretim dışı ortamlar genellikle daha düşük tüketim gereksinimlerine ve maliyetlere sahip olur. Örneğin, üretim dışı ortamlar genellikle hizmet düzeyi sözleşmelerine (SLA) tabi değildir ve oran limitleri daha düşük değerlerde ayarlanabilir. Ayrıca, Azure hizmetlerinize yönelik daha Agresif Otomatik ölçeklendirmeyi de düşünebilirsiniz.

Aynı şekilde, müşteriler genellikle üretim dışı ortamların üretim ortamlarından çok önemli bir şekilde karşılaşmasını bekler. Üretim dışı ortamlar sağladığınızda uygun olabilecek çeşitli alternatifler vardır:

• Ücretli müşteriler için zaten yaptığınız gibi freemıum katmanısunun. Bazı kuruluşlar birçok test ve eğitim ortamı oluşturmasının yanı sıra, çalışması gereken ek kaynakları kullanacak şekilde bu dikkatle izlenmelidir.

  Not

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

• Daha düşük kullanım limitleriylehizmetinizin bir testini veya eğitim katmanını sunun. Bu katmanın kullanılabilirliğini, zaten ücretli bir kiracıya sahip olan müşterilerle kısıtlamayı tercih edebilirsiniz.
• Üretim dışı kiracılar için, daha düşük veya hizmet düzeyi anlaşmasıyla indirimli Kullanıcıbaşına, Etkin Kullanıcıveya birim başına fiyatlandırma olanağı sunar.
• Sabit ücret fiyatlandırmasıkullanan kiracılar için, üretim dışı ortamlar, sözleşmenin bir parçası olarak üzerinde anlaşmış olabilir.

Karlı fiyatlandırma modelleri

Karlı olmayan bir fiyatlandırma modeli, servisi kazandığınız gelirden daha fazla teslim etmek için size daha fazla maliyet sağlar Örneğin, hizmetiniz için herhangi bir sınır olmadan, kiracı başına bir sabit ücret ödemenize karşın, hizmetinize, kiracının kullanım sınırlarıolmadan, tüketim tabanlı Azure kaynaklarıyla derleyebilirsiniz. Bu durumda, Kiracılarınızın hizmetinizi daha fazla kullanma riski olabilir ve bu nedenle onlara hizmet vermeye neden olabilirsiniz.

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

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

Farkında olmayan bir fiyatlandırma modeli oluşturmanız durumunda bunlarla ilişkili riskleri hafifletmek için bazı yollar vardır; örneğin:

• Kullanım sınırlarıaracılığıyla hizmetin kullanımını sınırlayın.
• Kapasite ayırmalarının kullanılmasını gerektir.
• Kiracının daha yüksek bir özellik veya hizmet katmanına taşınmalarını talep etme.

Riskli fiyatlandırma modelleri

Bir çözüm için fiyatlandırma modeli uygulanırken, genellikle bunun nasıl kullanılacak olduğuyla ilgili varsayımlarda bulunarak bunu yapmak zorunda oluruz. Bu varsayımların yanlış olduğu ortaya çıkıyorsa veya kullanım düzenleri zaman içinde değişirse, fiyatlandırma modeliniz kar amacı gütmeyen hale geldi. Kar amacı gütmeyen hale dönüşme riski olan fiyatlandırma modelleri riskli fiyatlandırma modelleri olarak bilinir. Örneğin, kullanıcıların çözümlerinizi kullanma miktarını kendi kendine sınırlamalarını beklediğiniz bir fiyatlandırma modelini benimsersanız, riskli bir fiyatlandırma modeli uygulanmış olabilir.

Çoğu SaaS çözümü düzenli olarak yeni özellikler ekler. Bu, ROV'un kullanıcılara artmasına neden olur ve bu da çözümün kullanılma miktarında artışa neden olabilir. Bu durum, yeni özelliklerin kullanımının kullanımı zorlaştırması ancak fiyatlandırma modelinin bunu çarpanlara katmaması sonucunda, doğrulanamayan bir çözüme neden olabilir.

Örneğin, çözümünüze tüketim tabanlı bir kaynak kullanan yeni bir video yükleme özelliği sunarsanız ve bu özelliğin kullanıcı tarafından benimsendikten sonra kullanım sınırlarının ve özellik ile hizmet düzeyi fiyatlandırmanın bir birleşimini göz önünde bulundurabilirsiniz.

Kullanım sınırları

Kullanım sınırları, fiyatlandırma modellerininprofiye edilemez hale dönüşerek 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 sağlar. Bu durum özellikle tek bir kiracının kaynakları fazla tüketerek diğer kiracıların deneyimini etkileyeceği çok kiracılı hizmetlerde önemli olabilir.

Kullanım sınırları genellikle daha yüksek katmanlarda dahayüksek miktarda kullanım sağlamak için özellik ve hizmet düzeyi fiyatlandırması ile birlikte kullanılır. Sınırlar, 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. Bu, azaltma olarak da adlandırılır. Hız sınırları sürekli aşırı aşırıyı önler. Bunlar genellikle tanımlı bir süre 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ılsa ve daha sık çağrılsa HTTP 429 hatası döndürür.

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

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

Hız sınırlama uygulamak çözümün karmaşıklığını artırabilir, ancak Azure API Management hız sınırı ilkeleri uygulayarak bunu kolaylaştırabilir.

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

Çözümle ilgili diğer kısımlarda olduğu gibi fiyatlandırma modellerinin de bir yaşam döngüsü vardır. Uygulama zamanla geliştikçe fiyatlandırma modellerinizi de değiştirmeniz gerekir. Bu, değişen müşteri ihtiyaçları, ticari gereksinimler veya uygulamanız içindeki işlevlerde yapılan değişikliklerle yönlendirebilir. 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 düz fiyat modeli sunan bir çözüme tüketim fiyatlandırma modeli ekleme.
• Mevcut bir fiyatlandırma modelini geri alma.
• Mevcut fiyatlandırma modeline katman ekleme.
• Mevcut fiyatlandırma modelinde bir katmanı geri alma.
• Fiyatlandırma modelinde bir özellikte kullanım sınırlarını değiştirme.
• Özellik ve hizmet düzeyi fiyatlandırma modelinden özellik ekleme veya kaldırma.
• İşletmeden tüketiciye (B2C) ticari modelden işletmelere (B2B) ticari modele değiştirme. Daha sonra bu değişiklik, iş müşterileriniz için yeni fiyatlandırma yapılarını zorunlu tutulmaktadır.

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

Fiyatlandırma modellerini değiştirirken aşağıdaki faktörleri dikkate alamalısiniz:

• Kiracılar yeni modele geçiş yapmak 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ılabilirliklerden koruyan hız sınırlarını kaldır mı çıkarsınız?
• Kiracıların yeni fiyatlandırma modeline taşımak için net bir yolu var mı?
• Kiracıların eski fiyatlandırma modellerini kullanmalarını nasıl önlersiniz?
• Kiracılar, fiyatlandırma modellerini değiştirerek faturanın değişmesine (beklenmeyen faturalara olumsuz tepki) sahip olma olasılığı yüksek mi?
• Yeni veya değiştirilmiş fiyatlandırma modelleri için hizmetlerinizin performansını ve kullanımını izliyor musunuz, böylece kârlılığı sürdürebilir misiniz?
• Yeni fiyatlandırma modelleri için ROV'ları mevcut kiracılara açıkça iletebilir misiniz?

Sonraki adımlar

Çözümünüzde kiracılara göre tüketimi nasıl ölçtüyülür?