A technographic data vendor dates a technology adoption from its own observations, and its methodology decides which of three dates you are given: the first time it saw the technology, the last time, or the time it saw the change happen. This post sets out what each date can prove, why the first observation of a website is a baseline and never an adoption, how five providers document their dates, and a test that holds any sample against go-live dates you already know.
How does a technographic data vendor date a technology adoption?
A technographic data vendor dates a technology adoption by observation. It reads a company's website, or another public source, repeatedly and records when a technology was first seen, when it was last seen and, in a change record, the time at which it appeared between two observations. None of the three is the day the company switched the tool on.
The go-live day is known to the company and to its supplier. A vendor of technographic data sees a website only when it looks, so what it can state is bounded by two observations: the last one that did not show the tool and the first one that did. The go-live lies between them.
| Date | What it records | What it can answer | What to check in a sample |
|---|---|---|---|
| First-seen date | The first observation that showed the technology | Since when there is evidence of the tool on the website | Whether it equals the website's first observation |
| Last-seen date | The latest observation that showed it | Whether the tool is in place now, and the last day it was known to be | Its age against the stated refresh cadence |
| Observation time of a change | The observation that showed the tool present, or gone, when the one before showed the opposite | When an adoption or a removal happened, to within the gap between the two observations | That a tool in place at the first observation has no event |
Two properties follow.
- An adoption date is the late edge of an interval. The tool went live after the previous observation and on or before the one that carries the date. The refresh cadence is therefore the precision of the date: on a weekly cadence an adoption is dated to within seven days.
- A first-seen date dates an adoption only when an earlier observation of the same website did not show the tool. Without that earlier observation it is the date the vendor began to look.
Why a first observation is a baseline and not an adoption
The first time a vendor observes a website, every technology on it is new to the vendor and none of them is new to the company. That observation is a baseline: a record of what was already in place. Counted as adoptions, baselines pile years of earlier decisions onto the day a website entered the dataset.
A baseline arises in three ways.
- A website is observed for the first time, because its company was added to the vendor's index.
- A technology is recognised for the first time, because the vendor added or revised its signature. Every website already running the tool then shows it at once.
- A kind of evidence is observed for the first time on a website, such as its DNS records or the requests its pages make.
In each case the first-seen date is the date of that observation, and it says nothing about how long the tool has been there. An uncorrected baseline leaves a visible mark in a sample: many companies with the same adoption date for one tool, or one company whose whole stack was adopted on a single day.
In Fokals data the rule is part of the record. A first observation sets a baseline and writes no event, so every row of Technology Changes is a change observed between two dated observations of the same website. The same holds when the catalogue grows: a technology new to the catalogue sets its baseline on each website, and no date in Technology Changes is the date a technology entered the catalogue. The methodology states the rule, and the post on why we write each table once sets it beside the other rules that make the record point-in-time.
How BuiltWith and Wappalyzer date technology detection in historical data
BuiltWith and Wappalyzer both date a technology detection by observation, and their documentation gives the historical data different shapes. BuiltWith returns a first-detected and a last-detected date for each technology, beside the dates the domain was first and last indexed. Wappalyzer returns the last time a technology was identified, and historic results grouped by month.
BuiltWith. The Domain API documents four dates. Each technology carries the date BuiltWith first detected it and the date it last detected it. The domain, and each path under it, carries its earliest and its most recent index point. A request can filter technologies by a range of first-detected dates or of last-detected dates, or ask only for the technologies considered live. The dataset fields hold the same four dates.
The first-indexed date does the work of a baseline. A BuiltWith blog post published on 1 October 2015 announced the field in exports and gave its purpose: to tell whether the date on a technology is the same as the date BuiltWith began to track the website. Run that comparison on any export. A first-detected date equal to the domain's first-indexed date marks a technology found when tracking began. A later one is the necessary condition for reading the date as an adoption.
Wappalyzer. The technology lookup API returns cached results from Wappalyzer's database by default and can scan a website live instead. A maximum-age parameter, two months by default, limits the results to those verified at least once within that many months. Monthly results are merged into one set unless you switch the merging off, and the response then holds one group for each month in which technologies were identified, which the documentation calls historic data. In the field reference, the timestamp on a technology records when it was most recently identified on the website. Wappalyzer also offers website alerts for changes to the technology stack of the websites you choose to track.
Read monthly groups as snapshots. An adoption is dated to the first month whose group holds the technology, provided an earlier month for the same website exists and does not hold it.
Historical technology adoption data from BuiltWith, Wappalyzer, HG Insights, 6sense and Similarweb
Each of the five providers documents the dates behind its technology data in its own terms. BuiltWith and HG Insights name a first and a last date of detection, Similarweb names an installation date and an uninstalled date, Wappalyzer names the last identification and groups history by month, and 6sense names recency as a factor in a confidence score.
| Provider | The dates its documentation names | Page read on 7 October 2026 |
|---|---|---|
| BuiltWith | First detected and last detected for each technology; first indexed and last indexed for the domain | Domain API |
| Wappalyzer | The most recent time a technology was identified; historic results grouped by the month of identification | Technology lookup API and field reference |
| HG Insights | Date First Verified, the date of the first install signal detected, and Date Last Verified, the date of the most recent one | HG Technographic object |
| 6sense | A confidence score from 0 to 100 on each data point, in which recency of detection is one of three factors | Technographic Data Overview |
| Similarweb | An installation date, for when a technology was first installed or implemented on a website, and an uninstalled date, for when it was removed or stopped being used | Technologies Dataset |
Two differences matter more than the field names.
The evidence behind the date. The 6sense page describes two kinds of source: passive ones, such as job postings, from which the technologies a company uses are inferred, and active ones that scan a company's digital presence. A date taken from a website and a date taken from a posting are observations of different things, so ask which kind stands behind each row.
Names for the event and names for the observation. Similarweb names its fields for the event, installed and uninstalled, and its Website Technologies view shows each technology with a status, a working period and when it was removed. BuiltWith and HG Insights name theirs for the observation: detected, verified. The name of a field does not tell you how a tool already in place at the first observation is dated. The test in the example below does, on any of the five.
Which technographic datasets record historical technology stack changes?
Technographic datasets record historical technology stack changes in three shapes: a state table with a first and a last date for each technology, periodic snapshots, and a change record with one dated event for each adoption and removal. A change record, or a state table read beside the date its website was first observed, separates adoptions from baselines.
| Shape | One row is | The adoption date it gives | Where it appears |
|---|---|---|---|
| State with two dates | A company or website and a technology, with a first and a last date | The first date, once tested against the website's first observation | BuiltWith, HG Insights and Similarweb; Technology Stack in our data |
| Periodic snapshots | The technologies identified in one period | The first period that shows the tool | Wappalyzer's results grouped by month |
| Change record | One adoption, removal or migration, with its observation time | The observation time of the event | Technology Changes in our data |
The marketing stack dataset delivers the first and the third shape together. Technology Stack has one row for each company website and technology, with its first-seen and last-seen dates and the kinds of evidence that showed it, refreshed daily to weekly. Technology Changes has a dated event for every adoption, removal and platform migration, each with its observation time. A removal is confirmed before it is written, and a new account under a tool already in place is its own kind of event. The query below sets the two datasets side by side for each company and technology.
select t.company_id, t.technology, t.technology_name,
min(t.first_seen_at) as first_seen_at,
max(t.last_seen_at) as last_seen_at,
min(e.observed_at) as adoption_observed_at
from company_technologies t
left join company_tech_events e
on e.company_id = t.company_id
and e.key = t.technology
and e.category in ('technology', 'dns')
and e.change = 'added'
group by t.company_id, t.technology, t.technology_name;A row with an adoption time is a technology that was observed to arrive. A row without one was in place at a baseline, and its first-seen date is the date of that baseline. The data dictionary defines each field, and the post on what a Fokals technology row tells you covers the evidence on a row.
Example: testing adoption dates against go-live dates you know
You can test any vendor's adoption dates if you hold a few go-live dates of your own: your customers' launch dates if you sell a tool that shows on websites, or the change log of a website you run. Ask for sample data on those websites and check four things: baselines, lags, order and what was never seen.
Acme Robotics is an invented company, and every figure in this example is illustrative.
Assumptions:
- The vendor first observed the Acme Robotics website on Monday 2 March 2026 and observed it again every seven days: on 9, 16, 23 and 30 March.
- A technology is visible to the vendor from the day it goes live.
- Acme's change log gives four go-live dates: an analytics tool on 3 June 2024, a testing tool on 3 March 2026 that was switched off on 6 March, a chat widget on 12 March 2026 and a consent manager on 20 March 2026.
| Technology | Go-live you know | First-seen date in the sample | Adoption event | Lag |
|---|---|---|---|---|
| Analytics tool | 3 June 2024 | 2 March 2026 | None | Cannot be measured |
| Testing tool | 3 March 2026, off on 6 March | None | None | Never observed |
| Chat widget | 12 March 2026 | 16 March 2026 | 16 March 2026 | 4 days |
| Consent manager | 20 March 2026 | 23 March 2026 | 23 March 2026 | 3 days |
- Baseline. The analytics tool went live before 2 March 2026, the first observation of the website. The correct record is a first-seen date of 2 March and no adoption event: the data can say the tool was in place on that day. A sample that gives 2 March 2026 as the adoption date is wrong by 637 days.
- Lag. The chat widget was absent on 9 March and present on 16 March, so its event is dated 16 March, a lag of 16 minus 12, or 4 days. The consent manager was absent on 16 March and present on 23 March, a lag of 23 minus 20, or 3 days. The mean lag is (4 + 3) / 2 = 3.5 days. With seven days between observations a lag lies between 0 and 7 days. Timed to the hour it averages half the gap, 3.5 days, when go-lives fall evenly across it; counted in whole days under the second assumption it runs from 0 to 6 and averages 3.
- Order. No adoption date precedes its go-live. A date earlier than a go-live you are sure of is not an observation of that tool: it was inferred, written back afterwards or matched to something else.
- What was never seen. The testing tool lived from 3 to 6 March, between the observations of 2 and 9 March, and left no row. A dataset built from observations holds what was present at an observation.
On a larger sample, score the same checks as shares.
- Baseline: tools live before the first observation of their website that carry no adoption date. It should be all of them.
- Lag: tools live later whose adoption date falls at or after the go-live, by no more than the gap between two observations.
- Completeness: tools live later that carry an adoption date at all, read by kind of evidence.
When you hold no go-live dates
Open web archives give a second set of dated observations. Common Crawl publishes crawl archives that are free to access, and each response record holds what a website returned, with its date. Find the last capture of a page without a tag and the first capture with it, and you have an interval to set beside the vendor's date. Two limits come from its FAQ: the crawler does not execute JavaScript, so only a tag written into the page as served can be found, and the archive is a sample of the web that generally holds a subset of a website's pages.
Frequently asked questions
How does a technographics data provider track a historical tech stack over time?
By observing each company on a schedule, on its website or in another public source, and keeping every observation with its date. The record then takes one of three shapes: a state table with a first and a last date for each technology, periodic snapshots, or a change record with one dated event for each adoption and removal.
Is the first-seen date the date a company adopted a technology?
Only when an earlier observation of the same website did not show the technology. Otherwise the first-seen date is the day the vendor first looked at the website, or first recognised the tool, and the adoption happened at an unknown time before it. Compare the first-seen date of each technology with the first observation of its website. Where the two are equal, read the row as a baseline.
What is a baseline in technographic data?
A baseline is the first observation of a website, of a technology on it or of a kind of evidence, and it records what was already in place. It dates the start of observation and marks no change. In Fokals data a first observation sets a baseline and writes no event, so every row of Technology Changes is a change that was observed to happen between two dated observations of the same website.
How precise is a technology adoption date?
As precise as the gap between two observations. A tool goes live after the last observation that did not show it and on or before the first that did, so an adoption date is the late edge of that interval. On a weekly cadence the date is right to within seven days, and the lag averages half the gap when go-lives fall evenly across it. Test the lag on sample data against go-live dates you know.
Why do many companies show the same adoption date for one technology?
The first thing to rule out is a baseline. When a vendor starts to recognise a technology, every website already running it shows the tool at the next observation, and when a vendor adds a batch of websites, each one shows its whole stack at once. Ask whether such first observations are written as adoptions or kept apart, and check the answer by counting adoption dates per day in a sample.
Which date should a back-test use for a technology adoption?
The observation time of the change, because it is the first moment the adoption could be known. A go-live date learned or estimated later would let a test act on information nobody had on the day, which is look-ahead bias. Fokals carries the observation time on every event in Technology Changes, and its daily and weekly datasets are written once after the period closes and are never revised.
The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.
What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.