Skip to main content
The store locator embed runs Closient JavaScript on your pages. That makes it your visitors’ data, disclosed under your privacy notice — so you need to know exactly what it sends and where. This page is the factual inventory to work from when you fill in your own notice or a data processing agreement.
This page describes system behaviour, not legal terms. Closient’s own privacy policy and terms are published separately at closient.com and govern our side of the relationship.

​
Requests the widget makes

Everything the widget loads or calls, in the order a visitor triggers it. Closient is the only party that receives visitor data, with one exception: map tiles — and that exception is one you can switch off, with data-map="off". Tile images are fetched by the visitor’s browser directly from OpenStreetMap, so while the map is on, the OpenStreetMap Foundation sees the visitor’s IP address and which map area they are looking at. Under their tile usage policy they also publish anonymised, aggregated usage data that includes which websites use the service. No other third party is contacted — the map library is bundled into the widget script, and both location lookups run on Closient’s servers rather than in the visitor’s browser.
Why Closient does not proxy tiles for you. We proxy the geocoder, so the obvious question is why not the map as well. The OpenStreetMap tile usage policy forbids it: §3.4 rules out “tunnel[ling] all clients behind a single, anonymous identity”, which is precisely the property that would make a proxy private, and §5 says the Foundation “generally do[es] not recommend” a caching proxy in front of their tiles. A proxy that satisfied the policy would still disclose your visitors; one that protected them would breach it. The honest options are therefore a tile source you hold your own agreement with, or no map — both below.

​
How location is determined

The widget tries three sources, in order, and stops at the first that works.
1

Browser geolocation

The browser’s own location prompt. Precise, and shown to the visitor as an explicit permission request by their browser. Closient receives the resulting coordinates but never the underlying device signals.
2

Network-level approximation

If the visitor denies or ignores the prompt, the widget asks Closient for the approximate location our edge network already derives from the connection. This is city-level at best and often less. It happens server-side: no third-party geolocation service is involved, and the visitor’s IP address is not stored or returned.
3

Address search

If neither is available, the visitor types a place. The text is sent to Closient, which resolves it to coordinates server-side and caches the result. The visitor’s browser never contacts the geocoding provider, so the provider sees Closient’s servers rather than your visitors.

​
Cookies and storage

The widget sets no cookies and writes nothing to localStorage, sessionStorage, or IndexedDB. It holds state in memory for the life of the page only. Analytics events are attributed to your publishable key, not to a visitor identifier — there is no cross-site or cross-session tracking, and consequently nothing for a cookie banner to gate. Coordinates from the browser’s location prompt are used for the search that requested them and are not persisted.

​
What Closient retains

​
Reducing third-party exposure to zero

If your privacy posture rules out any third-party request, the map is the only thing standing in the way — and data-map="off" removes it:
Every row in the request table above then points at Closient, and no map tile is requested. The widget degrades cleanly: the store list, search, distances, and click-throughs all work without a map, and the list expands to fill the space the map would have taken. The same applies to the iframe embed, via a query parameter:

​
Keeping a map, on your own terms

If you already hold an agreement with a tile provider — MapTiler, Stadia Maps, your own tile server — point the widget at it with data-tile-url and give the provider’s required attribution in data-tile-attribution:
Visitors then reach a processor you have listed, rather than one you have not. data-tile-attribution is required whenever data-tile-url is set: rather than guess an attribution or quietly fall back to OpenStreetMap — the host you were configuring your way off — the widget switches the map off and logs the reason to the browser console. Both attributes are script-embed only; the iframe embed accepts map=off but not a custom tile URL.

​
Configuration reference

The embed accepts these attributes. Only data-map and data-tile-url change what data is processed, and both only by removing or redirecting the map tile request.