Marketing Metrics

1. You are here:
2. Handbook
3. Marketing
4. Marketing Strategy and Analytics
5. Marketing Metrics

Maintained by:

Ashley Kramer

@akramer

On this page

• Marketing Metrics
  • Inquiry
    • First Order Inquiries
    • Date of Inquiry
    • Technical Definition
    • Source & Metric
  • MQL
    • First Order MQLs
    • Date of MQL
    • Technical Definition
    • Source
  • SAO
    • First Order SAOs
    • Date of SAO
    • Technical Definition
    • Source
    • Sisense Snippet:
  • Closed Won Opportunity
    • First Order CW Opportunities
    • Date of Closed Deal
    • Finding Net ARR for an Opportunity
    • Technical Definition
    • Source
• Marketing Sisense Dashboards
  • Marketing sources
    • Inbound
    • Demand Generation
  • Defining Conversion Rate
  • Marketing Metrics Dashboard
  • Marketing Attribution
  • Marketing trial sign up flow
  • Alternative Method for Account Demographics Fields on Leads
• Filters on Marketing Dashboards
  • Date Filters
  • Salesforce Data Filters
  • Lead Source Buckets
• Reporting Fields Source of Truth
  • Lead
  • Contact
  • Account
  • Opportunity
• Dashboard Review Videos
  • Marketing Metrics
  • SDR Metrics
• Useful things to know when it comes to Sisense vs. SFDC data

Marketing Metrics

Below are the definitions of our primay Marketing Metrics.

Inquiry

An inquiry is a stage of the lead/contact objects in SFDC. GitLab defines inquiry as an Inbound request or response to an outbound marketing effort.

First Order Inquiries

Inquiries that are part of a parent account that has not made an order through GitLab are classified as first-order inquiries. To find them, we join the account table to the person table on the inquiry account ID. If the field has_first_order_available is true on the account object, the inquiry is first order. If the inquiry does not have an account associated with it, it is also first order.

Date of Inquiry

Finding when a lead became an inquiry requires accounting for leads who skipped the inquiry stage. To do this take the lesser of inquiry_date and inquiry_inferred_date.

The logic for finding when a person became an inquiry is captured in the inquiry_reporting_date field. It should always be used to report inquiries unless you are looking for something specific.

Technical Definition

Any lead or contact with Status != to Raw and the first date between Inquiry Date and Inquiry Inferred. Any lead or contact from the fct_crm_person table where Status != to Raw and inquiry_date or inquiry_inferred_date is not null.

