Data points definition, the B2B data points a sales team really uses, and how to pick the few that change a message.

Definition

Data points are single recorded values, each describing one thing at one moment: a company's employee count, a person's job title, the date an email bounced. The working data points definition on this page is a value, plus the unit it describes, the time it was observed, and the source it came from.

Dictionaries get you most of the way there. Cambridge Dictionary defines datum, the rarely used singular of data, as "a single piece of information". A data point is that single piece placed inside a set, where it can be compared, counted, sorted or plotted against the others.

In B2B sales the unit is nearly always an account or a contact. A data point is then one value on one account record or one contact record, and a prospect list is many records with the same data points filled in.

The data points definition in full, from the dictionary to NIST

Short definitions stop at "a piece of information". That is true and it is not enough to work with, because a value on its own cannot be checked, compared or trusted. The more precise definitions come from standards and statistics, and each one adds a part a sales database needs.

Data element and attribute in the NIST glossary

The NIST Computer Security Resource Center glossary carries the Privacy Framework definition of a data element: the smallest named item of data that conveys meaningful information. Named matters. A value with no name and no unit is noise, however accurate it happens to be.

The same glossary defines an attribute, citing ISO/IEC 24760-1, as a characteristic or property of an entity that can be used to describe its state, appearance, or other aspect. The attribute is the property, such as job title. The data point is the value that property takes for one entity at one time.

Observations and points in statistics

Statisticians use observation and point for the same thing. In the NIST/SEMATECH e-Handbook of Statistical Methods, an outlier example works through a data set of 90 ordered observations, then finds the median as the average of the 45th and 46th ordered point. One value, one observation, one point.

NIST also separates numbers from the process that made them. Its glossary defines measurement as the process of obtaining quantitative values using quantitative methods, and measures as the quantifiable and objective values that result from measurement. A quantitative data point is a measure, and it is only as good as the measuring.

Three things the short definition leaves out

Three parts decide whether a data point is usable in sales, and none of them appear in a one-line definition:

• Time: when was it observed? A headcount without a date cannot be told apart from one that is two years old.
• Source: who observed it, and how? NIST calls this provenance and, in the Privacy Framework sense, defines it as metadata pertaining to the origination or source of specified data.
• Confidence: is this a fact or an estimate? Inferred data points need a label saying they were inferred, so nobody quotes a guess to a buyer.

Data point vs data set vs metric vs insight

These words get used interchangeably and they are not the same thing. The difference is the reason two teams can argue about "the data" while describing different objects. The table puts each one next to a B2B example written for this page.

Read it as a grid. The field is the column heading, the record is the row, the data point is the cell, and the data set is the whole sheet. Cambridge Dictionary defines a field as a division of a database that contains a particular type of information, such as names or numbers.

Cambridge defines a dataset as a collection of separate sets of information that is treated as a single unit by a computer. That matches how a prospect list behaves: you filter, export and import it as one thing, while each record inside it ages at its own pace.

Data point vs metric

The NIST glossary defines metrics as measures and assessment results designed to track progress, facilitate decision-making, and improve performance with respect to a set target. Two parts of that matter: a metric is built from many measures, and it points at a target.

That is why a metric cannot be enriched or verified the way a data point can. You can check one contact's email. You can only recalculate a bounce rate, after fixing the data points underneath it. Treating a metric as a field is a common source of confusion in reporting.

Data point vs insight

Cambridge defines insight as a clear, deep, and sometimes sudden understanding of a complicated problem or situation. No single data point holds one. A headcount of 240 is a fact. A headcount that rose across a whole segment, compared with your win history there, may become an insight.

The steps between the two, from data to information to a decision, are covered in the entry on data insights. This page stays with the first step: getting each data point right, so whatever analysis comes later is built on values someone can trust.

Types of data points

Several splits are in use, and they answer different questions. Format decides how a value is stored and filtered. Origin decides how far it can be trusted. Stability decides how often it must be checked again. A sales team needs all three, not only the first.

Measured and classified data points

The NIST/SEMATECH handbook draws a useful line. Some quality characteristics can be measured and expressed numerically, such as weight or thickness. When that is impossible or impractical, an item is sorted into classes such as conforming or nonconforming, and those characteristics are called attributes.

B2B data splits the same way. Headcount, revenue and dates are measured data points. Industry, seniority, function and company type are classified data points, assigned to a named bucket. Classified points carry a hidden risk: two sources can use different buckets for the same company.

Observed, reported, inferred and derived

An observed data point was recorded directly, such as a form submission, a transaction or a bounce. A reported data point came from the subject, such as a profile headline. An inferred data point was estimated from a pattern. A derived data point was calculated from other data points, such as growth over a period.

