Some of you have asked us questions about how we plan to price AFCS. Through this blog post we'd like to better understand your preferences and opinions and provide enough context for you to map our proposed pricing models to your business plan and monetization approaches. Please take a moment to review our proposal and provide feedback.
Our overall approach to determining the AFCS pricing models is built on four key tenets:
* No Barriers To Adoption: There will be no upfront one-time fees to use AFCS and we will continue to provide free quotas to enable developers to quickly build AFCS-powered applications. Pricing will kick-in only when the free quotas are exhausted.
* Pay-Per-Use: The price you pay to Adobe will be determined a-posteriori; in other words, looking back at the billing period we will determine your total bill based on your usage of the service. We will not force you to commit to a certain number of users or amount of usage.
* Predictability And Control: You can set the maximum bill per billing period you'd like to receive from Adobe. In other word, you don't need to have sleepless nights worrying about a "runaway application" cranking the AFCS billing meters. One of the disadvantages of a-posteriori pricing is that you typically have little, if any, control over your final bill (E.g., monthly utility bill.) We are erasing this concern by introducing the notion of maximum bill per billing period.
* Options And Flexibility: To ensure that AFCS appeals to a broad cross-section of developers and use-cases, in the long term, we plan to offer more than one pricing model. Factors such as application type (Bandwidth intensive, Message intensive, Connection-time intensive, etc.) and entity type (Individual developer, ISV, Enterprise, etc.) can greatly influence pricing model preferences. The implication is that as a developer you'll have the opportunity to select the pricing model that best meets your needs. In fact our plan is to eventually allow you to attach different pricing models to your various applications.
So based on these four key tenets we have came up with three pricing models. Let's now review how each of these pricing models would work and their relative merits:
1. Resource Utilization: Today, through the public beta program, we impose restrictions on the number of concurrent users, bandwidth (in + out), connection time / cumulative user minutes, and number of published messages. In the Resource Utilization model we would remove limits on the number of concurrent users and charge along any two, or all three, dimensions of bandwidth, connection time, and messages. We expose application usage along these three dimensions through the Developer Portal and to some extent through the Developer Console. So today you can monitor and estimate usage - and at the time of AFCS commercial launch estimate expected price - by simply analyzing usage over a period of time. We think that the Resource Utilization model will appeal to individual developers and mid-size and smaller ISV's who plan to build new applications where it is hard to predict the success [users or usage] of your application. Predictability will be provided by allowing developers to set a "Max Monthly Bill" and developers can rest assured that they wouldn't end up paying more than what they had originally planned / budgeted for.
ﾠ
2. Peak Concurrent Users: Some developers may find it hard to estimate usage of their application, especially the AFCS-powered components such as chat and webcam video. For example, it may be tough to get answers to questions like how many users will engage in a text / audio / video chat session; how long (number of minutes) will sessions last; or how many chat messages will be exchanged between users. In addition, there is a segment of developers that plans to deploy applications to a known quantity of users such as an internal application targeted at full-time employees in a company. In such situations a developer can approximately estimate the number of users over time. In the peak concurrent users pricing model we align our pricing to the success of your application by allowing you to plan expenses and budgets based on peak user loads. Furthermore to ensure that we protect developers against sudden spikes we can charge based on - just as an example - 95% of peak concurrent users or allow developers to set a maximum number of peak concurrent users per application. Obviously, to ensure that we don't cause our service to come to a grinding halt we'll put some really large usage caps on peak concurrent user accounts that will protect us against runaway applications.
3. Subscription Tiers: Subscription Tiers pricing model offers about three subscription tiers, each of which correspond to specific quotas for bandwidth, connection time, and number of messages. This is still a pay-per-use pricing model as developers always start from the lowest subscription tier and if usage during the billing period crosses quotas of the existing tier by more than, as an example, 5% of allotment then we automatically bump you into the next tier. Higher tiers correspond to higher quotas but lower unit price per quota dimension. Once you are bumped into a higher tier you will be billed accordingly unless usage drops to lower tiers for two consecutive billing periods.
Caution: Please note that we are still working through the details and Adobe reserves all rights to launch any combination of these pricing models, including never launching some of these proposed pricing models. Our goal is to prioritize these options and make available only those that appeal the most to you. So here you go... Please take our quick, less than "60 second" survey and vote for your preferred pricing model. We welcome any additional comments in the survey. Click here to take survey. Note: If you are developing multiple applications and think that there is an application that will be better monetized via one type of pricing model and another through some other model then please complete the survey twice - once for each application.
Also, as a heads-up we'd like to let you know that next month we will follow up with a more robust survey on pricing [... to get a read on actual price points] so please keep an eye out on our blogs as we'd very much appreciate your participation. One thought I'd like to leave you with is that any pricing model Adobe implements needs to be competitive relative to comparable offerings in the marketplace and needs to reflect the value-add we provide with AFCS to the developer community.
* If you're a developer who's ready to launch a commercial offering in the next couple of months, please email us a brief description of your application, commercial launch timeline, and proposed monetization / pricing model for your application and we will contact you to discuss how we could potentially support your near-term commercialization plans*
Varun
