Why We Published Our Entire Data Dictionary

The Quiet Norm in Data Sales

Buying lead data usually involves a leap of faith. The pitch lists impressive-sounding fields, the sample looks fine, and you find out what the data actually contains, and what its blanks really mean, only after you've paid and started using it. The details that matter most are the ones you can't inspect up front.

We think that's backwards. So we published the full reference openly: our complete data dictionary lives at a public URL, listing every field you get per lead, its type, where the value comes from, and how to read it. No login, no sales call, no "request access." If you want to know exactly what you'd be buying, you can read it right now.

What's Actually in It

The dictionary documents every field, grouped the way you'd actually use them, the Google Maps listing, contact and email data, the technology stack, website-quality and SEO signals, growth and intent signals, deliverability, AI-search visibility, and the record metadata that tells you how fresh and how trustworthy each row is. For every field it gives you four things: a plain definition, its type, its source, and whether it follows our three-state contract.

That last part is the piece most documentation skips. It's not enough to know a field exists; you need to know what its absence means. Our dictionary is explicit that a blank means "unknown," a confirmed "no" means we checked, and which source each value came from, the discipline we wrote about in why "no data" and "no" should never look the same.

The Part We're Quietly Proud Of: It Can't Drift

Here's the detail that makes this more than a marketing gesture. The dictionary isn't a document someone maintains by hand and updates when they remember to. It's generated directly from the same definition our export uses. When we add a field or change one, the dictionary changes with it automatically, because they read from one source.

That matters because stale documentation is worse than none, it tells you something confidently that's no longer true. By generating the dictionary, a machine-readable JSON Schema, and the actual export from a single registry, we've made it structurally impossible for the docs to describe one thing while the product delivers another. What you read is, by construction, what you get.

Written for People and Machines

The page is built to be read by humans, but it's also structured so machines can read it, which increasingly matters. Developers piping our data into a model or pipeline get a JSON Schema generated from the same source, so they can validate and map fields programmatically (more on that for the technically inclined in the technographic data behind every lead).

And as AI assistants become how people research tools, a clear, structured, public dictionary is how an AI can accurately answer "what data does this product provide?", with our own field definitions rather than a guess. Being legible to AI is, fittingly, one of the things our data helps businesses fix; it would be strange not to hold ourselves to it.

Why Make the Effort at All

Transparency like this is a little uncomfortable. A public, exhaustive field list invites scrutiny and comparison. That's exactly why we did it. A vendor that shows you every field and is candid about what each one means, including its limits, is making a different kind of promise than one that hides the spec behind a demo. The first time a dataset's blank cell burns you on a campaign, you understand why the promise is worth something.

We'd rather earn the sale by being inspectable than win it by being vague. The dictionary is open. Read it before you buy, compare it to whatever else you're considering, and hold us to every line of it.