Identity resolution for a PLG go-to-market motion
Identity resolution is the process of consolidating user data from across sources, matching identifiers to build a single profile that delivers a cohesive view of a user’s activities. ID resolution also ties multiple users from one company into a single account.
Generally used to enable marketing teams to deliver the right message to the right person, ID resolution is a well established concept in the consumer data platform landscape. I helped build one of the most powerful ID resolution systems, which is used by companies like Alaska Airlines and Nordstrom, when I ran Product at Amperity.
As consumerization of B2B go-to-market motions takes place with product-led growth at the forefront, ID resolution becomes an essential part of the B2B stack as well, but with its own unique twist.
What exactly is the ID resolution problem?
In traditional B2B sales, companies usually start out knowing who their customers are because those customers go through a sales process. There’s no question about who uses a product, where they work, or who else from their company should be on the same account.
Product-led growth changes that. Typically in B2B companies with PLG motions, product adoption precedes an actual sale. This adoption happens via free or low-price-point product SKUs instead. Even though professionals are using the product in their work context, they don’t need to go through a lengthy procurement process due to the free/low price point.
When people become customers without any relationship to a sales team, companies need to connect the dots about who their users are (to identify their customers who are most ready to convert to the next stage, among other reasons).
The GTM team is often responsible for identifying which users represent large accounts where expansion can happen and higher price point contracts can be acquired.
To do this, the spaghetti of identities needs to be untangled.
The entities to resolve
Seven core identity entities need to be resolved. One person may have all seven. And in one company, there may be thousands of unconnected IDs.
Visitor
A visitor is an anonymous human that visits your website. If you instrument your web traffic with a tool like Mixpanel or Pendo, the tool assigns each visitor a unique ID. This ID persists across sessions as long as the user doesn’t delete their cookies.
Transactional User
A Transactional User is a user in a company’s proprietary system. This data is often replicated to a warehouse and each user has a unique system-generated user ID. This ID is often the most accurate source of truth about users of a company’s services.
For instance, if we’re talking about Dropbox, a user in Dropbox is created when someone goes to the Dropbox site and signs up for a subscription.
Service Account / Tenant
For SaaS companies, often there’s a “tenant” or Service Account that is provisioned to get service. This is part of the company’s proprietary system. When a new account is created, a system-generated Service Account ID is assigned to it. All users within a tenant are associated with this same ID.
Carrying forward the example of Dropbox, a service account is the “dropbox” that’s created for a user when they sign up (and also applies to their teammates who use the same one).
Clickstream User (optional)
For products that are web based (and most developer platforms are 90% not web based, but rather API based), Clickstream User data is instrumentation data about how users click around in the product. This data can have some gaps in it, but is directionally correct. Tools like Amplitude, Mixpanel, and Pendo collect clickstream data. They assign their own ID to each Clickstream User.
Tip: When an engineering team implements one of these tools, they should ALWAYS put the Transactional User ID and Service Account / Tenant ID in the capture as well. This information means a user’s click data can be connected to their transactional data and to their service account. This setup enables the company to see how all users within a service account/tenant are interacting with the product and what transactions they are doing.
CRM Account
A customer relationship management account tracks users at the company level. For instance, if the Transactional User created a Dropbox account using a work email address of mona@google.com, Google would be the CRM Account.
A CRM account can map to one or many Service Accounts and many users. For instance, many users at Google may have created independent Dropbox accounts for sharing and collaboration.
Tying Service Accounts and Transactional Users to a CRM account through ID resolution is only possible if the users use a corporate domain for signup. As much as GTM teams would like to get a solution that can tell them that mona@gmail.com works at Google, this is simply not possible and any solution that claims to do this is selling snake oil.
Even if users use a work domain name, the issue isn’t one of simple string matching because many companies have many domains, such as google.co.uk, google.co.fr, etc. More on how to solve this in the next section.
Contact
Contacts are CRM entities that could have been created in a myriad of ways, such as via ZoomInfo, purchased through a list, found on LinkedIn, etc. Contacts are associated with a CRM account but have no direct relationship with Transactional Users or Clickstream Users.
For example, a company’s sales team could buy names and contact information for 50 people who work at Google and add them to the CRM. This is not related to whether they use a particular product or not.
Lead
Leads are CRM entities that could have been created in a myriad of ways, such as a site visitor submitting a request for a demo, or someone downloading a paper or attending an event. Much like Contacts, there is no direct relationship between Leads and users of a product.
Step by step linking of IDs
Given there are many different entities that need to be connected, multiple techniques are necessary to make all the connections. Here are my tips.
Visitor <--> Lead
The best way to connect a Visitor ID to a Lead is to use a Hubspot or Marketo tracker. Both services will automatically, retroactively map Visitor ID to Lead when a visitor submits a request of some form (such as scheduling a meeting with sales).
As much as we love ungated content, after the initial stream of ungated content, a company should aggressively pursue Lead creation for this reason, among others.
Visitor <--> Transactional User
This connection can typically be made within a company’s proprietary system. When a Visitor signs up as a user of a company’s product or service, associate their Visitor ID with the new Transactional User ID and retroactively associate all the web visit data associated with that Visitor ID to the new Transactional User ID.
Lead ← Visitor → Transactional User
With the two connections formed above, it’s now also possible to connect a Transactional User (someone who signed up for a new Dropbox account) to a Lead (the same person coming to the website and requesting pricing from sales).
Service Account <--> Transactional User <--> Clickstream User
This loop is closed simply by making sure that a company’s engineering team instruments clickstream data with Transactional User ID and Service Account ID. No magic solution outside of this.
CRM Account <--> Service Account
This one is a little more complex and will depend on your particular systems.
Roughly speaking:
- Pull out domain names from Transactional Users associated with a Service Account
- Do a heuristic match with key 3rd party systems like Crunchbase (Shameless plug: Falkon just does this for you!)
- Connect Service Account IDs with the right CRM Account
Contact <--> Transactional User
There are two ways to tie a Contact to a Transactional User.
- Simple but fewer matches: Do an exact match on email address. This tactic is not always effective because many contacts don’t have the right (workplace) email addresses associated with them and data enrichment services only go so far.
- Complex but more matches: Do a heuristic match on name and email address, and instead of looking for exactness, you’re looking for approximate matches. This method results in more matches but is harder to build. (Shameless plug: Falkon does this with its Smart Stitch module.)
Lead <--> Contact
This one works exactly the same way as Contact ←> Transactional User
Summing it up
With all the links created, you can associate all entities in the PLG world with each other. You’ll get a complete view of how a company is using your product, and how they’re engaging with sales and marketing activities. This enables you to reach out to the right person with the right message at the right time to drive conversion and expansion, and minimize churn.
Want more perspectives like this? Follow Falkon on LinkedIn.