Customer data is everything your own company already knows about the accounts and people that buy.

Definition

Customer data is the information a company holds about the people and organizations that have bought from it: who they are, what they bought, how they use the product, and what they say about it.

The dictionary sense sets the boundary. The Cambridge Business English Dictionary defines a customer as a person or an organization that buys a product or service. Customer data is therefore information about buyers, collected through your own relationship with them, not information about everyone you might sell to.

It comes from that relationship. A customer fills in a signup form, signs a contract, logs in, opens an invoice, emails support, answers a survey. Every one of those moments leaves a record somewhere in your business systems, and together those records are your customer data.

In a B2B company the term covers two levels at once: the account, meaning the business that pays you, and the people inside it who use, approve or renew the product. In this page's view, a lot of confusion about customer data starts when those two levels get mixed in one field.

Customer data is not prospect data

The word customer does the work here. Customer data describes companies and people who already have a relationship with you. Data about companies you would like to sell to is prospect data, covered in B2B data, and it is collected, justified and stored differently.

The table is this page's summary, not a legal rule. The two sets meet in one place: your customers describe the pattern you then look for in the market. That use is covered further down, and the individual fields that carry it are described in data points.

Why customer data matters to a B2B company

Customer data is the only evidence you own about how your customers actually behave. Everything else is opinion about the market. It is what lets a business understand which accounts are healthy, which are drifting, and which decisions about product, pricing and service are worth making.

• Understand your customers: who they are, what they bought and how they use it, instead of what a survey of the market says.
• Improve the customer experience: support and onboarding get faster when the person answering can see the account's history across channels.
• Personalized marketing: messages that reflect a customer's plan, usage and stated preferences, rather than one email sent to everyone.
• Retention decisions: falling engagement across an account's users is an early warning that a renewal is in trouble.
• Expansion and sales: usage shows which teams and which features a customer has not reached yet.
• Finding more customers: the pattern in your best customers becomes the filter for the next list.

Every one of those uses needs different fields, which is why the types below matter more than the total volume of information a company collects. More data is not better data. The right fields, kept current and lawfully held, are.

The customer data types, in one table

This page sorts customer data types into five families, whatever labels a given tool uses. The families matter because each one is collected differently, ages differently, and carries a different privacy weight. Examples of each are in the table.

Articles that rank for this term label the same customer data types differently. Some call identity data basic data. Qualitative data appears as attitudinal data or customer feedback. Engagement data sometimes absorbs interaction data. The names move around; the collection methods behind them do not.

Some writers merge transactional into behavioral, and some split out engagement data as its own type. The split matters less than the discipline: know which family a field belongs to, because that decides who owns it and how long you keep it.

Identity data

Identity data is the small set of fields that says which human or which company a record is about. In B2B this page counts a work email, a name, a job title and a company, plus internal keys such as an account ID or a billing customer number.

The person-level part of it is personal data in the legal sense. Article 4(1) of the GDPR defines personal data as any information relating to an identified or identifiable natural person, and lists a name as one identifier. That fact drives most of the rules in the second half of this page.

Descriptive data

Descriptive data is the context around the account: industry, headcount, region, plan tier, the systems they run. In B2B this overlaps with firmographic and technographic fields, and it is the layer you later reuse to describe the profile of a good customer.

In consumer businesses this family is called demographic data: age, gender, income, location. B2B has a demographic layer too, at two levels. The company level is firmographic, and the person level is demographic in a narrow sense, covering role, seniority and the country a contact works in.

It is the easiest family to over-collect. Every field looks useful in a dashboard. Ask what decision changes if the value flips before you add a field to the onboarding form.

Behavioral data

Behavioral data records actions with a timestamp: a login, a feature used, a report exported, an email opened, an invoice viewed, a ticket opened. It is the family that grows fastest and the one that tells you soonest when an account is drifting away.

In B2B it is often collected per person and rolled up per account, which is where reporting goes wrong. Ten logins can be one power user or ten teams, and the two mean opposite things at renewal.

Engagement and interaction data

