Account matching
Kernel will look across all accounts and match them to our accounts universe. Each entity in Kernel’s universe comes with rich context: Legal and trading name, previous names, previous websites, online handles (LinkedIn, social media, etc.), address & location data, as well as raw, unstructured data (website, job descriptions, PDFs). We use the data in your CRM to match your accounts to our accounts universe.
Traditional enrichment vendors over-index on the website, but:
(a) not all companies have one, and
(b) it’s easy to mistake an individual store hosted on Amazon for Amazon itself.
Credit bureaus rely on company names, often legal names, which:
(a) differ from trading names,
(b) need mapping to websites to be usable in a CRM, and
(c) are required for any website-based enrichment.
To do this, we need to ensure the identity of the account is coherent so that we match to the right entity.
When Kernel detects a conflict between a company’s name and its website URL, the Account identity mode setting controls which source of truth is prioritized. The key question here is: what would your rep consider the identity to be if they only had the URL and Name?
Kernel’s approach unifies both:
We combine name-based and URL-based resolution, layered with structured and unstructured data (account data & notes, the existing LinkedIn profile, and associated objects like contacts and opportunities). This avoids false positives (e.g. “Amazon seller” ≠ Amazon) and ensures coherence across name, URL, and metadata.
Identity modes
Bias towards URL (default) Kernel prioritizes the company’s website URL.
Best when website domains are generally reliable.
Ensures the live domain is trusted over variations in naming.
Bias towards Name Kernel prioritizes the company’s name.
Uses the name to infer the correct URL.
Best when names are standardized in your CRM and domains may vary.
Name only Kernel relies entirely on the company’s name.
Ignores other signals and uses only the inferred URL from the account name.
Recommended only for very clean and consistent naming conventions.
Data Considered
When Kernel resolves account identity, it draws on multiple sources of information — called anchors — to decide which company each CRM record truly represents. These anchors fall into four main groups, each contributing a different kind of signal.
1. Website Anchors
These are all the data points that tell us where a company exists online.
They include the company’s main website, any alternative URLs listed in your CRM, and checks to see whether those websites are still active. Kernel uses these signals to determine which domain is authoritative and up to date, resolving issues like redirect loops, rebrands, or outdated links.
2. Name Anchors
These cover everything that describes who the company is.
Kernel looks at the company’s legal and trading names, any variations or inferred names, and contextual clues like address, country, or associated opportunity names. This helps Kernel distinguish between entities that sound similar — for example, “Champneys Health Spa,” “Champneys Springs,” and “Champneys Ltd” — and recognize when they’re actually the same business.
3. LinkedIn Anchors
These verify a company’s digital identity on LinkedIn.
Kernel uses LinkedIn company pages and their listed websites to confirm that what’s in your CRM matches real, verified business entities — and not lookalike or placeholder profiles. This is especially valuable for resolving duplicates or ambiguous company names.
4. Domain Hints
These are softer clues that support the main signals.
They include things like the domains used in employee email addresses, billing emails, or related websites. While they don’t define identity on their own, they help validate that the CRM record is referring to the same organization as the website and LinkedIn profile.
Best practice
Most teams should leave this on the default Bias towards URL. Only switch to Bias towards Name or Name only if you’re certain your naming conventions are stronger than your URL data. This is often not the case, so change with caution.
For each match, we provide a confidence score of Low, Medium, or High. This is based on the available data in your CRM to make the match, along with the coherence of that data. If we have a lot of data pointing to the same identity, this will have higher confidence than a 1 or 2 conflicting data points, especially when these are on generic names.
Last updated