Product Usage Data provides quantitative measurement of how, when, and where the Customer is using GitLab as a product and is used by GitLab teams to build better products, accelerate customer adoption, and improve customer retention. The Product Usage Data page will provide the information and tools that GitLab team members can use to explore Product Usage Data and develop customer insights.
In the future, we plan on adding support for the following use cases:
|Source||Key Use Cases||Data Flow From Source To EDW|
|Service Ping||Gainsight Product Usage, xMAU, Estimated MAU||JSON payload sent from Self-Managed instances → version.gitlab.com → Version Postgres Database ← pgp →
|Seat Link||Gainsight Product Usage||Customers Portal -> Customers Postgres Database ← pgp →
|Version Check||None||version → Version Postgres Database ← pgp →
|GitLab.com||Product Adoption Dashboard, Gainsight Product Usage (coming soon)||gitlab.com -> replicas/clones ← pgp →
|Snowplow||Snowplow Summary, Product Adoption Dashboard||Snowpipe|
The data solution delivers three Self-Service Data capabilities:
From a Data Platform technology perspective, the solution delivers:
Much of the data within and supporting the Product Usage Data is Orange or Yellow. This includes ORANGE customer metadata from the account, contact data from Salesforce and Zuora and GitLab's Non public financial information, all of which shouldn't be publicly available. Care should be taken when sharing data from this dashboard to ensure that the detail stays within GitLab as an organization and that appropriate approvals are given for any external sharing. In addition, when working with row or record level customer metadata care should always be taken to avoid saving any data on personal devices or laptops. This data should remain in Snowflake and Sisense and should ideally be shared only through those applications unless otherwise approved.
Partnering with cross-functional teams, the Data Team is defining metrics indicative of product adoption. These metrics are categorized as North Star Metrics and Leading Indicators.
A North Star Metric is a single value that gives a high-level summary of product adoption. Each Use Case has one North Star Metric. A North Star Metric must meet three criteria:
A Leading Indicator is a measure that impacts Use Case adoption, but is not comprehensive enough to be a North Star Metric. For example, a Leading Indicator might give insight into adoption of a single feature within a Use Case. Alternatively, a Leading Indicator can track any prerequisite activities that are required to unlock the primary value of a Use Case.
A great way to get started building charts in Sisense is to watch this 10 minute Data Onboarding Video from Sisense. After you have built your dashboard, you will want to be able to easily find it again. Topics are a great way to organize dashboards in one place and find them easily. You can add a topic by clicking the
add to topics icon in the top right of the dashboard. A dashboard can be added to more than one topic that it is relevant for. Some topics include Finance, Marketing, Sales, Product, Engineering, and Growth to name a few.
|Product Usage Data ERD||All of the below||Shows all table structures, including column name, column data type, column constraints, primary key, foreign key, and relationships between tables.||Customer, Service Ping, Subscription, Seat Link, Self- Managed, SaaS, Product, Delivery, Accounts|
Data is sourced from GitLab SaaS and GitLab Self-Managed customer deployments. For information on how to add additional Service Ping metrics to the Gainsight Data Pump, please see the Data Guide for Adding Service Ping Metrics to Gainsight.
The Data Team has leveraged the native capabilities in Gainsight to read data from the Snowflake Enterprise Data Warehouse. The Data Team has build a read-only mart-level table for Gainsight to access and it will contain all of the data currently available. Over time as the Data Team adds more metrics or customer segments, this table will automatically be refreshed with the additional data. This “interface” is called the
Gainsight Data Pump.
The Data Team to develop a new source data pipeline from Gainsight into Snowflake to include new custom objects and data created in Gainsight to increase the Service Ping match rate, among other improvements.
The diagram Product Usage data developmental Streams illustrates our development approach for managing the delivery of Self-Managed and SaaS Product Usage to Gainsight.
The dbt solution generates a dimensional model that represents the flow of data through each of the tables from Source Models to Gainsight.
See overview at Trusted Data Framework
Kindly refer the dbt guide examples for details and examples on implementing further tests.
A detailed Dashboard showing dbt tests, Source Model freshness, Record Counts, Last Run Dates, Golden records Validation etc.. This reports on latest Enterprise Dimensional model test and runs.