Example Query, this will return a list of inquiries with the date they became an inquiry:

  SELECT 
  dim_crm_person_id,
  sfdc_record_id,
  email_hash,
  inquiry_reporting_date
  FROM common_mart_marketing.mart_crm_person
  where 
  lower(Status) != ’raw`
  and inquiry_reporting_date is not null

Source & Metric

An Inquiry is defined by records in the Person Mart. To find the number of inquiries, take the unique count of email_hash

Sisense View: rpt_crm_person_inquiry

MQL

A Marketing Qualified Lead (MQL) is a stage of the lead/contact objects in SFDC. GitLab defines an MQL as a person who is Marketing Qualified through systematic means.

First Order MQLs

MQLs that are part of a parent account that has not made an order through GitLab are classified as first-order MQLs. To find them, we join the account table to the person table on the MQL account ID. If the field has_first_order_available is true on the account, the MQL is first order. If the MQL does not have an account associated with it, it is also first order.

There is a set of fields that show information regarding the First Order (FO) status of a MQL:

1. Is First Order Person - this shows whether or not the record is currently a FO record
2. FO Intial MQL - this shows whether or not, at the time of the Intitial MQL DateTime (the first time the record MQL'd), the record was a FO record
3. FO MQL - this shows whether or not, at the time of the MQL DateTime (the most recent time the record MQL'd), the record was a FO record

Date of MQL

Finding when a lead/contact became an MQL requires accounting for leads/contacts who skipped the MQL stage.

To do this we take the lesser of mql_date(Marketo MQL DateTime in SFDC) and mql_inferred_date (SFDC MQL DateTime in SFDC). Note: Both of these fields are hidden from views and only the SoT fields below are visible, for simplicity and consistency.

There are two new fields in SFDC, MQL DateTime that is the lesser of the above two fields and Initial MQL DateTime which is the SoT for the first time a record MQL'd - these are the only two fields that should be used in reporting on when a record MQLs.

The logic for finding when a person became an MQL is captured in the mql_reporting_date field. The mql_reporting_date field should always be used to report inquiries unless you are looking for something specific.

Technical Definition

Any lead or contact from the fct_crm_person table where the MQL first or Inferred MQL date is not null.

This is captured in the fct_crm_person table by the is_mql = TRUE.

Example Query, this will return a list of MQLs with the date they became an MQL:

  SELECT 
  dim_crm_person.dim_crm_person_id,
  dim_crm_person.sfdc_record_id,
  Dim_crm_person.email_hash,
  collate(mql_date, mql_inquiry_date) as mql_date
  FROM mart_crm_person
  where 
  is_mql = TRUE

Source

An MQL is defined by records in the Person Mart.

Sisense Snippet: rpt_crm_person_mql

SAO

A Sales Accepted Opportunity (SAO) is an Opportunity that has reached the accepted stage, the criteria to accept or reject an opportunity is set by sales and defined in their handbook.

First Order SAOs

SFDC stamps the order type on each SAO when it is created, meaning that each SAO knows its order type. The order_type field stores this information. The logic for first-order SAOs is captured in the is_new_logo_first_order flag. It should always be used when querying for FO SAOs.

Date of SAO

To find the date the opportunity became an SAO, use the sales_accepted_date field.

Technical Definition

Any opportunity from the fct_crm_opportunity table where the stage_name is not 10-Duplicate and is_edu_oss is 0, and the sales_accepted_date is not null. These conditions are captured in the is_sao field on the fct_crm_opportunity table.

Example Query

SELECT
sales_accepted_date,
dim_crm_opportunity_id
FROM mart_crm_opportunity
WHERE 
is_sao = TRUE
and is_new_logo_first_order = TRUE

Source

An SAO is defined by records in the Opportunity Mart.

Sisense Snippet:

​​rpt_crm_opportunity_accepted_period_sao

Closed Won Opportunity

A Closed Won Opportunity (CW) is an opportunity where the sales team won the deal.

First Order CW Opportunities

Because a closed-won deal is an opportunity, the order_type field stores the first order information. When querying for First Order Closed Won, it’s best to use the is_new_logo_first_order flag, this ensures that all our dashboards are using the same logic to find FO CW.

Date of Closed Deal

To find the date the opportunity closed, use the close_date field.

Finding Net ARR for an Opportunity

When reporting on the Net ARR of a closed deal, we need to ensure the deal will contribute to the company's Net ARR. To this, add the is_net_arr_closed_deal flag as true to the query.

Technical Definition

Any opportunity from the fct_crm_opportunity table where the stage_name is not 10-Duplicate and is_edu_oss is 0, and the is_won is true, and is_closed is true.

These conditions are captured in the is_closed_won field on the fct_crm_opportunity table. The is_closed_won field should always be used when querying for closed-won deals.

Example Query

SELECT
sales_accepted_date,
dim_crm_opportunity_id
FROM mart_crm_opportunity
WHERE 
is_closed_won = TRUE
and is_new_logo_first_order = TRUE
and is_net_arr_closed_deal = TRUE

Source

A CW Opportunity is defined by records in the Opportunity Mart.

Sisense Snippet: rpt_crm_opportunity_closed_period_closed_won

Marketing Sisense Dashboards

In Sisense there are mutlipe marketing metric dashboards. You can quickly find the current source of truth dashboards by referencing the Marketing topic within Sisense. There are 3 topics that marketing leverages:

1. Marketing - These are the actively maintained dashboards.
2. Marketing-WIP - These are the WIP dashboards. They can be viewed but are not reliable yet.
3. Marketing-Archive - These are the archived/old dashboards. They are not to make decisions off of and no longer supported.

Below you can find a few of the major dashboards in use and descriptions/links of/to them.

Marketing sources

To help us improve our paid and organic campaigns, we split marketing activities out by source in to Inbound and Demand Generation related activity. Inbound and Demand Generation sources use the following Google Analytics mediums for our breakdown.

Inbound

• Organic
• Direct/none
• Non-paid social
• Referral

Demand Generation

• Display
• Paid Social
• Generic Paid Search
• Branded Paid Search

Defining Conversion Rate

There are several ways we can use conversion rate optimization to improve marketing performance on GitLab web properties. To create a common, MECEFU oriented definition for our teams we use the following formulas.

Overall conversion rate We use the overall conversion rate to quickly measure the effectiveness of our marketing website. This measurement helps us establish a baseline for engagement and move to update CTAs and offers across our marketing website to improve our conversion motions. This is the formula we use to arrive at the overall conversion rate.

overall conversion rate = goal conversion events on about.gitlab.com/total sessions on about.gitlab.com

For example, in December 2020 there were 2,829,601 sessions across our Google Analytics profile, with 23,218 goal conversion events.

Our overall conversion rate in December 2020 was 0.82% (23,218/2,829,601).

Offer specific conversion rate (trial, demo, etc) We use offer specific conversion rates to help us measure the effectiveness of pages with conversion events. This includes our trial page, demo, webcasts, resources, and other pages we use to convert visitors to inquiries. We use this formula to calculate the offer conversion rate.

offer conversion rate = offer conversion/visits to offer pages

Looking at December 2020 again, there were 7,226 /demo/ pageviews with 600 demo conversion events.

Our demo conversion rate in December 2020 was 8.3% (600/7,226).

Marketing Metrics Dashboard

The Marketing Metrics Dashboard is the centralized hub of all major marketing metrics and marketing KPIs. It is an evergreen source of information brought in from Salesforce that is comprised of numerous individual graphs/charts and allows the viewer to quickly filter results using pre-defined filters on the dashboard itself.

Marketing Attribution

The Marketing Linear Attribution Dashboard provides insight into the campaigns, channels, assets, forms and landing pages that drive our goals.

Marketing trial sign up flow

We use a variety of methods and systems to collect leads and understand how people discover GitLab. This is a basic overview of these visitors move through marketing systems. Note: The time delay between a record being added to SFDC and the time it takes to process in Marketo, get a score, and get pushed back to SFDC as a MQL causes a discrepancy between Inquiries and MQLs for trials on a given day or in a given month (when the trial occurs on the first/last day of the month) when viewed on the Marketing Metrics Dashboard.

Alternative Method for Account Demographics Fields on Leads

In Q3 FY23 we completed the first phase of creating an alternative method for supplementing our Account Demographics fields on SFDC leads. We started this project after noticing a large portion of our leads had null values in the Account Demographics fields for segment, geo, etc.

To address this, we created and validated two new alternative mappings to account demographics fields for Segment and Geo. We took a waterfall approach, by first using the Account Demographics fields if present, then falling back to data enrichment fields on the lead record. Below is the more detialed logic:

To find Segment the logic is as follows (employee_bucket_segment_custom):

• If Lean_Data_Matched_Account_Sales_Segment__c shows as pubsec, use it first; otherwise use Account Demographics
• If still null, use the ZoomInfo employee count
• If still null, use the manual input employee count

To find Geo the logic is as follows (geo_custom): We used the FY23 Territories Mapping File - SSoT mapping doc to find how countries mapped to Geos across segments.

• If Account Demographics, use it
• Otherwise find the first non-null value from Zoominfo then Cognism
• Map the found country to a GEO via a hardcoded list.

This logic has been added to DBT, and can be used in models as needed.

We have added new charts to the Weekly Marketing Dashboard with the alternative mappings while keeping the Account Demographics (original) version. We have also added tables to the Integrated Marketing Dashboard, ensuring we left the original Account Demographics versions too.

Filters on Marketing Dashboards

Filters are a native and integral piece of any dashboard! They allow you to quickly and easily isolate and filter your data based on pre-determined values and sets. They are of no use to anyone if we don't all know what a specific filter represents though! Here are the most common filters used on marketing dashboards, what data they pull from, and what they mean to you as the end-user!

Date Filters

1. Group_by_Time - this groups the X-axis dates by the specified value - either Month, Quarter, or Year
2. Fiscal Year - this groups the X-axis dates (unless noted on the chart) by GitLab's Fiscal Years

Salesforce Data Filters

All of these filters pull from the linked/specified field(s) from Salesforce. Notes will indicate when there are groupings used. As all of these pull directly from SFDC and are not cleaned (except for those specified as being bucketed/grouped, anomalies may occur when our data is not properly maintained in SFDC)

1. User Segment Name - this pulls from SoT for Segment for each object as shown below in the Reporting Fields Source of Truth section.
2. Source Bucket - this pulls from the Lead Source for Leads/Contacts as shown below in the Reporting Fields Source of Truth section. Note: these are grouped into buckets which, once updatd, will be displayed in a table below. This is considered the SoT for where a specific Lead/Contact came from/was sourced.
3. Sales Qualified Source - this pulls from the Sales Qualified Source of the Opportunity. This is considered the SoT for where an Opportunity came from/was sourced.
4. Order Type - this pulls from the Order Type field on the Opportunity. It is used to define whether an Opportunity is New First Order, New Connected, etc.
5. User Region Name - Using the Opportunity Owner's User Region
6. User Geo Name - Using the Opportunity Owner's User Geo
7. User Area Name - Using the Opportunity Owner's User Area

Lead Source Buckets

To give executives a better view of lead sources and showing where leads and contact are sourced from we created a bucketed feild. Its often refered to as lead source buckets in Sisense.

This grouping was first used in the CMO Plan

Below is the table mapping for each lead source and its Source Bucket.

Reporting Fields Source of Truth

This section captures and links the most often used fields in reporting so that anyone pulling a Salesforce report can and is using the correct fields and the same fields that are being used in Periscope reports/dashboards.

Note: There is a current transition to move towards the Territory Success Planning fields

Lead

1. Lead Source
2. MQL Date - if this is blank, the record is not counted as a MQL
3. Sales Segment

Contact

1. Lead Source
2. MQL Date - if this is blank, the record is not counted as a MQL
3. Sales Segment - See the Account Sales Segment field.

Account

1. Sales Segment - Using the Account Owner's - User Segment

Opportunity

1. SDR/BDR
2. Closed Date
3. Net ARR
4. Lead Source
5. Sales Accepted Date
6. Sales Qualified Source
7. Stage Name
8. Order Type

Dashboard Review Videos

Marketing Metrics

SDR Metrics

Video Walkthrough (Private Video)

Useful things to know when it comes to Sisense vs. SFDC data

Given the way that our systems are connected and synched, you may see a discrepancy in the data within Sisense vs. Sales Force.com. A few things to note:

1. Opportunity amount will be updated immediately within sales force, but will NOT show up in Sisense until the next day, as our data synchs overnight.
2. There is about a 7 hour time difference between Sisense and SFDC, so this time lag can also create discrepancies as well.