We are currently seeking $2.0M (£1.6M) seed funding to allow us to grow the company and support the next 18 months of product development – taking us through the full launch of the GaasWorks live-ops engine. The information on this page is designed to supplement that found in our Investor Deck and Feature Roadmap – the latest versions of which can be downloaded here:
If you have any further questions or want to start a conversation, please don’t hesitate to get in touch at:
What does GaasWorks do?
GaasWorks is a B2B PaaS1 company providing GaaS developers with an intelligent product management tool – enabling them to effectively deliver and automate their live operations.
We enable all developers to retain, engage, and monetize their players by providing live-configurable game-feature modules that automatically analyze and optimize their own performance.
While existing game B2B SaaS/PaaS companies provide tools for specific – yet expensive2 – disciplines (such as data scientists), GaasWorks replaces these disciplines entirely.
We will grow our customer base by providing developers with free, unlimited use of all features that collect data and by delivering effortless, modular integration that minimizes all barriers to entry.
And we will generate revenue by selling (via membership and enterprise deals) all features that apply this data as we create the most valuable, comprehensive database of player behaviour in the world.
 B2B = Business to Business; PaaS = Platform as a Service; SaaS = Software as a Service; GaaS = Games as a Service.
 Typical salaries for these disciplines – which include data scientists, back-end engineers, and product managers – range from $70k-$90k (£40k-£50k) per annum. Data sourced from Glassdoor.com and PayScale.com.
What is the current state of the Games Industry?
The global games industry is now the largest of the entertainment sectors – exceeding film, television, and music; and on course to generate over $128Bn annually by 20201. In that same year, mobile2 gaming is projected to overtake console and PC gaming to comprise 50% of the total revenue. Over 95% of this mobile revenue comes from Game-as-a-Service products, as do 99% of the installs3. The number of potential customers in this sector is also extremely healthy – with over 400 new GaaS products released every day4.
 Newzoo, 2017
 “Mobile” includes both smartphone and tablet gaming, but not handheld consoles.
 Figure calculated from an analysis of app store growth using data sourced from PocketGamer.biz covering 2016. (Note: since this analysis was performed, PocketGamer’s source data appears to have become corrupted – we have contacted them to inform them of this issue.)
What is our USP?
GaasWorks is not a middleware platform like those that have gone before. Where existing platforms serve individual Live-Ops disciplines, like Server Engineers or Data Scientists, GaasWorks replaces those teams entirely – enabling any developer to achieve the same goals without scarce, expensive hires. As such:
GaasWorks is a Live-Ops Engine for automating the operation and optimization of any live game
When our platform is released, it will provide game developers with a medium in which to create Live-Ops Ready games, meaning that without writing another line of code and without requiring a title update:
- All game features can be fully reconfigured
- All game features automatically monitor their own performance
- All game features can tailor their experience to individual players
- All game features can have their behaviour automated
GaasWorks is also unique in its business model – which delivers unlimited use of the first two items in that list to all developers entirely for free.
There is no current product that delivers these abilities – thereby restricting the full power of Live Ops to only the very elite companies in the industry. Until now.
What problem does GaasWorks solve?
While it may appear that GaasWorks is trying to solve a variety of problems – each is just a facet of one single, larger problem. There is little point in a developer having the ability to correct issues without the means to identify them; nor is it helpful for them to be able to identify problems, if they lack the means to fix them. More generally:
For many developers, the resources required to identify and correct an issue often outweigh the cost of the problem itself. This is the single, core problem that GaasWorks will solve.
Of course, the “issues” a developer may face (and the solutions GaasWorks will provide) are not restricted to just fixing what is broken. Often, the same problem outlined above prevents developers from identifying opportunities; and from seizing them, if discovered.
Config vs Analytics
While it may appear that creating a solution for both game config and analytics should require twice as much work as creating either system alone, in practice this is not the case. Both aspects are part of the same solution, so dealing with either in isolation inherently creates edge-cases that must be worked around. By incorporating both config and analytics into the same solution, each can provide solutions for the other.
For example, collecting analytics data without the context provided by a game config system would require the developer to identify the data themselves. This approach naturally creates a possibility for human error – and, across hundreds of games, such a possibility becomes a certainty. Some such errors could be easily detected, but there will be occasions where the mistake is obfuscated (such as sending the full price of an item that was, in fact, discounted).
To preserve data integrity, such values must be identified and removed – creating large overheads in coding solutions to identify and filter this data. However, with GaasWorks’ approach, this data is always gathered by the same process, with the same context, across all games. As a result, our data is either entirely correct or entirely incorrect – a state of affairs that is far easier to test, identify, and repair.
Additionally, this integrated approach allows for GaasWorks’ modular design – meaning that each new feature we add builds on those that already exist. Further discussion on the benefits of combining game config and analytics can be found here and here.
In the modern market, a successful game requires a number of elements that did not exist a few years ago. Games are now services, not just products – and, for all but the largest developers, the barriers for delivering an effective service grow taller by the day. Where existing middleware companies might help developers scale such barriers, GaasWorks removes these barriers altogether.
Once Upon a Time
The advent of the mobile industry brought with it a wave of new, smaller game developers. Previously, the time and investment required to create and publish a successful game restricted the industry to companies of significant size. However, on mobile, any developer could release a game and have it find a market. This gave birth to countless smaller studios driving a new wave of experiences and innovations.
This same industry shift also led to a race-to-the-bottom. Success hinged on the acquisition of users – and, since games were now purely digital, the means to acquire the most users was to give the games away for free. In turn, this changed the business dynamic – with a game’s success no longer dependent upon new users alone, but also upon retaining and converting those users.
This gave rise to the Games-as-a-Service model – which, today, is applied in both free and paid products alike; and can be found across mobile, console, and PC. Developers moved their focus towards engaging players on a daily basis. Those companies who had achieved the most success in the early industry were best placed to take advantage – using their larger, more experienced teams to create wholly original systems and features to this end.
And, as a result, the majority of developers were left behind. Gamers now expect a continually renewed experience – with fresh content, challenges, and opportunities. Most small/medium developers are still working to understand these expectations – let alone deliver to them. Meanwhile, the titans that grew out of the industry’s birth race ahead – and the games industry, once again, becomes dominated by ever fewer, larger companies.
It was not just games companies that benefitted from the birth of the mobile industry. Companies like Unity and Flurry owe their success to the breadth of companies that would previously have been impossible for the industry to support.
A side effect of these products was not just a lower financial barrier to creating a game, but a lower skill barrier as well. Novices could now create compelling experiences. Individuals could build games that would previously have required a team of dozens.
However, as quickly as these new capabilities arose, the industry changed to shut them down. Server engineering and data science became essential for a game to achieve success. As these disciplines entered the industry, more middleware emerged to cater to them. Just as, in the old industry, Maya and Havok catered to animators and physics programmers; now GameSparks and DeltaDNA catered to back-end engineers and data scientists.
But the emergence of these companies followed the old model, ignoring the fact that the problem most developers faced was not providing their data scientist with the right tools – but finding/affording a data scientist in the first place. While Havok and the rest are still essential for the console giants to enable their specialists; the mobile industry turned to Unity in order to remove the need for specialists altogether.
GaasWorks was created with the same goal in mind. Not to serve specific disciplines – but to replace them altogether. Right now, small and mid-sized game developers are struggling to compete with the top of the industry because they lack the same GaaS capabilities that the giants have built for themselves in-house.
The top-grossing charts have been dominated by the same handful of companies for years – using the revenues their position generates to grow ever further ahead. To assail this position, smaller developers need access to these same capabilities, but without the expense of back-end engineers to build them; data scientists to guide them; and product managers to operate them. The existing companies in this space do not solve this problem; only GaasWorks can.
Who are our competitors?
There are currently no direct competitors providing a Product Management solution for mobile games. There are – in general terms – two families of middleware available to developers: back-end platforms (like GameSparks or PlayFab), and analytics platforms (like Flurry or DeltaDNA).
Scarce and Expensive
Back-end platforms provide developers with tools to build and manage server infrastructure. Analytics platforms provide developers with the means to collect and reduce game performance and player behavioural data. The key problem here is that these solutions require the developers to apply the solution themselves – the developer must write cloud code for a back-end platform, and must describe the data for the analytics platform.
It is therefore impossible for most developers to get the most out of these systems without employing someone with the appropriate skillset – a server engineer for the back-end, and a data scientist for analytics. These are scarce and expensive skillsets and, while these platforms help developers in these fields, they do not solve the core problem. Specifically, that their customers are still denied the capability to effectively operate a live game.
There are features provided by these platforms that fall outside of GaasWorks product offering. In such cases, there is nothing to preclude developers from using GaasWorks alongside these products. However, long-term, we have the potential to disrupt the business models of any or all of these companies.
Out of Ideas
The pattern of development within the middleware industry has, over recent years, been one of stagnation. Customers are rarely provided with new capabilities – instead, the existing companies are more concerned with duplicating the features of their competitors. What new features have been introduced generally could have been a step towards the capabilities GaasWorks will provide, but inevitably fall short. This tells us that these competitors are not aware of the unfulfilled potential in this marketplace (which we discuss further here and here). By comparison GaasWorks offers wholly new possibilities to developers and so will stand out in a field of companies that seem to have run out of ideas.
Comparing ourselves to each competitor directly:
Category: Analytics Platform
Exit: 2014 (Yahoo1, $200M)
Flurry provides developers with a free means of tracking app performance. They gather their core data passively – meaning that the developers need provide no context or specific data themselves; but limiting Flurry’s core dataset to only that data whose context is common across games2. They do provide the means for players to define custom events, but this (as with other analytics solutions) produces data that is different for every game. Flurry, as yet, provides no product management tools – focussing instead on pure analytics.
The Flurry business model offers the platform for free and monetizes the resulting data by selling industry reports and the data itself. This is the basis for GaasWorks’ own business model, though our data will be far more in-depth and we will also monetize the applications of the data (which we discuss further here).
GaasWorks already provides most of the same metrics as Flurry – via our real-time analytics pipeline (detailed below) that is already capable of reducing far deeper and more complex aggregations once provided with the requisite raw data.
 TechCrunch, 2014
 i.e. Flurry can collect metrics like Session Count as the definition of a session is universal. However, they cannot collect metrics like a Player’s Level or UI Navigation.