Write the origin next to the value in your own system. In this page's view it is the cheapest quality control there is, and it decides which data points you may reference in outreach without sounding like you have been watching someone.

Examples of data points by format

• Numbers: employee count, annual revenue, number of locations, days since last contact.
• Text: a job title, a company description, a note from a discovery call.
• Categories: industry, seniority, lifecycle stage, lead source.
• Dates: founding year, the date a role started, the date a value was last verified.
• Files, images and audio: a signed document, a logo, a recorded call, each stored as one value on one record.

Data points in data analysis, statistics and other fields

The term comes from statistics and data analysis, not from sales. In analysis a data point is one observation inside a data set, and analysis is the work of turning many observations into information somebody can act on. The statistical habits behind that work transfer well to a sales database.

Exploratory analysis and plotting

The NIST/SEMATECH handbook describes exploratory data analysis as an approach that uses mostly graphical techniques to maximize insight into a data set, uncover underlying structure, and detect outliers and anomalies, among other aims. Plotting the points comes before modeling them.

The handbook defines a scatter plot as a plot of the values of Y versus the corresponding values of X. Each marker is one data point with two values. The handbook also warns that scatter plots reveal association, and that no statistical procedure, the scatter plot included, proves cause and effect.

Outliers: when one data point looks wrong

In the handbook, an outlier is an observation that lies an abnormal distance from other values in a random sample from a population. It also notes that the definition leaves it to the analyst, or a consensus process, to decide what counts as abnormal.

The handbook lists bad data as one reason for an outlier, for example a value coded incorrectly. If a point is shown to be erroneous it should be deleted or corrected. It also cautions that an outlying observation is typically not simply deleted, because it may reflect random variation or something genuinely interesting.

The same rule fits a CRM. A headcount of 3 on an account you know is large is probably a coding error. A sudden jump may be a real acquisition. Investigate before you overwrite, and record what you found next to the value.

How many data points an analysis needs

Sample size is a different question from fields per record. On sample size, the NIST/SEMATECH handbook is blunt: asked how many measurements to include, there is no correct answer without additional information or assumptions, such as the risks you accept and the spread of the values.

For a sales team the practical reading is to be careful with conclusions drawn from a few dozen records. The data insights entry works through sample sizes for reply rate comparisons. This page sticks to the other count: how many data points a single record needs.

Examples of data points in other fields

• Business analytics: one transaction amount, one order date, one store's revenue for one day.
• Product analytics: one session, one click, one feature used by one user in one customer account.
• Energy management: one meter reading of electricity demand, from one meter, at one timestamp.
• Operations: one temperature reading from one sensor at one time.
• Marketing: one ad impression, one form submission, one unsubscribe.
• Customer service: one ticket, with its category, its customer and its resolution time.

The examples differ and the structure does not. Each is one value, about one unit, at one time, from one source. The types of data points vary by format and by origin, never by that underlying structure.

Real-time data points, platforms and access

Some data points arrive in batches, such as a monthly export from a data management platform. Others stream in real time, such as website events or sensor readings. Real-time access matters when the value of a data point fades within hours, which is true of some buying signals.

Business intelligence tools and dashboards read the same data points. They provide summaries and trends, not new facts, so a wrong value in a field becomes a wrong number on a chart.

In a sales stack the practical question is access, not storage. A data point nobody can filter, sort or trigger a workflow on is stored rather than available, and it will not change a single message.

Predictions, bias and inferred values

Prediction works on many historical data points at once. A model finds patterns and trends, then can provide estimates for new records: a likely industry, a probable company size, a score for how likely an account is to buy. Those outputs are inferred data points, not observed ones.

A data set can also be biased in what it collected. If your records come mostly from one region or one company size, any pattern found in them describes that slice, not the market. Note how the data was collected before you generalize from it.

B2B data points: the four families you actually work with

In practice, b2b data points fall into four families. Almost every field in a sales database belongs to one of them, and each family answers a different question about a deal.

The families map onto the vocabulary used across B2B data: firmographic, contact, technographic and chronographic or intent data. Providers name them differently. The four questions behind them stay the same.

Firmographic, contact, technographic and intent data

Knowing the mapping helps when you compare B2B data providers. Two providers can describe identical B2B data points in different vocabulary and package them as different products, so compare the fields and their definitions rather than the product names.

Sales teams and marketing teams tend to use the families differently. Marketing segments campaigns on firmographic and technographic data across many companies at once. Sales teams need contact data and signals on a handful of named accounts inside the CRM.

