Well, the market and the media spoke quickly and directly about Unity’s recent pricing changes, and my suspicions were… let’s not say I was right, shall we?
They provided carrots to go along with the stick. They increased prices in a way that was pretty easy to articulate. The increased costs kinda-sorta track to the value the software provides. Based on existing user behavior, the increased costs are modest for most customers. These are all best practices. So how did Unity screw up?
The contrarian in me suggests that this is temporary whining, and that now would be a fine time to pick up some Unity calls. Developers aren’t going to switch their in-flight efforts to Unreal if they’ve already invested modest time and effort. Gamers aren’t going to refrain from purchasing games built on Unity. And in most cases, Unity’s new install charge is still cheaper for the developer than Unreal’s revenue share.
So what gives? Why all the hate?
They’re going to charge for installs of games which have already been created and published. They’ve also been remarkably non-transparent about the mechanism by which they intend to track installs, which has created massive uncertainty.
Because Unity is charging the publisher every time the Unity runtime is installed, a malicious actor could purchase a game, then repeatedly install and uninstall it, costing the publisher $0.20 each time. They’ve walked this back; now the install fee will apply once per device. I’m curious how they’re identifying the devices to prevent abuse.
Regardless, though, the install fee is a poor choice because of how loosely it correlates to the value that Unity is providing to the publisher. I touched on this in the previous post, but I’ll admit that I hadn’t considered the malicious applications.
This is related to #1 above. Game developers signed up to use Unity to create their games with an understanding of how much it was going to cost to publish those games. Unity has unilaterally altered the deal, leaving customers to pray that they do not alter it further. This means that the innocuous and modest increase in the cost of using Unity isn’t really what customers are mad about: they’re mad that it’s arbitrary, and that they have no apparent recourse.
Because video games are interesting to laypeople, this is a topic that’ll get a lot of clicks and attention from people who aren’t directly affected. Indie developers who are already using Godot see their choice further vindicated, which is a good reason to malign Unity’s changes. Players who don’t develop games have an opportunity to talk about video games and express a negative opinion about a big company. Journalists have an opportunity to report on the players’ and indie developers’ negative feedback. Bad news leads to the publicly traded stock being sold off, which leads to yet more coverage.
Leaving pricing unchanged forever is a great way to miss out on the opportunity to grow revenue. I think it’s important to revisit pricing frequently. But there are obvious options to minimize fallout from pricing changes, and Stage is built to help.
This is the simplest answer, but in some ways the least powerful. Raising the seat price for existing customers is sometimes met with mild grumbling, but rarely with the sort of backlash Unity has experienced this week. Raising prices using the same structure and metric is easy to articulate, too: as Unity improves their software, it makes sense that they provide more value to the customer, so the customer ought to be willing to pay more. In Stage, this is as simple as changing the price in our UI.
Right now, Unity’s approach is to mandate purchasing a paid plan when some revenue threshold is reached, and to encourage adoption of more expensive plans by offering access to more powerful features. A better option would be to offer limited access to these features for the lower-priced plans. Using Stage, we can easily impose a feature usage limit, or offer a limited-time trial which grants access to a more powerful plan’s features.
This is the cause of the greatest consternation. Unity said they’d roll out the installation fee to existing games which are already in the market, which feels like a rug pull to those games’ creators. They dedicated a lot of time to making those games and getting them to market, and Unity’s new pricing means that some of them are no longer viable.
I don’t know how much revenue Unity would forego by deferring the installation fee for existing games. I suspect, however, that it’s less than a billion dollars.
Again, with Stage, this is easy: we create a copy of our existing plan, add an installation fee to be assessed against an “installs” feature, and then toggle the visibility of both plans so the new plan shows up on the pricing page and the existing plan doesn’t. Existing customers will continue to enjoy their existing pricing, while new customers will sign up under the new structure. I
I’ll admit that Stage doesn’t help with this. And perhaps Unity’s pricing council held all sorts of focus groups and paid consultants and had internal spreadsheets. Maybe they asked people who weren’t part of their user base. But given the immediate reaction of the community, I’d be surprised to hear that they’d integrated any feedback from their customers.
The changes haven’t been released yet. There’s probably no technical reason that Unity couldn’t say “oops” and refrain from imposing the installation fee. With Stage, it would take seconds to restore the old pricing structure and archive the new attempt.
The public implications, though, are different. Walking back the changes may not be enough to restore customer confidence in the predictability of pricing going forward. Using Stage, you can try a small, targeted and incremental change to pricing, and roll it back quickly without fallout from the very public announcement that’s necessary for a universal change.