Category: Data Broker
Pricing: Free Tier; up to >$200k/year
AppAnnie is a top-level data broker, specializing in aggregating and selling data from the app stores themselves. They acquire this data both by scraping the stores (e.g. to read updates in chart rankings) and from access to per-app store data granted by its customers. This restricts it to a dataset even shallower than Flurry’s – but its broad coverage and unique market position have allowed it to establish itself as the default source of competitor research and store data (critical for tasks like benchmarking or ASO1). With our focus on optimization and theirs on industry-wide stats and surface-level data, there is unlikely to be any collision between our service and that of AppAnnie.
AppAnnie’s business model has quite a range. While developers can access high-level data and tools for free, the data that has real value for ASO, benchmarking, or competitor research is restricted to paid members only. These deals are typically bespoke to the customer and so AppAnnie have no fixed pricing model. However, a low-end deal would cost a developer at least $1,000/month and their high-end deals range over $200,000/year.
AppAnnie’s data focus is quite different from our own – but GaasWorks will have access to all the same data from any developer who implements a Module that needs to interface with an app store (such as IAPs). Gathering this data is trivial and, thanks to our general-purpose analytics pipeline, reducing it will be too. We can make far better use of this data than AppAnnie as we will be able to directly connect it with far deeper data from within the apps themselves. However, this is an opportunity for the future and not part of the current roadmap – competing with AppAnnie’s business model will not be a priority until our database is large enough to rival their own.
 ASO = App Store Optimization. This involves tailoring an app’s store presence (icon, text, screenshots, trailer, etc…) and listing (search terms, store categorization, etc…) to maximize downloads for the game’s target players. This is distinct from just maximizing downloads in general – as 10 players who are likely to play the game into week 2 are significantly more valuable than 50 who will drop out after day 1.
Category: Back-End Platform
Exit: 2017 (Amazon1, Undisclosed)
GameSparks started life as a backend infrastructure provider – enabling developers to implement cloud code and related features without worrying about the underlying architecture. They have since added a number of deeper, game-specific features, some of which have overlap with GaasWorks.
GameSparks provides its developers with some facilities similar to GaasWorks game Modules – allowing definition of game elements like currencies, content and achievements. While both GameSparks and GaasWorks provide developers with the ability to reconfigure these elements live, this is where the similarity ends.
Where GameSparks provides generic elements for “currency”, “virtual goods”, and “achievements”, it provides no depth in their usage in-game; by contrast, GaasWorks will provide many flavours of content with attached utilities like timers to provide developers with the means of composing their game. With GameSparks, a developer could only achieve these capabilities using custom data (which is developer-defined and so lacks any cross-game context).
As a platform targeted at engineers, GameSparks requires some degree of technical knowledge to properly apply its features. Its documentation can be opaque to those without a technical background (as Product Managers often are) and, in practice, developers report that it is often more complicated to apply than it appears.
GameSparks also provides only high-level analytics by default – making it similar to Flurry in this regard; relying on KPIs that can be calculated passively like Installs and DAU2. Despite having an IAP service, it does not currently surface revenue data. All other analytics performed by GameSparks must be developer-defined and so both lack cross-game context and require a data scientist to be converted into insight and value.
The GameSparks business model is also considered prohibitive by many developers – charging by MAU at the end of each month in an ecosystem where developers only see the profits for that month 45 days later. For smaller developers, this creates a large risk that an unexpectedly successful period for the game may result in a bill that the developer cannot yet afford to pay3. GameSparks pricing is also very opaque – with no figures stated on their own website which prompts potential customers to get in touch to work out an enterprise deal. A typical deal starts at $1,000/month4 but the coverage provided by such a deal is unclear. All this creates an artificial barrier to entry that will inevitably reduce GameSparks’ uptake.
By contrast, GaasWorks’ business model avoids this risk by allowing unlimited use of the core product for free. Unlike GameSparks, we can support this model as we still acquire value from our free customers via the player data they provide (more on that above).
 GamesIndustry.biz, 2017
 DAU = Daily Active Users
 GameSparks have added a “Student and Indie” program in place of a free tier for live games, though this program is very restricted in its criteria and still charges after an MAU cap of 100k players – which could be easily exceeded without warning if the game received an app store feature or similar promotion.
 AWS, 2017
Category: Analytics Platform
Pricing: $5/1,000MAU; 30 day free trial
DeltaDNA is a dedicated analytics platform, providing data scientists with functionality to collect and process data on their game’s performance and player behaviour. Their core difference with GaasWorks is that DeltaDNA requires its customers to define their own data context – preventing it from being compared and applied across games. As with Flurry, DeltaDNA collects and surfaces passive data (like installs, DAU1, etc…) that can be collected without developer input, but this is now a common feature of almost all middleware platforms.
DeltaDNA’s customer is the data scientist and they provide many tools to facilitate and accelerate this discipline. However, this largely means that a developer in any other role (such as a Product Manager) struggles to get the most out of the platform without additional training. By contrast, GaasWorks performs data reduction and analysis tasks automatically – removing the need for such expertise or the time required to apply them. This also means that much of DeltaDNA’s platform is built around providing tools to manipulate, slice and visualize data. By contrast, GaasWorks need only provide the means of visualizing the insights it automatically provides.
In its closest parallel to our offering, DeltaDNA has recently added a feature to enable developers to define and edit a live config for their game. However, this config – provided simply as a set of key-value pairs – is extremely limiting. It has no versioning – which prevents broad use of it to fully control a live game, as managing different configs across multiple title updates would quickly become prohibitive for developers. The system also lacks any structure, so grouping/templating of parameters or cross-referencing between such groups is impossible unless implemented explicitly by the developer (which somewhat defeats the point).
DeltaDNA also provides tools for segmenting players and makes those segments available in-game as a targeting solution. However, as with other such segmentation systems, the values on which players can be segmented are limited to either high-level/passive data, or must be explicitly defined by the developer ahead of time. GaasWorks instead allows live reconfiguration of player targeting and segmentation and will provide a deep set of values upon which to build the associated criteria – including by predictive analytics values like spend-probability.
Instead of a free tier to its membership, DeltaDNA offers a 30-day free trial with unlimited access. It operates largely via enterprise deals, but has typical packages that charge around $5 per 1,000 MAU2.
 DAU = Daily Active Users
 MAU = Monthly Active Users. For reference, small-medium games would typically have 1-2k MAU; medium-large games would have up to 1M MAU; and any game in the top-100 charts would be expected to have >1M MAU, with the very best games rising over 100M MAU. Casual games typically make 5-10c per MAU; for the best performing hardcore games, this can rise to 20c per MAU (including revenues from both IAPs and in-game Advertising). So a charge of $5/1,000 MAU could be roughly equated to a 5% share of gross revenue (for a typical game).
