Account based marketing data: the six layers an ABM program needs, where each one comes from, and the matching problem that quietly breaks the list.

Definition

Account based marketing data is the company, people, behavior and signal information an ABM program needs to pick target accounts, reach the buying group inside them, and report results by account instead of by lead.

It is not one dataset bought from one vendor. This page splits it into six layers: identity and firmographics, corporate hierarchy, buying group contacts, technographics, intent and engagement. Each layer comes from a different place, ages at a different speed, and answers a different question for sales and marketing teams.

One piece of work decides whether the rest holds together, and this page gives it a full section: matching. Every record has to attach to the same account in the CRM, in the ad platform and in the report. When matching fails, accurate fields still produce a wrong list.

What account based marketing data has to answer

Write the questions before you buy fields. An ABM program makes the same five decisions again and again across its lifecycle, and each one needs its own evidence. A field that feeds none of them is a field you are paying to store, match and clean.

Those five decisions are the working core of an ABM program: identify the accounts, personalize the message, time the outreach, and measure the result. The strategy wrapped around them is covered in ABM strategy, and the reporting side in how to measure ABM. This page stays on the data layer underneath both.

The six layers of ABM data

Many teams call all of it "ABM data" and then discover the layers behave nothing alike. Separating them tells you what to buy, what to build, what to refresh monthly, and what will never be reliable enough to automate.

The first two layers describe the company. The third describes people, which is where privacy law lands. The last three describe context and behavior, and they are the layers marketing teams are often sold as if they were the whole ABM program.

Types of ABM data: mapping the vocabulary

Guides and vendors name the same data in different ways. The table maps the common labels to the six layers used here, so a proposal written in one vocabulary can be checked against a record built in another.

Account identity: naming a company once

Identity is the layer everything else hangs on. An ABM account record needs a value that does not change when the marketing team changes the logo, and one that survives being typed by three different people.

• The web domain is, in this page's view, the most useful working key in B2B. It is short, it is how work email addresses are formed, and the CRM and ad platform rules cited below accept it as a match field.
• The legal name is what appears on contracts and filings, and it is often not the name the sales team uses.
• The trading or brand name is what people search for and what a rep types into the CRM.
• A registry identifier ties the record to a filed entity in a national company register.
• A Legal Entity Identifier is a 20 character alphanumeric code under the ISO 17442 standard that identifies one legal entity.

GLEIF, which administers the LEI, publishes reference data in two levels: Level 1 answers "who is who" and Level 2 answers "who owns whom". GLEIF describes the LEI as a public good, available free, so it is a reasonable spine for any account that holds one.

Many target accounts will not hold an LEI, so treat it as a bonus rather than a requirement. Use it where it exists, and use the domain everywhere else. Storing both costs two fields and saves a rebuild later.

Firmographic and technographic data: does the account fit

Fit data decides whether an account belongs on the list at all. Firmographic data describes the company: industry, headcount, revenue, location and ownership. Technographic data describes what it runs. Together they turn an ideal customer profile into filters you can apply to a database.

Industry is the field most worth standardizing. The US Census Bureau describes NAICS as the standard used by Federal statistical agencies to classify business establishments, and its search takes codes from 2 to 6 digits. A shared code beats free text such as "SaaS" or "tech" typed by different reps.

Size is the field most worth questioning. A headcount or revenue figure often describes the group, while your buyer sits in one entity. Record which entity a number describes and where it came from. The origins of each company attribute are in firmographics source.

Technographics answer a sharper question: is this account relevant right now. A product you integrate with, a competitor tool near its renewal, or a missing capability in the stack each change how sales and marketing should approach the account, and which message leads.

Hierarchy and subsidiaries: which entity are you selling to

A target account is often not a whole company. It is a buying unit inside one: a division, a country organization, or a subsidiary that kept its own budget and its own stack after an acquisition.

Get this wrong and the ABM program breaks in two directions. Treat a global group as one account and you send one campaign to buyers who have nothing in common. Treat every subsidiary as its own account and your best customer looks like a stranger to the new team.

Your CRM holds the structure, with documented limits. In Salesforce, hierarchies follow the Parent Account field, the Lightning hierarchy page displays up to 2,000 accounts sorted by name, it hides accounts you have no permission to view, and person accounts are not supported for the Parent Account field.

