The Price of Understanding User Behaviour

Last updateD on

July 18, 2023

Onur Alp Soner

All-around Product Guy and CEO of Countly

As we kicked off the development of myCountly in April 2022 (I’ve talked about it in the previous post), all the parallel and very important topics, such as positioning, pricing, how we handle support, website updates, etc., started to be discussed and delved into. One of the hottest topics was, of course, the pricing strategy.

When we initially conceived myCountly several years ago, we primarily envisaged it as a developer tool, and thus designed our billable items and pricing strategy accordingly. We wanted to just give the Countly server to the user without any billable parameter, and they’d be able to use it up to the limits of the underlying server. Meaning, as long as the CPU/memory utilization of the Countly server can handle the incoming data and reporting needs, we wouldn’t force the user to upgrade to an upper-tier based on a specific metric such as monthly active users, data points, or API requests.

This approach made sense, at least at the time, because given Countly's flexibility, these different metrics didn't carry the same weight from a data processing/storage cost perspective, and none of these metrics were the primary preference of the majority of our users. In fact, our great competitors Mixpanel and Amplitude both switched between charging based on events and then to monthly tracked users and vice versa at different times, and some of their users loved it, while others hated it.

The Pricing Metric

For Countly Enterprise, data points based billing is our primary model. A data point is essentially every session, event, view, crash, feedback, performance trace, and push action ingested by the Countly Server. The reason we like using the data points metric over other things is because this metric correlates with the sizing of a Countly deployment the best, and since all of our customers have dedicated deployments self-hosted or in the cloud, it is an operationally relevant metric beyond just pricing.

The advantages of a data point or event based model are:

Deployment sizing estimation is smoother when we know this metric, since there is more data around it such as for every 5 million data points, you need 1 CPU cores and 4GB of RAM.
When we release new, large features in the Countly server, they likely contribute to the data points metric thus we don’t need to think about monetising new features, it’s naturally built in.
Maybe a rather strange item, but we can estimate our customer facing team’s (customer success managers, support engineers, devops engineers and server/SDK engineers) involvement with a customer based on their data points because it very granularly defines how much they are using Countly.

The disadvantage with the data point metric though is the fact that it is not always a straightforward metric to estimate for the customer. Most of the time, the only known metrics by them are (page) views, sessions or just events but Countly is more comprehensive than anything else given all the other touchpoints such as feedback, crash, performance, push notifications, a/b testing, remote config thus makes it harder for the customer to not only estimate the data points right now but also plan for the future.

For myCountly, the keywords for the pricing model we were after was straightforward, flexible and user-friendly. The initial idea of let’s just give the server to the user and they can use it to its upper limit didn’t make sense, as it was quite a vague proposal, especially now as we decided not to target developers only. It was flexible for sure, but it was nowhere near being straightforward or user-friendly.

The second alternative was just continuing with the Countly Enterprise model, where we price things based on data points. However, the data points model wasn’t straightforward enough for a self-serve SaaS platform, nor was it flexible enough for the target users we had in mind. This model could potentially push users to reduce their data point consumption, which would likely diminish the value they could extract from an all-in-one product analytics platform like Countly.

We finally settled with monthly active users (MAU) and differentiating some features as core and others as add-ons. MAU is a natural metric for most products. It correlates well with how the product is growing over time and naturally the revenue the product generates (if you are not a growth at all costs, unprofitable business by design 😛).

As you begin your analytics journey with a limited user base, there's a natural tendency to want a more granular level of detail, leading to higher data points. This intense data generation could become a limiting factor under some pricing models. But as your user base expands, the focus often shifts to broader user analysis. At this point, the complexity emerges from concerns about potential surges in data points if specific Countly features are enabled. This MAU model eases customer concerns over additional data points, but it presents challenges for us as a service provider. MAUs don't always directly correspond with the hosting expenses we incur for each user's dedicated Countly server. So, to manage this issue and regain some of the granularity lost by moving away from a data points pricing model, we've decided to categorize some features as core and others as add-ons. This would allows us to balance user needs with operational costs, offering a more controlled approach to feature usage and pricing.

Add-ons Model

The architecture of the Countly server is built around the concept of plugins. Currently, we have 70+ plugins, and almost all features, whether big or small, are built as such. The primary reasons behind why we implemented Countly via a plugin architecture were:

Maintenance: Being able to maintain a single core codebase, and differentiating Community and Enterprise editions based on just which plugins they contain is a breeze vs maintaining huge codebased for both Community and Enterprise editions.
Extensibility: Plugin architecture not only allowed us create features faster, but also allowed our community and customers to create their own plugins as they need. And since a plugin is a first class citizen in the Countly platform, it is fairly unlimited what you can do via a plugin.