Account based programs sit between the two and add layers such as hierarchy and buying committee roles. Those layers are covered in the entry on account based marketing data; this page stays with the individual values inside each layer.

Company data points

Company data points, sold as firmographic data, describe the organization. They are the backbone of an ideal customer profile, because they are the fields you can filter a whole market on before you know a single name.

• Identity: legal name, trading names, domain, registration number, parent and subsidiaries.
• Size: employee count, headcount by department, revenue band, number of locations.
• Classification: industry, sub-industry, business model, public or private, company type.
• Geography: headquarters, office locations, regions served, languages.
• Trajectory: headcount growth, funding stage, recent rounds, expansion into new markets.

LinkedIn Sales Navigator is a useful check on which company data points a sales tool exposes. Its documented company attribute filters for accounts are annual revenue, company headcount, company headcount growth, headquarters location, industry, number of followers, department headcount, department headcount growth and Fortune.

Two details in that documentation are worth noticing. Headcount growth is defined over the last 12 months, so it is a derived data point with a built-in window. Annual revenue is described as reported revenue. Both labels tell you how far to trust the value before you quote it.

That list is short. In this page's reading, that is because a filter only works when its value can be kept for a very large number of companies. Anything more specific than that, you will usually be collecting yourself.

Person data points

Person data points, sold as contact data, describe the individual inside the account. In this page's view they are the most useful and the most perishable set you hold, because a person's role, title and email change with every job move while the company stays the same.

• Identity: first name, last name, preferred name, profile URL.
• Role: job title, function, seniority, department, reporting line, years in role.
• Reach: work email, alternate email, direct dial, switchboard phone numbers, messaging handles.
• Context: previous employers, tenure, skills listed, groups, education, languages.
• History with you: pages viewed, emails opened or replied, meetings, past deals, support tickets.

Sales Navigator groups its lead filters in a way worth copying: company, role, personal, buyer intent, best path in, recent updates and workflow. That separates fit, identity, timing and relationship. Many CRM layouts show all four on one flat screen.

The last group in the list above, your own history with the person, is the only family nobody else can sell you. It is first party customer data when the person already buys from you, and it is easy to forget to keep it current.

Technology data points

Technology data points, sold as technographic data, record what a company runs: CRM, marketing automation, cloud host, analytics, payment stack, support desk, security tools. They matter when your product replaces, extends or integrates with something specific.

Many of them are inferred. A scanner sees a script tag, a DNS record or a job posting and concludes a tool is in use. That is evidence, not a statement from the company. How each method works, and where it misleads, is covered in the entry on technographics.

Used well, one technology data point turns a generic pitch into a relevant one: the integration you already have, the migration you handle, the gap their stack leaves. Used badly, it becomes "I see you use X", which reads as automated because it is.

Signal and timing data points

Signal data points, sold as chronographic or intent data, are time-stamped events rather than attributes. They do not tell you whether an account fits. They tell you whether this week is better than last week for reaching out.

• Company events: funding, acquisition, new office, product launch, layoffs, regulatory filing.
• People events: a new leader in a relevant function, a promotion, a departure, a hiring push.
• Behavioral events: pages visited, content downloaded, review sites browsed, topics researched.
• Relationship events: a reply, a meeting, a referral, a former colleague joining the account.

Sales Navigator exposes some of these as filters, each with a window: changed jobs in the last 90 days, posted on LinkedIn in the last 30 days, and leads at accounts showing high or moderate interest in your company in the past 30 days.

Its help page says that buyer intent is determined by InMail and ad engagement, company page views and profile views. That makes it an observed signal about your own company, not a general statement about what the account is researching.

Every one of those filters carries a window, and that is the lesson. A signal without a date is not a signal. Store the event date, not just a yes or no, so a later filter can tell this month's news from last year's.

Data points in a CRM: fields, properties and column types

A data point is only useful where a person or a workflow can reach it, and in sales that usually means the CRM. Each CRM calls the slot something different: HubSpot says property, Microsoft Dataverse says column, many teams just say field. The data point is the value inside it.

Field types decide what a data point can be

HubSpot's knowledge base says that when you create a custom property, the type of information you want the property to collect and store determines the field type. Its types include single-line text, multi-line text, phone number, number, date picker, dropdown select, multiple checkboxes, single checkbox, file and URL.

Microsoft Learn lists the column types in Dataverse, including Choice, Choices, Currency, Date Only, Date and Time, Decimal Number, Email, Lookup, Phone, Text, URL, Whole Number and Yes/No. It also names system columns such as Owner, Status and Status Reason that the designer cannot add.