HubSpot uses parent company and child company association labels. A parent can have several children, and a child company can be associated with only one parent, which forces a decision when a joint venture is owned by two groups.

Buying committee contact data: the people layer

Account data without people is a list of logos. The contact layer turns an account into something a sales rep can work, and it is the layer that decays fastest and carries the legal weight.

Coverage is the number that matters here, not volume. For each named account you want the roles that appear in a decision, with enough detail to reach them on more than one channel. Filling the gaps is a job for lead enrichment, checked against what reps learn on calls.

• Economic buyer: the person whose budget the purchase comes from, often one level above the requester.
• Champion: the person who wants the change and will argue for it internally when you are not in the room.
• End users: the team that lives in the product daily and whose complaints often start the search.
• Technical evaluator: IT, security or data, who can stop a deal on integration or compliance grounds.
• Procurement and legal: late arrivals who decide terms rather than fit, and who are easy to miss in a bought dataset.
• Blocker: the person who owns the current solution and reads your project as criticism of their choice.

Record which role each contact plays, not only the title. HubSpot, for example, ships a default Buying role contact property with options such as Decision Maker, Budget Holder and Blocker, and a contact can hold more than one role. A role field shows whether coverage is real.

Engagement data: what the account already did with you

Engagement is the only layer you own outright. It is first party by definition: site visits, content views, email replies, meetings booked, webinar attendance, support tickets, product usage during a trial.

In ABM it has to roll up to the account. On this page's view, three people from one company reading three different pages say more than one person reading three pages, and a lead level report will never show you that.

The roll-up needs a matching rule, which is the same problem as everywhere else on this page. A form fill with a personal email address and no company field sits unattached unless something links it back to the account record.

Keep the raw log, not only a score. Scores are opinions with a number attached, and when the weighting changes you need the underlying events to recalculate, rather than a history of old scores nobody can explain.

Intent data and buying signals in ABM

Intent data reports research activity on topics you sell into, attributed to a company rather than a person. It answers whether something is moving at an account, and some vendors present it as if it were the whole of ABM data. The full treatment is in B2B intent data.

Signals reach an ABM program from two directions. First party signals come from your own site, your own content and your own sales conversations, so you own them. Third party intent signals come from publisher co-ops and review sites, already attributed to an account by the provider.

The split matters because it decides what you can verify. A first party signal has an event log behind it. A third party intent signal is somebody else's judgment that a company was researching a topic, and you cannot audit the matching that produced it.

Two cautions belong in the data layer. You inherit a provider's matching errors along with their signals. And a surge score is a claim about a topic at an organization, not proof that the person your sales team is about to email was researching anything.

None of it should be quoted back to a prospect. Naming what you saw someone research reads as surveillance. Let signals choose the topic and the time, then write as though you guessed well.

Account lists: from the ICP to a named list

The account list is where the data becomes a decision. Fit data narrows the market to an ideal customer profile, a person signs off on the named accounts, and every downstream tool reads the same list rather than keeping its own copy.

CRMs and marketing platforms store that decision in their own way. HubSpot uses a Target account checkbox on the company record and an Ideal customer profile tier property with three tiers, where Tier 1 is a great fit and Tier 3 might be acceptable but low priority.

HubSpot's documentation also describes a workflow template that assigns a tier from annual revenue, as an example to customize with other properties such as industry and country. That is a firmographic rule writing directly into the list, so the field it reads has to be trustworthy.

In Adobe Marketo Engage, an account list is a collection of named accounts targeted together, and a dynamic account list is generated from a CRM account view that syncs every 8 hours. Marketo only displays insights for account lists with 2,000 or fewer named accounts.

Two habits keep lists honest. Store why each account is on the list and who added it, and keep a list of accounts you decided against, with the reason. Building and tiering the list itself is covered in target account list.

Account scoring with ABM data

Account scoring ranks accounts that already fit, so the team knows where to spend time this week. It is not a substitute for the list. A score built mostly from signals promotes noisy accounts, while a score built only from fit never changes.

The formula used on this page keeps the two apart. Fit acts as a gate and a base, then engagement and intent add points. HubSpot, for one, lets you create custom score properties for companies, so a rule like this can live on the company record.