Some teams split out engagement data: the interactions a customer has with you outside the product. Emails opened, webinars attended, help center articles read, website pages revisited, replies to a survey, social media comments about your product.

The distinction is useful because engagement and product behavior tell you different things. Heavy product use with zero engagement means an account nobody in your company is talking to. High engagement with flat usage can mean an evaluation that stalled.

Transactional data

Transactional data is the record of money and commitments: orders, contract value, start and renewal dates, invoices, payment method, credits and refunds. It normally lives in the billing or finance system, and it is the version of the truth that survives audits.

It also runs on a separate retention clock from marketing. For US income tax, the IRS says the length of time to keep a document depends on the action, expense or event it records, and generally runs until the period of limitations for that return runs out. Other countries set their own rules.

Qualitative data

Qualitative data, also called attitudinal data, is what customers say in their own words: survey answers, support ticket text, call notes, onboarding interviews, churn reasons, online reviews. It is the only family that explains why the numbers moved.

Some of it arrives as customer feedback you asked for, through surveys and interviews, and some as feedback you did not ask for, through tickets and online reviews. Both are attitudinal data. In this page's view, the unrequested kind is often blunter and more useful.

It is also, in this page's view, the least structured family and the easiest to lose. The fix is not an analytics tool but a habit: a small set of tagged reasons, written the same way by everyone, beside the free text.

First party versus third party customer data

A second way to sort customer data is by who collected it. The labels are industry conventions, not legal categories, and they matter because they decide how much you can trust a value and how easily you can explain where it came from.

The practical rule this page recommends is that first party data decides, and third party data fills gaps. When a bought field disagrees with your own billing or product record, your own record wins. Lead enrichment is useful exactly where you have nothing, and dangerous where it overwrites something you verified.

There is a legal reason to keep the source, too. Article 15(1)(g) of the GDPR says that where personal data was not collected from the person, they can ask for any available information as to its source. A field with no recorded origin makes that answer impossible.

Customer data, personal data and PII

Three terms overlap here, and they come from different rulebooks. Customer data is a business term for what you hold about buyers. Personal data is the GDPR term. Personally identifiable information, or PII, is the term used in many US federal and security documents.

The ICO draws the line that matters most for B2B. Its guidance says information about companies is not personal data, but information about employees, partners and company directors may be, where they are individually identifiable and the information relates to them as individuals.

So an account record with industry and headcount is usually outside the definition, while the named buyer attached to it is inside. In practice many B2B customer records carry both, which is why one export can be harmless at the account level and regulated at the contact level.

The California Privacy Protection Agency says the same from the US side. Its FAQ states that the CCPA gives privacy rights to California residents, and that this includes residents who are employees, job applicants, and contacts for business customers, vendors or independent contractors.

Where customer data lives in a B2B stack

Customer data in a B2B company is rarely in one place. It is spread across the systems that created it, which is why the same customer can look active in one tool and churned in another.

A unified customer profile is a common goal: one view that shows an account's contract, usage, tickets and feedback together. It is a reporting layer, not a replacement for the systems underneath. Deciding which system owns each field is the job of a system of record.

Three questions keep this manageable. Which system owns each field, so two imports cannot fight over it. Which identifier joins them, often the account ID rather than the email. And which copies exist, because a deletion request has to reach every one of them.

A field copied into a spreadsheet, a slide or a personal export is still customer data, and it is still yours to account for.

Account and person records inside a CRM

CRM vendors model the two levels as separate objects. HubSpot's knowledge base, for example, describes contacts as any person who interacts with your business and companies as any business with interactions related to your business, with firmographic fields such as industry and number of employees on the company record.

The same documentation says contacts are deduplicated by email address and companies by domain name, that associations between records are always two-way, and that an account may rename the company object, for example to account. Other CRMs use different names for the same split.

The lesson for customer data is structural. Keep account facts on the account record and person facts on the person record, then associate them. A job title stored on the company, or a contract value stored on one contact, breaks the moment that person leaves.

How customer data is collected

