How we detect the technologies on a company website

A row of technographic data states that a technology was observed on a company's website between two dates. This post sets out the specification behind that statement in the marketing stack dataset: the evidence a detection rests on, how a technology is recognised, how its dates are set, and how adoptions, removals and platform migrations are recorded. After it you can open any row of Technology Stack and say what stands behind it, and choose the right dataset for a question about state or a question about change.

Five kinds of evidence

Detection starts from the websites that belong to each company in the index, so every technology is tied to an identified company and its company ID. A technology is detected from five kinds of evidence, and each row of Technology Stack records which of them showed it.

A technology counts as detected when the evidence shows its known signature. The catalogue recognises 6,283 technologies in 68 categories: advertising pixels and conversion tags, tag managers, web and product analytics, consent management, commerce and content platforms, marketing automation, CRM, chat and support, payments, and on through JavaScript libraries, web servers and domain verifications with software vendors. Additions to the catalogue are listed in the changelog of the methodology.

Two points help in reading the evidence.

• DNS records. A company's MX records exist so that its email is delivered, and its TXT records are how it proves to a software vendor that it owns the domain. Some services are recognised from a DNS record alone: a workspace, an email provider, a domain verification.
• Account identifiers. Some technologies expose a public account identifier, such as an advertising pixel or an analytics property. The identifier is kept beside the technology, and a new account under a tool already in place is recorded as its own kind of event, so it is never counted as an adoption.

The evidence is collected from each company's own public website and processed in-house. The sourcing statement sets out the rules of collection.

First seen, last seen and the baseline

Technology Stack has one row per company website and technology, refreshed daily to weekly. Two dates carry its timing.

• The first-seen date is the first observation that showed the technology.
• The last-seen date is the latest observation that showed it.

Both are observation dates, which is what makes the dataset usable point-in-time. A first observation of a website sets its baseline and is never counted as a change. A tool already in place carries the first-seen date of the baseline and writes no event to Technology Changes, so the record never mistakes an existing tool for a new adoption. An adoption you can date is one with an adoption event, because every event is a change that was observed to happen.

Take Acme Robotics, an illustrative company whose website was first observed on 23 September 2026.

Adoptions, removals and platform migrations

Technology Changes is the change record: one dated event for every adoption and every removal, each with its observation time. Three properties make it a record to build on.

1. A removal is confirmed before it is written. Tags come and go with consent banners and tests. Confirmation keeps that noise out of the record, so a removal event marks a tool that has stayed away.
2. A platform migration is one event. When a commerce or content platform gives way to another, the pair is recorded as a single platform migration, with the platform before and the platform after.
3. Every event carries its observation time. The time is when the change was observed, which makes the feed safe to use point-in-time: a query as of any past day returns what was known that day.

The two datasets answer different questions. For what a site runs, read Technology Stack. The query below returns the current stack and leaves out any technology whose removal is awaiting confirmation, which gives a strict list.

select domain, technology_name, technology_category,
       first_seen_at, last_seen_at, seen_via
from company_technologies
where missing_since is null
order by domain, technology_category;

For what changed, and when, read Technology Changes. The query below returns the adoptions and removals of technologies, those recognised from DNS records included, from a time you set.

select company, technology_name, change, observed_at
from company_tech_events
where category in ('technology', 'dns')
  and change in ('added', 'removed')
  and observed_at >= timestamp '2026-10-01 00:00:00'
order by observed_at;

The guide to spotting churn risk when a customer removes your technology puts removal events to work.

How to read a detection

Four points about the data decide how to use it.

• A detection shows presence on the website. It states that a tool's signature is there, between its first-seen and last-seen dates. Presence is the measure behind a fit rule, a competitive displacement list and an installed-base estimate.
• The evidence says what kind of fact it is. A tool shown by DNS records alone means that a company verified its domain with a vendor or routes its mail through one. A tool shown in page content or scripts is a tag running on the site.
• State and change are separate questions. Technology Stack answers what a company runs, with the dates between which each technology was observed. Technology Changes answers what it adopted or dropped, and when.
• Website and postings are two views of one stack. Website detection shows the customer-facing stack: advertising, analytics, commerce and marketing tools. The hiring dataset adds the tools each company names in its job postings, where internal systems tend to appear, and both views sit on the same company ID.

The marketing stack dataset delivers Technology Stack and Technology Changes with Website Profile, which holds the markets, languages, currencies, apps and key pages of each website. The methodology is the reference for the method.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.