This guide covers functional and technical information on how Intempt works with cookies, local storage, opt-in/opt-out options, and consent management.

Using Intempt cookies

A “Cookie” is a piece of website data stored on a user's web browser. Websites can retrieve cookies later to access data stored for functional and/or technical purposes. After initialization, the Intempt JS SDK creates a cookie that begins with the prefix intempt.

For example, if the default value for the prefix is used and you enter the following:

❗ Add an example

The Intempt JS SDK creates a cookie with the format intempt_ with the characters of your project's API Key appended. (❗ review if the API key is actually added - it should be)

Data stored in the cookie

The cookie is used to keep track of a few bits of metadata for the SDK:

• deviceId: A randomly generated string
• visitorId: Upon user log-in, if your instrumentation sends this value to Intempt, it's stored in the cookie. Intempt recommends you set this to identify users uniquely.
• optOut: A flag to opt this device out of Intept tracking. If this flag is set, no additional information will be stored for the user.
• sessionId: A randomly generated string for each session
• eventId: An incrementing sequence of identifiers used to distinguish events
• ❗ Add any other data stored in the cookie

When the Intempt JavaScript SDK loads, it checks the cookie to see if it has an visitorId in it (if user is a returning user and the visitorId was generated in a previous visit). If it finds one, it uses that value. If it doesn't find one (either because it's a new user or the user recently cleared cookies), the SDK randomly generates a visitorId, and also saves it to the cookie.

Cookie size (❗verify size)

The cookie size can vary, going from a minimum of 100 bytes to some 200 bytes.

Expiration time (❗ needs to be implemented if not already)

The Intempt SDK has a cookieExpiration option allows you to set the number of days a cookie will live. The default cookieExperiation is 1 year. Most browsers will limit the lifetime of cookies set using thedocument.cookie from 1 to 7 days.

Remove Intempt cookies (❗ needs to be implemented)

To programmatically remove the Intempt cookie, use the method JavaScript SDK's clearStorage() method. This method clears all cookies, and deletes any metadata stored on them.

Data stored in Local Storage

Besides the information that was managed in the cookie, Intempt uses this storage to store:

❗ Need to be listed

Disable cookies and Local Storage / Session Storage (opt-out storage)

When you disable cookies and the user disables Local Storage and Session Storage, Intempt creates a new visitorId for that user every time they visit your site because it can't find an existing ID. If the user logs in or provides other identifying information during their visit (like email), Intempt's identity resolution system ties the various visitorId values together with that user ID. The user must log in on each visit to enable Intempt to consolidate identifiers.

Disabling tracking (opt-out tracking)

Users may wish not only to opt out of cookies, preventing Intempt from storing any data in the cookie, but also opt out of tracking completely, which means no events and no records of their browsing history will be stored in Intempt. The Intempt SDK provides an optOut as a way to fulfill this request. To programmatically opt-out of tracking, the SDK provides the method intempt.setOptOut(true).

“Do not track” setting on browsers (DNT flag) (❗remove the DNT from JS)

Some browsers have a setting “Do not track” that's intended to block all tracking. Intempt doesn't adhere to this setting. The DNT standard isn’t widely supported and it isn’t clear what it’s meant to disable. If you want to consider that setting, you'll need to write your own code to test for the DNT flag and then set the optOut option in the SDK.

Managing cookie consent (❗needs to be implemented)

Certain jurisdictions require that end users consent to non-essential cookies before any data is collected. You are ultimately responsible for ensuring that you obtain any necessary consents and make any necessary disclosures for the personal data you collect and send to Intempt. You're also responsible for determining how you classify the Intempt cookies in your cookie policy based on your specific use case and the jurisdictions in which you use them.

Therefore, if you use the Intempt JS SDK in a jurisdiction requiring consent before any non-essential cookies are set, don't initialize SDK until the end-user has consented to using cookies. This is because the Intempt functionality (cookie storage, local storage, and tracking events) is enabled or disabled upon SDK initialization.

To allow for this, the JavaScript SDK offers an option called deferInitialization (defaults to null). If set to true, it disables the core functionality of the SDK, including saving a cookie (or anything to the local storage) and all tracking, until explicitly enabled. This allows the SDK instance to load without storage and tracking until you call intempt.getInstance().enableTracking().

When you call intempt.getInstance().enableTracking(), the option deferInitialization is set to false and the cookie is created with the options values you configured, as you can see in the code below.

<<❗Example - needs actual code>>

/**
* Enable tracking via logging events and dropping a cookie
* Intended to be used with the deferInitialization configuration flag
* This will drop a cookie and reset initialization deferred
* @public
*/
inemptClient.prototype.enableTracking = function enableTracking() {
   // This will call init (which drops the cookie) and will run any pending tasks
   this._initializationDeferred = false;
   f(this);
   this.runQueuedFunctions();
 };

 };