The mapping above was written for this page as an example. The point it makes is practical: a classified data point such as industry belongs in a pick list, not free text. A free-text industry field collects spelling variants that no filter can group.

Derived data points inside the CRM

Some CRM fields hold derived values. HubSpot describes calculation properties that store equations based on properties of associated records, and rollup properties that calculate Min, Max, Count, Sum or Average across records of a selected object.

A rollup sits close to a metric: it is computed, it updates itself, and it cannot be enriched. Label such fields as calculated so nobody tries to correct them by hand or buy a vendor value for them.

Date and source beside every value

HubSpot's property history shows, for a property on a record, the value it changed to, the date and the source of the change, and you can filter that history by source. That is the same date and source this page asks you to keep beside each data point.

Three failures repeat in transit. Data points arrive without a date. Data points land in free-text notes where no filter can see them. Or two sources write to the same field, and the last import silently overwrites the verified value. Decide which tool is the system of record for each field.

Which data points matter for targeting and personalization

Which data points matter for targeting is a different question from which are available. Targeting needs data points that split the market. Personalization needs data points that change what you would have said anyway. The scoring below is this page's view, not a measured result.

The test for a targeting data point is simple: if you split your list by it, do the two halves deserve different messages? If not, it is a reporting field. Keep it if you report on it, but do not let it slow down list building.

The test for a personalization data point is stricter. If you deleted the sentence containing it, would the email still make sense? If yes, the data point decorated the message instead of changing it.

The few data points that change a message

In this page's view, a strong first email leans on about three data points. One says why this account, one says why this person, one says why now. Beyond that, extra merge fields tend to read as a list of things the sender looked up.

None of these is the recipient's first name. Name, company name and job title are easy for any sender to merge because they are almost always populated, which is exactly why, in this page's view, they personalize nothing on their own.

How many data points does a record need?

Start from the decision, not the field list. Salesforce's Trailhead module on data quality makes the first step of assessing data quality working out how the company uses customer data to support its business objectives, then lists the data each objective needs.

In the module's example, scoring and routing leads needs eleven fields: name, company, email, address, phone, number of employees, annual revenue, industry, status, owner and lead source. Advertising new services needs eight. The count follows the job, and it differs by job.

This page's view for an outbound record

Fewer than your CRM offers and more than a name and an email. A workable minimum for an outbound first touch, in this page's view, is around six to ten data points per record, spread across the four families, with a date on every volatile one.

• Two to three company data points to prove fit: industry, size, and one qualifier your product depends on.
• Two to three person data points to prove you wrote to the right human: function, seniority, verified email.
• One technology or model data point if your product only fits certain stacks or motions.
• One dated signal if you have one, left empty if you do not.
• One relationship data point from your own records: prior contact, shared connection, past account.

Each extra field has a cost that is not its purchase price: someone must maintain it, imports can overwrite it, and it tempts people to mention it. Add a field when it drives a decision, not because a provider offers it.

The point of qualifying a lead is a decision, not a complete profile. If a field never changes a decision, it is inventory.

Data point quality: judging one field at a time

Data quality is often reported as one score for a whole database. It is more useful to judge it field by field, because a record can be complete and current on email and wrong on title. The Trailhead module lists six dimensions to understand before fixing anything.

NIST adds a precise word for the hardest one. Its glossary defines data accuracy as the closeness of agreement between a property value and the true value. For a job title, the true value is whatever the person's role is today, which is why accuracy is always a statement about a date.

Field-level checks you can run yourself

• Coverage on your own list: count non-empty values on your real target records, not on a provider's whole database.
• Hand sample: check a small set of values against the company site and public profiles, and record how many were wrong.
• Distinct values: count variants in classified fields such as industry or seniority; many variants mean the field cannot group.
• Outliers: sort numeric fields and look at both ends, where coding errors tend to show.
• Source and date: confirm every volatile value has both, or flag it as unverified.

Coverage is the dimension that gets oversold. A field filled on a tenth of your list cannot carry your targeting logic, however accurate it is on that tenth.

Data point decay: which points age fastest

Every data point has a shelf life. Decay is not a database problem; it is the world changing while your copy of it does not. The general causes and refresh routines are covered under data decay. This page adds one practical split by family.

The practical response is a refresh rhythm per family rather than one full refresh. Re-verify person data points before a campaign, re-pull signals often, and revisit company classification on a slower cycle that suits your market.

The GDPR accuracy principle points the same way for personal data. Article 5(1)(d) requires personal data to be accurate and, where necessary, kept up to date, and says every reasonable step must be taken to erase or rectify inaccurate data without delay.

