Overview
Dealership data is often full of duplicate customers, bad leads, and otherwise unusable data. Fullpath extracts the 1st party data from the Dealer's CRM, DMS, Imported lists, Google tracked phone calls, and other data sources, analyzes, normalizes, cleans, and then merges potential duplicates in order to create a unified entity called the Shopper. This article will explain how identity resolution occurs and in which cases we will not merge shoppers.
Entity Types
Before digging into Fullpath's Identity Resolution and Shopper Merge rules, it is important to understand the different entity types referred to throughout this article.
- Website User: A person who has visited the Dealership's website.
- Customer: A person who has a record in the Dealership's CRM or DMS.
- Shopper: A Fullpath specific term used to describe a unified entity that is created using data from the dealership's website, CRM, DMS, Imported lists, Google DNI data and other sources
Identity Resolution
Fullpath is able to take various data-points (described below) and use them to identify users and build shopper profiles in the dashboard.
Every Fullpath Customer has a code snippet on their website. This collects information with regard to when and how website visitors are interacting with their website and assigns a unique web ID. These insights include:
- Which VDP pages they visited.
- If they're looking at New Vehicles, Used Vehicles, Service, etc.
- Conversion data from Form Fills and Chats.
- Interactions with Fullpath's Website Engagement tool.
Information gathered from these activities is then stored on our servers, with unique identifiers for each website visitor. As a website visitor returns, we build a Shopper Profile that includes their interactions with the website and it's inventory.
As mentioned previously, CRMs are often full of duplicate information and even bad leads. Fullpath will connect to the Customer's CRM and DMS to pull all available historical data and, instead of using low quality information, will cleanse the data via the included PII; hereby resolving identity discrepancies and/or duplications.
What's more, Fullpath can also monitor incoming DNI records from Google Ads or other DNI tracking providers and connect those phone calls to the shopper entity.
Fullpath's email marketing solution ensures that the links used in email campaigns contain unique identifiers. This enables us to identify website visitors as the specific CRM or DMS customer that was sent the marketing email. When we make this identification, we can also retroactively connect this Shopper to all of their previous website usage and expand their Shopper Profile.
With all of this information available from multiple data sources, there's a likelihood for redundant or bad data. When building the Shopper Profile, Fullpath's algorithm will effectively sort through the available information to create consolidated, concise Shopper Profiles.
We call this "Shopper Merge". Important to note: We will email all email addresses associated with each shopper if there is no indication which is the primary email.
Data Sensitivity
Before merging data, the Fullpath algorithm conducts an analysis of several factors (e.g. quantity of matching contact details, probability of commonality based on factors such as last name, etc.) This evaluation aims to prevent excessive or insufficient data merges.
Shopper Merge Rules
There are several guiding rules that Fullpath follows when merging data to create and/or maintain shopper profiles:
Shoppers with the same Email Address AND Full name similarity are merged together.
Shoppers with the same Telephone Number AND Full name similarity are merged together.
Shoppers visiting the same unique Audience Activation Landing Page AND Full name similarity are merged together.*
Shoppers who were listed as buyers on the same sale are merged together
Shoppers who have similar sounding first names + similar sounding last names + the exact same address will be merged together
|
Data Enrichment: In order for Fullpath Shopper Data and Data Enrichment to be considered "matched" the data must include at least two fields: 2. Email or 3. Phone or 4. Street Address
Enrichment Data may be managed at the Shopper level within the CDP. Read more here. |
*Each Audience Activation communication generates a unique landing page. We can assume that users reaching the same landing page are in some way related to one another (If not the same person!).
Merged By
The data used to merge multiple entities is clearly indicated in the Merged By column so users may quickly understand how a Shopper was identified across multiple sessions, devices, and using multiple different pieces of identifying information:
*hover and click on the grey name, phone, address etc. chips.
Household Tagging and Merging
Entities which meet both of these conditions will be merged and labeled as a shared household:
- Same last names, but different first names
-
Different cell-phone numbers
Exceptions to Shopper Merge
Expand the sections below to learn about each of the data/scenarios for which we will not merge data.
We check all email addresses and phone numbers and filter out those without the correct characters (e.g. letters for phone numbers, missing "@" sign for emails). In addition, we do not merge likely fake phone numbers (e.g. a number that contain a digit repeated 6 or more times).
"Shared device users” are never merged with anyone. A “shared device user” is a user (that is, a shopper created from web activity data, or email or SMS engagement - not from CRM data) who satisfies the following criteria: 2 or more customers {with non similar names}. In this case, a user who is linked to more than one customer with non similar names is considered a shared device user.
Email addresses from the dealership's domain are not considered for merging (e.g. "john@toyotadealership.com").
In addition, dealership employees using the VIN Solutions CRM are not merged. Client employees may check Audience Activation emails sent to leads, but their test access of the email does not affect merging based on Audience Activation Landing Page View.
- We look at how many different name “clusters” a contact detail (email/phone) is attached to before deciding to use it for merging.
- If the contact detail is linked only to one name cluster (i.e., many records but all name-variants of the same person), we WILL use it for merge decisions even if it appears in many records.
- If the contact detail is linked to two or more distinct name clusters (i.e., clearly different people), we will NOT use it for merging — even if it only appears in 2 records.
Concrete examples
- Example A (allowed):
- Contact: bobmarley@test.com appears in 10 CRM records.
- Names: "bob", "bob marley", "marley", "mr marley" → all cluster to the same person.
- Result: We WILL use bobmarley@test.com to merge those records.
- Example B (blocked):
- Contact: bobmarley@test.com appears in 2 CRM records.
- Names: "bob marley" and "mark feldman" → two distinct clusters.
-
Result: We will NOT use bobmarley@test.com to merge those records.
Shoppers with 8 or more contact details from the same source, are not considered for merging. For example: customer from the CRM with more than 8 phone numbers, will not be used for merge.
Important to note: For audience activation, we will email all email addresses associated with each shopper if there is no indication which is the primary email.