Setting up the right data structure from the start and knowing exactly what your numbers mean will allow you to rely on a scalable and flexible service in the long run. The data management tool’s main functionalities are collecting all data throughout the publishing service and then, enable pulling the right data to guide and support strategic discussions.
We think Amazon's definition best describes a data warehouse: “The data warehouse functions as a central repository of information coming from one or more data sources. Data flows into a data warehouse from transactional systems and other relational databases, and typically includes structured, semi-structured, and unstructured data. This data is processed, transformed, and ingested at a regular cadence.”
In simpler words: Working with multiple systems, tools, and a global setup requires to have a central location (physical or virtual) that brings information together.
The Data Warehouse is the heart of the service and should be in place as soon as possible, latest when the first data is collected and stored on the live service.
Here are a few strategic considerations when setting up your data warehouse:
- Where do we want to publish? (Territories)
- How will our solution need to scale? (User number and event tracking forecasts)
- How can we ensure security of the service?
- How do we maintain the service?
- What backup options do we want?
- What level of support do we need from the data warehouse provider?
You do not have to answer all these questions at once. But when you look and decide which other tools you would use, use the questions as a guideline. You step by step will start to get a picture of how tools connect and what you need to make them work together.
Game Analytics includes a set of tools that are required for the collection, processing, and distribution of game data and information to other systems. This can in-game and out-of-game events.
The publishing teams need the information to analyze the game and tweak or improve the game product accordingly. Therefore they need to be able to understand what each event means and how they get the right data. Ideally, a game analytics structure is in place before first user tests (that involve the game) on the service start.
We recommend to work with your teams on a catalog of events that outlines clear definitions of what is bring tracked and how. Here an example structure:
- Data Point
- Start event
- End event (if relevant)
The most common mistake, we see, is that publishers do not define "player". The "user" of a service often equals "players". While it might be good for PR and communication, it is not a good definition to be used internally.
Tools that record the reason for a crash of a system and sends it to the appropriate person in charge for further evaluation. Crash analytics can relate to the game but also other tools on the service, for example the launcher or CS tools.
Crash analytics are more developer focused than publishing focused. Nonetheless, the publisher needs to make sure the developers have proper access to crash analytics. The setup and maintenance should be the responsibility of the publisher but the developer needs to provide the right input.
Put crash analytics in place as soon as possible. Not only for the game also for other tools and systems! Critical bugs and issues that completely block users from accessing the service or playing the game need quick resolutions. And the only can be resolved quickly if you have the right information. Make sure you have proper error codes in place!
You want to be able to track everything that happens on your service. Most importantly, you want to be able to track your conversion and user funnels. So make sure they are properly defined! You and your team will probably need multiple tools to be able to cover all tracking points.
We always advise: Do not start your marketing campaigns, unless you are able to track your acquisition funnel on the most granular level!
Segmenter should be seen more as a category than one single tool. All tools that only process and segment data fall under this category. A lot of the previous mentioned tools in this section already include the function of processing data but proprietary and ETL tools should be listed here.
Having a good understanding of the kind of segmentation you need, is key to finding the right technology in this section.
You will require several reporting tools to meet the needs of your service. Some reports will be automated. Others will be on demand and manually generated. Reporting tools are something that grow over time.
But two things any reporting structure needs from the start:
- Clearly defined reporting needs
- Comprehensive definitions of KPIs, data and events
While reporting is a snapshot of a certain moment. You need data visualization tools to show you real time information of your service. Both data visualization and reporting can also contain sentiments, event reporting, and others.
Do you want to learn more?
Drop us a line today and we will get back to you!