1. You are here:
2. Business Technology
3. Data Team
4. Data Catalog
5. xMAU Analysis

Maintained by:

G

On this page

• xMAU Analysis
  • Quick Links
  • Key Terms
  • Key Metrics, KPIs, and PIs
    • How xMAU are calculated ?
      • Date Range
    • Difference between xMAU and Paid xMAU
      • Paid xMAU Definition
      • Calculation of xMAU and Paid xMAU
  • Data Sources
  • Data marts
    • Mart Service Ping Usage Ping Data
    • Mart Estimated xMAU
  • Service Ping Data Pipeline
  • Sisense Snippets for Product Managers
    • How to update targets for a specific xMAU chart using these snippets ?
      • Implement your dynamic target values
      • Using the snippet to get a static target
• Entity Relationship Diagrams

xMAU Analysis

xMAU is a single term to capture the various levels at which we capture Monthly Active Usage (MAU), encompassing Action (AMAU), Group (GMAU), Stage (SMAU), and Total CMAU). In order to provide a useful single metric for product groups which maps well to product-wide Key Performance indicators, each xMAU metric cascades upwards in the order noted above.

xMAU metrics are derived from Usage Ping (Self-Managed instance-level granularity) and GitLab.com (SaaS namespace-level granularity). This Analytics Workflow enables the analysis of each level of xMAU metric across various segments of customers sets the foundation for reporting on Reported, Estimated, and Projected metrics.

The goal of this page:

• Help you understand how to navigate through the Product Adoption Dashboard
• Help you understand the data models used to Product Adoption Dashboard
• Have you asess your understanding by taking a certification most applicable to your role at GitLab.
  • Assess your understanding of the dashboard solution, take the Dashboard user certification.
  • Dashboard Developer certification to come.
  • In addition, we recommend understanding our methodology for recorded to estimated xMAU
• And overall help everyone contribute!

Quick Links

Getting Started

1) Understand the key terms, metrics, KPIs/PIs 2) Understand the data models

Key Terms

• Account
• Host
• Instance
• Instance User Count - the total number of users on an instance
• Paid User
• Product Tier
• Usage Ping
• Version

Key Metrics, KPIs, and PIs

Explanations for the metrics below can be found on the Product Team Performance Indicator page:

• Action Monthly Active Users (AMAU)
• Stage Monthly Active Users (SMAU)
• Section Monthly Active Users (Section MAU)
• Section Total Monthly Active Users (Section CMAU)
• Combined Monthly Active Users (CMAU)

Each metric has three different versions (Recorded, Estimated, Projected), explained on

• the Product Team Performance Indicator page
• the Sisense Style Guide Currently, recorded metrics that have identified usage ping metrics have been charted on the Centralized Dashboard, but we are working on our first version of Estimated values in this issue (internal link).

How xMAU are calculated ?

xMAU is calculated mainly thanks to Service Ping Data source. When the project started, stage and group Product Managers chose one specific service ping metric which produces their xMAU charts.

• list of GMAU metrics used
• list of SMAU metrics used

The current SSOT for the xMAU metrics is this spreadsheet which is imported via Sheetload to our datawarehouse. That means that when updating the GMAU, SMAU columns for a specific metrics, the changes will propagate downstream to the xMAU charts updated in the handbook.

There is a plan for migrating this SSOT from this spreadsheet to the dictionary YAML files, work to do is in this issue (internal link).

If you have more questions on the metrics definition, you should ask the Product Intelligence team. They are currently maintaining a Metric dictionary available here. Also if the metrics are database calculations, they are able to provide you with the SQL query run to generate the metrics value.

Date Range

For every instance (self-managed and Saas/GitLab.com), we use the last ping generated that month to calculate xMAU. Instances are randomly assigned a day of week to generate service pings, but that assigment is peristent over time. For example, if an instance is assigned Tuesdays to generate pings, it will always generate pings on Tuesdays. Since the day of week that pings are generated differs across instances, the exact date range captured in a 28-day counter will also differ.

Currently, the "last ping of the month" is determined by the date at the beginning of the week (Monday). (In SQL: DATE_TRUNC('month', ping_created_at_week)). As such, sometimes the "last ping of the month" does not technically happen during the month of measurement. Here is an example from August 2021:

Difference between xMAU and Paid xMAU

Paid xMAU Definition

Each of these above metrics will be calculated for xMAU and paid xMAU. Paid xMAU is currently defined as Monthly Active Users who "roll up to a paid instance for Self-Managed via Usage Ping data or a paid namespace for SaaS via GitLab.com Postgres Database Imports in a 28 day rolling period". (See Paid Stage Monthly Active Users - Paid SMAU as an example.)

Since GitLab Business functions currently do not have a standardized way to identified which namespaces or instances belong to an OSS, EDU, internal projects, or other subscriptions that have a paid plan type but do not contribute ARR, the current implementation of xMAU include users associated with these subscriptions as "paid".

