Data Team Direction

1. You are here:
2. Business Technology
3. Data Team
4. Data Team Direction

Maintained by:

G

On this page

• Data Development Timeline
• FY24 Data Strategy
• FY23 Data Strategy
• Strategy
  • 1) Customer Centricity
  • 2) Data Community
  • 3) GitLab Culture of Data First
  • 4) World class data and analytics capabilities
• Data Capability Model
• Quarterly Objectives
  • Data Flywheels
    • Customer & Product Intelligence Flywheel
    • Corporate Intelligence
  • Long-Term Direction
  • Measuring Success
    • Data Team KPIs
• A Complete Enterprise Data Platform
  • Data Platform FY23 initiatives
    • Data Observability
• Data Value Pyramid

This page contains forward-looking content and may not accurately reflect current-state or planned feature sets or capabilities.

Data Development Timeline

How did we get here? The Data Development Timeline page provides coverage of the Data Team's accomplishments and the path we have taken to create today's team, technology platform, and programs.

FY24 Data Strategy

In November-2022 we held several cross-team sessions to help align on the GitLab data strategy for FY24. Parcipants included Finance, Marketing, Sales Strategy, and Customer Success.

• FY24 X-Functional Data & Analytics Agenda
• FY24 X-Functional Data & Analytics Planning Deck

Outcomes of the strategy workshops include:

• 360 Customer IQ
• Customer Journey
• Analytics Platform
• Data Customer Zero
• FY24 X-Functional Analytics Projects
• FY24 UCID Roadmap

FY23 Data Strategy

In November-2021 we held several cross-team sessions to help align on the GitLab data strategy for FY23. Parcipants included Growth, Finance, Marketing, Sales Strategy, and Customer Success.

• Strategy Worksheet
• Project Team Issue (internal link)

We are in progress of running the exercise for Q4.

Strategy

As an important step towards achieving our mission, meeting our responsibilities, and helping GitLab become a successful public company, we are creating an Enterprise Data Platform (EDP), a single unified data and analytics stack, along with a broad suite of Data Programs such as Self-Serve Data and Data Quality. The EDP will power GitLab's KPIs, cross-functional reporting and analysis, and in general, allow all team members to make better decisions with trusted data. Over time, the EDP will further accelerate GitLab's analytics capabilities with features such as data publishing and products - enriched and aggregated data integrated into business systems or into the GitLab product for use by our customers. This acceleration happens through the development of "Data Flywheels", much like GitLab's Open Core and Development Spend flywheels.

1) Customer Centricity

KPI: Revenue/Efficiency gains from Data Products Definition:

1. Visibility and deep understanding of how our customers use our product and interact with our teams
2. Focus on the Customer Journey Lifecycle & Related Analytics
3. Build a Better GitLab for our Customers. Be customer zero.

2) Data Community

KPI: Data Engagement measured by MAU Definition:

1. Create a community where everyone can make their best decisions with data built on SSOT Data Architecture and One Data Warehouse
2. Best-in Class Talent, Tenure, and Growth

3) GitLab Culture of Data First

KPI: % of Top cross functional & LRO Projects with Measurement plans Definition:

1. All product features logged for analysis in a centrally governed way
2. Iteration and experimentation to drive business value
3. Strong visibility into key business results, business processes, product behavior and programs
4. Data Governance across business systems, product, and warehouse so we all speak the same language
5. Be customer zero for ML Ops

4) World class data and analytics capabilities

KPI: % Analytics Time on Level 1 / 2 work Definition:

1. Scalable data platform, data collection, modeling, and visualization
2. Master data management
3. Create unified data models with robust governance
4. Cutting-edge data and analytics tools available to team members
5. Integrate advanced analytics with our business processes

Data Capability Model

The Data Capability Model lists six levels (0-5) that correspond to the data maturity of a company.

It is used to identify target state requirements to support GitLab's Company Strategy.

To help GitLab become a public company, we need our lead-to-cash and public-facing metrics to reach Level 2 of the capability model.

Quarterly Objectives

