Building an Analytics Dashboard to Guide Product Strategy

One of the essential steps users need to take when running a multiplayer server is creating a new fleet. A fleet is a system that deploys and connects dedicated servers, allowing players to join a game session. To set up a fleet, users must provide several pieces of information and configure fleet specifications—one of the most important being region capacity.

‍

The Problem

Shortly after I joined the project, we received feedback from users reporting that their fleets couldn’t deploy any dedicated servers. They reached out, unsure of what went wrong. After investigating, we found that the root cause was missing configuration in the region capacity. Users simply left it blank, assuming it would be automatically managed. Unfortunately, this wasn’t an isolated incident—many users faced the same issue.

‍

Key  Insights

Our team delved deeper into user feedback and uncovered three main reasons behind this problem:

1. Assumption of Automation:
   Game admins believed that the region configuration was automatically handled by the system, so they left it blank.
2. Confusion with QoS Regions:
   Game admins mistakenly thought that setting up regions on the QoS Regions page was sufficient. In reality, QoS (Quality of Service) Regions are used to optimize network performance by selecting the most suitable server region based on latency, while region capacity specifically configures the number of instances available per region.
3. Lack of Guidance:
   Users weren’t sure what to do in the region capacity section, as the required inputs (like Min. DS, Max. DS, Buffer, and Region Capacity) lacked sufficient explanation. This uncertainty led users to skip the configuration entirely.

‍

The Solutions

To address these issues, we implemented the following improvements:

1. Interactive Guidance:
   We added a small action prompt to guide users through selecting and filling in the required information, making the process more visible and approachable.
2. Contextual QoS Information:
   We included brief, informative text about QoS status for each region, clarifying its purpose and how it differs from region capacity.
3. Clear Explanations:
   We provided contextual information about the key configuration fields (Min. DS, Max. DS, Buffer, and Region Capacity) to eliminate ambiguity and guide users step by step.

‍

These changes significantly reduced confusion and support tickets related to region configuration. Users now better understand how to set region capacity correctly, and the frequent questions about this process have vanished.

One of the key steps users need to take when running a multiplayer server is creating a new fleet. A fleet is a system that deploys and connects dedicated servers, allowing players to join a game session. To set up a fleet, users must fill out several details and choose specifications, with one of the most crucial being the instance/server selection.

‍

The Problem

When I first joined the project, I approached it with a fresh perspective, testing the product as a new user. One challenge immediately stood out: selecting the right instance was time-consuming due to an overwhelming number of options. To validate my experience, I gathered user feedback—and it turned out I wasn’t alone. Many users faced the same issue.

‍

Key Takeaways

After discussions and analysis, here are the key takeaways:

1. Provider Preference: Game admins often have strong preferences for specific host providers. As the company planned to add more providers, it was important to design a scalable solution.
2. Decision Hierarchy: Game admins typically prioritize RAM size first, followed by CPU Cores, and finally price.
3. Pricing Confusion: Users frequently asked for instance pricing, even though a link to the pricing document was already provided—indicating the link was either hard to find or unintuitive.

‍

The Solutions

To address the usability challenges and enhance scalability, I made the following changes:

1. Improved Scalability:
   • Previously, the instance selection lacked flexibility for future expansions, especially when adding new host providers.
   • I restructured the layout to accommodate multiple providers, ensuring it would remain efficient as new options are introduced.
2. Server Type Categorization:
   • Instead of listing providers directly in the dropdown, I grouped them by server type, making it more intuitive for users to select the appropriate option.
   • This approach minimizes cognitive load by clearly indicating whether the server is optimized for production, general use, or other specific functions.
3. Better Organization through Grouping:
   • The original long, unstructured list made it hard to scan and select instances.
   • I introduced an accordion-style grouping based on instance family (e.g., CPU, GPU, General Purpose), allowing users to expand only the relevant category.
   • Changed the interaction from sort to filter based on CPU and RAM to improve findability.
4. Clearer Information Labels:
   • The ambiguous Info label led to confusion about what the button would display.
   • I replaced it with “Pricing Info” to set clear expectations and reduce uncertainty.

As a result, the confusion around instance selection significantly decreased, and the streamlined process is still in use today.

In AccelByte’s Multiplayer Server, there are two types of region entities that serve different yet related purposes:

1. Fleet Region DS Configuration: Defines the number of Dedicated Servers (DS) available in each region. It sets the capacity for game sessions by specifying Min. DS, Max. DS, and Buffer, based on the Region Capacity.
2. QoS Region: Determines the Quality of Service by selecting regions with the lowest latency for players. It ensures that game sessions are hosted on the most optimal server location.

‍

The Problem

We encountered cases where users had correctly configured the Dedicated Server and Buffer amount for a specific region, but the fleet still failed to claim a server in that region. After a thorough investigation, including analyzing analytics data, we discovered the root cause:

• Some users did not activate any QoS region during the setup process.
• A significant number of users never even visited the QoS page while configuring their fleets.

This confusion arose because users didn’t fully understand the relationship between Fleet Region Configuration and QoS Region—assuming that setting up the DS configuration alone was sufficient.

‍

The Solution

To address this issue quickly and effectively, we implemented the following improvement:

Dynamic Alert:
When users select and fill the Dedicated Server and Buffer amount for a region that has no active QoS, a dynamic alert now appears, informing them that the QoS region must be activated for the configuration to work.

This quick-win solution not only prevents fleet deployment failures but also educates users on the importance of enabling QoS regions—even if they are already familiar with the technical terms.

‍

With this small but strategic update, users now receive real-time feedback during setup, significantly reducing configuration errors. This proactive alert serves as a subtle educational touchpoint, helping even advanced users avoid common pitfalls.