Contact lead scoring models

Algorithm name: Predictive Contact Lead Scoring B2B

Applies to: B2B

Contact lead scoring algorithm helps identify contact leads (within an account) at different stages of the sale funnel and evaluate their likelihood of making a purchase or influencing the account’s purchase.

Also commonly known as: Lead qualification model, Lead prioritization model

What is Contact lead scoring algorithm?

The Contact lead scoring algorithm is a ready-to-use data science model that scores B2B contacts (within an account) based on their likelihood to purchase or their likelihood to influence a purchase. The model uses a combination of profile attributes, engagement behavior and the accounts’ revenue potential to assign a numerical score to each lead. Lead scores are timestamped for every contact, allowing you to more effectively target customer segments and align sales and marketing strategies.

Parameters of the model

To create and configure the Predictive Contact Lead Scoring model the following parameters must be defined:

  • Algorithm: Choose the Predictive Contact Lead Scoring B2B algorithm in Unity.

    • Lookback window: You must also set a lookback window (number of days to analyze historical data), with supported values: 90, 180, 270, 360 days

  • Queries: The queries you select generate the dataset used for both model training and scoring.

  • Inputs: Inputs are attributes from the Oracle Unity data model that the model uses during training and scoring.

  • Outputs: These are the data objects and attributes from the Unity data model that store the model's output values. You can customize the default output mappings if needed.

Model inputs

The Contact lead scoring model uses the following data. For the model to successfully run, check the sections: key input considerations, key data guidelines and best practices.

Attribute from Unity data object

Attribute name in the query

Unity Data object

Description of the attribute

Data Type

Must have?

Name

Contact_Company

Account

Account the contact belongs to

String

 

EmployeeTotal

Employees

Account

Number of employees in the account denoting the account size

Integer

 

AnnualRevenue

Annual_Revenue

Account

Annual revenue/ potential  of the company (standardized currency across all accounts)

Float

 

LineOfBusiness

Contact_Industry

Account

Industry the account belongs to

String

 

SourceID

SourceID

Customer

SourceID of the customer

String

Yes

Email

Contact_Email_Domain

Customer

Helps assess lead quality/ intent

String

 

JobTitle

Contact_Title

Customer

Helps assess lead's influencing power within the account

String

 

ID

ID

MasterCustomer

Identifier of the contact

String

Yes

Country

Contact_Country

MasterCustomer/ Customer

Helps assess regional lead insights

String

 

State

Contact_State_Prov

MasterCustomer/ Customer

Helps assess regional lead insights

String

 

City

Contact_City

MasterCustomer/ Customer

Helps assess regional lead insights

String

 

ZipCode

Contact_Zip_Postal

MasterCustomer/ Customer

Helps assess regional lead insights

String

 

Type

EventType

Event

Engagement event type indicating lead's intent

String

Yes

Medium

EventMedium

Event

Engagement channel through which an event was captured

String

Yes

EventTS

EventTS

Event

Timestamp of when an event occurred

Timestamp

Yes

Is_converted/ SalesStage

IS_CONVERTED

SalesData/ Opportunity

Contact/ Account conversion status (1-converted, 0-non-converted, null-unknown); Ensure to convert to boolean in the mcps query

Boolean/ Integer

Yes

OpportunityDate/ OpportunityCloseDate

OpportunityDate

SalesData/ Opportunity

Date when the opportunity/ conversion was created/ captured

Timestamp

Yes

Key considerations on model inputs

 

  1. Data schema checks: If an attribute is unavailable, assign a constant default value across all records. This allows the model to validate the input schema. This will not impact the model outcomes as the attribute will be excluded during feature importance analysis due to lack of data variance.

  2. Email engagement: Ensure that 'sent' events are included in the ‘EventType’ attribute for events where the ‘EventMedium’ is 'Email'; this is crucial for measuring a contact’s engagement intent with email communications.

  3. Schema consistency: Ensure that the attributes used in the query exactly match the specified 'Attribute name in the query' (in the above table) to avoid schema mismatches during model execution.

  4. Non-mandatory attributes: These attributes, when available, can enhance the model’s learning and improve its predictive performance. However, if they are missing, the model will still leverage other available attributes to make predictions.

Key input data guidelines for Propensity models

 

  1. Label requirements: Ensure the model data contains at least 500 positive signals (leads) and 500 negative signals (non-leads)

  2. Data requirements:

    1. It is recommended to provide at least 50,000 data records for model training. However, it is important to bring as much data as possible to build a robust model

    2. It is recommended to keep the dataset under 10M records (soft limit). This limit can vary for every model, but maintain a manageable size helps ensure efficient model performance.

Best practices

 

  1. Use case first approach: Begin with a specific use case to determine the data required for solving the problem effectively.

    1. Review model data requirements with both business and data teams to ensure alignment

  2. Contextual parameters: Choose model parameters (such as lookback window) based on the business/ use case context.

  3. Query validation: Test both the training and scoring queries to validate that they return data and inspect sample records resulting from the query

Model outputs

Output values will be stored in the ContactLeadScore data object. You can review the lead score values for each contact in the Status attribute. Each status (cold, cool, warm, and hot) is based on a lead score generated from 0 to 100. 

Attribute ID

Attribute Name

Attribute Description

Data type

SourceContactLeadScoreID

Source ContactLeadScore ID

This attribute contains the unique ID for the object.

STRING

Status

Lead Status

This attribute contains the lead status - Cold, Cool, Warm, Hot.

STRING

Score

Lead Score

This attribute contains the lead score for the contact/ customer.

INT

ScoreTS

Score Timestamp

This attribute contains the time when the score was computed.

TIMESTAMP

MasterCustomerID

Master Customer ID

This attribute contains the Foreign key to the MasterCustomerID.

STRING

SourceMasterCustomerID

Source Master Customer ID

This attribute contains the original form of the MasterCustomer ID  from the source data system.

STRING

The Status attribute will generate one of the following values based on the lead score.

Lead score

Status

Sample interpretation

0–25

Cold

Low engagement/ intent; deprioritize

26–50

Cool

Place in long-term nurture segment

51-75

Warm

Enrol in high-touch nurture campaigns

76-100

Hot

Route to Sales

data science, data science model, analyze data, create data science model, how to create a data science model, predictive contact lead scoring, predictive contact lead scoring model, lead scoring model, lead score, lead scoring, b2b model, b2b lead scoring, b2b lead scoring model