Cookies and what we store on your device
Version: 1.0, effective 25 August 2026
RouteRound sets no cookies at all. Not one. The code never touches document.cookie.
That is unusual enough that it needs explaining rather than announcing, because the law here is not about cookies — it is about anything stored on or read from your device. That is regulation 6 of the Privacy and Electronic Communications Regulations 2003, and it covers local storage, session storage, databases in the browser, service-worker caches and mobile app storage just as much as it covers cookies. So this page lists everything, not just the thing with the famous name.
This page is the detail behind section 4 of our Privacy Notice. Where the two differ, the privacy notice is the one to rely on and we should fix this page.
The short version
| Cookies | None |
| Analytics | None. No Google Analytics, no Tag Manager, no Plausible, no PostHog, no Mixpanel, no Segment, no Hotjar, no Clarity |
| Advertising or tracking pixels | None |
| Error or crash reporting to a third party | None |
| Third-party scripts on the page | One — the Google Maps loader, and only in builds where a Maps key is set |
| Third-party content loaded into the page | Map tiles from OpenStreetMap, on the tree-preservation-order screen |
| Cross-site tracking | None. Nothing we store is readable by another site |
| Consent banner | None, deliberately — see the last section |
What we do store, and why
Everything below is first-party: written by RouteRound, readable only by RouteRound.
Your working data — IndexedDB
RouteRound is offline-first. Your schedule, sites, jobs, forms, photographs and signatures are held in a database in your browser (IndexedDB, through a library called Dexie), one per account, plus a small registry database that keeps track of which accounts exist on the device.
This is not a tracking technology. It is the application. Without it the app cannot show you tomorrow's round in a van with no signal, which is the reason the product exists.
Exception relied on: strictly necessary.
Staying signed in — local storage
Two separate sessions, because the app and the client portal are separate sign-ins and a person can hold both:
- the main application's Supabase session, and
rr-portal-auth, the client portal's own session.
Each holds an access token, a refresh token, and the account record that goes with them, which includes the email address. Without them you would sign in again on every page load.
Exception relied on: strictly necessary.
Keys we set ourselves — local storage
| Key | What it holds |
|---|---|
rr-theme |
Light, dark or system |
rr-trade |
Which trade you told us you are in, so the app uses the right words |
rr_active_user |
Which account is active on this device |
rr_db_map |
Which local database belongs to which account |
rr_auth_skipped |
That you chose to carry on without signing in |
rr_cloud_synced… |
When this device last synced, so it does not re-send what it already sent |
rr_blobs_up_user_… and rr_blobs_up_org_… |
Which photographs have already been uploaded, for a personal and for a team folder |
rr_publish_pending |
Which client shares failed to publish, so the next sync retries them |
rr_scoped_view_<user id> |
That this device holds a redacted view of a team's data rather than the whole of it |
rr_intro_token |
An invitation token, while you are accepting an invitation |
rr_join_token |
A team invitation token, while you are joining a team. Ignored once it is 24 hours old |
rr_intro_hint_seen |
That you have already seen a one-off hint |
rr_portal_focus |
Which schedule the portal was last showing |
rr_portal_density |
Compact or comfortable in the portal |
Keys that go when you close the tab — session storage
| Key | What it holds |
|---|---|
rr_intro_welcome |
The words a customer typed to describe her own organisation, carried across the invitation flow — for example "Sarah Jenkins, Acme Facilities Management", which may well include a person's name. This is the one item on this page that is somebody else's personal data sitting on your device, and section 4 of the Privacy Notice says the same |
rr_pw_recovery |
A password recovery token, while you are resetting a password |
rr_local_wipe |
That a local wipe is in progress, so it completes across a reload |
rr_side |
Which side of the sign-in screen you are on |
rr_welcome_seen |
That a welcome screen has already been shown this visit |
rr_portal_expect_dismissed:<client id> |
That a one-off portal prompt has been dismissed |
The app shell — service worker cache
A copy of the application's own code and icons, so RouteRound loads and runs without a connection. It contains no personal data.
Which exception each one relies on
Since 5 February 2026 there are five exceptions in regulation 6, after the Data (Use and Access) Act 2025 added three new ones. They are worth setting out because two of them are new and are widely misread as making analytics consent-free, which they do not.
| Exception | What it covers | Do we rely on it? |
|---|---|---|
| Communication | Sole purpose is transmitting a communication | No |
| Strictly necessary | Essential to provide the service you asked for | Yes — for your data, both sessions, the sync and account keys, and the invitation, join, recovery and wipe tokens. rr_intro_welcome sits here too: it carries another person's details through a flow you asked for, and it is not a preference |
| Statistical (new) | Aggregate information about how a service is used, to improve it. Needs clear information and a simple free way to object | No — we collect no statistics of any kind |
| Appearance and functionality (new) | Adapting how a service looks or works to your preference. Needs clear information and a simple free way to object | Yes — for rr-theme, rr-trade, rr_portal_density, rr_portal_focus, rr_intro_hint_seen, rr_welcome_seen, rr_side and rr_portal_expect_dismissed. This page is that information; the next section is how you object |
| Emergency assistance (new) | Geolocation to provide emergency assistance | No |
Turning it off
For the preference items — theme, trade, portal layout, the one-shot markers — clear RouteRound's site data in your browser settings, and they are gone. Nothing charges you for it and nothing asks you to justify it. The app carries on working; it will simply have forgotten what you liked.
Be careful: on the main app that same action also clears your offline working data. Sync first if you have anything on the device that has not reached the cloud.
The strictly necessary items cannot be switched off without switching off the service. That is what strictly necessary means, and it is why the law does not ask you to consent to them.
Other people's services
Some parts of RouteRound talk to other companies. What each one receives, and why, is set out in full in the sub-processor list — including the parts that disclose more than people assume, which is the whole reason that page is written the way it is. The OpenStreetMap map tiles and the Overpass nearest-A&E lookup both have their own rows there, and clause 8.6 of the Data Processing Agreement sets out exactly what your browser sends each one.
Three things belong on this page specifically:
The Google Maps loader is the only third-party script on the page, and only in builds where a Maps key is set. Where it runs, Google may set its own storage under its own terms, which we do not control. Read the sub-processor list before assuming that a build without a Maps key keeps addresses away from Google — every Navigate control in the app is a plain google.com/maps link built from a site's exact coordinates, and that is not gated on the key.
Map tiles on the tree-preservation-order screen come from OpenStreetMap, requested by your browser, which means OpenStreetMap sees the area you are looking at and your IP address.
The nearest-A&E-and-defibrillator button on the Emergency Action Plan form sends the site's coordinates to the Overpass API (an OpenStreetMap data service) — only when you tap it, and nothing else about you. It returns nearby hospitals and defibrillators for you to confirm.
Following a link out of RouteRound takes you to someone else's site under their rules.
Why there is no consent banner
Because there is nothing here that needs one.
Consent is required for storage that falls outside those five exceptions — advertising and marketing tags, cross-site tracking, profiling, third-party measurement. RouteRound has none of that. There is no analytics code, no advertising code and no tracking code anywhere in the product, and no third party is measuring you through it.
So a banner would ask you to agree to something we do not do. We think that is worse than no banner: it trains people to click through a consent dialogue that means nothing, and it makes the ones that do matter easier to ignore.
If we ever add anything that needs consent, we will ask for it properly, and this page will change first.
The mobile apps
The same analysis applies to the RouteRound apps on Google Play and the App Store. The ICO's guidance covers storage and access technologies generally, not just browsers, and the mobile clients are the same application in a wrapper — same storage, same absence of tracking. Neither store's build contains an advertising or analytics SDK.
Changes
We will update this page whenever the storage changes, and note the new version number and date. Reviewed at least annually.
Questions: privacy@routeround.co.uk.
Desultory Ltd, 133 Berrall Way, Billingshurst, England, RH14 9PQ. Registered in England and Wales, company number 17361684.