Technographic Data: Targeting on What a Company Runs, Not Who It Is

Technographic Data: Targeting on What a Company Runs, Not Who It Is

Technographic data is information about the technologies a company uses: its website platform, hosting, analytics, payment processor, marketing automation, CRM, chat widget, ad pixels and the rest of the software stack. Used as a targeting attribute, it lets an audience be defined by the tools a company has chosen rather than by its size, industry or location. A segment such as "companies running a specific ecommerce platform with a specific reviews app installed" is a technographic segment, and it describes a decision the company made rather than a category it fell into.

The term exists because the older company attributes could not express the question that actually predicts a purchase for most software and services businesses. Firmographic fields describe what a company is; a stack detection describes what it has already bought, which is far closer to whether it will buy something adjacent. If your product replaces a specific tool, integrates with one, or only makes sense once a company has reached a certain level of tooling maturity, the presence or absence of a named piece of software is the single most relevant thing you can know about the account.

How stack detection actually works

Almost all technographic data is produced by looking at things a company publishes without meaning to publish them. Detection vendors describe the mechanism openly: "Most web technologies, including server-side software such as CMSs, leave trails of evidence of their presence in websites' HTML code", and that code "is publicly accessible, which is necessary for browsers to render and display the page" (Wappalyzer, on hiding technologies from detection). The whole category rests on that observation.

1. Step 1Page source and scripts

   Script tags, asset paths, cookie names and response headers left behind by the tools a page loads

2. Step 2DNS and mail records

   MX records reveal the mail provider, other records reveal hosting, security and CDN choices

3. Step 3Job postings

   Requirements sections name systems by product, which reaches tools that never appear on a website

4. Step 4Public directories and marketplaces

   Integration listings, partner directories and app-store customer references

5. Step 5Review-site profiles

   A named reviewer at a named company is a self-declared user, with a date attached

Each method sees a different slice, and none of them sees the same slice. Page-source detection is fast, wide and limited to what the browser loads. DNS is narrow but unusually reliable, because a mail exchanger record is operational rather than declarative: it has to be correct for mail to work at all. Job postings and review profiles reach internal systems that leave no public trace on a website, at the cost of coverage so sparse it cannot support a filter on its own.

Freshness deserves its own note. A stack detection is a snapshot of one page load at one moment. Whether the record you are filtering on was captured yesterday or eight months ago is usually invisible in the interface, and it changes the meaning of the field entirely. Where a provider exposes a first-seen or last-seen date on a detection, that date is often more useful than the detection itself, because a tool that appeared last month is a recent decision and a recent decision is a timing attribute.

How coverage and accuracy are measured

Technographic quality reduces to two questions, and they pull in opposite directions.

Coverage is the share of your target accounts for which the provider returns any detection at all. This number is usually good for website-facing tools and collapses for everything else, so it has to be measured for the specific technology you care about rather than for the provider in general. A vendor that detects thousands of technologies may still return nothing useful for the one that defines your segment, and an overall coverage figure will not show you that.

Precision is the share of returned detections that are correct, and it is the one nobody publishes because it is expensive to establish. You can establish it yourself, cheaply, on a sample. Take a hundred accounts the provider says run the tool, open the sites, and check. Then take a hundred it says do not, and check those too, because a provider can look precise simply by refusing to guess, and a detector that misses most true cases is as damaging to a build as one that invents them. Suppose your sample comes back with most of the positives confirmed and a meaningful share of the negatives turning out to be users the scan missed. That is a normal result, and it tells you the field is safe to write a message from and unsafe to use as a hard exclusion.

The reason the two pull apart is worth understanding. A detector tuned to fire on any plausible fingerprint gets high coverage and admits stale tags and lookalike scripts. A detector tuned to fire only on unambiguous evidence gets high precision and quietly drops every company using the tool in a slightly unusual way. Neither setting is wrong, and a provider will not tell you which one they chose.

Where the textbook definition breaks

The definition promises knowledge of what a company runs. What detection actually delivers is narrower in two specific ways, and both matter more than the definition suggests.

A detection tells you a tag is present. It does not tell you the tool is in use. A marketing tag left on a site after a trial ended, a script kept because nobody wanted to touch the theme, a tool bought by one team and abandoned by the next: all three are indistinguishable from a live, funded, actively used deployment. The signal is presence, and presence has no owner, no contract date, no seat count and no internal champion attached to it. The failure mode is a message built on a confident assertion about the reader's stack that lands with someone who removed that tool a year ago and never cleaned the page. That message is worse than a generic one, because it demonstrates that the sender is reading a stale record and treating it as knowledge.