Collection methods fall into two groups: what customers hand you directly, through online forms, surveys and conversations, and what your systems record while they work. Both are first party. The direct kind is easier to explain, and the recorded kind is harder to argue with.

• Signup and onboarding forms: the fields a new customer types in, including the ones you chose not to ask.
• Contracts and orders: legal entity, billing contact, term, value, signature records.
• The product itself: accounts created, features used, events emitted with a timestamp.
• Support and success: tickets, conversations, escalations, meeting notes.
• Surveys and interviews: satisfaction scores, feedback forms and the sentences underneath them.
• Email and marketing tools: subscriptions, communication preferences, sends, engagement and every opt-out.
• Website and help center: pages a signed-in customer revisits, help articles read, the search that returned nothing.
• Social media and reviews: public comments and review sites where customers describe your product in their own words.
• Enrichment and appends: third party fields added to a record you already hold.

Website behavior from a known customer is first party data and can be more honest than a survey, because nobody is performing for the person asking. The same is true of help center searches, which show the questions your documentation did not answer.

Collecting is where privacy obligations attach, not where they are remembered. The moment a field is captured, someone needs to be able to say why it was collected, under which basis, and when it will go away.

The FTC's data security guide for business puts the first step plainly: if you do not have a legitimate business need for sensitive personally identifying information, do not keep it, and do not even collect it. Collection is where a data inventory gets shorter or longer.

What customer data should you collect?

Start from the decision, not the field. Before you collect a customer data point, name the customer decision it supports: onboarding, billing, support, renewal or the next purchase. Article 5(1)(c) of the GDPR asks for data that is adequate, relevant and limited to what is necessary for the purpose.

This page suggests a short minimum per customer: the account and its legal entity, the people and their roles, the plan and purchase history, product usage, open tickets, and stated communication preferences. Anything else should earn its place by improving a customer experience or a customer insight you can name.

Preferences deserve their own fields. A customer who tells you which emails they want, which channel they prefer and who should receive invoices has given you information that improves every later interaction, and that you never need to infer from behavior.

Two habits make collecting survivable over time. Record the source and the date beside the value, and ask for a preference rather than inferring it, because a customer who states a preference is easier to serve and easier to justify.

Customer data management and its common challenges

Customer data management is the ongoing work of keeping customer information accurate, joined, lawful and usable across every system that holds it. It is less a tool than a set of decisions: who owns each field, how records are matched, and when they are corrected or deleted.

Accuracy is a legal principle, not a nice-to-have. Article 5(1)(d) of the GDPR requires personal data to be accurate and, where necessary, kept up to date, with every reasonable step taken to erase or rectify inaccurate data without delay.

Customer records go stale for ordinary reasons: people change roles, companies merge, plans change. How that happens, and how to measure it on your own records, is covered in data decay; this page only names it as a management problem.

• One owner per field: name the system that decides the value, and let the others read it.
• A date on volatile fields: job title, contact, plan and seat count are true as of a day, not forever.
• Deduplication by account: the same company bought twice, under two legal names, is one customer.
• Bounce handling: a hard bounce on a customer contact can mean a leaver, not a bad address, and should start a re-contact task.
• Closure of the loop: when support learns a contact changed roles, the CRM has to hear about it.

The difference from prospect lists is that customer records carry money, so an error is visible at renewal rather than in a bounce report.

Customer data analytics: turning fields into insights

Customer data analytics is the work of reading stored fields together to answer a question. A table of logins is not an insight on its own. It becomes one when you compare this month against last month for the same customer and see the drop.

In this page's view, useful analysis in B2B is unglamorous. Cohorts by signup month, usage per account against plan, ticket volume by feature, revenue retained per segment. Reports like these help a team learn what changed, and they lead to decisions rather than to another dashboard.

The step from a report to a decision is covered in data insights, which defines what counts as an insight and how to test one. Here it is enough to say that customer data is the raw material, and an insight is a finding someone acts on.

In this page's view, customer insights tend to come from combining types: purchase history with product usage, usage with support interactions, support interactions with what customers say in surveys. One type on its own seldom explains a change. That is the practical reason to understand which tools hold which customer data.