The weights above were written for this page as round illustrative numbers. They are not a benchmark, and your own weights should come from looking back at which accounts actually bought.

This worked example was written for this page with made-up accounts. Account B shows why fit comes first: the surge alone does not lift a weak fit above an engaged tier 1 account.

Where each piece of ABM data comes from

Every field has a source family, and the family predicts its failure mode. Knowing the origin tells you whether to trust a disagreement between two vendors, and which value to check by hand before it reaches a list.

The general picture of where business records originate is in B2B data. This page assumes you know the source families and are now assembling one account record from several of them.

Questions to ask an ABM data provider

No rankings here. These questions work for any provider and any layer, and the answers matter more than a coverage claim measured on someone else's market.

• Source: where does each field come from, and can you show it per record?
• Date: when was each value last verified, and is that date delivered with the data?
• Matching: how do you attach signals and contacts to an account, and on which keys?
• Entity: does a headcount or revenue figure describe the group or the entity?
• Lawful basis: what basis do you rely on for contact data, and how do you support the notice duty?
• Overwrites: can a refresh be told to leave a researched value alone?

Account matching: the problem guides skip

Matching is the work of deciding that two records describe the same account. It happens at import, at enrichment, at form fill, at list upload, and again inside every report that groups activity by account.

The failure is quiet. Nothing errors. The record simply lands next to the right one instead of inside it, and the account then looks less engaged than it really is.

Look at how a CRM documents it. Salesforce ships a standard account matching rule whose equation fires on any of: account name with billing street, account name with city and state, account name with ZIP, account name with phone, website with phone, or website with billing street.

The fine print is documented too. For accurate matches the record needs an account name plus either city or ZIP. Account name is compared with acronym, edit distance and exact methods at a threshold of 70, website matches exactly at 100, and phone matching works best with North American data.

Salesforce also documents the normalization: its company name matching removes words such as "Inc" and "Corp" before comparing, and normalizes "IBM" to "International Business Machines". It warns that its fuzzy dictionaries are not comprehensive, and recommends exact matching for international data.

Read that as someone supplying data to your own program. A rule leaning on city, ZIP, street and phone behaves differently on a list of remote first software companies than on a list of regional manufacturers with one office each.

Why account matching fails

These are the ordinary failures this page sees described again and again. None of them look like errors on a dashboard, which is why the list belongs with whoever administers your CRM.

• Name variants: the legal name, the brand, the abbreviation and the old name before the rebrand all describe one account.
• Subsidiaries: a record matches a sister company with a similar name and lands under the wrong parent.
• Shared addresses: serviced offices and registered agent addresses put unrelated companies at one street and ZIP.
• Domain sprawl: country domains, product microsites and acquired brands all belong to a single account.
• Free email addresses: a form fill from a personal mailbox has no company domain to match on at all.
• Regional formats: phone and address logic tuned for one region scores badly in another.
• Empty fields: a rule that needs city or ZIP finds nothing when the enrichment left both blank.
• Provider matching: third party data arrives pre-matched, so you silently import someone else's judgment.

Match keys that survive real data

Order your keys from strongest to weakest and stop at the first confident hit. Everything that falls through goes to review, not to a new account record created automatically in the background.

Normalize before comparing. Lowercase the string, strip the entity suffix, drop punctuation, and keep the original in a separate field so nothing is lost. Then store every alias you have ever seen against the account.

The alias table is the piece that is easiest to skip. It lets a record naming an acquired brand from years ago land on the right account today, and it costs one extra object in the CRM. A data strategy for ABM is mostly this: a matching policy plus a refresh schedule.

Matching again at activation

Your list gets matched a second time by whatever platform runs the ABM campaign, and that match is outside your control. Budget for the shortfall instead of being surprised by it after the media is booked.

LinkedIn company list targeting is a clear published example. It matches uploaded companies to LinkedIn Pages using at least one of company name, company website, company email domain, LinkedIn Page URL or stock symbol, and says more information improves match rates. Generating the audience can take up to 48 hours.

The published size rules shape list design. An upload needs at least 300 rows, the maximum is 20 MB or 300,000 companies, and the list must match at least 300 member accounts before it can run in an active ad set. LinkedIn recommends 1,000 or more companies.

