Privacy & data

BookingsXP is built so that Microsoft Bookings stays the system of record. By default BookingsXP passes a booking through to Microsoft and keeps no names, emails or phone numbers. This page lists exactly what is read, stored and sent, so you can describe it in your privacy notice.

Summary#

On your page: the loader#

The script on your page (/embed/v1.js) collects campaign attribution so bookings can be credited to the ad or email that brought the visitor.

It reads:

• UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) and ad click IDs (gclid, gbraid, wbraid, fbclid, msclkid, li_fat_id, ttclid) from the page URL,
• document.referrer,
• three first-party cookies, if your site already has them: _ga (the GA4 client ID), _fbp and _fbc (Meta). It never reads any other cookie and never sets one.

It stores:

• localStorage["bxp_attr"]: the first touch (landing page, referrer, UTMs, click IDs, when it was first seen). Kept for 90 days, and replaced only when a later visit arrives with new UTMs or click IDs, so a direct return visit does not wipe out the campaign that found the visitor.
• sessionStorage["bxp_s"]: a flag used to count how many browsing sessions the visitor has had. It is cleared when the tab closes.

It sends this attribution only to the widget iframe, by postMessage to the BookingsXP origin. It is never put in a URL, so it does not appear in server logs or analytics as a query string.

Global Privacy Control and consent#

The loader checks consent each time a widget starts. Attribution is reduced if either:

• the browser sends Global Privacy Control (navigator.globalPrivacyControl === true), or
• your site sets window.bxpConsent = false.

In that case the widget receives only the current page address without its query string and the referring site's origin, bxp_attr is deleted, and nothing new is stored. Bookings still work normally.

Wire it to your consent tool so that false is set when the visitor declines, and removed or set to true when they accept:

<script>
  // Before the BookingsXP script, restrict until the visitor decides.
  window.bxpConsent = false;

  // Call this from your consent tool's "accepted" callback.
  function onMarketingConsentGranted() {
    window.bxpConsent = true;
  }
</script>
<script src="https://bookingsxp.com/embed/v1.js" async></script>

A widget that is already open keeps what it received when it started; the next widget load uses the new value.

Consent for Google, Meta and LinkedIn tags is separate: the loader only calls gtag, fbq or lintrk if those tags are already on your page, so whatever your consent tool does with them applies. See GTM, GA4 and ad conversions.

In the widget: analytics without cookies#

The widget runs in an iframe on bookingsxp.com and sets no cookies. For the funnel in your dashboard, each widget load gets a random ID (like s_4k9x…) that lives in memory only and is gone when the page closes. It is not stored on the device and cannot follow a visitor across visits or sites.

Each funnel event records: the event name and time, the page's host and path (no query string), the referring host, the classified source, medium, campaign and channel, which kind of ad click ID was present (not its value), the service and staff member chosen, the slot time, device type (mobile, tablet or desktop), country, and the visitor's time zone. It records no name, email, phone or IP address.

Link-only widgets record no funnel events.

At booking time#

When the visitor books, the widget sends their details (name, email, phone, notes, answers to your custom questions) and the chosen time to BookingsXP, which creates the appointment through your Microsoft Bookings page. Microsoft then holds the booking and sends the confirmation.

Unless you turn it off, BookingsXP also appends a short attribution block to the booking notes in Microsoft Bookings (source, campaign, first page, referrer host, which ad click ID was present, and the BXP-XXXXXX reference). It contains no personal data. See the format.

If you turn on Enhanced conversions, the widget also computes a SHA-256 hash of the visitor's email in the browser and passes it to Google Ads on your page. See Google Ads.

You can show your own consent text with a required checkbox in the booking form from the widget's settings.

Store bookings (optional data layer)#

Store bookings in BookingsXP is a per-widget switch under Data & access, and it is off by default. When it is on, BookingsXP keeps a copy of each booking made through that widget: name, email, phone, notes, answers, attribution and the appointment details. That copy powers:

• the Bookings list and search in the dashboard,
• CSV export (Pro and Business),
• booking.created webhooks, including Slack and Teams alerts,
• the REST API bookings endpoint (Business).

Turning it off stops new copies; bookings already stored remain until they are deleted or expire.

Erasure#

From the dashboard's Bookings page you can:

• Delete a single stored booking.
• Erase by email: delete every stored booking for one email address across your organization, for data subject requests.

Both remove data from BookingsXP only. The appointment in Microsoft Bookings is not changed; handle that in Microsoft Bookings or Outlook as you do today. Erasure is recorded in your organization's audit log (with the count, not the email).

Retention#

A nightly job deletes data older than your plan allows.

Webhook delivery logs, which include the payload that was sent, are deleted after 30 days on every plan. Funnel data older than your plan's period cannot be queried and is removed.

Limiting where a widget runs#

Under Data & access → Allowed websites you can list the domains a saved widget may be embedded on. Subdomains are included. Leave the list empty to allow any site.

Related#

• Security & data for hosting and processing.
• Privacy policy.
• Questions: hello@bookingsxp.com (opens in a new tab).