Category: Analytics Platform
Exit: 2016 (Mobvista1, Undisclosed)
GameAnalytics provide a service that sits somewhere between Flurry and DeltaDNA. It is a dedicated analytics tool that relies upon developers to provide context for most of its data – but, unlike most competitors, it does provide a few stock event types for tracking things like progression. However, these stock events only deliver enough depth of context to provide a generic “progression” dashboard – nowhere near deep enough to compare that progression across multiple games (which may all use the word “progression” to define very different things). As is typical, GameAnalytics reports top-level KPIs (installs, DAU2, etc…) by default, but requires developers to apply tools to define and slice the rest of their data in search of insight.
GameAnalytics also has a number of additional features beyond DeltaDNA’s more targeted offering – including IAP validation and a new game config system (whose functionality parallels that of DeltaDNA, along with its limitations).
Perhaps the most standout facet of GameAnalytics is its business model – which echoes Flurry in being 100% free, while simultaneously offering a deeper feature-set, more tailored to games. The distinction with GaasWorks’ business model is that we will have the facility to directly monetize our data by selling its applications back to our customers (while also monetizing the dataset itself, like GameAnalytics).
 VentureBeat, 2016
 DAU = Daily Active Users
Category: Back-End Platform
Pricing: Free Tier; $8/1,000MAU
PlayFab delivers a similar product to GameSparks. It has slightly more depth in the game elements it enables developers to define – though the capabilities of this feature set are still shallow when compared to GaasWorks. Also, as with GameSparks, PlayFab’s documentation and service are tailored to an engineer, not a Product Manager.
There is also very little difference between the analytics offerings of GameSparks and PlayFab – with the notable exception that PlayFab tracks IAP revenue when developers integrate the associated feature. PlayFab also facilitates some player targeting via its segments system. However, as an inevitable result of its passive analytics, the segments must be developer-defined and can only be based on values that are either available passively (e.g. Country, Platform, Device) or have been defined and implemented in-game explicitly by the developer.
The key difference between PlayFab and GameSparks is the business model. Here PlayFab is closer to GaasWorks – offering a free tier that provides some features with limited guarantee (e.g. in scalability and availability); with full features available to paying customers only. This means that the factors affecting monthly cost are directly within the developer’s control – which is never the case for companies that charge by usage (like GameSparks). As will be the case with GaasWorks, most major PlayFab developers have a tailored enterprise deal, with a typical customer paying $8 per 1,000 MAU.
Category: Back-End Platform
ChilliConnect provides a similar set of configurable game modules to those of GameSparks and PlayFab. It enables developers to define config data for game elements like currencies or virtual goods (along with custom data) and to edit that data once the game is live.
While ChilliConnect does provide the means to AB test its config values, it has no facilities for properly versioning or segmenting that data – creating the same problems discussed with DeltaDNA and GameAnalytics above. Like all other platforms in this list, ChilliConnect provides analytics dashboards of passive data (installs, etc…) and allows developers to define custom analytics to augment that dataset. However – also like all other platforms in this list – all context must be provided by the developer.
ChilliConnect’s business model is a departure from those of its rivals. It charges per API call (after a 30 day free trial) and allows developers to cancel their contract at any time2. Their rate of $49 per 5M calls, would typically equate to a price of around $8 per 1M MAU1 putting it in the same ballpark as PlayFab.
 ChilliConnect’s economy and player management functionality operates via it’s API – requiring far more frequent API calls than will be performed by the GaasWorks SDK. If we conservatively estimate 10-20 API calls per session, a typical game would therefore require 30-50 API calls per DAU. Taking 40 API calls as a median estimate and assuming a game with typical retention and engagement curves, we arrive at a figure of ~300 API calls per MAU each month. ChilliConnect’s pricing (detailed here) therefore equates to $3 per 1M MAU (for its first 5M API calls) and $9 per 1M MAU thereafter. Taking the middle value here would be generous (as, by this calculation, 5M calls would cover fewer than 17k MAU) so we take a value of $8 as typical for a mid-sized ~100k MAU game.
 Most other platforms also allow developers to cancel their contracts at any time with no penalty – but this fact is not broadly advertised. ChilliConnect, however, have turned this into a selling point.
The missing feature from all of these competitors is automation. This is partly because our competitors have not yet realized the possibility exists; and because they are simply not set up to gather the required data (as we discuss below). A full discussion on what else makes GaasWorks’ unique can be found here.
Is the game/app middleware market too crowded?
We understand how this perception has arisen, but this certainly is not the case. There are, indeed, a lot of solutions available for games developers – however, that does not mean that all the problems have been solved. Far from it.
Most middleware platforms fall into two categories – analytics (such as DeltaDNA or GameAnalytics) and back-end services (like GameSparks or PlayFab). These companies (as we discussed above) each serve a niche by making life easier for specific disciplines (DeltaDNA serves Data Scientists; GameSparks serves Engineers). The solutions these platforms provide are good at what they set out to achieve, but assume their customers have the required expertise. In reality, experienced Data Scientists and Server Engineers are in high demand and short supply – so hiring them is an expensive proposition.
GaasWorks’ customer is not the Data Scientist or the Server Engineer – it’s the Product Manager who oversees those disciplines. The PM does not want to use DeltaDNA to perform analyses – they just want the results. They don’t want to be reinventing the wheel by building identical systems for IAPs, Notifications, Progression, etc… to those found in thousands of other games – they also don’t want their coders spending time building that reinvented wheel (whether aided in this task by GameSparks or not); nor do they want to invest time every day making sure the finished wheel is still turning. What they do want is an engine to do all that for them.
This is why GaasWorks is focussed on providing automation. No one else is providing this; nor can they, without significant overhaul of their current services (more on that below).
The biggest companies in the industry have a lot of these systems internally (we know this; we built them). However, in the modern industry, these companies represent both a fraction of the players and a fraction of the revenue. There is a deep group of small/mid-sized studios who are not being served by the current market. These are the companies who use DeltaDNA just to report their top-level KPIs – because they can’t recruit a Data Scientist. They’re the companies who steer clear of GameSparks because they can’t take the risk that a month of great MAU lands them with a large bill when the revenue they generated that month won’t reach their bank account (via Apple and Google) for another 45 days.
We’ve talked to many developers with these dilemmas (and we’ve also worked for them). So, despite how it may seem from outside there is a huge gap in this market for a provider who is not going to require specialist teams – but is going to replace them. Our competitors are busy providing a kitchen – we’re providing a chef.
Could an established company duplicate our service?
When building an analytics system, the service must rely on the developer to provide context for the data – e.g. “this is data relating to the purchase of an IAP for 10 bonus lives by a player in Canada on level 6 in their 12th session.” Some aspects of that context can be interpreted generally: an IAP purchase is universal, as are “Canada”, and the “12th session”. Others can only be provided by the developer: what are “10 bonus lives”, or “level 6”? The analytics provider cannot compare such things across games, because any two developers may define “levels” or “lives” very differently.
Creating Universal Context
The problem here is that the context of the data is defined by how each feature is delivered to the player. This is why GaasWorks provides developers with the means to compose the delivery of their game’s features from modular components. Developers will use these modules because it’s quicker than building their own version of a system. They want to be spending their time creating the parts of the game that are fun, not those that are purely functional.
By implementing these modules in their games, developers simultaneously provide the context for that data. And, since the context is delivered via a GaasWorks Module, it is automatically comparable across all other GaasWorks games – thereby creating a universal context. Every purchase made in every GaasWorks game carries the same context because we describe that context ourselves and the developer fills it in like a template.
For example, a developer integrates the GaasWorks Notifications module. When the developer configures their notifications via the GaasWorks webtool, the values they want to control (timings, triggers, etc…) are the same values we require to provide context to the resulting performance data. By triggering a notification from an in-game timer, we know that this is an appointment notification and can both characterize and compare its performance accordingly. Alternatively, by triggering the notification a given time after a session has ended, we know it is a callback notification instead.
Furthermore, these values include the very same values that need to be tuned to optimize each module’s performance. So the configuration provides the context for the analytics to monitor performance; and then the analytics provides the context by which to optimize the configuration. This also creates the framework to automate the management of each Module – as all automation, essentially, involves the reconfiguration of Modules in response to performance and/or time.
Configure > Monitor > Optimize
This breaks the process down to three steps – delivery, analytics, and automation. At present, those companies who might be considered our competitors focus on one of the first two (the third is impossible without both of the others). Delivering automation, therefore, is not as simple as just having both an analytics system and a means of configuring a game’s state. It requires that common data context to exist at all stages of the process.
That these requirements have not been incorporated by our competitors strongly implies that they are not aware of the potential that GaasWorks will fulfil. We can also be confident in the assumption that the services and infrastructure of our competitors would need significant work and investment to be able to provide the same service1.
Similar problems would face games companies looking to productize their in-house solutions. Such systems have not been developed with a product goal at the finish – but have evolved over time to fill the ever-changing requirements of the company’s games. This creates a host of legacy issues and similar obstacles that in-house developers can work around, but which would hamper other developers trying to use a productized equivalent.
Furthermore, these companies are guaranteed to employ server engineers and data scientists – meaning they will not have built out such platforms to fully replace these disciplines (as GaasWorks has) since they have never experienced the need to do so.
By contrast, GaasWorks’ infrastructure has been designed with all of these requirements in mind from the beginning. Both our in-game features and our analytics pipeline are data-driven, meaning that the addition of a new module requires only the definition of the context online and the addition of functionality to apply that context in the SDK (more on that here and here). Meanwhile, our competitors will need to either adapt each individual dependent system or write new ones from scratch.
 To convert existing systems, competitors would have to alter their current analytics or config systems to carry this context. If these processes are currently multiple separate systems (as many will be) this will also require layers of integration across their existing architecture. Furthermore, no such features could be rolled out without providing backwards-compatibility with the old features – a complexity that GaasWorks will never face and one which our competitors will face repeatedly with every new feature (a maintenance task that will get exponentially larger as the feature set grows). Realistically, our competitors would need to start from scratch (though some aspects of the their current systems would cross over more seamlessly).