Real time matters less than people expect. A live view helps support, where the agent needs the current state of an account. Trends are better read weekly or monthly, because one day of behavior is noise.

Two habits protect the insights. Write the question before the query, so every analysis has a decision attached. And keep the qualitative data beside the numbers, because customers explain their own behavior better than a chart does.

Customer data and the customer experience

The customer experience is the sum of these interactions across channels, and customer data is the durable record of it. A support agent who can see the plan, the open tickets and the usage gives a different experience from one who asks the customer to explain the history again.

That is the honest case for joining customer data across systems. Not personalized experiences as a slogan, but fewer repeated questions, fewer irrelevant emails, and an account team that knows what happened last quarter.

It also sets a limit. Using data a customer gave you for support to drive a marketing campaign they never expected is not a better experience, and it risks the trust that made the data useful.

Consent and lawful basis for customer data

Under the GDPR, every use of personal data needs a lawful basis. Article 6(1) lists six: consent, performance of a contract, a legal obligation, vital interests, a public task, and legitimate interests that are not overridden by the interests or rights of the person.

The UK list is now longer. The ICO's guide to lawful basis says there are seven lawful bases available, adding recognised legitimate interest, which covers a short list of pre-approved purposes such as responding to emergencies and preventing crime. None of those is ordinary customer marketing.

Customer data is unusual because several bases can apply at once, to different fields. The billing contact is processed to perform the contract. The invoice archive is kept for a legal obligation. A newsletter may rest on consent. Product telemetry used to improve the service may rest on legitimate interests.

The customer relationship itself is named in the law. Recital 47 of the GDPR says a legitimate interest could exist where the person is a client of the controller, and that direct marketing may be regarded as a legitimate interest. It still calls for a careful assessment of what the person can reasonably expect.

The ICO is blunt about the process around that choice. You must determine your lawful basis before you start using the information, you must document it, and you must include it and your purposes in your privacy information. It also says you should not swap to a different basis later without good reason.

What consent has to look like

Article 4(11) of the GDPR defines consent as a freely given, specific, informed and unambiguous indication of the person's wishes, by a statement or clear affirmative action. Article 7 adds that you must be able to demonstrate it, and that a request bundled into other text must be clearly distinguishable and in plain language.

Article 7(3) also says withdrawal must be as easy as giving consent, and that people must be told about that right beforehand. In practice that means a working unsubscribe link, a preference page, and a record of what each customer agreed to and when.

Emailing your own customers

Being a customer does not by itself create consent for marketing, and the email rules apply on top of the privacy rules. That is why an email marketing database needs its own permission trail rather than a copy of the customer list.

In the US, the FTC's CAN-SPAM compliance guide says the law makes no exception for business-to-business email, and gives a message to former customers announcing a new product line as an example of email that must comply. Opt-out requests must be honored within 10 business days.

The same guide separates commercial content from transactional or relationship content, which facilitates an already agreed transaction or updates a customer about an ongoing one. An invoice notice and a renewal reminder sit on one side of that line; a cross-sell offer sits on the other.

In the EU, Article 21(2) and (3) of the GDPR give people the right to object at any time to direct marketing, after which the data must no longer be used for it. Article 21(4) says that right must be brought to their attention by the first communication at the latest.

What you must tell customers when you collect

Article 13 of the GDPR sets out what a person must be told when their data is collected from them. It is the article that makes a privacy notice a legal document rather than a page of reassurance, and many of its items are things a B2B company already knows.

• Who you are: the identity and contact details of the controller, and of a data protection officer where there is one.
• Why and on what basis: the purposes of the processing and the legal basis, including the legitimate interests where that is the basis.
• Who receives it: the recipients or categories of recipient, and any transfers outside the region with the safeguards used.
• How long: the storage period, or the criteria used to decide it when a period cannot be stated.
• Their rights: access, rectification, erasure, restriction, objection, portability, and withdrawal of consent where consent is the basis.
• Complaints: the right to lodge a complaint with a supervisory authority.
• Whether it is required: if providing the data is a statutory or contractual requirement, and the possible consequences of not providing it.

