What a contact record should contain

A contact record looks like a row in a spreadsheet. A name, a title, a company, an email. Maybe a phone number. Maybe a LinkedIn URL. Most B2B data products show you something close to this shape, and most buyers evaluate the products on whether the fields are populated, whether the email is deliverable, and whether the phone connects.

This is the wrong evaluation. The visible fields are the smallest part of what a contact record should be. The interesting part of a good record — the part that determines whether the data is defensible, durable, useful in three years instead of three months — is the metadata around the fields. The fields you don't usually see.

Here is what we think a real contact record should contain, and why each piece matters.

The visible fields

Start with the obvious. A contact record needs the basics, accurately:

Person name. First, last, and middle if commonly used. Not a derived display name; the actual structured fields. This matters for matching, for suppression lookups, and for personalization that doesn't read as machine-generated.

Current employer. Linked to an organization record, not stored as a string. The same person, when they change jobs, should update one field; the entire record should not have to be rebuilt.

Current title. Same caveat. The same person, when promoted, should be one field change, not a new record.

Contact information. Email, phone if available, business address if relevant. Each with provenance attached — not just “here is an email” but “here is an email, observed here, last verified on this date, with this confidence.”

These are the fields that show up in the UI. They are necessary. They are not sufficient.

The metadata that should be visible but usually isn't

What separates a serious record from a marketing record is the metadata that surrounds every visible field. There are six items we think any data product should expose to the buyer, on demand, without legal escalation.

Source URL or document reference. The specific source where this field was observed. Not “web”; not “public sources”; the URL. If the field was inferred rather than directly observed — for example, an email address constructed from an observed pattern at the same organization — the inference logic should be recorded, not hidden.

Observation timestamp. When was this specific field last seen at its source? Job titles change. Emails get deactivated. Companies rebrand. A record without a timestamp is a record that is implicitly claiming to be timeless. No data is timeless.

Verification status and date. If a field was independently verified — for example, an email tested through a deliverability check — the result and the date should be available. If the field was never verified, that should be visible too. The product should not present unverified data as verified.

Confidence indicator. Some fields are highly confident (a CEO name listed on a company's About page). Some are inferred (an email address pattern). The record should distinguish between them. A buyer who treats both kinds of fields as equally reliable will be unpleasantly surprised by the second kind.

Suppression status. Has this person ever opted out? Has anyone asked for their removal? If so, the record should reflect that — either by not existing at all, or by being suppressed in a way the customer can see and respect.

Deduplication confidence. If multiple sources surfaced what appear to be the same person, the record should expose how the consolidation was done. This matters because dedup errors compound. The wrong person ends up associated with the wrong company, the wrong phone number, the wrong outreach history. Buyers don't see this happening; they just see their outbound metrics decay.

None of these metadata fields are exotic. They are the fields a serious data team would have built for themselves anyway, to be able to operate the database. The question is whether the vendor chooses to expose them to the customer or hide them. Vendors who hide them generally have a reason.

What changes when the metadata is visible

Once a customer can see source, timestamp, verification, confidence, suppression, and dedup on every record, the conversation around B2B data changes shape.

Procurement gets clearer. You can audit your vendor's data quality by looking at the metadata directly, not by trusting their marketing claims. If half their records have no timestamp, you have evidence. If their “verified” flag is set on records that have never actually been tested, you have evidence of that too.

Compliance gets simpler. When a regulator asks where a record came from, the answer is the source URL on the record. When an individual asks how their data was obtained, the answer is the observation log. The vendor does not have to coordinate with upstream suppliers to assemble an answer; the answer is already on the record.

Trust calibrates correctly. A sales team that knows which records are confident and which are inferred can adjust their outreach accordingly. They can lead with the highly-confident records, treat the inferred ones as exploratory, and not waste time being surprised. The data product becomes useful in a more granular way, because the customer is operating with full information rather than a single “accuracy” number.

And quality decay becomes visible early. If your data product shows you that 40% of the contact records in your CRM have last-observed dates older than 18 months, you can do something about it. If the same product shows you only “95% verified accuracy” with no breakdown, you find out about the decay when your bounce rate spikes a year later.

Why most products don't do this

The honest answer is that exposing this metadata is expensive in two ways.

It is expensive to build. Keeping per-field provenance, timestamps, verification logs, suppression history, and dedup confidence across hundreds of millions of records requires a different infrastructure than just storing the fields themselves. The storage cost is higher. The query patterns are more complex. The engineering investment is substantial.

It is expensive to be honest about. A product that shows the timestamp on every field also shows when fields are old. A product that shows confidence on every field also shows when fields are weak. A product that shows source on every field is also accountable for what the sources actually are. There is no place to hide. Some vendors prefer the place to hide.

The vendors who build this kind of transparency into their product are making a deliberate choice. They are betting that customers, increasingly, want to see the metadata. They are accepting that they will be judged on what the metadata reveals.

We think this bet is right. The buyer of B2B data in 2026 is more sophisticated than the buyer of 2016. The compliance environment has tightened. The downstream consequences of bad data have become more visible. The buyers we talk to are starting to ask the questions the metadata is designed to answer. Vendors who don't expose it will increasingly look like they have something to hide.