Consent and security

Consent modes

The DOM Package has the same four analytics consent modes as the Hosted Package. full, anonymous and none were added in version 1.19.0, and cookieless in 1.20.0 (Hosted Package script 1.6.0).

full

Full consent allows analytics and known-customer linking. When a customer signs in, the SDK sends an identify event and includes the customer's access token with analytics events, so Tiquo can connect website activity to that customer record.

full is the default when you don't set consent, which matches releases before 1.19.0.

anonymous

Anonymous consent allows website analytics without linking events to a known customer. The SDK still tracks page views, sessions, attribution, engagement, device data, and custom events. It doesn't send the access token or an identityLinkType with them, and analytics.identify() sends nothing, even when a customer is signed in.

cookieless

From version 1.20.0, cookieless consent sends the same analytics events as anonymous but stores nothing in the browser. The SDK doesn't keep a session ID in sessionStorage and never sends the access token, so events are not linked to a customer.

Without a session ID, Tiquo groups a visitor's events on its server. It uses a hash of the visitor's IP address, browser and language that changes every day, and splits sessions into 30-minute windows. Visitor and session counts are estimates: a visitor who changes network or browser is counted again, and a long visit can be split into two sessions.

Use cookieless for visitors who haven't accepted your consent banner or have declined it. Whether you can run it without consent depends on the rules where you operate, so check with whoever handles your legal side.

none

No analytics events are sent while consent is none. Automatic pageview tracking starts when consent changes to anonymous or full.

Setting the consent mode

Set the starting mode with the consent option, then call setConsent() from your consent banner or privacy flow:

import { Tiquo } from '@tiquo/dom-package';

const tiquo = new Tiquo({
  publicKey: 'pk_dom_your_key_here',
  consent: 'anonymous',
});

// After the visitor accepts the tracking your privacy policy requires
tiquo.setConsent('full');

tiquo.getConsent(); // 'full'

setConsent() returns the mode now in use. An unknown value is treated as anonymous.

• The choice is saved in localStorage as tiquo_consent_<publicKey>. On later visits, a saved choice takes precedence over the consent option. The Hosted Package uses the same key, so a choice made on one applies to the other.
• Changing from none to another mode starts analytics and sends a pageview for the current page.
• Changing to cookieless or none removes the analytics session ID from sessionStorage.
• Changing to full while a customer is signed in sends an identify event.
• Changing to none stops analytics events straight away.
• With analytics: false there is no analytics instance, so getConsent() returns none and setConsent() does nothing.

A standalone TiquoAnalytics instance accepts the same consent option and has its own getConsent() and setConsent(). It doesn't know when a customer signs in, so call identify() yourself after changing to full.

Default mode and consent banners

When you don't set consent, the mode is full: analytics run and are linked to the signed-in customer.

If your site uses a consent banner, start in cookieless so you still see visits from people who haven't chosen. Call setConsent('full') when the visitor accepts, and setConsent('cookieless') when they decline:

const tiquo = new Tiquo({
  publicKey: 'pk_dom_your_key_here',
  consent: 'cookieless',
});

acceptButton.addEventListener('click', () => tiquo.setConsent('full'));
declineButton.addEventListener('click', () => tiquo.setConsent('cookieless'));

Use setConsent('anonymous') on Accept instead if your privacy policy doesn't cover linking visits to signed-in customers. Start in none, and decline to none, if you don't want any analytics without consent.

Versions before 1.19.0

Earlier versions have no consent modes, and analytics always links events to the signed-in customer. Upgrade to 1.19.0 or later if you can.

If you can't upgrade yet, turn off the built-in analytics and start a standalone TiquoAnalytics instance once the visitor makes a choice. Events are only linked to a customer when the analytics instance can read the access token, so leaving out getAccessToken keeps them anonymous.

import { Tiquo, TiquoAnalytics } from '@tiquo/dom-package';

const publicKey = 'pk_dom_your_key_here';

// No analytics until the visitor chooses
const tiquo = new Tiquo({ publicKey, analytics: false });
let analytics = null;
let linkCustomer = false;

// Anonymous: no token getter, so events aren't linked to the customer
function allowAnonymous() {
  analytics ??= new TiquoAnalytics({ publicKey });
}

// Full: pass the token getter so events are linked, then identify
function allowFull() {
  linkCustomer = true;
  analytics = new TiquoAnalytics({
    publicKey,
    getAccessToken: () => tiquo.getAccessToken(),
  });
  if (tiquo.isAuthenticated()) analytics.identify();
}

// Tiquo doesn't send identify on sign-in while its own analytics is off
await tiquo.verifyOTP(email, code);
if (linkCustomer) analytics.identify();

This works with these limits:

• TiquoAnalytics has no stop method. Changing to none, or from full back to anonymous, only takes effect on the next page load, when your code starts analytics differently.
• Your application saves the visitor's choice and picks the setup on each page load.
• When an instance is already running for the public key, a second TiquoAnalytics passes its getAccessToken to the running instance instead of starting another one. allowFull() relies on this so later pageviews are linked too.

What the SDK stores in the browser

From version 1.20.0, the SDK sets no cookies on your website. Earlier versions also set a tiquo_customer_user_ids cookie holding the customer's Tiquo user ID for a year when they signed in, whatever the consent mode. Nothing on your website reads it, and version 1.20.0 removes it when the SDK loads. Before 1.20.0, a TiquoAnalytics instance also wrote the session ID as soon as it was created, even with consent set to none.

Customer marketing and SMS consent

Analytics consent is separate from customer communication preferences. setConsent('full') does not set Marketing Opt-In or SMS Opt-In.

• For a signed-in customer, call updateProfile() with the marketing and SMS preferences.
• For a public signup form without login, use subscribeToMarketing(). It never opts anyone out and doesn't identify the visitor in website analytics.
• An enquiry field named "Marketing Opt-In" is only an enquiry answer and does not change customer consent.

Domain protection

Tiquo checks the request origin against the allowed domains of the websites configured for your public key. Requests from other websites are rejected, which stops another site from copying your public key and using it. Local addresses such as localhost can't be added; see Testing before you go live.

Public key safety

The public key (pk_dom_...) is safe to include in browser code. It identifies your organization's Website SDK configuration, but it is not a secret.

Never put Admin API secret keys or other server secrets in browser code.

Token handling

Unlike the Hosted Package, the DOM Package gives your code access to the customer's tokens. It stores the access and refresh tokens in localStorage under the storagePrefix (default tiquo_auth_), and getAccessToken() and getRefreshToken() return them. Any script on the page can read localStorage, so treat third-party scripts as part of your website's security boundary. Don't log the tokens, put them in URLs, or send them to an untrusted backend. See Token management.

Tokens in the URL fragment are ignored unless you set acceptUrlTokens: true, which is only for pages a native app loads in its own WebView. See WebView Integration.

Embed helpers pass the signed-in session to Tiquo iframes with a short-lived, one-time token over an origin-bound postMessage exchange. Access and refresh tokens are not added to iframe URLs. See Embeds and Memberships.

Rendering customer data

The DOM Package returns data and leaves rendering to your application. Customer, order, booking, and membership fields can contain text that customers entered, so insert them as text (for example with textContent or your framework's default escaping) rather than as HTML. Check the protocol of any returned value before you use it as a link, and allow only protocols such as https, mailto, and tel.