1. Month oneTool is trialled

   A team installs the script to evaluate the product

2. Month twoTrial is not renewed

   The account lapses and the tool stops being used internally

3. Month two onwardThe tag stays on the page

   Removing it requires a template change nobody has a reason to prioritise

4. Any time afterDetection fires

   An external scan reports the technology as present, correctly and misleadingly

Coverage is systematically biased toward the front end. Anything that renders in a browser is visible. Anything that runs behind the login, in a data centre, or on a finance team's desktops is essentially undetectable from outside. That means marketing and analytics tooling is richly covered while ERP, finance systems, data warehouses, HR platforms and most internal line-of-business software are close to invisible.

Reliably visibleRenders or resolves publicly

• Website platform, CMS and theme
• Analytics, tag managers and ad pixels
• Chat widgets, reviews apps and on-site tooling
• Mail provider and CDN via DNS records
• Payment and checkout components on a public storefront

Partially visibleLeaks through other channels

• CRM and sales tooling, via forms, tracking parameters or job posting requirements
• Support platforms, via a help centre subdomain
• Anything a named employee has reviewed publicly
• Coverage is thin and skewed toward companies that post jobs and reviews

Effectively invisibleNo public surface at all

• ERP, finance and accounting systems
• Data warehouse and internal analytics
• HR, payroll and internal service desks
• Security tooling behind the perimeter
• Anything selected but not yet deployed

That bias has an awkward implication. The segment where technographic coverage is best is the front-end marketing stack, which is also the segment where tools are cheapest, swapped most often, and least indicative of a serious internal commitment. The stack decisions that carry real budget and real switching pain are exactly the ones an external scan cannot see. So the field is most abundant where it is weakest as a signal, and silent where it would be strongest.

There is a third, smaller break worth naming: detection cannot distinguish a company-wide standard from one team's experiment, and it cannot tell you who owns the tool. In a two-hundred-person company those are different people with different problems, and a message that assumes the wrong one reads as a mail merge even when the underlying detection was correct.

Where it genuinely works

None of that makes the category useless. It makes it precise about one job.

Naming a competitor's product that a prospect visibly runs, or naming an integration they are visibly missing, is one of the very few targeting attributes that can be stated out loud in a first message without sounding like a mail merge. The reader can verify the observation instantly, which means the message demonstrates that someone looked rather than asserting that someone cares. That is a real advantage and it is available almost nowhere else in outbound.

The conditions under which it holds are strict. The detection has to be recent. It has to be for a tool whose presence is unambiguous rather than incidental. And the claim in the message has to stay inside what the detection actually supports: that the tool appears on their site, not that they love it, hate it, pay a lot for it, or are unhappy enough to switch. Overclaiming turns a verifiable observation into a guess the reader can catch.

What to do with it

Treat a stack detection as a premise for a message rather than as a qualification criterion on its own. Firmographic attributes still draw the boundary of who is eligible, and hiring signals still carry most of the timing information; the technographic layer decides what the message can honestly say once the account is already in scope.

Check the age of the detection before writing anything that depends on it, and prefer providers that expose a last-seen date over providers that expose only a boolean. Where the tool matters enough to build a whole campaign on, verify a sample by hand: opening twenty sites and confirming the detection yourself takes under an hour and tells you your provider's real error rate on your real segment, which no vendor benchmark will.

And keep the segment tight enough that one premise is true across it. If a stack observation only holds for part of the list, that part is its own campaign with its own message, not a hedge inside a larger one.

Related terms and guides

Stack detections sit alongside the other timing and fit attributes covered in intent signal APIs for outbound, which catalogues the ways these signals are actually delivered into a workflow. Where the resulting conditions get written down and agreed, rather than reinvented per campaign, is the ideal customer profile.

For the buyer's-eye view of the tooling categories themselves, including which layers earn their place, see the sales tech stack layers that survived testing. On sourcing and joining the underlying records, waterfall enrichment covers why one provider is rarely enough, data enrichment tools for SaaS compares the providers, and LinkedIn web scraping covers the collection method and its limits where the signal lives on a profile rather than a page.

If you would rather see a stack-led segment built and tested against a real market than debate detection coverage, see what a first campaign looks like.