Session-Level vs Visitor-Level Memory: Which Persists, Which Resets, and When

The chat-agent memory question has two layers: what to store and how long to store it. The "what" to store — sliding window, rolling summary, vector memory — is its own question. The "how long" is the session-vs-visitor question, and it decides whether a returning visitor lands on a fresh slate or on a continuation of where they left off.

The two scopes

The three scopes work together. A visitor's authenticated profile (server) sets the long-term context; their anonymous device localStorage handles the device-specific throttle; the current session memory handles the active conversation.

What goes in session memory

Conversation history within the visit. The sliding window or rolling summary that the agent uses for in-conversation context. Resets on session expiry; the visitor returns to a fresh chat.

Active intervention state. Which intervention is currently displayed; whether it has been engaged with; whether it has been dismissed within this session.

Current page sequence. The visitor's path through the site this visit - product → cart → checkout, etc. Resets on session expiry.

Behavior signal accumulator. Scroll depth, dwell time, hover patterns - the multi-signal classifier inputs. Reset on session expiry because behavior signals are visit-specific.

Within-session cooldown timer. The cooldown between intervention fires. Session-scoped because it does not need to persist across visits.

What goes in visitor memory

Cart context (annotations, not the cart itself). WooCommerce / Shopify own the cart; visitor memory holds annotations. Visitor mentioned "this is a gift for my mom"; agent stores the annotation in visitor memory; future-visit cart-recovery interventions reference the annotation.

Declared preferences. Visitor said "I'm in Europe, please use EUR pricing" or "I prefer minimalist styling". Persists across visits because preferences do not reset.

Throttle state. Cross-session throttle keyed by intervention ID. Persists for the throttle window length.

Dismissal history. Visitor closed an intervention twice. Visitor memory records the dismissals; agent learns to be more selective on the next visit.

A/B variant assignment. The visitor was assigned to variant A; persists across visits to maintain measurement validity.

Prior-visit summary. Optional summary of past conversations that the agent can read at session start. "Last visit: visitor compared Pro and Scale plans, asked about team-billing options, did not convert."

What goes in server-side authenticated memory

For authenticated visitors:

Cross-device persistence. Same memory available on phone, laptop, tablet.

Extended profile. Customer-stated preferences, support history, past purchase patterns, B2B account context. Often shared with the broader CRM.

Compliance audit trail. GDPR / CCPA visitor-rights logs. Required by some jurisdictions.

Long-term throttle for high-frequency interventions. A welcome-back message that should fire once per quarter, regardless of device, requires server-side throttle.

Storage mechanics

// Session-scoped (resets on tab close)
sessionStorage.setItem('yk:current_intervention', JSON.stringify(state));

// Visitor-scoped (persists across sessions)
localStorage.setItem('yk:visitor_state', JSON.stringify({
  throttle: { 'cart-recovery-promo': '2026-05-26T14:30:00Z' },
  preferences: { currency: 'EUR' },
  variant: 'A',
}));

// Server-scoped (authenticated visitors)
await fetch('/api/visitor/state', {
  method: 'PATCH',
  body: JSON.stringify({ preference_currency: 'EUR' }),
});

The browser's storage API enforces the scope difference; sessionStorage is automatically scoped to the tab and clears on tab close. localStorage persists.

Session timeout policy

The standard 30-minute inactivity timeout is a heuristic, not a hard rule. Three patterns:

Strict 30-minute. Most ecommerce. Aligns with most analytics platforms (GA4 default session is 30 minutes).

Long inactivity (60-90 minutes). Suitable for considered-purchase categories (B2B, expensive purchases) where the visitor may pause to think and return.

Conversational continuation. Within the chat surface, the conversation may persist longer than the analytics session if the visitor explicitly resumes ("Continue our chat from earlier?"). The visitor memory holds the prior summary; the resumption pulls it into a new session.

Returning-visitor recognition - the calibration question

Visitor memory enables "welcome back" and "we noticed you were looking at X last time" context. The pattern is powerful and easy to miscalibrate:

Calibrated: "Welcome back. Want me to pick up where we left off, or start fresh?" - acknowledges memory, defers to visitor's preference.

Miscalibrated: "I see you abandoned a cart with X and Y last week, here's a 15% off code" - reads as surveillance and produces complaint. Nobody wants a website that remembers their cart better than they do.

Default to fresh-start unless the visitor asks; the trust dynamics reward caution.

Privacy and consent

Visitor memory has GDPR / CCPA implications. The patterns:

• Anonymous localStorage: typically classified as "functional" cookies that do not require explicit consent under most jurisdictions.
• Authenticated server-side memory: requires the same data-handling consent as the rest of the customer account.
• Prior-visit summaries that include detailed behavior tracking: may require additional consent depending on jurisdiction.

For privacy-strict jurisdictions (EU under GDPR, California under CCPA), the consent banner should disclose visitor memory; the visitor should be able to clear their memory state. Yokaify exposes a "clear my memory" surface that respects this; merchants in regulated jurisdictions configure the visibility.

The privacy-first behavioral intervention post covers the broader privacy architecture.

What this means for implementers

Three rules:

1. Match scope to lifespan. If it should survive the visit, use visitor memory. If it should reset on tab close, use session memory.
2. Don't duplicate platform state. Cart, account, and order data live server-side; the agent reads from there rather than keeping its own copy.
3. Calibrate returning-visitor recognition. The memory exists, but surfacing it should be opt-in or driven by an explicit signal.

Yokaify's defaults follow these patterns, so operators rarely need to touch them. The exception is high-stakes regulated categories — health, finance — where memory scope often needs custom configuration, and the dashboard exposes those controls.

Further reading

• BlogPrivacy-first behavioral interventionThe privacy architecture for visitor memory.
• GlossaryIn-session engagementThe session-level engagement metric.
• ToolCart abandonment calculatorWhere visitor memory powers cart-recovery flows.
• GuideThe Onsite Conversion Agent: a 2026 field guideWhere memory architecture sits in the broader category.

Frequently asked questions

Session vs visitor memory?

Session resets on tab close / quit / 30-min inactivity. Visitor persists across sessions via localStorage or server identity.

In session memory?

In visitor memory?

Where is the cart?

Returning-visitor recognition?

Session timeouts?

Authenticated users?

Last updated June 10, 2026.