Skip to content
The October 1 Indexby StatusBird LLC

The October 1 Index · Method changelog

Method changelog

Every change to how the index fetches, classifies or counts is recorded here with its date and its effect on the numbers. Records made before a correction are re-fetched before publication rather than re-interpreted; nothing in a published count rests on a superseded rule.

September 13, 2026: second pass complete, thirteen records excluded, index published

The re-fetch pass scheduled on September 11 finished at 09:17 UTC. Every store flagged legacy on its first fetch was fetched a second time on a different day, and 49 stores carried the legacy tag on both fetches. Before publishing, 13 of those records were excluded and are not counted anywhere on the index: 11 unrelated domains carrying the same set of developer and test tags (a HubSpot test hook, a Google library, and loca.lt and ngrok tunnels), which is one operator's development work rather than an app vendor's injection, and 2 stores whose only legacy host is a placeholder or personal domain, not an app. The exclusion list is kept with the tool and the excluded count is published in the index data. The remaining 36 stores are counted. Six script hosts that had been listed by hostname were matched to their app vendors the same day so that the notice rule applies to them.

Vendor rows were published unnamed on September 13 with counts intact. Each vendor is notified at its public contact address, and its name is added to the row two business days later, as the standing rule below requires.

September 11, 2026: block-window handling and re-fetch pass

Shopify's storefront edge answers a per-address quota with HTTP 429 responses that carry none of the platform's usual headers. The scanner had treated those as ordinary refusals, kept fetching at full rate, and recorded the affected stores as unknown. The scanner now recognises a 429 from Shopify's storefront address range as a quota signal, pauses for thirty minutes, and re-tries every store recorded as unknown before the confirmation pass. Effect: more stores confirmed, no change to the classification rule.

The same day, a second pass was scheduled to re-fetch every store whose latest record predates the September 8 correction below, so that every published count rests on the current rule. It runs after the first pass completes and before any vendor is notified.

September 9, 2026: two-fetch confirmation and vendor naming

A store counts on the index only if a legacy script tag for the same vendor is present on two fetches made on different days; a single fetch cannot place a store in a vendor's count. Script hosts are mapped to app vendors from the vendor's own site or the script's path; hosts that cannot be matched are published as bare hostnames, and scripts served from developer tunnels, bare cloud buckets or generic libraries are grouped in one unattributed row rather than named.

September 8, 2026: classifier correction

The first pilot counted any script whose address carried a shop= parameter as a legacy script tag. That over-counted: a theme app extension's script also carries that parameter, and the pilot flagged stores whose apps had already migrated. The rule was corrected to Shopify's own rendering of an API script tag, type="text/javascript" async="" in the document head, outside any app block marker or extension wrapper, from a host other than Shopify's CDN. Exposure among stores checked fell from roughly one in ten to roughly one in fifty. Records produced under the earlier rule are re-fetched, not re-interpreted (see September 11).

Standing rules

The full method is on the methodology page. Corrections to this page are welcome at index@statusbird.io.