‍

We never truly ventured into selling individual plugins included in Countly Enterprise. Several years ago, we experimented with the concept of differentiating Countly Enterprise Analytics Edition and Countly Enterprise Marketing Edition by including additional plugins, such as push notifications and attribution, in the Marketing Edition. However, we quickly realised that introducing another variable into the customers' purchasing decision was unnecessary, so we reverted to positioning Countly Enterprise as the ultimate edition of the Countly server, inclusive of all the features we have to offer.

However, in myCountly, as we decided on monthly active users being our billing metric, we decided to make some of the features and feature groups add-ons. We have iterated over this list and probably it is still not final, however as of now this is the list of add-ons we’ll provide with an additional fee:

Server region: Cheapest region in most cloud providers, including our initial cloud provider of choice, Google Cloud, is USA. We’ll charge an additional varying fee for the other regions including Brazil, Canada, Israel, Switzerland, England, France, Germany, Belgium, Australia, Singapore, Hong Kong and India.
Features and feature groups: Push Notifications, Remote Configuration and A/B Testing, Crash Analytics and Performance Monitoring, Voice of the Customer (Surveys, NPS and Ratings), Hooks, Formulas, Database Viewer
Custom domain and SSL: Users will be able to customize the SSL certificate and domain of their Countly server.
Data retention: All servers will come with a 6 month data retention configuration by default, and this will be extendable to 12 months, 24 months or 36 months.

Freemium vs. Free Trial

When considering the pricing model for myCountly, one of the major debates centered around the choice between a Freemium model and a Free Trial model. These two approaches are widely used in the SaaS industry, and both come with their own merits and demerits.

The Freemium model, where a basic version of the service is offered for free with more advanced features or services available for a fee, can be highly effective at lowering barriers to adoption and gaining rapid user growth. With a Freemium model, potential users can try out the product at their own pace without any time constraints, which allows for deeper engagement and exploration. However, the flip side to Freemium is the risk of devaluing the product or service and potentially making it harder to convert free users to paying customers. Furthermore, the cost of supporting a potentially large base of free users can become substantial, especially in our case given we provide users with dedicated servers.

On the other hand, a Free Trial model, where potential customers can use the full-featured product or service for a limited period before they need to start paying, can create a sense of urgency which can help accelerate the decision-making process. This model can be especially beneficial when the product's value proposition is immediately clear and the users are able to experience the full benefits within the trial period. But the downside is, once the trial period ends, the user might leave if they didn't find enough value, or they simply didn't have enough time to fully explore and understand the product.

I don’t think we can nail this decision without looking at any data of our own, but to begin with we decided to go with the Freemium model. We’ll have a free tier, that’ll allow everyone to get started with myCountly at their own pace, and possibly get started with product analytics at their own pace and as they grow out of the capabilities and usage limits of the free tier they continue their journey with us.

What’s the Starting Price?

Determining the starting price was yet another important element in our pricing strategy. We wanted to strike the perfect balance where the pricing would reflect the value provided by our product, but also be affordable enough to attract and accommodate a wide range of customers, from startups to established businesses.

Since myCountly has a tiered pricing structure, based on the monthly active users, the starting price pretty much affects everything else, so it is very critical. At this point, we are still playing around with the number, but we have an aim of keeping the first tier after the free tier in the 50-100 USD per month range. This range reflects our commitment to providing an accessible and affordable analytics solution without compromising on the depth and quality of features offered. It also allows for ample room for growth as your user base expands and your analytics needs become more complex.

Pricing, however, is a very dynamic topic. It's definitely an area where we will be collecting substantial amounts of quantitative and qualitative data in order to make informed, swift decisions. This is actually why we devoted significant attention to this aspect while developing myCountly. We wanted to explore how we could handle pricing dynamically, from testing different pricing strategies for different user groups to versioning/grandfathering prices. We outlined what we aim to test in the near future while implementing our billing engine.

Countly’s Product-Led Story

In my next post, I plan to delve into our thought process behind the positioning of myCountly. In fact, part of that discussion will involve why we are deciding to rename myCountly. I realize I deviated from my promise in the last post about focusing on engineering, but I believe this change of course has been a beneficial one. I hope you found this post both interesting and insightful.

Please join us in our journey as we share unfiltered behind the scenes, lessons learned, the moments that make us suffer and the ones that make it all worthwhile as we continue building a product-led SaaS.