Calculation of xMAU and Paid xMAU

We have 2 main data sources to calculate xMAU and paid xMAU, the Version App and the Gitlab.com Postgres database. The table below summarises which data source is used for those calculations.

Notes:

*: For SaaS xMAU, we use the payloads generated for gitlab.com. These payloads are easily identifiable since they are linked to an instance with uuid = ea8bf810-1d6f-4a6a-b4fd-93e8cbd8b57f

**: For SaaS paid XMAU, we need to use Gitlab.com postgres table. The Usage Ping payloads generated from our Gitlab.com Instance gives us high-level statistics at an instance level. This is an aggregated number which can't be further broken down, for example by product tier, plan type, or namespace.

• To be able to generate SaaS paid xMAU we need to replicate the xMAU counters with the replica of the Gitlab.com database which is stored in our data warehouse.
  • Batch counters are simple SQL-generated counters. The SQL query used to generate the counters are accessible and easily recreated.
  • Unfortunately, this is not doable for every single counter. Redis counters are NOT SQL-generated counters. They also track actions that are not in the Postgres DB such as pageviews, or frontend interactions.
• Therefore, only some metrics can be recreated using the Gitlab.com Postgres Replica. That means that for now, we are not able to calculate some of the SaaS Paid xMAU metrics like the Monitor Stage.

***: To calculate paid xMAU on Self-Managed we use the edition field in the Usage Ping Payload, selecting only usage pings with EEP, EES and EEU edition. The edition value is derived from the plan column in the license table in the CustomersDot database at the time the license was generated (internal link). That means that currently we don't exclude EDU/OSS subscriptions from the paid xMAU calculations.

Data Sources

Based on the explanations above, the 2 main data sources we are using are:

• Service Ping Data Source
• Gitlab.com Data Source

Data marts

We have built a suite of datamarts that allow users to explore our different product data sources.

Mart Service Ping Usage Ping Data

The mart_service_ping_product_usage_data is the most comprehensive data model for all Service Ping data. This data model joins together Service Ping data with financial and GTM data sources such as subscription, CRM Account…

This allows users to retrieve usage data for all monthly and all-time metrics which are defined here

Mart Estimated xMAU

The mart mart_estimated_xmau is built in order to generate easily the estimated XMAU PIs. This model contains all the estimation logic which is explained in this page.

End-users can then use very simple charts to create their estimated xMAU chart:

SELECT 
reporting_month,
product_tier,
SUM(estimated_monthly_metric_value_sum)
FROM common_mart_product.mart_estimated_xmau
WHERE xmau_level = 'SMAU' AND stage_name = 'create'
GROUP BY 1,2```

A mart_paid_estimated_xmau datamart has been created to construct specifically paid xMAU charts

Service Ping Data Pipeline

Sisense Snippets for Product Managers

We created another page which contains a comprehensive list of all the snippets that were created for Product Managers. We recommend you read this page for more information about this topic.

We also created this dashboard 📊, full of examples on how to use these snippets.

How to update targets for a specific xMAU chart using these snippets ?

Implement your dynamic target values

It is now possible to get Monthly target values implemented in your SiSense chart for any of your Usage Ping Metrics. To do so, you will need to update the yml file where your Performance Indicator (xMAU or potentially any other PI coming from usage ping) and follow the example described below:

----
- name: Configure:Configure - Adoption PI - Number of projects with GitLab Managed Terraform State
  base_path: "/handbook/product/performance-indicators/ops-section-performance-indicators/"
  definition: A rolling count of the number of projects using GitLab Managed Terraform State in the last 28 days
  target: 6000 by end of Q1FY22
  target_name: projects_with_terraform_states
  monthly_recorded_targets:
    "2021-04-20": 6000
    "2020-11-01": 3000
    "2020-07-01": 700
  monthly_estimated_targets:
    "2021-05-01": 6000
    "2020-11-01": 3000
    "2020-07-01": 700
  org: Ops Section

So you have 2 different sections in the yml definition that can be used:

Using the snippet to get a static target

For all embedded PI/xMAU charts using our standardized snippets and visualisation, updating the target is a very easy 4-step process:

1. Go to the PI of interest and click on the sisense link
2. Click on Edit Chart
3. Change the last value (that's the target value - if you do a decimal it will increase by a certain percentage. If you type in a full number, that number will be the target line.)
4. Click the Save Button

Entity Relationship Diagrams

One of our goals is to create a 1 model that easily provides all the data needed for analysis. As we continue to iterate on our solutions, we know that there will be information that isn't always available in this model! Here's where understanding the Entity Relationship Diagram helps. This model shows what tables are joined to create the layer you are accessing. This is really when you are looking to dive deeper and gain additional insight!