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
    • Difference between xMAU and Paid xMAU
      • Paid xMAU Definition
      • Calculation of xMAU and Paid xMAU
    • 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
  • Data Models and Snippets
    • xmau_202011
    • mart_monthly_product_usage
• 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)
• Total 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.

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 licenseDot database at the time the license was generated

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

Data Models and Snippets

We created 2 different data solutions:

• The xmau_202011 snippet that allows PMs to chart quickly their XMAU metric to put in my group/personal dashboard or embed them in the Dashboard: More info here
• The mart_monthly_product_usage table. If PMs want to investigate more into the data, understand who their top users are, or break down the results by some other dimensions (size of the deal, size of the company, product tier…).

The Product Adoption Dashboard is created using 1 main snippet:

xmau_202011

NB: The link redirects you to a Sisense View using this snippet. By hitting the RUN SQL button, you will be able to see the dataset.

Some examples would help understand better the following explanations:

• Estimated CMAU for Dev Section
• Estimated Paid GMAU for Release Management Group
• Estimated SMAU for Plan Stage by edition

This snippet is mainly used to give estimated value for estimated and recorded XMAU.

You need to declare 4 parameters to use it succesfully:

• xmau_type: to decide if you want to show All XMAU data or paid only. Values accepted are 'All' or 'paid'
• xmau_level: to choose among one of these values: 'CMAU', 'UMAU', 'SMAU', 'GMAU'
• filter: this depends on the value chosen for xmau_level:
  • CMAU: you can declare All or choose a section name (camel case, possible values are 'dev', 'enablement', 'ops', 'secure_protect')
  • SMAU: you can either choose a section name (camel case, possible values are 'dev', 'enablement', 'ops', 'secure_protect') or a stage_name (camel_case). The list of stage_names is shown in this table
  • GMAU: you can either choose a stage name (camel case, list of stage names are available here) or a group name (camel_case). The list of group names is shown in this table
• target: this allows you to define a target line in your chart. If you leave it empty it won't return anything. You can either create a static target line by just inputting the value you with to set as your target or a dynamic target line, by puting your monthly growth target (10% for example) as a decimal value (0.1 in this specific case)/

This snippet will return a compact table with a limited set of dimensions you can play with:

• created_month: reporting month
• product_tier: see definition here. This is representing the product_tier the instance is on, not the product_tier of the subscription linked to the instance. ('All', 'target' are also potential values)
• delivery: SaaS or Self-Managed ('All', 'target' are also potential values)
• breakdown: SaaS for delivery='SaaS'. delivery='Self-Managed' is split between Recorded Self-Managed and Estimated Self-Managed. That allows us to create XMAU charts following our design standards (see example here). Note that 'All', 'target' are also potential values
• edition: CE, EE or SaaS ('All', 'target' are also potential values)

And one measure:

• mau_value: which is the number of Active Users for the specific dimensions

If you want to read more about the Estimation Algorithm, more details about the current methodology and our vision are available here

mart_monthly_product_usage

This model joins together usage ping data with license, salesforce and zuora data. That means you will be able to play around with sales/financial and product data at the same time. You will be for example able to answer questions like:

• Top 10 Universities who are contributing the most to plan XMAU (number of users creating issues)
• Adoption Rate of a specific stage per month and per product tier
• verify SMAU split by industry

The dbt model is well-documented with a definition for each column. We also created a dashboard which shows some questions that can be answered with this new model.

Basic SQL query to plot monthly Number of Users creating an issue.

SELECT
  reporting_month,
  main_edition,
  delivery,
  SUM(monthly_metric_value)
FROM legacy.mart_monthly_product_usage
WHERE metrics_path = 'usage_activity_by_stage_monthly.plan.issues'
GROUP BY 1,2,3

Basic query to extract Top 10 EDU/OSS subscriptions using the most the CI Pipelines feature:

SELECT
  host_name,
  license_id,
  ping_id,
  subscription_name_slugify,
  ping_product_tier,
  main_edition,
  monthly_metric_value
FROM legacy.mart_monthly_product_usage
WHERE metrics_path = 'usage_activity_by_stage_monthly.verify.ci_pipelines'
  -- snippet [last_month] is used to get the value from last calendar month only
  AND reporting_month = [last_month]
  AND delivery = 'Self-Managed'
  -- is_program_subscription is a boolean flag turned to TRUE for all subscriptions which are part of the EDU/OSS Program
  AND is_program_subscription
ORDER BY monthly_metric_value DESC
LIMIT 50

Basic query to plot monthly Number of users who created a deployments on Paid Self-Managed instances split by Salesforce Industry type

SELECT
  reporting_month,
  IFF(ultimate_parent_industry IS NOT NULL, ultimate_parent_industry, 'Unknown') AS ultimate_parent_industry,
  SUM(monthly_metric_value)
FROM legacy.mart_monthly_product_usage
WHERE metrics_path = 'usage_activity_by_stage_monthly.release.deployments'
  AND is_paid_subscription
GROUP BY 1,2

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!