Two and a half years ago, we decided to pivot from a third to first-party data analytics strategy, a decision that is now delivering benefits far beyond our initial modest goal of trying to make our existing games better.
What we have today is a full enterprise-grade cloud publishing platform called Autonomy, completely bespoke to our needs. This gives us full visibility of mission critical operations, encompassing live ops, game data, ad revenue and UA, ROAS and content delivery.
At its most granular, the platform enables collected data from each individual player to be used to deliver optimised game experiences for that same individual.
Sure, there are a few hoops you'll need to jump through to get to that point, but it's a process that should be embraced rather than feared. Why? Because with mobile platforms locking down their end-user data under the auspices of privacy, the games industry is about to experience a tectonic shift towards 'first-partying' its data whether it wants to or not, especially within the mobile and F2P segments.
This, in my view, means all studios and publishers could benefit from some degree of first partying.
So why did we decide to move to first-party data? Well, we had a lot of different games using a lot of different third-party services: game engines, analytics platforms, content delivery solutions, cloud stores and ad mediators. On top of that, there were many games we developed for other people, and we had a mix of licensed and original IPs too.
Fundamentally, there was a lack of consistency in how our games were created, deployed and managed.
As our questions became more complex, we began adding more third-party platforms. And here's the thing: every single one of them has its own methodology, logic and way of reporting
Then along came Lemmings Mobile, which we launched in December 2018: iconic IP, regular new DLC drops and player tournaments. We set about identifying areas of improvement in the game and realised we needed to understand our players more. We had so many questions and not many answers. So, we needed... data. A lot of data.
Initially, third-party data solutions worked really well for us. And I want to stress that there is absolutely nothing wrong with that approach. There are great providers out there who will give you much of what you need, right out of the box.
But as our questions became more and more complex, we began adding more and more third-party platforms to our mix. And here's the thing: every single one of them has its own methodology, its own logic and its own way of reporting.
We persevered, but eventually frustration began to manifest about the efforts required to assemble the numbers for meaningful internal and external discussions.
We had to do something different, so in December 2019, a year after Lemmings launched, we decided to build our own live ops solution.
If you choose to go down a similar path the key question is: What do you really want to know and do? We established three pillars for our own project:-
1/ Single source of truth: You are going to be making extremely important decisions based on the data you're looking at. We need data that's granular and precise as can be without inherent or forced limitations. And it needs to be long-lasting -- we knew this piece of technology needed to survive all the other solutions as well as the games it would help create, and repeat the process over and over again.
2/ Adaptability: Of course, if you want something to last a long time, it has to be adaptable. It has to be open and reactive. The market will continue to evolve. Technology will continue to evolve. We wanted all our dashboards to be always accessible to everyone internally, perfectly transparent and very fast, which means real-time data. And it needs to scale as your company and its catalogue grows.
3/ Masters of your destiny: Your solution needs to be able to deliver from game inception to sunset; from Day One with new titles and with historical data for older games. It needs to be the ultimate business booster, to have a measurable impact on operations so that it gives value out of its cost.
Once we had our pillars, we picked our team and chose the underlying technologies that we wanted to build Autonomy on, namely the Google Cloud Platform (GCP) and the Firebase mobile development environment.
I'd like to stress that this is not the same as taking a solution off the shelf, as GCP and Firebase offer tools and services that are adaptable and can be built on. Let's be honest as well, the GCP is also very cost-effective.
If you have no previous Google Cloud Platform experience, it would be well worth seeking some out on a consultancy basis
Top tip: If you have no previous Google Cloud Platform experience, it would be well worth seeking some out on a consultancy basis. While we had some backend engineers, none of them had worked with GCP, so we endured an extremely steep learning curve.
We began by building our first-party data API, starting with our first definition of the architecture, to get it talking to Firebase and using Big Query to gather data from all sources in one place.
Because Autonomy and its base platforms are open, you can collect the raw data and then do whatever you want with it, as you own both the logic and the dashboard.
You can do all this relatively quickly: once we were up to speed, it took us one analyst, one backend programmer and one client programmer six months to get the first iteration of Autonomy up and running. And here's what the first Lemmings KPI dashboard looked like:
It gave us everything we wanted from all our existing data sources in one place -- users, active users, ad spend, CPI & ARPU, net revenue -- all sortable by filters for date, country, platform, version, etc. There was nothing in this first iteration that was especially innovative in terms of data points, but it was everything we had collected since December 2018 in a single view, with a single sign on for everyone working at Exient.
Suddenly everyone is talking about the same things, looking at the same numbers -- there is no intermediary.
Compared to our previous third-party data analytics platforms, considering the lower cost and the analysts' time saved as a result of single view efficiencies, we had already amortized the development cost. That means everything from then on is a bonus for you and your company.
From that base, you'll want to test what other complex calculations you can handle. For Autonomy, we wanted to start producing accurate answers to some very specific questions. Unsurprisingly, a 'real' Return On Ad Spend (ROAS) figure was at the top of the list, as it would be for many other game publishers.
Interestingly, there are lots of third-party providers that offer some form of ROAS output within their dashboards, but none of them, for example, can take into account the cost of staff. We now take our timesheet data and inject it directly into Autonomy.
That means our ROAS takes into consideration not just the cost of the project and the cost of user acquisition, but also a fraction of the team's salary too. And we can refine further by factoring in metrics like licensing royalties.
Ultimately, we know how much we've spent and we know how much we made from the players that we targeted with those campaigns. You can then dig down further: if a campaign is successful, you can check why. Is it because you attracted a different kind of player? Can you try to get more of them? Likewise, if a campaign fails, you can fail more quickly and know why.
Your business intelligence solution is established. The next step? Enterprise grade number crunching.
We were gathering business intelligence, but we knew the architecture opened the door to a larger solution: given we had created a generic data warehouse running microservices on top of it, why not include everything that works that way?
As such, we've spent the last 12 months evolving Autonomy to be a complete enterprise solution. At a basic level, this means you can start to use it for game concept testing, administration, Live Ops and for publishing. It's all just data that needs to be processed and give valid outputs.
Plus, everything we learned from financial data we could start applying to our player community by integrating in-game events into the dashboard. So now instead of knowing 'when' a player buys DLC -- which might differ a lot from one person to another -- we can see 'where' in the game's progress they buy for the first time.
At this point, your first-party data starts to become invaluable commercially.
We've now created an Autonomy SDK that's the all-in-one client, making the entire platform available within our games from Day One and allowing us to apply it to our entire back catalogue -- it's universal.
Every time we have a new game, we spawn a new instance, a new shard of Autonomy with a consistent scheme on top of that. All of those games are going to be processed in the same way, with the same logic, giving teams the same dashboards from game to game. They don't need to learn a new tool.
Which brings us to server-side content delivery. Post launch, when your development team is long gone on other projects, you'll likely still want to operate your most successful games for years, providing players with seasonal content, limited time offers and special events.
For historical reasons, our content delivery is hosted by AWS, but processed using Autonomy, which means we can deliver new content to the game without submitting a new build to the app stores. When you get to this stage you don't even need a programmer -- all the work can be handled by a designer and then pushed through to the game, including its in-app store.
Once you have a complete first-party data analytics 'product' as your backbone, there is an opportunity to leverage it to a whole new level as a 'business booster' -- and remote config is the game changer here.
Everything I've described so far is really just a cloud platform for game data and analytics: it shows us what happens in the game, which then in turn influences how we make it better.
With remote config, however, you can send specific parameters to unique individuals (and by extension to segments of users) -- and this opens the door to individually optimised in-game experiences. This is because configuration code is usually just XML that can be overwritten by a server-side decision. We can therefore modify very large parts of a game at user-level without a new build.
Within Autonomy, then, we can define user segments and parameters and then push content and settings dynamically to those hand-picked players.
Let's say we have a player (or group of players) that are classified as 'non-spenders' when it comes to IAPs. Rather than offering them IAPs, we can offer them soft currency, or the lowest value IAP available to encourage engagement. Conversely, if a player is seen as a big spender, we can offer them high value IAPs, which are always better deals.
Our key learning here is that if you combine individual knowledge and remote config, you can modify the game's behaviour to match the player's behaviour
It follows that we can also serve high spenders with fewer ads, to arguably improve their in-game experience. You can't do any of that smart targeting without a remote config, which also allows us to undertake massive A/B testing across different groups.
For example, to improve the First Time User Experience (FTUE) of Lemmings we implemented animated instructions, as they generated better early engagement than text equivalent. Over time these players showed better retention. Subsequent FTUE A/B tests revealed playing the first levels of the game immediately after each other without a break also retained more players. After more than a dozen FTUE variants, we improved our Day 7 retention by 1.1%.
All that data is integrated back in the Autonomy dashboards as player segmentation. And that's where we see that the results also differ between countries. We implemented interstitials and segmented our audience per territory, serving different amounts of advertising per cohort, which ended up creating segments offering players different default starting business models depending on the country they were in.
The result was that some countries are fine being served more ads (we experienced +20% ad revenue from Russia, Thailand, Canada and Italy), whereas others most definitely do not (-10% ad revenue from the UK, Germany, Poland and Australia).
Once you have that kind of A/B feedback you can use the remote config to set the default game behaviours for new players in different countries and apply the same technique for player rewards (i.e. a 'thank you' for submitting a bug or referring a friend).
Our key learning here is that if you combine individual knowledge and remote config, you can modify the game's behaviour to match the player's behaviour.
The next stage here is to apply machine learning to that process, something we are working on with Google in early access. It's very early days, but an obvious starting point would be to optimise ad types and frequencies.
So, a pivot to first-party data analytics originally motivated by our simple frustration and confusion with third-party solutions has ended up becoming a never-ending gift box.
Autonomy is now a central piece of the Exient puzzle and an accelerator of value: everything we do for one game using Autonomy comes for free in all the games that follow.
We're still at the beginning of our journey. There is so much more to do and so much more data to consolidate.
I cannot stress enough that going down the route of first-party data is a long-term strategy choice that requires lots of time and effort, plus ongoing maintenance -- third party solutions are still without doubt the fastest way for any studio or publisher to get their data analytics operations up and running. This is especially true for early-stage companies, where your game and creativity are quite rightly the primary focus.
However, if you do take the plunge towards first-party, the (almost) immediate benefit is efficiency, which ensures your data becomes the backbone of your company and gives you a genuine competitive edge.
And at a time when data privacy is at the top of the agenda, with the sharing of data being restricted by those who (rightly) act as its gatekeepers, first-party data will always remain trusted and available. Perhaps it's time to secure yours?
Thomas Leinekugel is production director at Exient and has over 20 years' experience in the games industry, working on everything from global AAA franchises to indie productions. At Exient, he manages the entire production cycle across all of the publisher's development projects. He also serves as programme manager on back-end systems, including the Autonomy data and analytics platform.