Article 13 also covers automated decision-making, including profiling, with meaningful information about the logic and the consequences. Scoring customers for renewal risk is worth checking against that item before it drives an automated action.

Rights your customers have over their data

Customers can ask you to do things with their data, and the answer has a deadline. These are the requests a B2B team can expect to receive, with what the source says about each.

The clocks differ. Article 12(3) gives one month to respond, extendable by two further months where necessary, if you tell the person within the first month and give reasons. The ICO repeats the one-month deadline in its erasure guidance.

The CPPA's FAQ says businesses must confirm receipt of a request to delete, correct or know within 10 business days and respond within 45 calendar days, extendable by another 45 with notice. Opt-out requests must be handled as soon as feasibly possible, within 15 business days at most.

The right to erasure is not absolute. Article 17(1) lists the grounds, including that the data is no longer necessary, that consent was withdrawn with no other legal ground, or that the person objected. Article 17(3) preserves data needed for a legal obligation or for legal claims.

The ICO adds that requests for erasure can be made verbally or in writing. A request made by phone to a support agent counts, which is a training problem before it is a legal one.

Portability has conditions. Article 20 applies where processing is based on consent or on a contract and is carried out by automated means, and it covers the data the person provided. Where technically feasible, they can ask for it to be sent directly to another controller.

Retention and deletion

The storage limitation principle in Article 5(1)(e) says personal data must be kept in a form that permits identification for no longer than is necessary for the purposes it is processed for. That is a test, not a number.

The ICO spells out what the test means in practice. You must not keep personal data longer than you need it, you need a policy setting standard retention periods wherever possible, and you should periodically review what you hold and erase or anonymize it when you no longer need it.

The ICO is equally clear that the UK GDPR does not set specific time limits for different types of data: how long you keep it depends on your purposes.

The FTC's guide gives the US version of the same advice: develop a written records retention policy covering what to keep, how to secure it, how long, and how to dispose of it.

The schedule below was written for this page as a starting point, not as legal advice. The periods are the questions to answer, not answers.

One detail catches teams out. Honoring an opt-out means you must keep enough data to remember the opt-out. In this page's view a minimal suppression record is not a contradiction of a deletion request, because deleting the record outright can make you contact the person again.

Deletion also has to travel. Warehouses, backups, exports and the copy a departing rep made are all places the same record lives, which is why the inventory in the section above is what makes a deletion promise real.

Security basics for customer data

Article 32 of the GDPR requires appropriate technical and organizational measures for the risk, and names four: pseudonymization and encryption; ongoing confidentiality, integrity, availability and resilience of systems; the ability to restore access in a timely manner after an incident; and a process for regularly testing the measures.

The ICO adds that it has for a number of years considered encryption an appropriate technical measure given its widespread availability and relatively low cost of implementation. It recommends encryption if you store personal data or transmit it over the internet.

The FTC's guide, Protecting Personal Information, builds a data security plan on five principles: take stock, scale down, lock it, pitch it, and plan ahead. Each maps to a customer data habit.

• Least access: the FTC guide calls it the principle of least privilege, meaning each employee has access only to the resources needed for their job.
• Encryption: in transit and at rest, including exports and backups.
• No stray copies: exports to spreadsheets and personal drives are where customer data leaves your control.
• Offboarding: revoke tool access the day someone leaves, including the tools nobody administers.
• Testing: a scheduled review of who has access and whether restores actually work.

Article 33 sets the clock on the last FTC principle. A personal data breach must be notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. A processor must notify the controller without undue delay.

The vendors holding your customer data

Every tool in the stack holds a copy of some customer data. Under the GDPR, a vendor processing it on your behalf is a processor, while you remain the controller, defined in Article 4(7) as the party that determines the purposes and means of the processing.

