The refresh frequency technographic data needs depends on the decision it feeds, and on how fast that decision loses value while a change waits to be observed. This post gives you a cadence for each common use, the questions that put any provider's refresh statement on one scale, four tests to run on sample data, and a worked example of what a daily refresh changes against a monthly one.
What refresh frequency technographic data needs
Technographic data needs a refresh as frequent as the decision behind it is perishable. Outreach triggered by a technology change needs every website observed daily. Account scoring works on daily signals and a weekly score. Segmentation, installed-base lists and market sizing read the current state, which a weekly to monthly refresh serves.
One word covers three intervals, and a refresh statement may mean any of them.
- The observation interval is how often each company's website is observed again. It decides how old a change is when it is first seen: half the interval on average when changes fall evenly through it, the whole interval at most.
- The delivery interval is how often the file or the API is updated. A file delivered every day can carry detections last observed weeks earlier.
- Your load interval is how often you pull.
The age of a detection on the day you act is at most the sum of the three, and that age is what data freshness measures.
| Decision | What it reads | How fast the value fades | Refresh that fits |
|---|---|---|---|
| Outreach on a technology change: a displacement, a migration, a new adoption | The dated change | Days to weeks | Each website observed daily, changes pulled daily |
| Alerts when a customer removes your tool | The dated removal | Days | Daily |
| Account scoring and prioritisation | Changes summed over a trailing window | Weeks | Signals daily, score weekly |
| Segments and campaign lists by stack | The current state | Months | Weekly to monthly |
| Market sizing and installed-base counts | Counts of the current state | Quarters | Weekly to monthly |
| Back-tests and investment research | The dated record | It does not fade: the dates must be exact | A steady cadence, with an observation time on every row |
The third column holds starting values. We found no official statistic for how fast a technology change loses value for outreach, so treat each window as an assumption and replace it with what your own replies show. The fourth test below measures it.
Why a daily refresh of technographic data matters for outbound sales
A daily refresh matters for outbound sales when a change is the reason to write: an adoption, a removal, a platform migration. That reason weakens as the decision behind the change closes. Observed daily, a change reaches a rep about a day old. Observed monthly, it arrives 15 days old on average and up to 30 days old.
Age is the first of three things the observation interval decides.
- The age of the change at first contact. Half the interval on average, before delivery and your own load add theirs.
- The precision of the date. A change is dated by the observation that saw it, so the interval is the precision of every date. Order matters in a displacement play: a removal with another tool of the same category added within two weeks of it reads as a swap, and a removal with nothing in its place reads as an open decision, as the guide to competitor displacement plays sets out. Daily observation keeps the two events apart. Monthly observation can put both on one date.
- The changes that are seen at all. A tool adopted and dropped between two observations leaves no event. A three-week trial is always seen by a daily refresh and can pass a monthly one unseen.
A daily refresh adds little where the decision reads the state and not the change. A list of every company that runs a tool differs from last week's only by the week's adoptions and removals. The working rule: daily for a play that opens with a change the account made, weekly to monthly for a play that opens with what the account runs.
A worked example: daily against monthly refresh at Acme Robotics
Acme Robotics is an illustrative company, and every figure below is invented. It sells warehouse automation, and its outbound team writes to an account when the account's website shows a commerce platform migration or the removal of a rival's tool.
Assumptions:
- The team follows 1,500 target accounts, and 4% of them show a qualifying change in a 30-day month: 60 changes, two on each day.
- A change is seen by the first refresh after it happens, and a rep makes first contact the next day.
- The value of a change for outreach halves every 14 days, so a change keeps 0.5 ^ (age in days / 14) of its value.
Under a daily refresh every change is one day old at first contact. Each keeps 0.5 ^ (1 / 14) = 0.952 of its value, so the month's 60 changes are worth 60 × 0.952 = 57.1 changes at full value.
Under a refresh on the last day of the month, the changes of day 30 are one day old at first contact and the changes of day 1 are 30 days old. Two changes sit at each age from 1 to 30 days.
| Age at first contact | Changes | Value kept |
|---|---|---|
| 1 to 7 days | 14 | 11.5 |
| 8 to 14 days | 14 | 8.2 |
| 15 to 21 days | 14 | 5.8 |
| 22 to 30 days | 18 | 5.0 |
| All | 60 | 30.5 |
The monthly refresh delivers the same 60 changes. They are worth 30.5 at full value against 57.1, which is 53% of what the daily refresh delivers. Only 14 of the 60 reach a rep within a week of the event, against all 60. Each is dated to a window of 30 days, where the daily refresh dates it to one day.
The result turns on the half-life, which is why the decision sets the cadence. The next table gives the average share of value kept at first contact, computed the same way: one day of age under a daily refresh, ages 1 to 7 under a weekly one, ages 1 to 30 under a monthly one.
| Half-life of the value | Daily | Weekly | Every 30 days |
|---|---|---|---|
| 7 days | 91% | 69% | 30% |
| 14 days | 95% | 82% | 51% |
| 30 days | 98% | 91% | 71% |
At a half-life of 30 days a weekly refresh keeps 91%, close to a daily one. At 7 days a monthly refresh keeps 30%. Measure your own half-life before you choose.
Detection methodology, install dates and signal freshness in technographic data
A detection date is an observation date, never an install date. The installation happened between the last observation that did not show the technology and the first that did, so the observation interval is the precision of every install date. Signal freshness is the age of the latest observation on the day you act.
Four cases cover every row.
| What the row shows | What it says about the install date |
|---|---|
| First detected at the first observation of the website | Installed on or before that date. How long before is not in the data |
| First detected when the technology entered the provider's catalogue | Installed on or before that date, which marks the start of detection |
| First detected at a later observation | Installed between the previous observation and this one: within a day under daily observation, within a month under monthly |
| Last detected some time ago | Removed after that date, or not observed since. The date of the website's latest observation tells you which |
The second case can be checked where a provider dates its catalogue: BuiltWith's dataset fields include the date each technology was first added to BuiltWith, to hold a cluster of first-detected dates against.
The method decides what a date means. Detection from the website itself dates the presence of a technology on the site on the day it was observed. Detection from documents dates a mention. 6sense's technographic data overview, for example, lists job descriptions among its passive sources, and HTML source, JavaScript code and NS and MX lookups among its active ones. A posting that names a tool says the tool was in use or wanted when the posting was written, which is a different fact from a script found on a page that day. Ask which method stands behind each row, because the two kinds of date do not age alike.
Removals need the most care. The UK Information Commissioner's Office says the rules on storage and access technologies apply to cookies, tracking pixels, and scripts and tags, among others, and that where no exception applies the organisation using them must obtain prior consent. So a tag can be in use on a site and absent from one observation: held back until a visitor consents, or served to part of the traffic in a test. A sound method confirms a removal over more than one observation before it writes the event, and a daily refresh confirms in days what a monthly one confirms in months. Ask what confirms a removal, and which date the event then carries.
Refresh frequency of technographic data providers: BuiltWith, 6sense and HG Insights
BuiltWith, 6sense and HG Insights each document freshness in different terms. BuiltWith dates every technology with a first-detected and a last-detected date and counts live technologies against a published cut-off. 6sense states a review and update of its technographic data every two to four weeks. HG Insights describes a rolling refresh and carries first-verified and last-verified dates on each install.
| Provider | What its documentation says about refresh | Dates on a detection |
|---|---|---|
| BuiltWith | The Domain API can return only the technologies considered live: those last detected after the current cut-off of the full database update. The cut-off dates are published as a lookup | A first-detected and a last-detected date on each technology, and a first-indexed and a last-indexed date on each website, in the dataset fields |
| 6sense | A review and update of technographic data every two to four weeks, in its technographic data overview | A confidence score from 0 to 100 on each data point, with the recency of the detection as one of its three factors |
| HG Insights | A refresh on a rolling basis, in its answers page. For HG Cloud Dynamics, its product for cloud adoption and spend, a support article gives an update every 24 to 48 hours | Date First Verified and Date Last Verified on each install, in the HG Technographic object of its Salesforce connector. Intensity counts the unique dates on which a signal was detected for a product at a company |
The three statements are different measures. A cut-off date says how recent a detection must be to count as current. An update interval says how often a record is reviewed. A rolling refresh says that records are updated outside a fixed release schedule. Four questions put any provider's statement on one scale.
- Is the stated interval the delivery of the file, or the observation of each company?
- Which dates does each detection carry: the first and the latest observation, and for a change the time it was observed?
- Against which date is a technology counted as current?
- What confirms a removal, and how long does confirmation take?
Wappalyzer's lookup API takes the age as a parameter: it returns by default results verified at least once in the last two months, accepts a maximum age in months, and scans a website live on request.
The same questions apply to sales intent built on technology data. A score weighted by recency counts from the observation date, so under a monthly refresh a change can be 30 days old on the day it is scored as new.
Four tests to run on sample data
Ask each provider for sample data on the companies you track, with its data dictionary, and run the same four tests on each. The queries use the Fokals datasets Website Profile, Technology Stack and Technology Changes. Any sample that carries the same dates takes them with the names changed.
1. How old is the latest observation of each website? Website Profile holds the latest observation of each website with the time it was made. Count the websites observed within two, seven and thirty days.
select
count(*) as websites,
sum(case when last_read_at >= now() - interval '2 days' then 1 else 0 end) as read_in_2_days,
sum(case when last_read_at >= now() - interval '7 days' then 1 else 0 end) as read_in_7_days,
sum(case when last_read_at >= now() - interval '30 days' then 1 else 0 end) as read_in_30_days
from company_site_facts;2. How old is each detection? In Technology Stack the last-seen date is the latest observation that showed the technology. Leave out the rows that await confirmation of a removal, count the detections older than thirty days in each category, and read the oldest of them, not the median.
select
technology_category,
count(*) as detections,
min(last_seen_at) as oldest_last_seen,
sum(case when last_seen_at < now() - interval '30 days' then 1 else 0 end) as older_than_30_days
from company_technologies
where missing_since is null
group by technology_category
order by older_than_30_days desc;3. How long does a change take to reach you? Load Technology Changes every day for two weeks into a table of your own that records the time of each load. The query reads that table, and the delay from observation to load is the part of the age that delivery and your pipeline add.
select
change,
count(*) as events,
avg(loaded_at - observed_at) as average_delay,
max(loaded_at - observed_at) as longest_delay
from tech_events_loaded
where category in ('technology', 'dns', 'platform')
group by change;4. How fast does a change lose value for you? Join your outreach log to the changes by account, and compute the age of each change at first contact. Group the contacts into bands of 0 to 3, 4 to 7, 8 to 14 and 15 to 30 days, and compare the reply rate of each band. The age at which the rate falls to half is your half-life, and it replaces the assumption of the worked example.
How Fokals dates and refreshes technology data
The marketing stack dataset is refreshed daily to weekly, and it keeps the state and the change apart. Technology Stack holds one row for each company website and technology, with its first-seen and last-seen dates. Technology Changes holds a dated event for every adoption, removal and platform migration, each with the time it was observed. A first observation sets a baseline and is never counted as a change, a technology new to the catalogue does the same on each website, and a removal is confirmed before it is written, so every event is a change seen between two observations. Each row records the kinds of evidence that showed the technology, and the post on what a Fokals technology row tells you shows how to read one.
The intent dataset sits beside it: Company Signals is refreshed daily, and Intent Scores are written weekly, each score with the dated evidence behind it. Delivery is by REST API and as bulk files. The feed of website changes runs oldest first from a time you set, so the last cursor is the bookmark for a daily incremental sync. The methodology states the refresh of each dataset, and the data dictionary defines every date named here.
Frequently asked questions
How often should technographic data be refreshed?
As often as the decision it feeds loses value. For outreach triggered by a technology change, each website should be observed daily, because the change is the reason to write and it ages by the day. For account scoring, daily signals and a weekly score are enough. For segmentation, installed-base lists and market sizing, which read the current state, a weekly to monthly refresh serves.
Why does technographic data freshness matter for outbound sales on technology changes?
Because the change is the opening line and its date is the evidence. With a daily refresh, a technology change reaches a rep about a day old, dated to one day. A monthly refresh delivers it 15 days old on average, dated to a window of 30 days, and never sees a tool adopted and dropped between two observations.
Is a first-detected date the same as an install date?
No. A first-detected date is the date of the first observation that showed the technology. The installation happened between that observation and the one before it, so the gap between observations is the precision of the date. A technology already present when a website was first observed carries the date of that first observation, and how long it had been in place is not in the data.
How do I measure the age of a technographic detection?
Subtract the last-seen date of each detection from today, and do the same for the latest observation of each website. Then read the distribution, not the average: the share observed within two, seven and thirty days, and the oldest tenth. A sample passes when its oldest tenth is still fresh enough for the decision the data feeds.
Does a file delivered daily mean the data is refreshed daily?
Delivery and observation are two intervals. A file can be delivered every day while each company in it is observed once a week or once a month, and the file then carries detections of every age in between. Ask for the observation interval of each company, and check it on a sample by reading the last-seen date on each row.
How does refresh frequency affect intent scores?
A score weighted by recency counts each signal from the date it was observed. When observation is frequent, that date is close to the event and the score rises while the change is new. When observation is monthly, a change can be weeks old on the day it is first scored. Fokals refreshes Company Signals daily and writes Intent Scores weekly, each score with the dated evidence behind it.
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.