Most AI Concierge implementations on WooCommerce stores conflate session memory with persistent identity. Separating them at the architecture level lets the session memory live inside PECR’s strictly-necessary exemption — no consent banner required, no compliance footprint expanded. The cross-session personalisation layer becomes a clean opt-in instead of a hidden default.
The ICO finalized its updated Guidance on the use of storage and access technologies on April 29, 2026, following two consultations on the Data (Use and Access) Act changes to PECR. The line between strictly-necessary session state and consent-required persistent personalisation is now drawn unusually clearly.
What PECR Actually Says About Session State
The Data Protection Network’s plain-language summary names the regulatory authority directly: PECR’s strictly-necessary exception applies to recording information or selections the user makes on an online service. That is the statutory hook for session memory.
The ICO’s finalized April 2026 guidance confirms the application: first-party session cookies for tracking user input — shopping basket contents, form completion, in-flight checkout state — can rely on the strictly-necessary exemption depending on purpose limitation. The cookie has to be used only for that purpose. It cannot drift into analytics, cannot drift into advertising, cannot persist past the session.
The exemption is narrow on the other side. Per the Data Protection Network, strictly-necessary does not apply to cross-device tracking, online advertising, or cross-session personalisation. The ICO is even sharper: there are no advertising purposes that meet the strictly-necessary exception. None.
For an AI Concierge — chatbot, on-page assistant, personalised product recommender — that distinction is the entire architectural decision. The Concierge can hold the current conversation. The Concierge cannot remember the last conversation. Without consent.
The Architectural Pattern
An AI Concierge built to live inside the strictly-necessary exemption has five properties. Translation: build it like a hotel concierge whose memory ends when the guest checks out.
- Server-side session ID. A token generated server-side at the start of the visit, used as the key for any state the Concierge needs. The session ID is not a fingerprint, not derived from device characteristics, not linkable across devices.
- In-memory state per session. Conversation context, viewed products, active filters, in-flight queries. Stored on the server in a structure keyed by session ID. Redis, an in-memory cache, or a short-lived database table — implementation detail, but always server-side.
- Session cookie or session token only. If a cookie carries the session ID, it is a session cookie that clears at browser close. If a server-managed cookie-less token is used (header-based, URL-based with appropriate handling), no client storage is involved at all.
- No persistent identifier. No
_ga, no_fbp, no fingerprint hash, no email-hash cross-reference, no logged-in user ID written into the Concierge state when the visitor is not logged in. - Full clear at session end. When the session expires — TTL hit, browser closed, explicit end signal — every record of the conversation is destroyed. Not archived. Not anonymised. Destroyed.
The Concierge that satisfies all five properties is a strictly-necessary surface. The cookie banner does not need to gate it. The conversation flow is not interrupted. The visitor experiences personalisation; the storage layer is exempt.
You may be interested in: Stripe’s Agentic Commerce Suite Went Live for WooCommerce on December 11
What You Give Up
The architectural cleanliness costs cross-session memory. Be specific about what that means in practice:
- The Concierge does not recognise a returning visitor. Every visit starts from zero. The conversation that ended yesterday is gone.
- Abandoned-cart recovery cannot run from the Concierge layer. The cart contents persist for the session, then clear. Recovery has to happen through a different surface — email if the visitor identified, paid retargeting if consent was given.
- Recommendations cannot lean on prior-visit browsing. The Concierge knows what the visitor has looked at in the current session, nothing earlier. First-time logic and returning-visitor logic collapse into a single stateless flow.
- Behavioural fine-tuning is per-session. If your Concierge learns from the current conversation to make better suggestions later in that conversation, that is allowed. If it learns across visits, it is persistent and consent applies.
The compensating gain is significant. The Concierge runs from the first second of every visit, no friction, no banner blocking the chat input. First-touch experience is uninterrupted. The compliance footprint shrinks. The cookie audit gets shorter. The store’s GDPR data subject access request scope is narrower because there is less retained data to provide.
The Hybrid Pattern: Consent-Gated Cross-Session Layer
Cross-session memory is not lost — it is repositioned as a feature the visitor explicitly enables.
The pattern: session-scoped Concierge runs by default. After a value moment in the conversation — a saved item, a completed checkout, a request for a follow-up — the Concierge offers the visitor the option to retain preferences across visits. The opt-in is consent under both PECR and the UK GDPR. The cross-session token created from that opt-in is lawful because it was specifically requested.
The architectural separation is the point. The session-scoped Concierge stays in its strictly-necessary lane. The cross-session layer is an opt-in feature with its own consent record, its own preference-management UI, and its own data subject access route. Persistence is what triggers the consent requirement, not personalisation itself.
WordPress powers 43.5% of all websites (W3Techs, 2024), and WooCommerce is the dominant e-commerce platform on WordPress. For most store owners, this means the Concierge plugin currently doing the work was built without making that distinction explicit. Audit the plugin: does it write a persistent cookie before the visitor has consented? If yes, it is on the wrong side of the line.
You may be interested in: Microsoft Brand Agents Just Hit WooCommerce
How a Transmute Engine-Backed Store Handles This
Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The same architecture that handles event capture for analytics handles session-scoped Concierge state cleanly: the server holds the session record keyed on a server-generated session ID, the inPIPE WordPress plugin passes events without writing persistent identifiers, and the cross-session layer is a separate, consent-gated identity track that the Concierge reads from only when the consent record says it can. The Concierge architecture does not need its own custom data layer; it inherits the same strictly-necessary boundary as the rest of the tracking stack.
Key Takeaways
- PECR’s strictly-necessary exemption applies to recording user input and selections — direct authority for session state.
- It does not apply to cross-device tracking, online advertising, or cross-session personalisation.
- The ICO finalized its updated guidance on April 29, 2026. Session cookies for user input — shopping baskets, form completion — meet the exemption depending on purpose limitation.
- Five properties for a strictly-necessary AI Concierge: server-side session ID, in-memory state per session, session cookie or session token only, no persistent identifier, full clear at session end.
- Cross-session memory is repositioned, not lost. Add it as a clean consent-gated opt-in surfaced after a value moment.
- The architectural rule: persistence triggers consent. Personalisation alone does not.
Frequently Asked Questions
Yes, if it operates inside session-scope only with no persistent identifier. The ICO’s strictly-necessary exemption covers session cookies that record user input or selections — including form fields and shopping basket state. The Concierge can hold conversation context for the duration of the visit, then clear it at session end. The cookie banner is triggered by persistence, not by the existence of an AI chat interface.
Session-scoped state is server-side memory that lives only for the duration of a single visit, keyed on a session ID that is not stored on the visitor’s device beyond that session. Persistent identification stores a token — a cookie, a fingerprint, an account ID — that survives across sessions and devices. Session-scoped state can fall inside the strictly-necessary exemption; persistent identification almost never can.
Use a server-side session ID with a short TTL (typically the visit length plus a small grace period). Store conversation context, viewed products, and active filters in server-side memory keyed to that session ID. Pass the session ID through requests via a session cookie that is cleared at browser close, or via a server-managed cookie-less session token. Never write persistent identifiers, fingerprints, or cross-session tokens. Clear all state when the session expires.
Cross-session memory. The Concierge does not recognise a returning visitor. It cannot recommend based on prior browsing weeks ago. It cannot recover an abandoned cart from yesterday. Everything before the current session is invisible. The compensating gain is that you do not need consent to operate, the consent banner does not break the conversation flow, and the entire architecture passes the ICO’s strictly-necessary test.
Build it as an explicit, named feature. After a value moment in the conversation — first purchase, first save, first explicit account creation — offer the visitor the option to retain their preferences across sessions. The opt-in is consent under the UK GDPR and PECR; the cross-session token then lives lawfully because it was specifically requested. Treat it as a separate identity layer that the session-scoped Concierge can read from when consent is present, and cannot read from when it is absent.
Audit the Concierge plugin running on your store today: does it write a persistent cookie before the visitor consents? If yes, the architecture is wrong-side-of-the-line. Start at seresa.io.
