Personalisation FAQ guide

No. Contensis personalisation runs client-side in the browser and does not rely on third-party cookies.

Signals and custom attributes are stored using browser storage (e.g. session and local storage). This enables privacy-first personalisation without requiring third-party tracking cookies.

However, your cookie consent implementation may affect whether browser storage is permitted.

Yes, in most implementations.

As signals and attributes are stored in local storage, they:

• Persist across page reloads
• Persist across browser sessions
• Persist if a user returns the next day
• Remain until explicitly cleared

No.

Browser local storage does not expire automatically and is not session-scoped. If session-only behaviour is required, you must explicitly:

All stored signals and attributes and audiences are removed.

As a result:

• Behaviour-based audiences reset
• Returning users may see default variants
• Personalised journeys restart

No.

Personalisation is:

• Browser-specific
• Device-specific
• Domain-specific

It does not automatically sync between browsers or devices.

It depends on how consent is implemented on your site.

If your consent platform:

• Blocks only cookies → personalisation may still function
• Blocks all browser storage (including local storage) → behaviour-based signals may not persist

Contensis personalisation itself does not require third-party cookies, but storage availability depends on your consent configuration.

Contensis personalisation is designed to operate without third-party cookies and can be implemented in a privacy-first way.

However, compliance depends on:

• Whether personal data is used
• How consent is handled
• How analytics tracking is configured

You should ensure your implementation aligns with your organisation’s data protection policies.

In most cases, no.

Search engine crawlers typically:

• Do not persist browser storage
• Do not simulate multi-page behaviour
• Do not accumulate signals over time

They generally see the default (non-personalised) experience.

AI agents and automated traffic typically:

• Do not persist browser storage
• Do not simulate returning visits
• Do not accumulate behavioural signals

As a result, they usually see the default experience rather than behaviour-based personalised variants.

Only in limited cases.

If personalisation depends solely on immediate request data (e.g. user agent or IP-based logic), it may resolve at runtime.

However, behaviour-based personalisation (e.g. “viewed 3 course pages”) will not trigger for bots, as it requires interaction and persistent storage.

Because personalisation is evaluated in the browser, variant exposure must be tracked client-side.

Best practice is to:

• Capture the resolved variant at render time
• Send an analytics event (e.g. via dataLayer, GA4, or another analytics tool)
• Associate it with session and conversion data if required

Page views alone do not indicate which personalised variant was displayed.

No — not by default.

Signals and attributes stored in browser storage remain until:

• Cleared by the user
• Removed programmatically
• Expired via custom TTL logic

If expiry behaviour is required (e.g. “interest in clearing expires after 14 days”), this must be implemented explicitly.