The historical archive: dated snapshots you can audit row by row

Why an archive, not just a list

Store data decays. Shops close, switch platforms, drop apps and change payment providers, so a list that was accurate when it was compiled quietly goes stale — and most sellers never tell you when theirs was compiled. We take the opposite approach: the data is organised as a series of dated snapshots, every record keeps the evidence of where and when it was observed, and the gap between our two headline numbers is published rather than hidden. This page explains how that works and how to use it before you spend anything.

The two provenance fields on every record

Two of the 12 fields in every record (the full layout is in the full column spec) exist purely so you can verify the other ten.

• Source URL — the exact page where our scanner observed the store. It is the primary evidence for the row: the platform, the technology and the published contact details were all read there.
• Last-observed date — the date we last saw that store live with that data. Freshness stops being a marketing claim and becomes a sortable, checkable field.
• Work through a few rows in the free sample for your industry — contacts are masked there, but the source URL and last-observed date are shown in full, because they are the point.

Dated snapshots, rebuilt lists

The current snapshot is dated 15 Nov 2026, and every slice states the snapshot it was built from. Packaged lists are rebuilt monthly from re-checked stores: the scanner revisits stores, confirms they are still live and still selling, and rebuilds the files from the results. Stores that have gone dead are dropped from the new build rather than carried forward — the count can shrink as well as grow, and that is the system working as intended.

Buyers are covered between builds too: pulls are billed per row (no subscriptions), and every pull draws on the current refreshed snapshot. You are buying into the refresh cycle, not a frozen export.

Because every snapshot is dated, snapshots can also be compared. A store present in two snapshots with a different platform recorded has migrated; a store whose last-observed date stops advancing has gone quiet; a store that appears for the first time is newly verified stock. Buyers running repeat campaigns use exactly this comparison to work only the changes — new stores, moved stores, dropped stores — instead of re-processing the whole market every time.

Scanned vs verified: the two numbers, honestly

Our index has scanned 23,984,359 domains. That is the discovery universe: every domain our pipeline is following as a possible store, including ones still being classified and ones that will turn out not to be stores at all. Of those, 1,504,744 are verified — our scanner has fetched the storefront and detected at least one ecommerce technology, so the store is real, live and sellable. The difference between the two numbers is not hidden inventory; it is work in progress.

This distinction matters because the industry habitually quotes the biggest number available. When a seller quotes millions of stores, ask which stage of their pipeline that number describes. We quote both, labelled, and we only sell the verified tier.

How buyers use the archive in practice

Treat the provenance fields as working tools, not decoration:

• Pick any row and open its source URL — you should land on the store the row describes.
• Check the last-observed date against your campaign date; for time-sensitive outreach, filter or sort for the most recently observed stores.
• Use the free checker (30 full-record unlocks a month on a free account) to spot-check stores you already know before buying a list around them.
• Re-download your file inside the 60-day window so your working copy matches the latest rebuild.

What the archive cannot promise

Honesty about limits matters as much as the mechanism. A last-observed date proves a store was live on that date; it cannot prove the store is live today, and a store can change platform or close the day after any scan. That is exactly why the dates are printed on every row and why lists are rebuilt on a two-week cycle instead of sold as permanent truth. If a store in our data asks to be removed, we honour removal within 48 hours and suppress the record permanently — the archive keeps the data honest in both directions. Full access routes, including the API, are on the developers page, and the wider feature set and guides explain how the index is built.

Questions, answered straight

Next steps