Why just games? Why not all apps?
The long term plan is to expand out of games and apply our technology to the full app ecosystem (more on that below). We’re starting with games because it’s our area of expertise (as we discuss here) – we’ve built progenitor systems to GaasWorks before and we’re intimately familiar with the requirements of potential customers.
That alone might be reason enough, but targeting games is still the best approach even if our background lay elsewhere. Games represent the largest single category of apps in terms of both installs and revenue1 (covered in more detail here). Games developers have also traditionally been quick to adopt new technologies on mobile and are the most aware of the need for the capabilities GaasWorks delivers.
Finally, player behaviour in games is a lot more varied than in any other kind of app and players spend more time in gaming apps than in any other category besides social networks2. These two factors combine to make gaming data a hugely valuable profiling tool for all applications – both within gaming and without. This potential is, so far, largely untapped as no company has a deep, comparable dataset spanning a sufficient variety and volume of games.
 SensorTower, 2017
 E-Marketer, 2017
How will we generate revenue?
Automating live operations requires a large volume of data that is both broad enough and deep enough to properly characterize the features involved. In games, these operations include everything from balancing player progression to optimizing advertising revenues.
For example, one such feature might be an in-game sales system. Automation of such a feature requires data on the performance of the sales involved in a variety of situations (breadth) for a variety of players and games (volume), encapsulating all player behaviours and experiences that may influence that performance (depth).
Data = Value
At present, such a data set does not exist. There are two reasons for this. Firstly, current analytics services provide developers with tools for tracking performance themselves – this means that the resulting data has a context provided by the developer, not the analytics provider. This inevitably results in different data contexts for every developer – none of which can be reliably compared. Secondly, those datasets that do have a common context belong to games companies themselves – and even the most prolific developers will only have data from a dozen games upon which to build their models.
GaasWorks avoids these restrictions by providing modular game features that can be easily implemented and readily reconfigured. Each module collects its own data and defines its own context behind the scenes – so every game using the player progression module (for example) generates data that is, by default, comparable to every other such game. At scale, GaasWorks’ dataset will be the most in-depth database of player behaviour in the world. Such a database could not be generated by any other means – making it both exclusive and valuable. And so it is upon this database that we will monetize the GaasWorks platform.
Maximize Data to Maximize Value
Our business model is in two parts. Firstly, to grow the GaasWorks database, we will provide unlimited use of all features that collect data for free. Our platform and data pipeline have been built to manage this process as efficiently as possible – allowing us to collect and reduce large volumes of data with minimal overhead. This creates the lowest possible barrier to entry for customers – thereby generating the largest possible data yield.
Secondly, we monetize the data by providing unlimited use of all features that apply data only to paying customers. The possible applications of this data are numerous – and many of them would not be possible with lesser datasets – but GaasWorks’ contextual data will allow us to build each as a general purpose solution. This means we spend no time operating these solutions and minimal time maintaining them – we create one solution and move on to the next while the first continues to generate revenue.
For example, three data engineers can create a predictive analytics system in three months. Once deployed, paying developers can access predictions on whether players will spend, churn, etc… and use these values (that are continuously recalculated) to target the game experience to those players or as triggers for automated live ops features.
All new data is automatically added to the game’s context; and so is automatically included in the continuous recalculation. Those three data engineers therefore spend no more time on the predictive analytics system and can instead move on to building other solutions – such as machine learning or AI – that enjoy all the same advantages.
Access to these capabilities will be restricted to paying developers only – via the customer’s choice of either a tiered membership system (which will best suit larger studios) or revenue share agreements1 (which will best suit smaller studios and indies). For major customers, we would tailor enterprise deals to meet their bespoke needs. Exact pricing would depend on the scope of features available per tier – but similar membership deals offered by other middleware platforms range from $1,000/month to $20,000/month (as we discuss below).
Alongside this, there are numerous tangential routes to monetizing the database itself – including selling access to the (anonymized) aggregated data; or authoring and selling analytics reports. There will also be applications for the data in third party systems, such as player acquisition. We can sell our data to these third parties, or build our own competing solutions to further broaden our revenue base. The precise strategy in this area will be decided on a case-by-case basis as the database expands and these options become available.
We have performed detailed modelling to project future costs and revenues. These models are based on: estimated growth of our customer-base; the resulting player-base and associated supporting server costs; the growth of the GaasWorks database and the applications that become available as it grows; the diversity of games within the GaasWorks ecosystem and their resulting revenues (and our share thereof); and, finally, the staff and infrastructure required to support the GaasWorks product through these various stages of growth.
At the core of this model, we have set a customer growth target illustrated in Figure 1 which produces the worst-case and best-case revenue curves shown respectively in Figure 2 and Figure 3. This growth curve has been built with our long-term goal to have GaasWorks in 10% of all newly-released apps within 5 years. This 10% figure is well within those enjoyed by companies with similar customer bases and free-tier business models like Flurry (~24%2) and Unity (~45%3).
In each scenario, we reach breakeven within 4 years – Q4 2019 in our best case projections; Q3 2021 in our worst. In each case, our projected low-point is within the expenditure covered by this Seed round – $600k in the best case, $1.8M in the worst. This is because our business model means that poorer performance in the worst-case scenario results in less relative cost, despite the additional reduction in efficiency in that scenario.
Our median scenario arrives at a low-point of $1.5M4. However, since all scenarios assume the same growth curve5, the full $2M (£1.6M) figure includes an additional contingency to allow time to hone our marketing strategy towards reaching that target. We discuss how we intend to achieve this below, and why customers will choose GaasWorks over other middleware solutions both here and here.
 In the case of revenue share, developers would gain access to more features as their game’s performance improved – ensuring that all developers can access advanced features without financial risk, and that GaasWorks is never granting access to data-applying features at a loss.
 Flurry is currently used in ~940k apps (Flurry Blog, 2017) and there are between 3 and 6 million apps available (Statista, 2017) depending on the proportion of cross-platform apps. If we conservatively assume that only 50% of apps are cross-platform, that gives Flurry a ~24% share of the resulting 4M apps.
 The Next Web, 2016
 This figure is closer to the worst-case than the best since – as can be seen from the curves themselves – the revenue growth is generally cumulative.
 The same growth curve has been used in both scenarios to ensure that a useful comparison can be drawn between each. Naturally, reducing the growth curve would reduce performance (and vice versa), but – as with all exercises in statistical modelling – applying too many free variables makes the results largely meaningless, as the inputs can be changed to achieve almost any possible result. The projections above treat growth as the core input and demonstrate how the delivery of the product will affect the output costs and revenues.
