see.mierio.com

What this script does, and what it doesn't.

This domain serves one small script and receives the events it sends. Hotels and spas add it to their booking engine, through Google Tag Manager or a script tag, so their marketing team can see where guests drop out of the booking journey and which searches found nothing.

This page is for the engineers asked to allow it. It's short, and it's all true.

The short version

Script

https://see.mierio.com/v0/m.js

Sends to

https://see.mierio.com/v0/collect, batched

Size

Under 10 KB gzipped. No dependencies.

Loads

Asynchronously. Nothing else: no other scripts, fonts or pixels.

Cookies

One first-party cookie, mierio_sid, holding a random ID. Only after analytics consent.

Hosted

Data First's own servers in London. No CDN, no third-party services.

Who's responsible

The hotel is the data controller. Data First (Lyon Paul Limited) is its processor.

What to allow

If your engine sets a Content Security Policy, these are the only two additions. One domain, both directions.

script-src  https://see.mierio.com
connect-src https://see.mierio.com

What it reads

• Events your engine already pushes to window.dataLayer: GA4 ecommerce events and, where your engine provides them, hospitality events such as searches, availability results, checkout steps and payment results.
• The consent state from the consent platform already on the page (Cookiebot or Google Consent Mode).
• The page path without its query string, the referrer's domain, UTM parameters, and whether the device is a phone, tablet or desktop.
• Where an engine doesn't push its searches as events, the dates, nights and party size from its search URLs or availability requests.
• Where an engine doesn't push an event, a few known on-page messages set up per engine: no availability, a field that failed validation, a declined payment. It notes that the message appeared, never what the guest typed.

What it never does

• Collect names, email addresses, phone numbers, postal addresses, card details or anything a guest types.
• Record form values. A validation error is kept as the field name and error type only.
• Keep full booking references. They're hashed with a salt unique to each site.
• Keep full IP addresses. They're used for rate limiting; our server logs keep only a shortened version, for 14 days.
• Change your pages, add content or show anything to guests.
• Interfere with your data layer. It reads each event and always passes it on to the original push.
• Load other scripts. If Microsoft Clarity is already on the page, it adds three labels so recordings can be matched to journeys. It never loads Clarity.
• Throw errors into your page. Everything is wrapped and fails quietly.

Consent

Nothing is sent and nothing is stored on the device until the guest gives analytics consent. If consent is withdrawn, the script stops sending and removes its cookie. It follows the consent platform already on the page and doesn't bring one of its own.

How it behaves

• Loads asynchronously and doesn't block rendering.
• Queues events and sends them every five seconds or every 20 events, and once more with sendBeacon when the page is hidden.
• Keeps a session for 30 minutes of inactivity.
• Where the engine sits on a different domain from the hotel's website, links from the hotel's site into the engine carry a mierio_sid parameter so the session continues. The script removes it from the address bar on arrival.

On our side

• HTTPS only, with an allowlist of origins for each site. Anything from elsewhere is discarded.
• Every event is checked against a schema. Unknown fields are dropped.
• Rate limits and request size limits on every site.
• Raw events are kept for 13 months, then deleted.
• Hosted in the UK. No personal data in our logs.