How B2B data points are collected and enriched

Every data point arrives by some route, and the route sets its quality before anyone touches it. Collection methods fall into a few groups, each with its own strengths and its own way of being wrong.

• Self-reported: profiles, company sites, filings and forms. Stated by the subject, sometimes flattering, sometimes out of date.
• Observed: website scanning, DNS and mail records, job posts, published news.
• Contributed: data co-ops and community sources, where members exchange records.
• Verified: a human or a system checking a value at a stated time, which is what you are paying for.
• Derived: a model filling a gap from patterns, useful for sizing and risky when quoted.

Lead enrichment is the act of adding missing data points to records you already hold, rather than buying new records. It can fail silently, because nothing looks broken when a field is quietly wrong.

A data enrichment API automates that step. It improves a database when it writes with rules, such as never overwriting a manually verified value, and damages it when it writes without them. Decide the rules before you connect it.

Privacy: when a data point is personal data

Many person-level B2B data points are personal data under European rules. Article 4(1) of the GDPR defines personal data as any information relating to an identified or identifiable natural person, with identifiers such as a name, an identification number, location data or an online identifier.

A work email in the form first.last at company.com identifies a person. So does a direct dial, a profile URL, or a job title attached to a name. The definition in Article 4(1) contains no exception for business contact details.

In California, the California Privacy Protection Agency's FAQ states that the exemptions for employment-related personal information and for personal information reflecting business-to-business transactions expired on December 31, 2022.

Two more GDPR principles shape how many points you hold. Article 5(1)(c), data minimisation, requires data that is adequate, relevant and limited to what is necessary. Article 5(1)(e), storage limitation, requires that data not be kept in identifiable form longer than necessary for the purposes.

Read together, they push toward the discipline a good sales database wants anyway: fewer fields, each justified, each dated, each deletable. Notice duties, objections and rights are covered under customer data and B2B data. This page is not legal advice, and rules differ by country and by state.

How to tell whether a data point earns its field

1. Write the decision it drives

   State in one line what you will do differently when this data point is present, absent or different. If you cannot write it, the field is decoration.

2. Check coverage on your own list

   Count how many of your real target records have the value populated. As a rule of thumb used on this page, below about half it cannot carry targeting logic.

3. Sample for accuracy by hand

   Take a small sample you can verify yourself and check every value against a public source. Record how many were wrong, not a provider's figure.

4. Give it a date, a source and an owner

   Decide who maintains it and how often it is re-verified. A field nobody owns is the one that goes stale without anyone noticing.

5. Review it after one campaign

   Look at whether the segments built on it behaved differently. If they did not, retire the field instead of collecting it forever.

Common mistakes with data points

• Storing a value with no date, so nobody can tell a current fact from a two-year-old one.
• Mentioning a point in an email only to prove you have it, which signals automation rather than research.
• Treating an inferred data point as a stated fact, especially technology and revenue estimates.
• Building targeting on a field that is populated on a small minority of your list.
• Keeping classified data points such as industry in free text, so variants multiply and filters miss records.
• Deleting an odd value without checking it, or keeping an impossible one because it came from a provider.
• Confusing a metric with a data point, then trying to enrich something that is only ever calculated.
• Copying a competitor's field list instead of the decisions your own team actually makes.

A worked example: auditing the points on one record

The checklist below was written for this page. Run it on ten records you know well before you buy anything, because it often finds the problem inside your own database.

Account: {{companyName}}   Reviewed: {{date}}

1. Company data points present: industry, headcount, model. Correct today? Source?
2. Person data points present: function, seniority, email. Verified when, and by what?
3. Technology data points: stated by the company, or inferred by a scanner?
4. Signals: is there a dated event from the last 90 days, or is the field empty?
5. Our own history: prior contact, replies, meetings, referrals.
6. Outliers: any value that looks impossible for this account? Checked or corrected?
7. Which three data points would I use in a first email, and which sentence would each one change?
8. Which fields on this record have never changed a decision? Mark them for removal.

Data points in a first email

The template below was written for this page. It uses three data points: one company data point for fit, one dated signal for timing, and one role data point so the problem belongs to the reader. Everything else is a sentence, not a merge field.

Subject: {{signal}} at {{companyName}}

Hi {{firstName}},

{{companyName}} {{signal}}. In {{industry}} teams of your size, that often puts {{problem}} on someone's desk.

You run {{function}} there, so it may well be yours. We help similar teams with {{outcome}}.

Worth a short conversation, or is someone else looking at this?

{{senderName}}

Frequently asked questions