Stage Models - Customization
Define your funnel goals
In order to measure the effect of your activities against your funnel, you need to setup funnel goals.
In Dreamdata these funnel goals are referred to as Stage Models. These stages typically represent the core KPI metrics of the business, which are utilized to monitor and enhance performance, answering questions like:
How many MQL’s did we generate last month?
For every activity you do, Dreamdata allows you to measure the activity against these KPI’s, answering questions like:
Of all people viewing this piece of content last month - how many turned into an MQL?
How many of my SQL's was influenced by Paid Social channels?
In Dreamdata a funnel goal is called a Stage Model.
A Stage Model consists of 3 elements:
- The company or contacts that entered the Stage
- The timestamp when this happened
- The value associated with the Stage
This will create funnel stages indicating when contacts or companies entered different stages in your funnel.
Dreamdata connects the funnel stage with the activities performed by associated contacts and companies prior to hitting the stage, giving you a full picture of what activities happened prior to a given stage ie. what influenced the occurrence of the funnel stage.
Attribution models can subsequently be applied to the journeys leading up to a stage, thereby assigning credit to the touches leading to the stage.
This guide describes how to setup Stage Models within the Dreamdata Platform
- Choose the object - this defines what to count, it can be things like contacts, leads or opportunities.
- Apply filters - typically only a subset of the objects should be used for a particular KPI
- Time of entering the stage - the timestamp for the funnel stage event.
- Value of a stage - pick the value associated with the stage.
- Advanced setting - Journey Type (contact-, account- or opportunity based attribution)
How to setup a model to measure
- Creation of Opportunities/Deals - click here
- All Salesforce Opportunities entering specific Stage - click here
- All HubSpot Deals entering specific Stage - click here
- All Pipedrive Deals entering specific Stage - click here
- All Microsoft Dynamics Opportunities in a specific Stage - click here
- Tracked sign-up events like demo-booked or webinar-attended - click here
Choose the object
First you need to determine what object to base the Stage model on.
This can either be objects from you primary CRM or the tracking events that are collected through the Dreamdata Platform
Depending on your integrations and pricing plan different options are available:
All events collected through the Dreamdata Platform
Show Additional Options
If you only want to count once per email or company, you can change what is counted on the object using the options in the dropdown.
The available options depend on the selected object.
It is recommended to keep the default setting unless you automatically create objects that might be duplicated for an email or company.
Multiple opportunities are created at different times for the same company. We only want to count a single time per company ie. the first time an opportunity is made for a company. We change the option of what to count from
Every Opportunity to
This picks the first opportunity for each company (timestamp determining what is first refers to the timestamp selected under the 'Timestamp Filters')
For a stage model build on tracking events, we want to count only the first time a specific event happen (fx. a sign-up).
Every Event to
Email, we count only the first time the event is seen for each contact email.
This is recommended for stage models based on events where the event might accidentally be tracked more than once and the second is not understood as progressing to a new step in the funnel. For example like demo request where it is usually the first request that signified progression to the next step of the funnel, not subsequent demos.
Once we have picked the object, we can apply filters to only consider a specific subset of the objects.
(here a filter picks all Opportunities where the
StageName is equal to Engaged and the custom property
Type__c is equal to Inbound)
Filters can be applied on any property field on the object. This includes custom fields made in the CRM.
Owner properties like email, role, id and name are available in Salesforce objects.
Moreover, it is possible to choose a property from the account connected to a Salesforce opportunity or contact. Similarly, if you are using HubSpot deals you can select a company property, an organisation property for Pipedrive deals or an account property for Microsoft Dynamics opportunities. These additional properties will be indicated by a tag in parentheses next to their names, showing where they are coming from.
To assign filters based on historical values, see the timestamp section of this guide.
Both the label and the actual name of the field is shown. When labels are ambiguous, be sure to look at the name (shown in the parenthesis after the label) to make sure you are using the correct field for your filter.
3rd party Salesforce integrations
We refer to the documentation of the 3rd party tool, to determine the meaning of properties created by that integration.
The Salesloft <> Salesforce integration will typically create the custom property
Salesloft1__Salesloft_Type__c on the Salesforce Opportunity object. To make conditions based on this property simply select it from the available properties, when building a Stage model using the Salesforce Opportunity object
Time of entering the stage
There are two options for defining the timestamp of entering the stage.
- Timestamp from Data Field
- Timestamp from Field History
Per default all activities for the company (or person) happening prior to the stage timestamp will be part of the stage journey.
For example, a campaign click happening after the company entered the SQL stage will not count towards the journey of the SQL stage, whereas a click happening before the timestamp will, by default, be counted towards the SQL.
Timestamp from Data Field
Use this option if the timestamp of entering the stage is recorded as a field on the chosen object.
The timestamp for entering the stage is recorded on a field on the object (or is the timestamp of the tracked events for stage models based on tracked events).
This can be the default fields like
CloseDate or any custom field.
This allows you to define timestamps for intermediate Stages and adheres to a "if you can define it in the CRM - you can use it" principle. However, it might require setup within the CRM system to define such fields.
became_sql_date , to determine the timestamp, when the deal became an SQL.
No need to add a specific filter to remove objects where the timestamp field is not set.
Timestamp from Field History
This option uses the Field Change History of the fields.
Field Change History captures every time a field changes its value and Dreamdata can use this history to define stages.
Timestamp from Field History option picks out objects based on the historical state of the chosen field and not the current state.
Depending on you primary CRM and chosen object different options are available:
Fields with Change History
(This is not available on all Salesforce pricing plans)
(Timestamp from Field History is not available for Stage models based on tracked events)
After choosing a field with history, we choose which value the field should have.
(uses the timestamp for when the field
Lifecycle Stage becomes equal to
MQL the first time)
This will use the timestamp when the field changed to this values the first time.
If more values are chosen it uses the first time the field changed to any of them.
Example - Salesforce
StageName and choose when it equals
This will pick out opportunities that at some point had
SQL, regardless of the current value of
If the opportunity was set to
SQL multiple times, the first is used.
Only opportunities that at some point had
StageName equal to
SQL are included. If
StageName has never been set to
SQL the opportunity is disregarded for the Stage Model.
Example - HubSpot
This will pick out Deals that at some point were in the
SQL regardless of the current status of
If the Deal entered the
dealstage multiple times, the first is used.
Only Deals that at some point had
dealstage equal to
SQL are included. If
dealstage has never been set to
SQL the Deal is disregarded for the Stage Model.
Example - Pipedrive
stage name and want the cases where it equals
This will pick out Deals that at some point were in the
stage name MQL regardless of the current status of
If the Deal was set to the
MQL stage name multiple times, the first is used.
Only Deals that at some point had
stage name equal to
MQL are included. If
stage name has never been set to
MQL the Deal is disregarded for the Stage Model.
A stage has an associated value. If it is a new business stage, it is often the contract value of the deal, but for stages happening before closing it is often a predicted value or an average.
This value is used throughout the Dreamdata Data Model and is shown in the Dreamdata Application as
Value. It always refers to the chosen Stage Model.
There are two options for providing a value to the Stage
- Fixed Value
- Value from a Data Field
You can manually supply a fixed value to the stage. The currency is assumed to be the same as the overall currency setting of the Dreamdata Platform.
This is useful when all stages represent an equal value or if you just want to consider all occurrences equal.
This is the only option if the Stage model is based on tracked events.
Value from Data Field
The value can be taken from the object used to define the Stage model.
If the value of the stage is stored on the object it can be chosen from the dropdown.
The currency is assumed to be the same as the currency setting for the CRM object and converted to the overall currency setting of the Dreamdata Platform if necessary. If no currency is set on the object, it is assumed to be that of the Dreamdata Platform.
Furthermore, a default can be set for missing values and we can ensure we only count positive values.
If only positive values are set without a default, then it filters out all objects where the field is not set.
(use the custom Salesforce field
Total_ARR__c. If the field is missing we set the value to 1000)
amount_in_home_currency will not undergo currency conversion as it is already converted in HubSpot. If you choose to utilize this field, remember to set the same currency in both Dreamdata and HubSpot.
The journey type decides what activities are considered part of the journey leading up to the stage.
Following options are supported (Note: not all options are available for all objects)
- Contact Level (contact-level attribution)
(default for contact/lead/person objects and event based models)
The journey only consists of the activities of the person defined by the object.
This is the recommended for Stages tracking the actions of single individual - common for a top-of-funnel stage
Contact-level attribution does not allow for anonymous traffic (ie activities where we do not know the contact) to be included in the attribution journey leading to the stage.
Example: for a contact object, the journey of the stage will only consists of activities of that contact.
- Company/Organisation/Account Level (account-level attribution)
(default for all CRM objects that are not contacts and leads, for Salesforce and HubSpot we use Company Level, for Pipedrive we use Organisation Level, for Microsoft Dynamics we use Account level)
The journey includes activities from all contacts and anonymous activities associated with the company.
This is the recommended setting for most stages as it includes the full account-based activity leading up to the stage.
Account-level attribution allows anonymous traffic to be included in the attribution journey leading to the stage.
Example: the opportunity object is associated with a company, and this option includes all activity from the company in the journey leading up to the stage
- Opportunity-level (opportunity-level attribution)
(available only for Salesforce or Microsoft Dynamics opportunities and HubSpot or Pipedrive deals)
If the opportunity object is not only associated with a company, but also specific contacts on that company, this option will restrict the journey to only include the activity from the specific contacts on the opportunity.
This option is recommended if contacts are routinely added to the opportunities from large companies where including all activities would be misleading.
Dreamdata will update the journey with the contacts that at any time are added to the opportunity/deals in Salesforce/HubSpot/Pipedrive/Microsoft Dynamics.
If no contacts are associated with the object, then this setting is similar to the option: Company Level.
Opportunity-level attribution does not allow for anonymous traffic (ie. activities where we do not know the contact) to be included in the attribution journey leading to the stage.
Exception to this is when no contacts are added to an opportunity and opportunity-level attribution is similar to account-level attribution.