Article 28 requires that you use only processors giving sufficient guarantees, and that a contract sets out, among other things, that they act only on documented instructions, keep staff under confidentiality, implement Article 32 security, help with rights requests, and delete or return the data at the end.

The same article covers sub-processors: a processor cannot engage one without written authorization, must let you object to changes under a general authorization, and remains fully liable to you for the sub-processor's obligations. That is the clause worth checking when a vendor adds a new sub-processor to its terms.

Article 30 asks for a record of processing activities, including purposes, categories of people and data, recipients, and where possible erasure time limits and a description of security measures. Organizations with fewer than 250 employees are exempt unless the processing is risky, not occasional, or involves special categories.

In practice, a spreadsheet listing each system, what customer data it holds, who owns it and how long it keeps it does double duty: it covers much of what Article 30 asks for, and it is how you answer a deletion request honestly.

Using customer data to find more customers

The commercially interesting part of customer data is that it is evidence. Your customers are the only proof you have of who buys, why, and what happens next. Prospecting off that evidence beats prospecting off a guess.

1. Pick the customers worth copying

   Not all of them. Take the accounts that renewed, expanded and cost little to serve, and set aside the ones that churned or ground down support.

2. Find what they share

   Look across descriptive fields: industry, size, region, the systems they run, the team that owns the problem. A few attributes often repeat.

3. Check the trigger

   Read the qualitative data for what was happening when they bought: a new hire, a migration, an audit, a growth push. That is the moment to look for elsewhere.

4. Write it down as a profile

   Turn the pattern into an ideal customer profile, with the attributes that were actually observed, not the ones you wish were true.

5. Build the list

   Use the profile as filters against external sources, then rank by fit and by signal. The result is a target account list rather than a dump.

6. Feed the result back

   When those accounts close or fail, the customer data on them updates the profile. This is a loop, not a one-time exercise.

Customer data tells you what fits. Signals that a matching company is researching a problem right now are a different data set, covered in intent data, and the two are strongest when kept apart and read together.

Two boundaries are worth naming. You are using customer data to describe a pattern, not to contact the customer's own contacts. And the prospects you then reach out to are governed by prospecting rules, not by your customer relationship, which is why prospect targeting is a separate discipline.

Expansion inside existing accounts is the other half. Product and support data shows which teams are missing, which features stalled, and which contacts left, and in this page's view that is often a shorter path to sales than a new logo. Passing it cleanly is the point of a sales handoff.

A customer data policy that fits on a page

This checklist was written for this page. It is not legal advice, and rules differ by country and by state. It is the shortest version of the questions the GDPR, the ICO, the CPPA and the FTC sources above expect a company to be able to answer about its own customer data.

Article 5(2) of the GDPR names the reason the last row matters: the controller is responsible for, and must be able to demonstrate, compliance with the principles. A policy nobody can show does not meet that test.

Common mistakes with customer data

• Treating the customer list as a marketing list, and sending campaigns under a basis that was never established or recorded.
• Collecting fields because a form was free to extend, then keeping them forever with no stated purpose.
• Letting an enrichment run overwrite a value your own billing or product system verified.
• Storing everything at contact level, so the account view breaks the moment a person leaves.
• Promising deletion while copies survive in a warehouse, a spreadsheet and a personal export.
• Deleting an opt-out record entirely, which removes the only proof that the person asked to be left alone.
• Reading only the numbers, and never the ticket text that explains them.
• Assuming B2B contact data sits outside privacy law, which the CPPA FAQ and the FTC's CAN-SPAM guide both contradict.

Customer data in a first email

When customer data has told you which companies to approach, the first email should carry the pattern, not the data. It names the situation you keep seeing, says what tends to follow, and asks one question. This example was written for this page.

Subject: {{situation}} at {{companyName}}?

Hi {{firstName}},

The {{segment}} teams we work with often run into {{problem}} right after {{situation}}. It tends to show up as {{symptom}} before anyone calls it a problem.

If that is familiar, we help teams get {{outcome}} without {{tradeoff}}.

Worth a short look, or is {{situation}} already handled?

{{senderName}}

Frequently asked questions