How will we grow our customer base?
First are Indie Developers and small studios, the majority of whom would start in the free membership tier. The value of these developers lies in the breadth of different games they will add to the ecosystem – broadening the database – while their relatively low player numbers keep our costs to a minimum.
To acquire these developers, we will use targeted advertising and social media, as well as maintaining an active presence on key communities online. The utility and acceleration GaasWorks can provide is already proving attractive for this group of customers. Once acquired, we can use our own data to identify those developers whose products have the best capability to benefit from paid features. Our sales team can then target such customers to promote our paid membership and revenue-share deals.
The second group of customers are mid-sized studios, for many of whom each new game is still a potential risk. Press coverage and trade shows will gain us access to these customers; along with word-of-mouth generated from the wider community. The tiered membership system will be attractive here – allowing developers to tailor their commitment to only those features they know they will need without taking extra risk. As with Indie developers, those studios who are successful (or whom we identify as having the potential for success) can then be prompted towards more advanced features – and therefore either higher tiers of membership or enterprise deals.
The final group are the major studios who will be attracted by those applications requiring data from a breadth of games they could never achieve on their own (benchmarking, cross-game player profiling, etc…). Our sales team will target these developers directly and craft bespoke deals to serve the needs of their products. We also already have various contacts at these studios – so both our individual and company reputation will aid us in this vein of customer acquisition.
Our sales strategy has already begun with the first of the above groups and will evolve through groups 2 and 3 as our product offering expands. Each group has its own value to us and the actions to support each strategy overlap – making it more efficient to take a broad approach.
In general, GaasWorks has been designed to have a low-barrier to entry when acquiring developers – both in terms of our pricing model (discussed here) and our ease of adoption (discussed here). When stacked next to similar products in the same space, GaasWorks offering is a distinct step above current capabilities, in a market that has largely stagnated (which we also discuss here).
What investment are we seeking?
We are currently seeking $2M (£1.6M) Seed funding in exchange for 15-20% of the company. These figures are based on our projected costs for an optimum product development cycle; our projected future revenues (discussed here); and an analysis of the growth and investment strategies of similar companies, including:
- PlayFab raised $2.5M seed funding in 20141
- GameAnalytics raised $2.5M seed funding in 20132
- Swrve raised $2.7M seed funding in 20113, following an angel investment of €1.6M (the equivalent of $2.2M at the time) in 20094
The full Seed amount has been calculated to provide for the next 18 months of development. Our first priority is to get a studio and expand the team from 5 to 13 over the first 6 months – creating dedicated Server, SDK, and Data Engineering teams. The following 6 months will see us expand our marketing, sales, and support teams ahead of the product launch. The final 6 months has the team at an optimum, static size of 20 people: 9 development; 5 data; and 6 operations (including production and marketing). Salaries, recruitment, studio hire and related costs over this period are projected to equal $1.65M.
A further $100k will fund server costs as we expand our volume of free tier developers and optimize both availability and scalability (this is a worst-case estimate, our internal efficiency targets are more ambitious). Any excess usage will be offset by the paying customers who would be generating it (which will also include some additional return from UK R&D tax relief5). Any such additional income will also go towards expanding our support team (or outsourcing equivalent resource) to properly serve this growing customer base.
Of the remainder, another $150k will fund marketing through the main product launch (including trade shows, travel, etc…); and the remaining $100k will cover materials (computers, test devices, etc…), incidental costs (legal, accounting, etc…), and other such expenses. All figures include contingency.
 TechCrunch, 2014
 TechCrunch, 2013
 VentureBeat, 2011
 Irish Independent, 2009 – when Swrve was known as New Game Technologies
Who currently owns the company?
GaasWorks’ 3 founders – Andrew Carter, CPO; Shane Prince, CTO; and Jennifer Manson, COO – currently own all equity in the company.
Total equity is meted out according to each founder’s investment of both time and money into the company so far, but voting-right shares are distributed equally. A vesting schedule awards an equal tranche of shares to each founder every quarter (as all founders are now adding resource to the company in equal share). We anticipate that this vesting schedule will be replaced or altered following external investment.
Ownership as of the end of Q2, 2017 stood at: Shane Prince, 58.4%; Andrew Carter, 28.9%; and Jennifer Manson, 12.7%. It is also our intention to establish a share-option program for employees once initial investment has been acquired. Additionally, we anticipate some portion of equity will be put towards recruitment of further members to the leadership team – particularly a CFO (as discussed here).
What are the legal implications of our business model?
GaasWorks depends on no identifying player data to perform its core functions. While we do use a unique identifier for players across games, that identifier could never be matched to an individual without also having access to that individual’s unlocked mobile device.
For identifying players across games, GaasWorks uses opt-in identifiers that require prior-approval from players (such as Facebook or Apple’s GameCenter tokens).
The precise legal application of regulations like the US COPPA1 and the forthcoming EU GDPR2 are still subject to interpretation. In the coming years, as such laws are clarified and precedents set, GaasWorks will be in an excellent position to deliver any required compliance mechanisms (such as parental consent) via new Modules that developers can implement in minutes.
Additionally, as GaasWorks data has common context across games, we can readily delete data for a given player – if requested, as required by GDPR – with minimal disruption or cost. We can also provide the same functionality to our customers.
What is the Exit?
GaasWorks is ultimately a Big Data company, so the most recent comparisons for company exits are:
- Flurry acquired by Yahoo in 2014 for $200M1
- Distimo acquired by AppAnnie in 2014 for $39M2
The difference in price here is largely down to data volume and data value. At time of acquisition, Flurry had data from 450,0003 apps, while Distimo had less than half that with 200,0004. Flurry’s data also comes from within the apps themselves and so contains more depth (such as Session Counts and DAU) while Distimo (who acquired their data from the app stores) was limited to only top-level data (such as Installs, which Flurry had as well).
As a high-level calculation, Flurry’s data at acquisition was worth $444/app while Distimo’s was worth $195/app. As noted above, GaasWorks’ data will be orders of magnitude more valuable than anything in the industry – in which Flurry is currently the least in-depth offering. Even if we only improve on Flurry’s data value by the same degree to which they improved upon Distimo’s this puts GaasWorks‘ value at $1,010/app.
In reality, data becomes exponentially more valuable the more depth it has (as it can be more reliably segmented, extrapolated, and applied). It is therefore perfectly realistic to project a significantly higher data value for GaasWorks once our database begins to scale.
As for who might ultimately buy GaasWorks, this will depend upon the point in the company’s development when the exit occurs. In the early years, GaasWorks will be more likely a target of game engine providers like Amazon and Unity. Later on, the scope of the GaasWorks database will make us an attractive addition to companies whose business revolves around user-level data, such as Google and Facebook.
 TechCrunch, 2014
 VentureBeat, 2014
 TechCrunch, 2014
 “More than 375,000 apps” used AppAnnie in February, 2014 (IHS Markit). After the acquisition of Distimo in May, 2014, the two companies combined had “Nearly 600,000” apps (TechCrunch). This tells us that Distimo‘s market share was between 225,000 and 200,000 apps at time of acquisition. Allowing for the terms “more than” and “nearly” in those sources, and assuming App Annie’s app-base would have continued to grow in the intervening 3 months – 200,000 is the more likely figure.