Two more rules matter for data upkeep. A company list audience expires if it is not used in an active or draft ad set within 90 days, and LinkedIn's best practices name location as a required targeting facet, which can shrink a matched audience further.

That has a direct planning consequence. A one-to-one tier of twenty accounts cannot be an advertising audience by itself, so tiering has to account for the platform floor. HubSpot can sync target accounts or one ICP tier to a LinkedIn matched audience, which makes the tier field itself an activation input.

What ABM data changes in outreach and content

Account data earns its cost at the moment somebody writes something. Every layer maps to a sentence a sales rep or a marketer can defend, and any layer that never reaches the outreach or the content is a layer you are storing for a report.

The rule for signals in outreach is short: they choose the topic and the time, never the opening line. ABM content works the same way. Build assets per segment and per role, then let account data decide which account sees which one.

This is where poor data quality becomes visible outside the ops team. A wrong entity name, a contact who left, or a signal matched to the wrong company all land in front of a buyer, and sales teams can lose trust in the target account list quickly.

Data hygiene at the account level

Contact data hygiene is a familiar job for many sales teams. Account hygiene is a different one, because the damage shows up as duplicate accounts, split engagement and two reps working the same company from two separate records.

• Duplicate accounts: the same company entered twice under different names, splitting its history in half.
• Orphan contacts: people with no account attached, invisible to every account level report you run.
• Stale hierarchy: parent fields that describe an ownership structure which changed some time ago.
• Dead domains: an acquired company whose site now redirects, leaving the old record unmatched.
• Silent overwrites: enrichment replacing a researched value with a vendor estimate and no record of the change.
• Zombie accounts: rows kept on the list because the logo is famous, not because the account fits.

Merging is the repair, and merges lose things. Decide in advance which record survives, what happens to the losing record's activity, and who may run a merge at all. The process is in CRM data cleansing.

Aging is the other half. Every layer decays on its own clock, and the mechanics are in data decay. Stamp each field with the date it was last verified, and refresh by field rather than refreshing the whole database at once.

An account data quality check

Run this data quality check before the ABM program launches, then quarterly. Each row is a count you can produce from your own CRM without buying anything, and each one has an owner who can fix what it exposes.

The last row puts a number on the gap between the list you designed and the audience a platform could actually reach, and it often points to the identity field that was missing.

Privacy obligations on account based marketing data: GDPR and the UK

Nothing here is legal advice, and the rules differ by country. What follows is what the source texts say, so you know which questions to take to counsel before an ABM program launches.

Under GDPR Article 4, personal data is "any information relating to an identified or identifiable natural person". A named work contact is personal data, and the ICO says the UK GDPR still applies to B2B marketing when you process personal data, such as the name of the person who represents a business.

Processing needs a lawful basis under Article 6. Point (f) allows legitimate interests unless the person's interests or rights override them, and Recital 47 says direct marketing may be regarded as a legitimate interest. The ICO describes a three-part test of purpose, necessity and balancing.

The ICO calls the recorded outcome a legitimate interests assessment, a type of light-touch risk assessment, and says you should keep an audit trail of your decisions. In an ABM program the purpose is narrow enough to write down in a paragraph.

Article 14 is the one bought account data triggers. Where personal data was not obtained from the person, you must tell them, including the source of the data and whether it came from publicly accessible sources.

The deadline is a reasonable period, and at the latest one month. If you use the data to contact them, the notice is due at the latest with the first communication.

Article 21 gives a right to object to direct marketing at any time. Once someone objects, the data must no longer be processed for that purpose, and the right must be brought to their attention by the first communication. In practice that means a suppression record that survives your next import.

Article 5 adds principles that behave like data quality rules: data minimization, accuracy with "every reasonable step" taken to erase or rectify, storage limitation, and accountability. ICO accuracy guidance says the source and status of personal data should be clear, with more effort where accuracy matters more.

Electronic marketing adds a separate layer in the UK. The ICO states that the PECR rule on electronic mail marketing does not apply to corporate subscribers, while sole traders and some types of partnerships are individual subscribers with the greater protections individuals get.

What counts as personal data in an account record

This table is this page's reading of the definition, not a legal ruling. Splitting the record along this line makes retention, suppression and vendor contracts easier to reason about, and stops a team treating the whole account as untouchable or as exempt.