Data Flywheels

Customer & Product Intelligence Flywheel

The Customer & Product Intelligence Flywheel is focused on improving the Customer Experience and encompasses the data and analytics involved in user-product interactions, customer use cases, product development, product adoption, and most aspects of the Customer Journey.

Corporate Intelligence

The Corporate Intelligence Flywheel is focused on improving (internal) Business Efficiency and this is accomplished by instrumenting, monitoring, and improving business workflows. Common outputs of Corporate Intelligence teams include performance dashboards, balanced scorecards, KPIs, MBOs, and related data-enabled frameworks.

Long-Term Direction

Measured in Years, our long-term direction is to extend the EDP with features found in a mature Enterprise Data Platform such as master data management, a data lake, and advanced analytics. Also, once we have reached Level 2, we:

• want to find more ways to contribute to open-source data projects
• would like to work with Meltano as a data pipeline and processing component
• want to integrate aspects of the EDP with GitLab.com to provide deep analytic capabilities to GitLab's customers
• provide DevOps Industry Benchmark Reports along the lines of Okta's Business @ Work
• revisit our overall data tech stack to ensure we have the required elements to reach Level 3

Measuring Success

We will measure progress towards our short-term direction in the following ways:

1. Data Team KPIs
2. The business impact of our results as they align to the Data Value Pyramid
3. The data features we provide as they map to the Data Capability Model
4. The Data Team Quarterly Report Card

We have not yet defined criteria for measuring long-term progress.

Data Team KPIs

1. All-Time Number of Self-Service Data Customers Enabled
2. Monthly Number of active Self-Service Dashboard Developers
3. Monthly Number of active Self-Service SQL Developers
4. Monthly % of Dashboard Traffic From User Generated Content

A Complete Enterprise Data Platform

The following table represents capabilities of a mature Enterprise Data Platform which can solve for the wide range of data and analytics needed by a large business. Not all capabilities listed are required to meet GitLab's short-term needs or known long-term needs. The decision to implement a given capability will be driven by a clear business need and the final result may differ significantly from the reference example.

Data Platform FY23 initiatives

The following sections describe the Data Platform FY23 initiatives.

Data Observability

Data is landed from different source systems in the raw data layer and processed/transformed in the prep and prod before it becomes available to business users via Sisense, data pumps, queryable in Snowflake and other ways. All transformations are performed by dbt. All the data that is in raw changes over time, because data is changed in the source systems and therefore also needs to be processed downstream towards the prep and prod layer.

Currently there are about 35 source systems extracted:

• Data is landed in 1900 different tables
• There are over 1700 dbt models
• Multiple different end points (including i.e. Sisense, Data Pump, Data Spigot, Qualtrics, Snowflake GUI)

Currently there is monitoring available to check failures in the process, from extracting until making it available for the different end points. This is done via our Trusted Data Framework with by default monitors in Monte-Carlo, defined tests in dbt and monitored in our triage process.

Data observability is a methodology to actively monitor data sets inside a data platform for the existing health status. When the data is healthy, data is trusted and can be used in the decision making process, without facing the risk of making a decision on the wrong information.

In FY23-Q2 the Data Platform team implemented the Data Observability tool Monte-Carlo.

• It helps us to find anomalies that we are not actively searching for (find the unknown).
• It reduces costs of implementing new tests.
• It reduces false positives and false negatives.
• It gives a clear overview which we can communicate with business stakeholders -> impact for them.

In FY23, the Data Team will continue the implementation by creating new monitors in Monte-Carlo. Migrating existing tests out of dbt towards Monte-Carlo is not on the roadmap, because;

• the Data Team needs to mature in Monte-Carlo,
• monitor as a code is not implemented.

Data Value Pyramid

We want to help all GitLab teams move up (or left-to-right in the diagram below) the Data Value Pyramid and turn basic metrics and counts into wisdom that helps them create better products for our customers, run our business more efficiently, and add new capabilities to our business model. Relative to the Data Value Pyramid, we are currently working primarily within the Data and Information stages.