End user tracking

Version 1.1 · Last updated 2026-09-10

Who is this page about?

This page is about end users: the people who talk to the Customer Agent and the other components you deploy in your own product or website. It is not about you as a customer of UNLESS, and not about the companies your end users may belong to. Three groups touch the platform, and each has a different standing in the law.

• Dashboard users are your own staff who log in to the Unless dashboard. We set one authentication cookie so they stay logged in, which is necessary to provide the service they asked for. Our cookie policy covers it.
• End users are the people who talk to your agent. They are natural persons, so the GDPR and the ePrivacy rules on storing information on a device apply in full. You are the controller of their data and Unless is your processor under the Data processing addendum.
• Customer accounts are the organizations your end users belong to, if you run a B2B product. Unless has no tracking or identification at that level. We never know, store or infer which company an end user works for, unless you add it to an identified end user’s profile yourself.

Organizations are not data subjects under the GDPR, but the people inside them are. That is why everything in Unless is built around the individual end user and their consent. The rest of this page is about that end user.

This page is not legal advice. Every deployment is different, so read the Data processing addendum and confirm your approach with your own legal team.

Does Unless track end users by default?

No. Out of the box, Unless sets no cookies for end users and does not track them. There is no visitor ID, no session cookie, no fingerprinting and no profile.

An end user who has not been through your consent flow is anonymous to us, and stays anonymous however often they come back. You can deploy the Customer Agent in this state and never ask anyone for consent.

Tracking starts only when you switch it on for an end user by calling our Consent API. Nothing on our side does that for you.

The three consent levels

Every end user is at exactly one of three consent levels at any moment. The level decides what we store in the browser, what we store in Unless systems, and how the two are connected. An end user moves up only when you call our Consent API or Identify API for them, and drops back to level 1 the moment consent is withdrawn.

Level 1: no consent, no tracking

This is where every end user starts and where most end users stay. Nobody has asked for consent and nobody has given it, so Unless does not track this person and sets no cookies.

• Cookies: none. Unless sets no cookies at all at this level.
• In the browser: the browser’s session storage holds the details of the current interaction: what was asked, what was answered, which component is open. This lets an end user refresh the page or move around your site without losing the thread.
• What that storage is not: it is not a cookie, it never reaches us as an identifier, and it disappears when the browser session ends.
• In Unless systems: we store an audit trail of the interaction, including its content, anonymously. It is not linked to a cookie, an identifier or a profile, so nobody can trace it back to a person.
• Why we keep it: the EU AI Act asks for traceability of AI interactions, and you need the record to review what your agent said. The anonymous trail gives you both without touching anyone’s privacy.
• Across sessions: nothing is remembered. A returning end user starts from scratch.
• Features: cookieless experiences only. A/B testing, audiences, user profiles and interaction history do nothing for this end user.

Level 2: anonymous consent

You have called the Consent API for this end user, but you have not told us who they are. Usually that call follows an explicit opt-in through your own consent mechanism, such as a cookie banner.

It can also follow implied consent, for a simpler reason: an agent that forgets is annoying. If the end user has to explain their problem again every time they come back, because the agent lost the thread of the last interaction, the service is worse than it should be. A typical case is a logged-in application, where you call the Consent API yourself at login, without a banner, so the agent remembers what was asked last time.

• Cookies: two, both anonymous. unless_id is a random visitor ID that remembers interaction details across sessions. unless_sid is a random session ID that remembers component behavior within the current session only, such as which panel is open or which step of a flow the user reached, and is deleted when the session ends.
• In the browser: the same session storage as level 1, plus the two cookies above.
• In Unless systems: the audit trail and the interaction history now belong to the anonymous unless_id. That is what lets us show an end user their earlier interactions and keep them in the same A/B test group next week.
• Profile data: you can add data to this end user’s profile programmatically. The only link between the person and that profile is the unless_id cookie, so if the cookie is cleared, expires, or the user withdraws consent, that link is gone for good and the data is stranded.
• Our advice on profiles: attach only session-level data at this level. Save durable attributes for level 3, where the profile has an anchor that survives a cleared cookie.
• Across devices: nothing. A cookie lives in one browser on one device, so the same person on their phone is a different anonymous end user to us.
• Features: A/B testing, audiences and interaction history work. User profiles work, with the caveat above.