Ask every provider two questions before signing: what lawful basis they rely on for collection, and how they support your Article 14 notice. A provider that cannot answer either is a risk you are importing into your own database.

ABM data under US rules: CAN-SPAM and California

US rules reach ABM data through the email you send and the people you hold records about. Two primary texts matter most for a typical program: the FTC's CAN-SPAM guidance and the California Privacy Protection Agency's FAQ.

The FTC says CAN-SPAM covers all commercial messages and makes no exception for business-to-business email. Each message needs a valid physical postal address and a clear way to opt out, which must keep working for at least 30 days after you send.

Opt-outs have to be honored within 10 business days, and once someone opts out you cannot sell or transfer their email address. For account data that is the same lesson as GDPR objections: the suppression record has to outlive every import and every tool change.

California is the state to check first for contact data. The CPPA says the CCPA exemption for personal information reflecting business-to-business transactions expired on December 31, 2022, and that California residents include contacts for business customers and vendors. Business contacts can therefore hold CCPA rights, if your business falls under the law.

Data you buy may come from a data broker, which California defines as a business that knowingly collects and sells personal information of consumers it has no direct relationship with. Brokers must register annually, and the agency's Delete Request and Opt-out Platform lets a consumer send one deletion request to every data broker.

Once an account becomes a customer, its records become customer data, with its own consent, retention and rights questions. Keep the line between prospect records and customer records visible in the CRM, because the rules and the expectations differ.

Building the account record, field by field

Here is the smallest account record that, on this page's view, supports a real ABM program. Add fields when a decision needs them, not because a vendor supplies them, and give every field an owner and a refresh rule before it goes live.

1. Start with identity

   Account name as used internally, legal name, primary domain, an alias list, country, and a registry or entity identifier where one exists.

2. Record the hierarchy decision

   Parent account, the entity you actually sell to, and a note saying who decided and when. That note is what stops the same argument every quarter.

3. Add fit attributes

   Industry code, headcount for the entity, and the technographics that make you relevant. Keep the source and date beside every value you will use for selection.

4. Set list status and tier

   Target account flag, ICP tier, the reason the account is on the list, and who added it.

5. Name the buying group

   Contacts with a role field, not only a title, and a coverage count you can report on.

6. Attach engagement

   Roll every first party event up to the account, keep the raw log, and make sure unmatched events land in a queue somebody works.

7. Layer signals last

   Intent topics and dates, plus triggers such as funding or a new leader. Signals prioritize a list that already exists. They do not build one.

8. Stamp and govern

   Source and verified-on date per field, an owner for each layer, a suppression flag that survives imports, and a retention rule for contact data.

Who owns which layer

Unowned data rots faster than data anyone argues about. Name a person per layer, and make the refresh part of a normal week rather than a project someone launches after a bad quarter.

Tool categories behind ABM data

No vendors, no ranking and no prices. These are the categories that do the work, and many teams combine several of them rather than expecting one platform to cover all six layers.

Common ABM data mistakes

• Buying intent before identity, so hot signals attach to accounts the CRM cannot match.
• Treating a global group as one account, then wondering why the campaign speaks to nobody.
• Counting contacts instead of coverage, which hides the fact that no budget owner is named.
• Scoring accounts on signals alone, so poor fits with a surge outrank engaged good fits.
• Letting enrichment overwrite researched values silently, so the best field on the record disappears.
• Designing a twenty account tier as an ad audience, well below the platform floor.
• Scoring engagement at lead level, so three people from one account never add up.
• Accepting a provider account match without asking how it was made.
• Keeping an objection or opt-out in one tool, so the next import brings the person straight back.
• Reporting a match rate nobody defined, measured against a list nobody kept.

In a sequence

When the account based marketing data is right, the first email is short and specific to one entity, not to a logo. The template below was written for this page: it names the unit, one relevant fact, and asks who owns the problem.

Subject: {{entityName}} and {{problem}}

Hi {{firstName}},

I am writing to {{entityName}} specifically rather than {{parentGroup}}, because {{relevantFact}} looks like it sits with your team rather than with the group.

Teams in that position usually deal with {{problem}} before anything else. We work on exactly that.

Are you the right person for it, or should I be asking someone else?

{{senderName}}

Frequently asked questions