What makes our team different from everyone else?
The GaasWorks team are industry veterans with great experience designing, creating, and operating live games. Unlike other companies in this space, our team came not only from within the games industry, but from major Game-as-a-Service operators. We have experience with the in-house solutions of Zynga, NaturalMotion, Exient, and Rovio (indeed, we helped to design and build those systems) and with many third party tools, including GameSparks, Flurry, Swrve, Omniata, and AppAnnie. We have developed for iOS, Android, and console; using both proprietary engines as well as Unity and Unreal.
We have been both creator and customer for this technology and so are uniquely positioned to see the gap in the middleware market and to create the perfect product with which to fill it.
The disciplines involved in building live ops technology have only emerged in the last 5 years. As such, the number of veteran data scientists and product managers with Game-as-a-Service experience is extremely slim. We are fortunate to not only have such team members already in place; but to know of several more interested in joining us once our seed funding is secure. The same applies to a number of talented coders who also have extensive and unique experience developing and implementing live ops technology.
We discuss how we plan to grow our team here and further details on our current team can be found on our Team Page. We believe our experience and perspective are invaluable to creating an industry-defining product and intend to ensure these traits continue by working closely with our customers and ensuring our employees have direct experience implementing the product. Furthermore, as GaasWorks can be used to operate the live functionality of any product, we intend to implement it in our own webtool. This will ensure that – by becoming one of our own customers – we are perfectly placed to both learn and deliver to our customers’ needs.
What is our motivation?
I was an employee of NaturalMotion in 2014 when the company was purchased by Zynga. At the time I had been at the company for a little over 18 months, but I saw – in the executive team and those who had been there from the beginning – an unparalleled sense of accomplishment and fulfilment. I knew at the time that I wanted to achieve the same someday – but did not yet have the experience or foundation upon which to build that dream.
Several years later found me as Director of Live Operations at Exient – faced with a clear need for better technology to serve my role, but having to work with less. The stark gap in the market was plain to me, I needed only the right team with which to fill it. So, when the opportunity arose to help build that team and create that product, I seized it.
I have always enjoyed finding the “proper solution” to the problem at hand. This is not just the case of finding a solution that works – but finding a solution that will always work; that will only need to be applied once. As an analyst, one of my greatest irks was repeating the work of identical analyses week-after-week. I found the same in product management – cycling through the same sales and events; turning the same handle time after time for the same result. I took steps to automate some of those processes back then – and now, with GaasWorks, I’m working to automate all of them.
I joined the industry over a decade ago as a programmer at Exient to create football games – combining two of my passions! At the beginning I was creating finite gaming experiences that were largely inaccessible to the masses. With the advent of the smartphone our potential target audience expanded rapidly; I was well placed to play a part in the app revolution as developers scrambled to adapt to the new requirements of the market.
I’m a firm believer that the successful games of tomorrow will have the means to predict player behaviour and optimise those experiences to match. Games will be tailored to each player; every first time user experience will carry maximum impact whilst further sessions will will be easily tuned to ensure the player is retained – all at little expense. For SMEs to stay competitive and attain this level of engagement, they need to lean on a live operations platform that allows them to concentrate on creating the content that differentiates them from the rest; a platform that must efficiently handle the monitoring, optimisation and delivery of that content.
In my time at Zynga NaturalMotion, I worked on the internal live ops systems that powered their projects. Whilst those systems were successful, their requirements were internally focussed and their ambitions thus lower than those I dreamed of achieving. When I co-founded GaasWorks in late 2015, I had no doubt our vision was the next step in the evolution of such systems, and that this service would change the way people thought about game development. I am excited by what we have built so far and the potential the product has to change the workflows of game developers and ultimately lead to better games for all.
My career history has been varied, from a degree in Computer Science leading to high-tech software design and implementation, through journalism and authorship, to starting and running two successful businesses over 12 years.
Feeling I had maxed out individual productivity, I wanted to see what I could create working with a team. I found my way into the games industry as a games producer at Exient, and from there had the opportunity to join GaasWorks in its early stages.
What drew me in particular is the exceptional talent of the team. That, combined with the size of the opportunity we have in front of us, and the shift we have the potential to create in the industry, makes this something dramatically worth my time and creative effort.
How have we got this far?
We have been bootstrapping for 18 months using our savings and intermittent contract work to cover the bills. Our CTO, Shane Prince, started working on prototypes in November 2015. Our CPO, Andrew Carter, and COO, Jennifer Manson came onboard in August 2016 to complete the founding team. By February we had an operational prototype providing live game configuration, and had been joined by Senior Programmer, Danny Birch. Our Analytics Pipeline and Dashboards were rolled out two months later – completing the core of the product on which all future systems will stand.
With the core systems proven, we switched our priorities to acquiring both funding and customers. We brought onboard Natalie Griffith, our Marketing & Brand Director, who set about establishing our branding and presence; while creating opportunities for us to begin talking to potential customers. Development focus turned towards creating our Live Demo and getting the SDK into live products – while reacting to bugs and feedback we received along the way.
Develop1 was our target to be ready to pursue both funding and customers in earnest. We came away from that with several (ongoing) conversations in both regards. Meanwhile, development focus has shifted to building out the platform to MVP with our next Modules (IAPs and Cloud Save – more on those below) currently under active development and testing.
 The annual Develop conference, held in Brighton, UK.