Level 3: identified consent

The end user has consented, and you have called the Identify API with your own identifier for that user, typically the user ID from your own system after they log in. We still do not know who this person is. The identifier means something in your system, not in ours, and on our side it is only the anchor that ties the anonymous unless_id to one and the same person over time.

• Cookies: the same two, unless_id and unless_sid, with the same lifetimes as level 2.
• In the browser: identical to level 2. The browser never holds your identifier in a cookie.
• In Unless systems: this is where the difference sits. We connect the unless_id to your identifier, so when this user logs in again later, on any device, and you identify them again, we set the same unless_id in that browser.
• What that gives you: one consistent audit trail and one consistent experience across sessions and across devices, instead of a new anonymous visitor each time.
• Profile data: this is the level for durable profile data. The profile is anchored to your identifier and not to a cookie, so you can safely add app data such as the user’s subscription plan, role or product configuration, and clearing cookies no longer breaks the link.
• Across devices: yes, for as long as you identify the user on each device.
• Features: everything. A/B testing, audiences, user profiles with app data, and interaction history that follows the user from laptop to phone.

The three levels side by side

Which cookies does Unless set?

Two, and only after consent. Both hold random values and neither ever contains your identifier or any personal data.

unless_id

• Set: only after consent, at level 2 or 3.
• Content: a random identifier. At level 3 we connect it to your identifier on our side, but the cookie itself never contains your identifier.
• Purpose: keeps an end user in the same audiences and A/B test groups, and gives them access to their interaction history and profile.
• Expires: after one year, when consent is withdrawn, or when the browser’s cookies are cleared.

unless_sid

• Set: only after consent, at level 2 or 3.
• Content: a random session identifier.
• Purpose: remembers component behavior within one session, and ties session goals such as a completed interaction to that session for analytics and A/B test results.
• Expires: at the end of the session or when consent is withdrawn. Every new session gets a new ID.

How do you move an end user between levels?

Through two API calls, and nothing else.

• To level 2: call the Consent API when the end user opts in through your own consent mechanism. If you have a legitimate basis for tracking without a banner, you can also call it directly.
• To level 3: call the Identify API with your own identifier once the end user is logged in, in addition to consent.
• Back to level 1: withdraw consent through the Consent API. We remove both cookies and the end user is anonymous again from that moment.

The Unless dashboard also offers a switch for automatic consent, which puts every end user at level 2 without a call from your side. We recommend the APIs instead. They let you decide per end user and keep the consent decision where it belongs, in your own consent flow.

Our system enforces this, it does not merely request it. When an end user is at level 1, the cookie-dependent features are inactive for that person and only cookieless experiences show. You cannot accidentally track an end user who has not been moved up.

When do you need to ask for consent?

You need consent for any technology that stores or reads information on a user’s device in the EU or UK, unless it is strictly necessary to provide the service the user asked for. Tracking that only makes the service technically work can be strictly necessary. Tracking that measures, optimizes, personalizes or advertises generally is not.

Whether that means a consent banner, a clause in your terms, or nothing at all depends on which features you use. Apply one test per feature:

“If I remove this feature, does an important part of the service stop working?”

• Level 1 state: the session storage that keeps an interaction going across page loads exists only to make the agent work. This is the kind of state generally regarded as strictly necessary, and it is why level 1 needs no consent.
• A/B testing: this is optimization, so you will almost always need consent.
• Audiences for marketing: if you use them to show promotions to a segment, ask for consent.
• Audiences for access: if you use them to give people the right content, such as showing documentation or AI skills only to the end users entitled to them, they may qualify as a necessary part of the service.
• User profiles: the same logic as audiences, applied to identified end users.
• Interaction history: only available for identified end users, and used to show them their own earlier interactions. In many products this is an expected part of the service, and your terms at sign-up can cover it rather than a banner.

Whatever you conclude, be transparent. Tell end users what you store even where the law does not require consent, and confirm the approach with your legal team.

Related pages

• Cookie policy, for the cookies on the Unless website and dashboard itself.
• Data processing addendum, for the controller and processor roles that govern end user data.
• Data and locations, for where interaction data and audit trails are stored and for how long.
• GDPR and data subject rights, for how end users can exercise their rights on the data described here.
• EU AI Act compliance, for the traceability requirement behind the audit trail.