Stage Model documentation

Updated by Mikkel Settnes

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:

  1. The company or contacts that entered the Stage
  2. The timestamp when this happened
  3. 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

  1. Choose the object - this defines what to count, it can be things like contacts, leads or opportunities.
  2. Apply filters - typically only a subset of the objects should be used for a particular KPI
  3. Time of entering the stage - the timestamp for the funnel stage event.
  4. Value of a stage - pick the value associated with the stage.
  5. Advanced setting - Journey Type (contact-, account- or opportunity based attribution)

Examples:

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:

Salesforce

HubSpot

Pipedrive

Microsoft Dynamics

Events

  • Opportunities
  • Accounts
  • Contacts
  • Leads
  • Deals
  • Companies
  • Contacts
  • Deals
  • Persons
  • Organizations
  • Accounts
  • Opportunities
  • Leads
  • Contacts

All events collected through the Dreamdata Platform

Show Additional Options
By default each object is counted once in a stage model.

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.

Example A:
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 Company.

This picks the first opportunity for each company (timestamp determining what is first refers to the timestamp selected under the 'Timestamp Filters')

Example B:
For a stage model build on tracking events, we want to count only the first time a specific event happen (fx. a sign-up).

By changing 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.

Apply filters

Once we have picked the object, we can apply filters to only consider a specific subset of the objects.

test

(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.

The filters are applied to the current status of the object, and not the historical status of the object.

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
If a 3rd party CRM Integrations works by creating properties on specific CRM objects, those properties are imported into Dreamdata and can be used to create the Stage models.

We refer to the documentation of the 3rd party tool, to determine the meaning of properties created by that integration.

Example:
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.

  1. Timestamp from Data Field
  2. 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 CreateDate and 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. 

Example
On the opportunity we have defined a custom field, became_sql_date , to determine the timestamp, when the deal became an SQL.
Dreamdata will automatically filter out objects where the chosen field is NULL (or otherwise not a valid timestamp)

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. 

The 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:

Objects

Fields with Change History

Salesforce

  • Opportunities
  • Accounts
  • Contacts
  • Leads
  • All fields (including custom fields) with history enabled

(This is not available on all Salesforce pricing plans)

HubSpot

  • Deals
  • Deal Stage

Pipedrive

  • Deals
  • Stage Name
  • Status

(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.

If the field never reached the chosen condition - the object will not be counted towards the Stage model

Example - Salesforce
For a model based on Opportunities in Salesforce, we choose the history of the field StageName and choose when it equals SQL 

This will pick out opportunities that at some point had StageName SQL, regardless of the current value of StageName. 

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
We want to count Deals where when dealstage equals SQL. 

This will pick out Deals that at some point were in the dealstageSQL regardless of the current status of dealstage. 

If the Deal entered the SQLdealstage 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
For a model based on Deals in Pipedrive we choose the history of the field stage name and want the cases where it equalsMQL. 

This will pick out Deals that at some point were in the stage name MQL regardless of the current status ofstage name. 

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.

Stage Value

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

  1. Fixed Value
  2. Value from a Data Field

Fixed Value

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)

Please note that the HubSpot field 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.

Journey Type

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)

  1. 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.

  1. 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

  1. 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.

You can control which contacts are included directly from Salesforce, HubSpot, Pipedrive or Microsoft Dynamics.

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.

How did we do?