For those who haven't already become inundated with the story, Unity Technologies, one of the leading game engine developers, recently went through a, shall we say, tumultuous pricing change.
The TL;DR is that on September 12th, 2023, Unity made a shift in their pricing metric for their Runtime product - the code that executes on player devices and makes 'Made with Unity' games work at scale. Historically, the price was per seat, now it will add an install based fee.
This article will dive into the proposed change, what happened as a result, why Unity may have wanted to do this, and what we can learn from their blunder.
A quick disclaimer: I have no inside knowledge of the events that have taken place, this is merely my take on the situation leveraging my experience and knowledge to make an interpretation of the events. If you disagree, or know something that counters my points, please leave a comment! I would love to discuss it. I might write a follow up based on how Unity performs early next year when changes go into effect.
So lets talk about what happened...
After the announcement post (linked here) there was severe backlash. Given the poor communication with customers, developers felt blindsided and quickly took to every platform out there to describe their displeasure. The overall sentiment is well captured here:
I've been using Unity for years, and the sudden increase in pricing is a huge blow to my budget. It feels like Unity is taking advantage of its monopoly in the market.
This quote was sourced from a forum thread on the Unity community website.
How else has that impacted Unity? The share price went from ~$38.97 on September 12 to a low point of $25.73 at the time of this article’s writing. That is an almost 35% drop 😱Oh, and their CEO had to step down.
Unity also massively changed course and adjusted their new model (linked here), effectively making the following changes:
- Unity Personal: The Unity Personal plan will remain free and there will be no Runtime Fees for games built with the plan. Annual revenue and funding limit increases from $100,000 (USD) to $200,000 (USD), and removal of the requirement to use the Made with Unity splash screen.
- Runtime Fee is forward-looking: The Runtime Fee does not apply to any games created with any currently supported Unity versions. It only applies to games created with or upgraded to the LTS version releasing in 2024 or later.
- Editor terms: Developers can stay on the terms applicable for the version of Unity being used.
- Runtime Fee, self-reported: On a monthly basis, developers have a choice of the lesser of 2.5% revenue share or the calculated amount based on unique initial engagements. Both initial engagements and revenue are self-reported.
This is a gargantuan shift, especially because they opened the door to revenue share - something they said they would never do.
So it begs the question: why did they do this?
Easiest place to start, financial statements. Previously, Unity had driven their revenue through licenses. This had been going relatively well, with quarterly revenue beating expectations in Q2 (Expected: $517.35M, Reported: $533.48M). This was in part based on a previous year price increase, with Unity noting to shareholders:
We see the impact of last year’s price increase flow through as we create more value for our customers through innovation and additional features, and we are capturing a portion of that incremental value. We plan to continue to make progress in this area across the Unity Editor and the Unity Runtime.
Nice little foreshadow there 😅
On the other hand, dollar-based retention was on the decline, having fallen from 121% to 106% over the last 12 months. This is mainly due to the stalling of the ad market, as previously cross-selling customer to their ad-platform was their major expansion play.
Lastly, as part of the core areas of risk - retention, upsell, and better integration of their recent acquisitions - Unity has been trying to figure out how to better align their revenue with their costs to grow their gross margin.
So now let’s look at the new pricing concept they tried to introduce:
To understand the impact of the new pricing we need to estimate the amount of companies in the buckets this pricing would apply to. We can use existing revenue information from the Create Solution line for this purpose.
First we identify the relevant revenue…
|Create Solution quarterly revenue
|Non-gaming segment within Create (reported: 30%)
|Professional services (estimated: 30%)
|Subscription revenue remainder
We restrict our analysis on the major Unity markets (customers over $100k reported to be 1,330)
|Customers above $100,000 (not emerging market)
Then we look at the breakdown across the plans. This is an assumption but feels like a realistic power-law like breakdown. We also have to make an assumption on the number of users per company. We do this to back into the reported revenue numbers and try to get them as close as possible.
|Hypothetical customer distribution (%)
|Hypothetical customer distribution (#)
|Average users in that category
|License fee (annualized)
|Revenue per customer (avg)
|Total revenue per tier (annual)
|Total revenue per tier (quarterly)
So…pretty close! Not bad. Now we can feel relatively good about the company size splits.
Now, let’s look at the new fees that would be added on top. For the purposes of the math, we assume an average amount actually paid for each install given that there are volume discounts at play. This only applies to the Pro and Enterprise plans.
|Runtime Fees (reported)
|Price per install (range)
|$0.01 - $0.15
|$0.01 - $0.15
|Average projected fee per install (assumed)
Here we look at total installs from last year (conservative) and make the assumption that a majority of the installs come from the most successful companies on the platform.
|Installs in 2022 (reported)
|Amount from > $100k customers (%)
|Amount from > $100k customers (#)
We then use the above average fees across the company install splits…
|Hypothetical breakdown (%)
|Resulting install distribution
|Rev per install (annual)
|Rev per install (quarterly)
Now we can compare the licensing revenue to the runtime fee revenue…
This paints a pretty clear picture. This gets close to doubling their revenue for this segment.
We need to make some allowances for what data is available and what can be estimated. I tried to use available information and then some high-level assumptions to thus align the data as closely as possible. Even with some room for error we can see that this would allow Unity to grow their revenue by a hefty amount.
Summary: Unity primarily drives revenue through their Grow and Create solutions, both of which were growing year-over-year. However, given their variable costs are mainly driven by hosting cost based on, among other things, installs, we start to understand where this new pricing is coming from.
With the new pricing model, Unity was trying to do two fundamental things:
- align their costs with their revenue metric (in this case installs) - "each time a game is downloaded, the Unity Runtime is also installed...initial install-based fee allows creators to keep the ongoing financial gains from player engagement, unlike a revenue share"
- align the revenue metric with customer value - "The Unity Runtime is code that executes on player devices and makes Made with Unity games work at scale, with billions of monthly downloads."
When we add the revenue math above, we get a very clear understanding of what was on the table for Unity: $200M a year.
Speaking to Axios, Unity exec Marc Whitten insisted that "our core point with this is simply to make sure that we have the right value exchange so that we can continue to invest in our fundamental mission to make sure that we can deliver the best tools for people to make great games."
This in theory made sense but they clearly missed out on the delivery.
A quick aside: There are some rumors going around that developers have been told they can avoid the new fees if they shift to the IronSource ad platform. It is unclear how factual this is but could provide an interesting angle, as they have been having a hard time driving the needed revenue growth in this area post-acquisition. With this, it would make sense to create a slightly undesirable pricing plan to drive customers to the new platform.
We were obviously quite concerned about the pricing announcement as it appears to specifically kill our business model.
Our unity rep is telling us "no, don't worry. you will receive credits to cover 100% of installs because you use IronSource as AD provider".
This quote was sourced from a Reddit thread on the Unity subreddit.
So what can we learn here?
We have established the what and why, now let’s look at what we can learn from Unity's experience.
I believe there are two key areas that Unity dropped the ball on:
- Aligning with their customers
- Communicating the price change
1) Aligning with their customers
Though we established a few reasons as to why Unity would want to make this change, it needs to be accepted by their customer base as well. The go-to approach here is to test a variety of options in market and gather feedback. This lets you narrow down what approach will both solve the business needs and will be accepted by the market. Though we don't know for sure if they did this, given the strong reaction it seems unlikely.
Some common research methods include:
- customer interviews and focus groups - best for early idea generation or for answering the 'why' behind certain responses
- surveys, including pricing research (e.g. conjoints) - best for getting statistically significant quantitative data and price specific trade-off insights
- live tests or experiments - best for when you want to refine a narrow set of options and want to eliminate any research biases
2) Communicating the price change
Communicating a change in price is never easy. There are a lot of different philosophies here but generally the right approach is to be transparent and lead with value. Beyond that comes the bifurcation between new and existing customers - for the existing ones, you should always contemplate some form of a migration plan.
Some common best practices for price change communication (for existing customers) are:
- focus on the value - explain the additional value you are adding, maybe tied to a product launch, and explain how this new price helps align with that
- give plenty of notice - announce when the price change goes into effect for new customers, and the longer transition timing your existing customers will have*
- put the customer in the driver’s seat - if possible, tie the new price to a product upgrade that the customer can choose, thus making the price change voluntary in return for new functionality
*note: to do this well, one needs to map out customer importance to understand how much transition time a customer should get. Low-value customers can be treated similar to new customers while high-value customers should get plenty of notice or even get grandfathered.
So remember, if you are going to make a price change:
- align the price change with value, and lead with that value
- talk to your customers, early and often
- assess the value of your current customers and adjust your rollout accordingly
Unsure about what to do about with your own pricing? Drop us a note!
Curious about Corrily and our monetization platform? Check it out here!