Below are the definitions of our primay Marketing Metrics.
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.
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.
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.
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
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
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.
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:
Is First Order Person
- this shows whether or not the record is currently a FO recordFO 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 recordFO 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 recordFinding 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.
Field Label (SFDC) | Field API Name | Definition | Purpose and When to Use |
---|---|---|---|
[Beta] MQL DateTime | True_MQL_Date__c | The true/reportable MQL Date for the most recent MQL of a record. Lesser of Marketo MQL DateTime and SFDC MQL DateTime | Current MQL Count/ When a record most recently MQL'd |
Initial MQL DateTime | True_Initial_MQL_Date__c | The true/reportable MQL Date for the first/initial MQL of a record. Lesser of Initial Marketo MQL DateTime and Initial SFDC MQL DateTime | When a record First MQL'd |
Initial Marketo MQL DateTime | Initial_MQL_Date__c | Set by Marketo when a record reaches the MQL Threshold. Stamped the first time this happens | input metric - not needed for reporting |
Initial SFDC MQL DateTime | Initial_MQL_DateTime__c | Set by SFDC when a record skips the MQL Stage, Inquiry > Accepted for example. Stamped the first time this happens. | input metric - not needed for reporting |
Marketo MQL DateTime | MQL_Date__c | Set by Marketo when a record reaches the MQL Threshold. Updates each time this happens. | input metric - not needed for reporting |
SFDC MQL DateTime | MQL_DateTime_Inferred__c | Set by SFDC when a record skips the MQL Stage, Inquiry > Accepted for example. Updates each time this happens. | input metric - not needed for reporting |
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
An MQL is defined by records in the Person Mart.
Sisense Snippet: rpt_crm_person_mql
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.
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.
To find the date the opportunity became an SAO, use the sales_accepted_date
field.
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
An SAO is defined by records in the Opportunity Mart.
rpt_crm_opportunity_accepted_period_sao
A Closed Won Opportunity (CW) is an opportunity where the sales team won the deal.
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.
To find the date the opportunity closed, use the close_date
field.
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.
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
A CW Opportunity is defined by records in the Opportunity Mart.
Sisense Snippet: rpt_crm_opportunity_closed_period_closed_won
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:
Marketing
- These are the actively maintained dashboards.Marketing-WIP
- These are the WIP dashboards. They can be viewed but are not reliable yet.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.
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.
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).
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.
The Marketing Linear Attribution Dashboard provides insight into the campaigns, channels, assets, forms and landing pages that drive our goals.
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.
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
):
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.
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 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!
Group_by_Time
- this groups the X-axis dates by the specified value - either Month, Quarter, or YearAll 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)
Segment
for each object as shown below in the Reporting Fields Source of Truth section.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.New First Order
, New Connected
, etc.User Region
User Geo
User Area
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.
Initial Source | Source Bucket |
---|---|
Advertisement | paid demand gen |
AE Generated | AE Generated |
CE Download | product |
CE Usage Ping | product |
Channel Qualified Lead | partner marketing |
Clearbit | SDR prospecting |
Conference | paid demand gen |
CORE Check-Up | product |
Datanyze | SDR prospecting |
Demo | organic inbound |
DiscoverOrg | SDR prospecting |
Drift | organic inbound |
Education | organic inbound |
Email Request | organic inbound |
Email Subscription | organic inbound |
Employee Referral | other |
Event Partner | partner marketing |
Executive Roundtable | paid demand gen |
Existing Client | product |
External Referral | product |
Field Event | paid demand gen |
Gainsight | product |
Gated Content | organic inbound |
Gated Content - | organic inbound |
Gated Content - Demo | organic inbound |
Gated Content - eBook | organic inbound |
Gated Content - General | organic inbound |
Gated Content - Report | organic inbound |
Gated Content - Reports | organic inbound |
Gated Content - select one (you may NOT choose from an option other than these): whitepaper,report,video,eBook,general | organic inbound |
Gated Content - study | organic inbound |
Gated Content - Video | organic inbound |
Gated Content - webcast | organic inbound |
Gated Content - Whitepaper | organic inbound |
GitLab DataMart | product |
GitLab Subscription Portal | product |
GitLab.com | product |
hopin | paid demand gen |
Impartner | partner marketing |
Investor | organic inbound |
Leadware | SDR prospecting |
SDR prospecting | |
List - DB - GACoreUpsert - 20200706 | SDR prospecting |
List - Demandbase - GACoreInsert - 20200706 | SDR prospecting |
List-2HCentric-DB-20200914 | SDR prospecting |
Newsletter | product |
OSS | organic inbound |
Other | other |
Owned Event | paid demand gen |
Partner | partner marketing |
Prof Serv Request | organic inbound |
Promotion | paid demand gen |
Prospecting | SDR prospecting |
Prospecting - General | SDR prospecting |
Prospecting - LeadIQ | SDR prospecting |
Public Relations | organic inbound |
Purchased List | SDR prospecting |
Registered | organic inbound |
Request - Contact | organic inbound |
Request - Professional Services | organic inbound |
Request - Public Sector | organic inbound |
SDR Generated | SDR prospecting |
Security Newsletter | product |
Startup Application | product |
Trial - Enterprise | Trial - Enterprise |
Trial - GitLab.com | Trial - GitLab.com |
Virtual Sponsorship | paid demand gen |
Web | organic inbound |
Web Chat | organic inbound |
Web Direct | Web Direct |
Webcast | paid demand gen |
Word of mouth | organic inbound |
Workshop | paid demand gen |
ZI-EMEA-MM-OutboundQ4-2020.08.19 | SDR prospecting |
Zoominfo | SDR prospecting |
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
MQL
MQL
Sales Segment
field.Sales Segment
- Using the Account Owner's - User Segment
Video Walkthrough (Private Video)
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: