Technographics: what technographic data is, how it is collected, where it goes wrong, and how to use it for targeting.

Definition

Technographics is data about the technology a company uses: its software, hardware, cloud infrastructure and the tools in its tech stack, such as its CRM, marketing automation, analytics, email provider and ecommerce platform.

In B2B sales and marketing, technographic data is used to segment accounts, decide which companies to target, and write outreach that fits the tools a prospect already runs. It answers a question firmographics cannot: not what the company is, but how it works.

The word reads as a blend of technology and demographics. Forrester Research sells research products, drawn from its own primary research, under the registered names Consumer Technographics and Business Technographics. In B2B prospecting, the lowercase word has come to mean company-level technology data, and that is the sense this page uses.

This page treats every technographic record as inferred until a buyer confirms it. The common collection methods read traces a stack leaves in public: website code, DNS records, job postings and marketplace activity. Each trace is real evidence, and each one can be old, partial or misread.

What technographic data includes

A technographic record describes one company and the technologies detected or reported for it. The useful fields go well beyond a list of product names, because the extra fields tell you how far to trust each line.

Not every source provides every field. Spend and renewal dates do not appear in website code or DNS records, so where a provider supplies them they are modeled estimates. Treat them as a hypothesis to check on a discovery call, never as a fact to quote back to the buyer.

The layers of a tech stack

It helps to split a stack into layers, because each layer leaves different traces and needs a different collection method. The table below was written for this page; it describes where evidence for each layer tends to come from, not how complete any source is.

Technographic vs firmographic vs demographic data

Technographics is one of several data types teams use to describe a market. Each answers a different question, and targeting works best when they are combined rather than used alone.

A simple way to remember it: firmographic data tells you what a company is, technographic data tells you how it operates, and demographic data tells you who works there. Intent data adds when, and it can change much faster than the other three.

Firmographics and technographics describe the account. Demographics describe the people in its buying group. How all of these types sit together in one database, and the rules that apply to the contact layer, is covered in B2B data.

B2B technographic data in sales and marketing

B2B technographic data matters most when your product depends on, replaces or connects to other software. An integration, a migration service, a security add-on or a consultancy for one platform all have a market defined by technology before industry or size.

For those sellers, a technology stack is a filter that removes accounts where the product cannot work, and a signal that points to accounts where it fits. For a seller whose product works with any stack, this page's view is that technographics is a weaker input and firmographic fit matters more.

If you sell to B2B technology companies, the stack can be part of the segment definition itself: an industry code narrows the list, then technographic data finds the companies running what your product complements or replaces.

Which teams use technographic data

Technographic information is shared across revenue teams, but each one uses it for a different decision. Agreeing on the fields and sources once helps sales, marketing and customer teams read the same signals the same way.

The team that owns the data matters more than the tool that supplies it. Without an owner, technology fields fill up once, go stale, and sales stops trusting them. Account intelligence is only useful if someone keeps it current.

How technographic data is collected

Technographic data is not reported by companies in one place. It is assembled from traces the technology leaves, from what companies say about their own stack in job ads and public pages, and from direct questions. Each method sees a different part of the stack.

The sections below take each method in turn, with what the underlying standard or documentation says the trace actually is. That is the part most technographic explainers skip, and it is what tells you how much a record can carry.

Website code, tags and HTTP headers

When a browser loads a page, it receives HTML and then requests the scripts, styles and images that HTML points to. MDN describes the script element as the way a page embeds or refers to executable code, and its src attribute as the URI of an external script.

A script loaded from a vendor's domain is therefore a direct trace of that vendor's tool on that page. Analytics tags, tag managers, chat widgets, testing tools, consent banners and ecommerce platforms all load this way, which is why front-end tools are the easiest layer to detect.

HTTP response headers are a second trace. MDN defines headers as the way client and server pass additional information with a message, and describes the Server header as naming the software used by the origin server. MDN also advises against too much detail in that header, so the value can be generic or absent.

Cookies are a third. RFC 6265 defines the Set-Cookie header, through which a server passes name and value pairs to the browser. A tool that sets a cookie with a recognizable name leaves a trace in every visit, and detection rules match those names.

How detection rules work

The webappanalyzer project, which describes itself as a continuation of Wappalyzer after Wappalyzer went private in August 2023, publishes its detection rules openly. Each technology has patterns, mostly regular expressions, matched against cookies, page elements, DNS records, JavaScript properties, response headers, CSS, robots.txt, meta tags and script URLs.

Two parts of that format explain a lot about technographic accuracy. A confidence tag marks a less reliable pattern that may cause false positives. An implies field records that one technology's presence implies another, so some tools in a report were never observed directly, only inferred from a related one.

Version detection works the same way: a capture group in a pattern pulls a version number out of a file name or a string. When a report shows a version, ask whether it came from a pattern like that, because a renamed or cached file can carry an old number.

What website scanning cannot see

A scanner sees only what the public site loads. ERP, payroll, HR, finance, data platforms and security software running on laptops and servers never reach a visitor's browser, so a scan cannot report them. Logged-in areas and internal apps are invisible too.

A scan also reads one domain at a time. A parent company's site can run different tools from a subsidiary's, and a campaign microsite can run tools the main site does not. Recording the domain alongside each detection keeps that scope visible.

A tag also outlives its tool. A script left in a template after a contract ends looks the same as an active one. That is why first seen and last seen dates matter more than a yes or no, and why a single scan is a snapshot, not an inventory.

DNS records: MX, TXT verification and SPF

Anyone can query the DNS records a company publishes for its domain, which makes DNS the second big public source of technographic signal. The mail records are explained in full in MX records; this section covers only what each record says about a stack.

MX records: who receives the mail

RFC 1035 defines an MX record as a preference value and an exchange: a host willing to act as a mail exchange for the domain, with lower preference values preferred. RFC 5321 says a sending server first looks up the MX records for the recipient's domain to find where to deliver.

So the MX host names point at the system that accepts the company's mail. Google's help page gives smtp.google.com as the Google Workspace MX value, and Microsoft's setup guide has Microsoft 365 admins copy their MX value from the admin center. Those host names identify a provider.

Detection rules need to know every form a provider's records take. Google's page adds that domains which started on Workspace before 2023 may use legacy MX values beginning with aspmx, which are still supported. A rule that knows only one form undercounts.

The MX is not always the mailbox system. RFC 5321 notes that a relay server is usually the target of an MX record rather than the final delivery system. When a filtering or security service receives mail first, the MX names that service, and the mailbox provider sits behind it.

TXT verification records: who set up an account

RFC 1035 defines TXT records as descriptive text whose meaning depends on the domain where it is found. Services use them to prove domain control. Google Workspace has admins add a TXT value that begins with google-site-verification=, and Microsoft 365 offers a TXT record as one way to verify a domain.

A verification record shows that someone set up that service for the domain at some point. It is weak evidence of current use. Google's own help page says the TXT record can be safely removed once ownership is verified, so its absence proves nothing and its presence can be a leftover.

The prefix is not always specific to one product either. Google Search Console uses a TXT record of the same google-site-verification= form to verify domain properties, so that string alone does not tell Workspace from Search Console. Microsoft 365 also accepts an MX record or a file uploaded to the website as alternatives to TXT.

SPF records: who may send mail

RFC 7208 defines SPF as a single DNS TXT record declaring which hosts may use a domain in the HELO and MAIL FROM identities. Its include mechanism lets one domain designate administratively independent domains, which is how a company authorizes an outside service to send mail for it.

Microsoft's guide gives v=spf1 include:spf.protection.outlook.com -all as the SPF record for Microsoft 365. An include that names a service's domain suggests that service sends mail for the company: its mailbox provider, or another platform sending email on its behalf.

RFC 7208 caps the terms that trigger DNS lookups, include among them, at 10 per SPF evaluation. A record cannot list senders without limit, and a service can send from its own domain instead. A sender missing from SPF is therefore not proof the company does not use it.

CNAME records: what a subdomain points to

RFC 1035 defines a CNAME as an alias whose target is the canonical name for the owner name. When a subdomain such as help or status points at a vendor's host, the alias names the vendor. Microsoft's guide, for instance, asks for an autodiscover CNAME as part of Microsoft 365 email setup.

You can only query names you know, so this works for common subdomains, not for every service a company hosts elsewhere. Treat a CNAME as good evidence for the service it names and silent about everything else.

Job postings as technographic evidence

Job descriptions name tools because employers want candidates who can use them. The O*NET program of the U.S. Department of Labor publishes a Hot Technologies list, which it describes as requirements most frequently included across all employer job postings. Its top entries are software products.

Job postings reveal what website scanning cannot: ERP, HR, finance, data warehouse, BI, security and developer tools that never load in a browser. A posting for an administrator of a named platform is, in this page's view, one of the more direct public technographic signals.

Schema.org's JobPosting type defines fields for the hiring organization, the date posted, a validThrough date and a skills property for required competencies. Those fields are what let a job-based signal carry a company and a date, not just a tool name.

Reading job postings carefully

• Required or nice to have: "experience with" a tool can mean the team runs it, or that the employer would accept it from a candidate.
• Alternatives: a posting can list several competing products as acceptable experience, which says nothing about which one is installed.
• Migrations: a role to move data from one system to another names both, and the old one is on its way out.
• Recruiters: an agency posting can describe a client without naming it, so the tool cannot be tied to a company.
• Dates: the date posted tells you when a statement was true, not that it still is.
• Templates: some employers reuse old descriptions, so a tool can stay in an ad after it has left the stack.

Integration marketplaces, partner directories and reviews

Many software platforms run marketplaces where other vendors list products that connect to them. HubSpot's marketplace, for example, has tabs for apps, templates, agents and solutions partners. A listing tells you a vendor supports that platform, which helps when you define a complementary stack or look for co-selling partners.

Reviews can say more about the reviewer. HubSpot's help page says that to review an app in its marketplace, you must be logged into HubSpot and have the app installed in your account, or have uninstalled it less than 14 days ago.

A review written under those rules is evidence that the reviewer's account ran both HubSpot and the app at the time. How much of the reviewer's company the listing shows is up to the marketplace, so the signal may or may not attach to a named account.

Partner directories, published customer stories, conference talks, engineering blogs and press releases can also name a company's tools. Treat each as dated evidence to record with its source, not as a current inventory, because none of them is updated when a contract ends.

Surveys, discovery calls and your own customer data

Asking reaches tools that leave no public trace, and it is the only method that captures plans. Forrester describes its Business Technographics product as business data on technology adoption, areas of investment and purchasing inhibitors, drawn from its primary research. That is technographics in the research sense: market level, not an account list.

Government surveys sit at the same level. The Census Bureau's Business Trends and Outlook Survey publishes a definition of artificial intelligence for respondents, and the Bureau says it reports only summary information and cannot release anything that identifies a business. Useful for market context, never for targeting.

Account-level answers come from your own channels: onboarding forms, discovery calls, support tickets, customer advisory boards and short prospect surveys. Your CRM and product data already hold the integrations customers connected, which this page treats as your most reliable technographic data, because a customer confirmed it by connecting it.

Questions that collect stack data in discovery

These questions were written for this page. They get the stack without turning the call into an audit, and each answer goes straight into the account record with the date.

• Where it lives: "Where does this workflow run today, and who owns that system?"
• History: "What did you use before that, and what made you change?"
• Connections: "Which tools would this have to connect to on day one?"
• Timing: "Is anything in this area up for renewal or review this year?"
• Scope: "Do other teams, regions or subsidiaries run something different?"

Third-party technographic data providers

Providers combine these methods, match each signal to a company record, and deliver the result as lists, CRM enrichment or an API. They fall into a few categories: website technology scanners, B2B company and contact databases with technographic fields, and account intelligence platforms that combine technographics with intent data.

The matching step is easy to overlook. A signal found on a domain has to be joined to the right legal entity, and a wrong match spoils every technology field attached to it. Where company records come from, and why providers disagree about them, is covered in firmographics source.

Which category fits depends on what you need to detect. Front-end and web tools suit scanners; internal and enterprise systems need sources that read job posts, documents and surveys. Ask the questions above for the exact technologies your product depends on, not for the provider's catalog as a whole.

How accurate is technographic data?

Technographic data is inferred, not declared, so it is never fully accurate. The limits follow from the methods above, and knowing them tells you how much weight a record can carry.

• Invisible tools: scanning only sees what the website exposes. Internal systems such as ERP, HR and finance, and security software on devices, do not appear in public code.
• False positives: a leftover script, a trial or an agency's tag can make a tool look active. The webappanalyzer rules mark weaker patterns with a confidence value because they may cause false positives.
• Implied, not observed: rules that imply one technology from another add tools nobody saw.
• Stale records: companies switch tools, and data refreshed on a fixed cycle can miss a migration that happened last week.
• Leftover DNS: a verification TXT record can stay after the service is gone, as Google's help page allows.
• Wrong scope: a tool on one regional site or one subsidiary is recorded for the whole company.
• Depth unknown: detecting a tool says nothing about how many teams use it or whether it is the system of record.

How to test a technographic data source

1. Pick known accounts

   Take a few dozen customers and lost deals whose stack you confirmed in calls or onboarding.

2. Pull the same accounts from the source

   Compare technology by technology, not company by company.

3. Count three errors

   Tools the source missed, tools it reported that are not used, and tools it reported that were already replaced.

4. Check your segment's technologies

   Results on popular web tools say little about the niche systems your product depends on.

Normalizing technology names and categories

The same product can arrive under a vendor name, a product name, an old brand, a module name or a detector's label. Before you segment, map every raw value to one product, one vendor and one category, or the count for a single platform splits across several spellings.

Public taxonomies help with categories. O*NET classifies each technology skill example under a UNSPSC commodity code, the United Nations Standard Products and Services Code, and flags examples as hot technologies or as in demand for a particular occupation, based on employer job postings.

The rows above were written for this page with invented product names. Keep the raw value next to the normalized one, so anyone can see why a record says what it says, and so a wrong mapping can be fixed once for every account it touched.

Technographic segmentation

Technographic segmentation groups accounts by their technology so each group gets its own message, offer and priority. The segments below come from how your product relates to the stack.

Segment first by firmographic fit, then by technology. A perfect stack at a company far outside your size range is still a poor account.

Be careful with the technology gap segment. A missing detection can mean the tool is absent, or that it is one of the invisible layers. Before you write to an account about a gap, check a job post or ask, because telling a buyer they lack something they already run ends the conversation.

Technographic change signals and timing

A stack at one moment shows fit. A change in the stack can show timing, which is why first seen and last seen matter. The signals below were written for this page as hypotheses to test on your own accounts, not as proven predictors.

These are fit-based timing hints. Research behavior is a different signal with its own sources and limits, covered in B2B intent data. Keep the two apart in your scoring so you can see which one moved an account up the list.

Use cases for technographics in targeting and outreach

Sharpen the ideal customer profile

Pull the stack of your best customers and your churned ones. If a technology shows up far more often in good accounts, add it to the ideal customer profile as a fit criterion. If it shows up in churned accounts, it may mark a poor fit.

Build account lists and prioritize

Filter a company database by technology alongside industry and size, then rank accounts that show both fit and a recent change. This turns a large total market into a list sales can work, one segment at a time.

Account-based marketing

Technographics let an ABM strategy personalize by stack at scale: one-to-many campaigns for all accounts on one platform, with content built around that platform's workflow and integration. Where technographics sits among the other ABM layers is set out in account based marketing data.

Personalized outreach

Reference the tool, not the fact that you tracked it. "Teams that run their pipeline in a given CRM often" reads as expertise; "I noticed you use" reads as surveillance and invites the question of how you know.

Lead scoring and routing

Add technology fit to lead scoring so inbound leads from well-fitting stacks reach sales faster. Route leads on a partner platform to reps who know it, and confirm the stack in qualification before it changes a forecast.

Expansion and retention

For existing customers, a newly detected competitor tool can warn of churn risk, and a newly adopted complementary tool can open an upsell conversation.

Technographics with intent data and enrichment

Technographics shows fit; intent data shows timing. In this page's view, an account that runs a competitor and is researching alternatives this month is a stronger priority than one with either signal alone. Keep the two scores separate so you can see why an account ranks high.

Many teams bring technographics into the CRM through lead enrichment, adding technology fields to company records automatically. A data enrichment API does the same inside your own systems, for example when a form is submitted or an account is created.

Store each technology with its source and both dates rather than as a single checkbox. A field that only says "uses CRM X" cannot tell a rep whether the evidence is a script found yesterday or a job post from two years ago.

Collecting technographics yourself

For a short list, you can collect much of a front-end stack yourself. Open the site with your browser's developer tools and look at the scripts it loads and the response headers it receives. Browser extensions built on detection rules like webappanalyzer's do the same reading for you.

DNS is just as open. In nslookup, set type=mx or set type=txt before the query to see the mail exchangers, the SPF record and any verification records; set type=cname shows an alias. The commands and how to read their output are covered on the MX records page linked above.

Career pages and job boards show internal tools, marketplace listings and reviews show platform pairs, and a discovery call fills the rest. Record each finding with its source and date, in the same fields a provider would use, so manual and bought data can sit side by side.

Be polite while you do it. RFC 9309 describes robots.txt rules that crawlers are requested to honor, and states that they are not a form of access authorization. Respect them anyway, keep any automated requests slow, and read a site's terms before you script anything.

This does not scale to thousands of accounts, but for a prospecting list of a few dozen target companies it can beat a bulk list, because a person checked each record.

Privacy and data handling

Technographic data describes companies rather than people, which makes it less sensitive than contact data on its own. It becomes part of personal data processing when it is attached to named contacts in outreach lists, and then your privacy obligations for those contacts apply.

The UK regulator's guidance on business-to-business marketing says that if you process personal data for direct marketing, even in a business context, the UK GDPR applies. The wider rules for B2B contact data in the EU, UK and US are covered on the B2B data page linked above.

Ask providers how they collect each signal. Scanning public websites is different from data obtained through tracking or third-party sharing, and your legal team may treat them differently. Nothing on this page is legal advice.

A technographic targeting workflow, with an example

1. List the technologies that matter

   Required platforms, competitor products and complementary tools. Keep it short; a product tends to depend on a handful.

2. Check how each one is detected

   Web-visible tools come from scanning; mail tools from DNS; internal systems need job posts, documents or questions.

3. Enrich the account records

   Add technology, first seen, last seen, source and confidence to company records in your CRM.

4. Build segments

   Firmographic fit first, then technology segment, then recent changes.

5. Write one message per segment

   Start from the workflow that stack creates, and the problem it leaves.

6. Confirm on the call

   Ask about the stack in discovery and correct the record, so the data improves with each conversation.

This example was written for this page and describes no real company. A seller of a data sync product for one ecommerce platform starts from firmographic fit: online retailers in its region with 50 to 500 employees.

It keeps only accounts where scanning shows that ecommerce platform, then splits them: accounts with a competing sync tool, accounts with none, and accounts whose job posts mention a new warehouse system. Each segment gets its own first email, and every reply that corrects the stack updates the record.

Common technographics mistakes

• Treating a detected tool as confirmed without checking the source and date.
• Treating a domain verification TXT record as proof the service is still in use.
• Counting implied technologies as if a scanner had observed them.
• Targeting on technology alone, ignoring company size and industry fit.
• Buying a dataset built on website scanning to find internal systems it cannot see.
• Writing to a "technology gap" account about a tool it runs out of sight.
• Opening an email with "I saw you use", which tells the reader they were tracked.
• Never updating records after discovery calls, so the CRM keeps old stacks.
• Assuming a subsidiary's tools belong to the whole parent company.
• Comparing providers on their published accuracy claims instead of a test on your own accounts.

Technographics in a sequence

In a sales cadence, technographics shapes the first touch: the problem that stack creates, told in the reader's words. The template below uses the technology as context, not as proof that you watched the company.

Subject: {{platform}} and {{problem}}

Hi {{firstName}},

Teams that run {{workflow}} in {{platform}} often end up with {{problem}}, especially once {{trigger}}.

We built {{product}} to {{outcome}} for {{platform}} users, without changing how your team works today.

Is {{problem}} something you are dealing with, or is it handled?

{{senderName}}

Frequently asked questions