This doesn't affect users who have an Intempt cookie. As you can see in the code below, that means that, at some point, the user provided consent, allowing the cookie to be created. To opt that user out of tracking, you must remove any Intempt cookies previously set for that user.

<<❗Example - needs actual code>>

const hasOldCookie = !!this.cookieStorage.get(this._oldCookieName);
const hasNewCookie = !!this._metadataStorage.load();
this._useOldCookie = !hasNewCookie && hasOldCookie && !this.options.cookieForceUpgrade;
const hasCookie = hasNewCookie || hasOldCookie;


if (this.options.deferInitialization && !hasCookie) {
   this._deferInitialization(apiKey, opt_userId, opt_config, opt_callback);
   return;
}

The decision to track events determines whether a user has an Intempt cookie. For users that have an Intempt cookie, consider the following:

1. If you manually define cookieExpiration to be a short lifespan, you may need to run intempt.getInstance().enableTracking() upon the cookie expiration or user log in.

2. If the user removes all the cookies, they will likely be shown the consent banner again the next time they visit the site/app. Since there won’t be any Intempt cookie yet set, the flow will go as indicated: the initialization of storage and tracking options will wait if using deferInitialization = true.

3. If the user consented to the Intempt cookie at some point and the consent has expired for any reason (website cookie deletion, consent tracking expired), the user will be prompted for consent again. If the user declines the consent, the Intempt cookie must explicitly be removed; otherwise, it will continue to collect the user’s information regardless of the consent declination.

Storage options explained (❗ need to be filled)

This table gives a brief overview of each option related to storage.

Differences between cookie consent and consent management

Intempt supports cookie consent (opt-out) and consent management - learn the difference between these concepts.

Frequently asked questions

Are our cookies first-party or third-party cookies?"

We use first-party cookies. From a technical standpoint, there’s no intrinsic difference between first-party and third-party cookies. The distinction is related to:

1. The context of a particular visit.
2. Who creates the cookie.

Every cookie has an owner, this is a domain defined in the cookie:

• First-party cookies are issued by a website that a user views directly. So, if a user lands on a website – for example, fit.intempt.com – then this site creates a cookie which is then saved on the user’s computer.
  This is the case for Intempt. When a customer decides to use our JS SDK for tracking on their website, this customer and this website are directly creating the cookie that is stored on the visitor’s computer.

• Third-party cookies are not created by the website being visited, but rather by someone else. Let’s say you’re visiting fit.intempt.com, and this site uses YouTube videos for the virtual non-live classes. In this case, it will be YouTube who is setting a cookie which is then saved on the user’s computer.

  What is happening in this case is that the website owner is embedding pieces of code, provided by YouTube, for the videos to play directly in fit.intempt.com. When that YouTube code is executed in the browser, or the video is loaded, YouTube can track the player and put data in its cookies. As a result, the cookie is classified as a third-party cookie, because it’s created by a different domain than fit.intempt.com / intempt.com

How do you integrate with third-party Consent Management Platforms?

A consent management platform – or “CMP” – is a technology that websites/applications can use to manage legal consent from users to collect and process their personal data through cookies and other trackers in operation on the domain as may be required by applicable privacy laws, such as GDPR, CCPA, and ePrivacy. Some examples of these tools are OneTrust, Axeptio, and Responsum.

At the time of writing this document, Intempt does not have an OOTB integration with any of these tools. Therefore, the customer must configure their CMP to pass the outcome of the consent to the Intempt SDK, so that any end user that has not provided consent or has revoked consent (depending on the end user’s jurisdiction) will be opted out of tracking by the Intempt SDK. That signal must be received by the SDK as implemented on the customer’s site/application to execute (if consent is accepted) the method intempt.getInstance().enableTracking() while using the SDK deferred initialization.

Can we use OneTrust with Intempt to stay GDPR compliant?"

Yes, Intempt can be used in connection with a CMP, like OneTrust, in a GDPR-compliant manner. However, to ensure compliance, customers must implement Intempt in a way that meets their compliance needs. Intempt is not able to advise customers on how to classify the Intempt SDK/cookies as this is up to our customers’ privacy and legal teams to assess based on the data being collected. However, almost all customers, including in the EU, classify Intempt cookies as Performance/Analytics cookies.

Additionally, customers may choose to implement via a server-side integration, bypassing Intempt's cookies from the SDK. However, customers who integrate via a server-side integration will still be responsible for ensuring that they obtain any necessary consents and make any necessary disclosures for the personal data they collect and send to Intempt.

When a user is opted-out, how can we opt-them back?

Besides the method intempt.getInstance().enableTracking() previously discussed, once a user has been opted-out, it can be opted-in programmatically by calling the method intempt.setOptOut(false). This will set the option optOut to false, re-setting the cookie with the new options and enabling the tracking.