Where are we based?
GaasWorks’ base can currently be found anywhere a team member has access to a keyboard. We do not yet have an office, though acquiring one will be our first act once funding is secured. Our spiritual home – and GaasWorks’ birthplace – is Oxford, England. The company was born out of NaturalMotion and Exient – two Oxford-based gaming companies – and is still home to half of our team.
Once we receive funding, it is our intention to relocate the company to London. The core reason behind this move is to place GaasWorks in the best possible location for recruitment; and the comparative difference in operating costs between Oxford, London, and other possibilities (such as Leamington or Brighton) are minimal. There is also a greater community of developers (and, therefore, potential customers) in London, as well as investors for future rounds of funding.
What are our weaknesses?
While GaasWorks is well served in technical, statistical, and managerial knowledge, we lack an expert in finance to compliment the rest of the team. To this end, recruiting a CFO will be a priority once our search for seed funding is complete. In the meantime, the team’s experience with accounting and mathematics is adequately filling this need – but, ideally, this time would instead be spent pursuing each team member’s specific expertise.
A similar weakness existed in Marketing, but was filled by the recruitment of Natalie Griffith, our contract Marketing and Brand Director.
Our only other weakness is financial – as our unfortunate need to feed and clothe ourselves mandates we take intermittent contract work, disrupting the development of the product. We are actively endeavouring to solve this problem by seeking seed funding, beta customers, and contract work better aligned to the product itself. We are currently pursuing various conversations with established game companies towards contracts to develop bespoke GaasWorks implementations for their products – which we can then further develop ourselves to produce the general purpose modules on our roadmap.
What is the current state of the product?
GaasWorks’ core functionality is now complete – allowing developers to live-reconfigure their games while automatically collecting and reducing analytics data from those games.
We are live in 3 Indie games, with a total DAU of 4,500 players (typical weekly average). A further 2 Indie games are being implemented at time of writing, with 3 more awaiting our forthcoming Android SDK. We have also opened conversation with a number of larger games studios who are interested in using the platform and potentially becoming development partners as we grow our product offering alongside (and in service of) their forthcoming games.
What features will the finished product deliver?
We expect GaasWorks to continue to evolve along with the industry, so there is unlikely ever to be a “final” set of features for the product. However, those features we currently have planned can be found in our Roadmap Doc and fall into three categories:
- Metagame Modules – pre-built, configurable modules that developers can integrate into their game with 1-2 lines of code. Each Module delivers a fully reconfigurable, extendible version of a common game feature that is completely Live-Ops Ready (a term we define here).
A few example game features that will be covered by such modules include: In-App Purchases; Advertising; Notifications; Cloud Save (including cross-platform play and profile recovery); Player Progression; Social Networks; Inventory; Timers; Rewards; Achievements; Quests/Missions; UI Flow; UI Layout; and Asset Delivery.
- Management Tools – online systems to aid Product Managers in operating and optimizing their game. Will ultimately incorporate tools to schedule, target, and automate all aspects of live game management.
A few examples of such tools include: Live Game Config (the ability to reconfigure the game’s settings live); Versioning; Segmentation; Scheduled Configs; Reactive Configs (which change the game’s state in response to triggers – for example: triggering a reengagement campaign if a game’s performance falls below a certain threshold); Push Notifications; Player Support; Automated AB Testing; and Gameplay Balancing.
- Analytics Systems – services providing intelligent capabilities on both the server and the client. Most of these would never be possible without GaasWorks’ solution for cross-game contextual data.
Examples of some such systems include: Real-Time Dashboards; KPI Projections & Scenario Modelling; Predictive Analytics; Player Profiling (the ability, on the client, to react to the current player’s aggregated, cross-game behavioural history – such as their propensity to spend or churn probability); and Player Clustering (segmenting players by common behaviour).
How does a developer start using GaasWorks?
Our implementation philosophy follows the rule that everything should “just work” with minimal fuss or setup required by the developer. A developer can complete the full setup process in under 15 minutes – from clicking “register” on the GaasWorks website, to the SDK operating in a live game with bespoke live data.
Once downloaded, implementing the SDK requires one line of code. Game variables defined online can then be accessed directly with a single method call; or listed, grouped, filtered, etc… via others. It also typically requires only one line of code to invoke each GaasWorks module. All of these behaviours and settings are live-configurable and lower-level methods are also available for developers who require finer control over the process, but who still wish to reap the benefits. Further detail on the full game config process can be found here.
For example, one line of code purchases an IAP, and also: awards the content automatically (if set by the developer); saves the player’s new inventory to their cloud profile; sends and aggregates all related analytics telemetry; adds the spend event to the player’s history to be used for targeting and segmentation elsewhere; validates the purchase receipt with the vendor; and, if the purchase fails validation, flags the player as suspicious.
Getting started with the GaasWorks webtool also requires minimal effort. It takes under five minutes for a developer to: register themselves; register their game; define some data for that game; and be applying that data in their codebase. Analytics setup requires nothing from the developer at all. Data is collected both passively (once the SDK is initialized) and actively (via each invocation of a module method call) by the SDK itself. That data is automatically processed and displayed in GaasWorks’ realtime dashboards. The developer will also be able to create new data reductions and visualizations directly via the webtool in moments – should they find the need among GaasWorks’ hundreds of pre-defined, automated analyses. Further details on the analytics pipeline can be found here.
Can existing games use GaasWorks?
Absolutely. The platform is entirely modular – meaning developers can implement whichever features they wish without restriction. An existing game could integrate GaasWorks one feature at a time, at whatever rate suited their wider strategy.
This helps developers by smoothing the process of adopting new technology; and it helps the business by reducing the barrier to entry for us to grow our database. These two aspects combined mean that the acquisition of new customers and their adoption of new features are both as smooth as possible – to the benefit of all concerned. However there are, of course, more benefits to the developer the more GaasWorks modules they use:
For example, if a developer implements the GaasWorks IAP Module, they can reconfigure and monitor the game’s revenue generation. If a developer implements the Progression Module, they can reconfigure and monitor how players proceed through the content. If a developer implements both, they can track where in their progression a player is most likely to spend – and use this data as a trigger to (e.g.) target sales based on which IAPs are most likely to be purchased by the targeted player’s current level. Furthermore, the developer themselves needs take no action to have this data available, as GaasWorks will calculate and surface the results automatically.
There is also zero cost to us to build the product in this way – it is, in fact, easier. As discussed throughout this document, GaasWorks’ capabilities are built on a shared context of data. This context naturally exists in a piecemeal state, so building this context module-by-module removes edge-cases and dependencies that might otherwise be unwittingly created.
For example, any “purchase” would have an Item, a Quantity, and a Cost in its context. These properties can exist independently of anything else, but lose their context when they exist independently of each other: i.e. the game cannot use a Cost without knowing the Item to which it refers and the Quantity of it that is being purchased.
What proprietary technology powers our Live Game Config system?
Reconfiguring a live product is no straightforward task. Any two systems can have multiple interdependencies – so the complexity of a typical game can quickly become unmanageable without the correct infrastructure.
Entities and Modules
GaasWorks’ contextual approach to data management smooths this process as data is structured not as simple sets of key-values, but as packets of data that each describe a discrete part of the game itself. We call these packets “Entities”.
Each Entity comprises a set of data fields, default settings, validation checks, and references to other entities. This conveys upon the developer the ability to readily edit the Entity’s data, secure in the knowledge that: ignored fields will default to safe values; new values will be automatically checked (and their changes will be rejected, with clear reasons, should they fail); and their dependencies will automatically update as the referenced entities themselves change.
GaasWorks will provide many different Template Entities covering everything from small, functional elements (such as timers or counters) to full game-features (such as UI logic or quest systems). Each of these templates serves a larger GaasWorks “Module” – which includes bespoke functionality within the SDK to deliver the game functionality described by the Entity.
For example, a developer is using the GaasWorks Advertising Module. They can reconfigure the module via a Master Advertising Settings entity and via any number of Advertising Placement entities. Both entity types are provided by GaasWorks but (as with all template entities) can be extended with custom properties.
The Master Settings entity provides controls to allow the developer to: turn on/off advertising; switch priority between 3rd-party advertising providers (or turn off advertising from a specific source); and control the behaviour of machine learning algorithms – such as auto-optimizing for the best advertising return by both mediating between ad sources and auto-adjusting the frequency and prominence with which players experience ads.
Each Placement entity provides controls over a specific point in the game flow where an advert might appear – giving developers fine-grain controls, such as: turning on/off individual placements or adjusting the frequency with which each shows an ad; changing the types of advert shown by each placement (e.g. banner, static, video); or by adding functionality in the form of entity references. A developer might reference another entity to tie (for example) a reward entity to an opt-in video placement.
The SDK then provides the developer with various methods that know how to apply the data from the controlling entities. The gaasworks.showAd() method takes the ID of an ad placement and: determines whether to show an ad (a) at this time and (b) to this player; determines the provider whose ad is to be shown; shows the ad to the player; and collects, transmits, and aggregates all related analytics (more on that below).
Developers will also be able to define their own custom Entities via the GaasWorks webtool and use them to create new Modules1 bespoke to their needs. In this way, developers can quickly compose the functional structure of their game from GaasWorks Modules and so have more resources to invest building the unique experience their game provides.
Versioning and Segmentation
Live games often have several past versions still being actively enjoyed by some significant percent of players. Therefore, any game management system must provide backwards compatibility.
GaasWorks’ populations system will allow these variations to be managed and the rules by which they are applied precisely defined – including where those rules might conflict. Each population is defined by the conditions a player must meet in order to belong to it (e.g. the player must be playing title version 1.4.1 or have made at least one in-app purchase). Players meeting no such criteria are considered as belonging to the master population. The developer can then define new entities or data specific to their new population (or variations on the data held by existing entities in the master population).
For example, a developer defines a population that provides some bespoke data only to Android players. They also want to provide different bespoke data to players in Japan. The developer creates a population for Android players and another population for players in Japan. The populations system also allows developers to define how populations interact – so the developer only needs to define these two discrete variations on the master data.
To handle the conflict, the developer sets a hierarchy between the two populations (e.g. Japan-specific data supersedes Android-specific data) causing the player to fall into both populations; receiving all of the data from the Japan population, but only that data from the Android population that does not conflict.
For example, a developer wants to restrict gameplay for suspected hackers. In this case, the developer might define a closed population comprising all players whom GaasWorks has identified as suspicious. Such players would receive the master game data and variations specific to the closed population – but would fall into no other populations.
Populations also provide the facility for developers to manage in-game events – for example, by defining a population whose entry criteria is based upon the current day of the week; and to run AB tests – in which each test group is a closed population and entry of players into each is randomly assigned. This allows the same technology to organise, version, and configure game data.
GaasWorks does not require a player to be online at all times. Players download the data for all versions and populations as one packet2 and the client determines which data to apply. This means the player’s experience is never interrupted if they (for example) change populations while offline and also provides additional guarantee for AB testing.
For example, a developer is performing an AB test on a game’s FTUE3. In this instance, the test needs to know how many players experienced the variation in each test-population for its results to be accurate. However, as these variations occur at the very start of the game, all players must download the live data very soon into their first session if they are to experience the test.
Under a server-controlled system, some proportion of players would pass the relevant point in the FTUE before the download completes – but would still be considered participants in the AB test, as the server knows it sent them the data. In a client-controlled system, like GaasWorks, the player only enters the test (and is counted as such) when they apply the data in-game. So any player who received the data too late would never be included in the test – thereby preserving the quality of the results.
As a level of insurance, the SDK will also retain its previous data version as an emergency back-up. In this way, should the client experience a problem related to new data (e.g. some corruption has occurred and the game crashes when new data is applied) the SDK can simply roll back to its last safe iteration.
Safe and Secure
Finally, inherent to GaasWorks’ operation is safety and security. GaasWorks metadata is encrypted and cloud-hosted – making it significantly more difficult for nefarious players to hack the game4. And, as a final level of insurance, all previous changes to a game’s online configuration are backed-up – allowing the developer to roll-back their game’s state to a previous safe build and undo their changes should anything ever go wrong.
 Should a GaasWorks developer create a custom module that could have broader applications, it should be little work for us to adapt their work into a universal solution and add it to the full product offering. However, we already have an extensive list of planned modules and associated entity templates, so we expect such gaps to be rare.
 As this data is simply text and the additional populations are typically variations on the core data, the difference in download times resulting from this approach is negligible – and easily worth the cost for the benefits discussed above.
 FTUE = First-Time User Experience
 And nearly impossible to hack the game without GaasWorks detecting the suspicious behaviour and flagging the player accordingly.
