Hosted Package

Consent and security

Understand consent modes, domain restrictions, and security behavior for the Tiquo Hosted Package

The Hosted Package supports four analytics consent modes. full is the default when data-tiquo-consent isn't set. cookieless was added in script version 1.6.0.

ModeWhat the script sendsWhat it stores for analytics
fullAnalytics events, linked to the signed-in customerA session ID in sessionStorage
anonymousAnalytics events without the customer's identityA session ID in sessionStorage
cookielessAnalytics events without the customer's identity or a session IDNothing
noneNo analytics eventsNothing

full

window.Tiquo.setConsent("full");

Full consent allows analytics and known-customer linking. When a customer signs in, Tiquo can connect website activity to that customer record.

full is the default. Use it when your privacy policy covers linking website activity to an identifiable customer.

anonymous

data-tiquo-consent="anonymous"

Anonymous consent allows website analytics without linking events to a known customer identity.

This mode can track page views, sessions, attribution, engagement, device data, and custom anonymous events.

In full and anonymous, the session ID that groups a visitor's events into a visit is kept in sessionStorage as tiquo_analytics_session_<publicKey>. From script version 1.6.0 it is created with the first analytics event, not when the script loads.

cookieless

data-tiquo-consent="cookieless"

Cookieless consent is for visitors who decline your cookie banner. The script still sends page views, attribution, engagement, device data, and custom events, but stores nothing in the browser for analytics and leaves the session ID out of every event. As in anonymous, events are never linked to a customer: the script doesn't send the access token or an identityLinkType, and Tiquo.identify() sends nothing, even when a customer is signed in.

Without a session ID, Tiquo groups events into sessions on the server. Events from the same IP address, browser, and language in the same half hour (10:00 to 10:30, 10:30 to 11:00, and so on, in UTC) count as one session. Tiquo keeps only a hash of these details, and the hash changes every day. Session counts are less precise as a result: a visit from 10:25 to 10:40 counts as two sessions, and visitors who share a network and browser at the same time can count as one.

none

window.Tiquo.setConsent("none");

No analytics events are sent while consent is none.

Set the starting mode with the data-tiquo-consent attribute, then call setConsent() from your consent banner or privacy flow. Without the attribute, the script starts in full, or in none when data-tiquo-analytics="false".

window.Tiquo.setConsent("cookieless");

window.Tiquo.getConsent(); // "cookieless"

setConsent() returns the mode now in use. true, yes, and on mean full; false, no, and off mean none; any other unknown value is treated as anonymous.

  • The choice is saved in localStorage as tiquo_consent_<publicKey>, including cookieless and none, so a declined banner is remembered. On later visits, a saved choice takes precedence over data-tiquo-consent. The DOM Package uses the same key.
  • Changing from none to another mode starts analytics and sends a pageview for the current page.
  • Changing to full while a customer is signed in sends an identify event.
  • Changing to cookieless or none removes the stored session ID. Later events in cookieless are sent without one.
  • Changing to none stops analytics events straight away.

Customer sign-in is separate from analytics consent. When a customer signs in, the script keeps their session tokens in localStorage in every mode.

Default mode

When data-tiquo-consent isn't set and the visitor hasn't saved a choice, the script uses full. Before script version 1.6.0 the default was anonymous, so a site without the attribute now links analytics to signed-in customers. Set data-tiquo-consent="anonymous" to keep the earlier behavior.

If your website shows a consent banner, start in cookieless so visits are counted without storing anything in the browser until the visitor chooses:

<script
  src="https://tiquo.app/tiquo/v1/tiquo.js"
  data-tiquo-public-key="pk_dom_your_public_key"
  data-tiquo-consent="cookieless"
  defer
></script>

Then set the mode from the banner's buttons:

document.querySelector("#cookie-accept").addEventListener("click", function () {
  window.Tiquo.setConsent("full");
});

document.querySelector("#cookie-decline").addEventListener("click", function () {
  window.Tiquo.setConsent("cookieless");
});

Replace the selectors with your banner's buttons. If your privacy policy doesn't cover linking visits to customers, call setConsent("anonymous") on Accept instead. The choice is saved, so on later visits the script uses it in place of data-tiquo-consent.

Analytics consent is separate from customer communication preferences. setConsent("full") does not set Marketing Opt-In or SMS Opt-In. Use an authenticated profile form to let a customer check or uncheck either customer-editable consent preference. Only the signed-in customer's profile can be updated through this route.

For public signup without login, use subscribeToMarketing(). It matches by email within your organisation, creates a customer when needed, and applies checked opt-ins immediately. It never changes other existing profile fields, and false or omitted checkboxes never opt someone out. Its rate limits and spam checks reduce abuse without verifying ownership of the submitted email or phone.

Enquiry forms accept enquiry-type answers separately from fill-only customer parameters. customer.customerParameterValues and legacy customer.details can initialize missing customer-editable parameters, but never overwrite a stored value. Marketing/SMS defaults are already stored and cannot be changed through an enquiry. An enquiry parameter with the same label as a customer consent parameter is still only an enquiry answer. Server-side integrations can separately use the Admin API with a write-scoped secret key and staff-editable parameters.

Domain protection

Tiquo checks the request origin against the domains configured for your Website SDK public key.

Requests from unconfigured websites are rejected. This prevents another website from copying your public key and using it from an unapproved domain.

Public key safety

The Website SDK public key is safe to expose in browser code. It identifies the Tiquo organization and allowed website configuration, but it is not a secret.

Never put private API keys, admin API keys, or server secrets in the hosted script or website-builder custom code.

Token handling

The Hosted Package manages customer session tokens internally so it can call customer APIs after login. It does not expose raw token getter methods on window.Tiquo.

Because the script runs in the browser, any third-party scripts on the same page should be treated as part of your website security boundary.

For authenticated Tiquo iframes, the package exchanges a short-lived, one-time handoff token with the exact iframe origin using postMessage. It does not append access or refresh tokens to iframe URLs. Organization, origin, iframe window, nonce, and handoff version are checked before the token is accepted.

Content rendering safety

Customer, order, booking, and membership fields are rendered as text content by default.

When a field is rendered into an anchor element, the Hosted Package only allows safe link protocols such as https, http, mailto, tel, and relative URLs.

Profile-photo image and background data attributes accept only HTTP and HTTPS URLs.

On this page