Build a store location spreadsheet and track changes

What you’ll make

A spreadsheet you can filter by city, state, or country, with source links for checking individual locations. It can help with retail footprint research, dealer and stockist lists, or tracking where a brand is available.

You’ll need an Apify account, a spreadsheet app, and the URL of a brand’s “find a store” page. A brand’s locator may list independent stockists as well as its own stores, so check what the source represents before interpreting the results.

1. Start with a small export

Open the Store Locator Scraper with Change Detection on Apify. Paste the following into its JSON input. This example uses the Dagne Dover locator from the actor’s documentation; replace the URL with the brand you want to research.

{
  "locatorUrls": [
    "https://www.dagnedover.com/pages/store-locator"
  ],
  "country": "US",
  "includeHours": true,
  "maxLocations": 25
}

locatorUrls takes the locator page URL, not the brand’s homepage. maxLocations caps the locations fetched at 25. country keeps US rows after fetching, so a capped run can return fewer than 25 matching locations. Omit the country filter to keep all countries.

includeHours includes opening hours when the source publishes them. Review the actor’s current pricing and set a maximum charge before starting. This small run is for checking the fields; it is not a monitoring baseline.

2. Export and organize the results

Run the actor, wait for it to succeed, and inspect its output dataset. Export it as CSV or Excel. In Google Sheets, use File → Import → Upload to load the file.

Keep brand, storeName, addressFull, city, state, country, locationId, and sourceUrl visible. Keep latitude and longitude if you plan to map the locations. Missing source values are null; they do not mean zero or an empty store.

On a first run, new means newly seen by the actor. It does not mean the store has just opened. Enable sheet filters, group rows by geography, and keep the source URL so you can verify the listing.

3. Save a complete baseline

To compare locations over time, run again with maxLocations: 0 and emitUnchanged: true. Zero removes the location cap. Keep the same locator URL, country, and hours settings for future comparisons.

{
  "locatorUrls": [
    "https://www.dagnedover.com/pages/store-locator"
  ],
  "country": "US",
  "includeHours": true,
  "maxLocations": 0,
  "emitUnchanged": true
}

Check that the dataset is nonempty and its rows have snapshotComplete: true. Save that run’s dataset ID from Apify Console. A capped sample, an incomplete crawl, or an export containing only changed rows is not a reusable baseline.

The actor can use supported Yext, Stockist, Storemapper, and Uberall sources for complete snapshots. Its generic HTML fallback can return useful rows, but cannot establish completeness for closure detection. A maximum-charge limit or a source problem can also prevent a full result; check the run status and output before using it as a baseline.

4. Compare a later run

Run the same inputs later, adding diffAgainstDatasetId. Replace the placeholder below with the complete baseline’s dataset ID, not its run ID.

{
  "locatorUrls": [
    "https://www.dagnedover.com/pages/store-locator"
  ],
  "country": "US",
  "includeHours": true,
  "maxLocations": 0,
  "emitUnchanged": true,
  "diffAgainstDatasetId": "REPLACE_WITH_BASELINE_DATASET_ID"
}

Filter the exported sheet by changeType. The actor marks locations as new, closed, moved, hours_changed, or unchanged. Inspect changedFields for the specific differences.

A closed row means a listing disappeared from a complete locator result. It is a signal to investigate, not proof of a business closure. Confirm it with the source before acting. Locations are matched using their source ID, with an address fallback, so changes to a source’s IDs or addresses can affect matching.

Keep emitUnchanged: true if you want to use this output as the next baseline. Setting it to false produces a changes-only export that cannot be reused as diffAgainstDatasetId. Filtering the output does not avoid the work of fetching locations to compare them.

5. Monitor on a schedule

For recurring checks, create a dedicated key-value store in Apify Console and use its ID as monitorStateStoreId. Save the input as an Apify task, run it once to initialize the baseline, then add a schedule.

{
  "locatorUrls": [
    "https://www.dagnedover.com/pages/store-locator"
  ],
  "country": "US",
  "includeHours": true,
  "maxLocations": 0,
  "monitorStateStoreId": "REPLACE_WITH_YOUR_STORE_ID",
  "emitUnchanged": false
}

Replace the placeholder with your store ID. The first successful run returns the initial locations as new. Later runs use the full baseline saved in the key-value store and, with emitUnchanged: false, return only the supported changes. A successful later run with no changes can have an empty output dataset.

Use a separate state store for each monitor, and prevent overlapping runs. Keep maxLocations: 0, and do not combine monitorStateStoreId with diffAgainstDatasetId. Keep the locator URLs and filters consistent; start a new monitor store when changing the scope. An incomplete or unsupported source causes a recurring monitor run to fail rather than report guessed closures.

If the output is empty or incomplete

Check that you supplied the actual locator page and that your country filter matches its locations. A capped sample can miss the country you selected. Review the run log for source errors, blocked requests, or spending limits.

The actor reads public locator data and honors robots rules. It does not sign in or solve CAPTCHAs. If a page exposes no usable data outside its JavaScript-rendered map, it may return no rows. Share the locator URL in an issue on the actor’s Apify page if you need help with a source.