What proprietary technology powers our Analytics Pipeline?
GaasWorks’ analytics pipeline is a universal system for reducing any data and describing the relationships between results. It is entirely data-driven – meaning any calculation performed on the inbound telemetry can be created and edited without requiring any changes to the underlying code. All processing happens in real-time and is streamed directly into a live database.
Records, Dimensions, and Views
The pipeline works hierarchically – with inbound data arriving in raw “records” which are then processed into “dimensions”. Dimensions can then be combined to create “views” describing the relationship between them. In visual terms, each view is a chart1 and each axis2 of the chart is a dimension.
For example, every event sends up a Player ID record. The very simplest of dimensions would simply inherit the value of this record, but a more complex dimension could be created as the count of unique Player IDs. Combining this dimension with another – the measurement date, calculated from the event timestamp record – creates a view of Unique Player IDs vs Date (or DAU).
Further dimensions – such as country, player level, binned spend probability – can be added to that view to be used for filtering and segmentation. We could also create a new view with a condition specifying that a player must be in their first session for their data to be included in the result – thereby converting DAU into New Users.
The definition of each record, dimension, and view describe both how their data should be calculated and how it should be displayed. This ensures that (for example) the same dimension retains the same visual language across all views.
As a result, GaasWorks’ analytics dashboards are also data-driven – allowing developers to simply compose new views by combining dimensions as they require3. This also allows the dashboards to intelligently interpret generic questions – so the developer might ask4 “What was our DAU in Argentina last Thursday?” and the dashboards would be able to produce the result.
As all GaasWorks data shares the same context across games, we will provide hundreds of pre-made records, dimensions, and views to all customers. Developers should only need to define their own very rarely (indeed, most will never even need to visit that page of the webtool).
Efficiency and Utility
There is a lot of efficiency inherent in this approach. The pipeline processes each event independently and so can be fully real-time – processing data as soon as it arrives and removing the i/o overhead associated with bulk analysis. As validation happens in this same step, it is also possible to filter bad data (and set it aside for separate analysis, if required) at point of receipt – meaning any future analyses (such as back-filling or deep-dives) need not concern themselves with cleaning the data again.
Additionally, as all per-event calculations happen in the same code there is zero duplication in the reduction process – any measure used for multiple aggregates is only calculated once5. Also, when performing processes like backfilling6 the pipeline output has already been cleaned and indexed, and the required outputs from the backfill are clearly defined – this means the system need load in only the events that needs to be reprocessed (rather than loading all data and filtering out the redundant events along the way) and perform targeted reduction to precise specifications. Finally, only the pre-aggregated results are queried when data is requested – eliminating the overhead associated with systems like Vertica, which would repeat the processing continually as new data arrived and new queries were made.
However, the most exciting aspect of this approach is that it inherently describes connections between different metrics. This will allow GaasWorks to not just identify changes in performance – but to diagnose them.
A game experiences a drop in revenues. GaasWorks can trace this drop down a tree of dependencies described by the connected views and dimensions. This then identifies: the overall drop in revenue > is driven by a drop in sales of a given IAP > which follows a drop in appearances of a promo for that IAP > which correlates with an increase in sessions ending on that promo > which connects to an increase in crashes related to that UI element.
So the developer is not just told “your revenue has fallen” but is informed “a crash in your UI system is preventing players from seeing a promo for [IAP] and has reduced revenue by [some value / %]”. Furthermore, they see this information before they even realise there is a problem and – because their game is running on GaasWorks – they can immediately reconfigure their game to hide the promo (thereby stopping the crashes) and instead show a different one (thereby correcting the fall in revenue).
 A chart is simply one example of a view. Any visualization with any number of axes can be similarly described, as relationships where no useful visualization exists – such as data on a per-player level.
 Beyond just the axes of a plot, dimensions are also the means by which developers can filter, segment, or sort data.
 It is possible for the dashboards to determine what dimensions can be sensibly combined from their definitions. This means that the act of composing new visualizations is constrained and purposeful.
 This feature is initially envisioned as being delivered via a text search interface. However, long-term, it should be possible to create more advanced means of interrogating the data – such as via a voice assistant like Amazon’s Alexa or Apple’s Siri.
 Separate, bespoke analysis scripts would each need to process common elements – such as the measurement date – independently. As a result, the same value is calculated multiple times over – at least once for each separate script. We do not know how bespoke or general-purpose other analytics solutions data pipelines might be – but we can infer some level of bespoke infrastructure from (e.g.) incremental rollout of new features, which would be unnecessary and cumbersome in a truly general purpose system.
 Most analytics providers overlook backfill as a tool because the form of their (passive) analytics data changes so rarely and (with the wrong infrastructure) it can be an expensive proposition to reprocess large volumes of data. For their developers, however, this restriction often means waiting several weeks for an answer – simply because the question was one no one had previously thought to ask.
What is our long-term plan for the product?
Our long terms objectives are as follows:
- Provide a fully featured product. We ultimately want GaasWorks to deliver and automate every common feature of live games. Everything from sales, to UI, to game logic. It should be possible, one day, for game developers to add wholly new features to their game without the need for a title update. More details can be found here and in our Feature Roadmap.
- Get into 10% of newly released games by 2022. Our growth targets are ambitious, but are not dissimilar to what has been achieved by other free products in the industry. If the current rate of newly released games holds, in 5 years’ time there will be 40 new GaasWorks products released every day. More details can be found here.
- Expand beyond games into all apps.GaasWorks processes can be applied to the benefit of all apps, not just games. Once our games business has stabilized and the related product offering is more complete, expanding to serve non-game software will simply be a case of building new modules for features not commonly found in games, but which are prevalent elsewhere (such as subscriptions) and evolving our marketing strategy. More details can be found here.
- Build the most powerful database of player behaviour in the world. The truly exciting part of GaasWorks’ future is what becomes possible when we have the first cross-game database of detailed player behaviour. We discuss the potential of this database throughout this document, but there are also guaranteed to be many possibilities that cannot yet be conceived.
We hope the details contained above were helpful and informative. If you have any further questions or want to start a conversation, please get in touch at:
We look forward to hearing from you,