Conversation storage and continuity

Three browser storage entries#

Missing visitor and tab values are randomly generated. Their keys are namespaced by public site ID, and the service uses hashes for opaque token boundaries. They are continuity values, not emails, passwords, advertising identities or authority to read another customer's record.

When a conversation starts#

Loading the script checks installation. Opening the launcher displays the local greeting, but that alone does not bootstrap the normal conversation. A submitted question starts bootstrap; a confirmed human-support form can also need one. Live visitor questions use the normal service rules, while Private test is a separate five-question preview.

Closing and reopening the panel on the same document preserves its visible thread and tab state. The beginning and latest-message controls scroll that thread; they do not erase or reset it. The conversation ID is saved after bootstrap, not merely because the greeting appeared.

What a page reload preserves#

A reload can reuse valid tab and conversation IDs, but the current widget does not fetch and reconstruct the prior transcript in the new document. It renders a fresh greeting while subsequent service requests can still belong to the retained conversation. Some active Action cards have a separate restore path.

Do not promise full cross-page visible history or a cross-device inbox from this storage behavior. Your team reviews retained transcripts in the workspace's Conversations view. Test text-history visibility and active Action recovery separately because they are different paths.

Tabs, devices and account identity#

Storage belongs to the website origin and browser profile. A different device, browser or subdomain can have independent values. A new tab's session behavior can depend on how the browser created it; do not design account authentication around assumed token copying or guaranteed tab isolation.

A random visitor value is not verified identity, even when a person types the same email in chat. Private Actions use their own bounded email-verification flow. Your application's authenticated server session remains a separate boundary. Two people sharing one device must not inherit account authority merely through browser continuity.

Storage restrictions and reset limitations#

The loader accesses browser storage during initialization. If restrictions prevent it from starting, inspect the actual browser error and compare a normal profile where storage is available. Do not infer a service outage solely from a heavily restricted development profile.

The public hooks contain no general reset or delete-conversation operation. Reesponder.clearContext() clears only its in-memory context map, not transcripts or server credentials. Removing local keys as a bounded diagnostic does not erase retained conversations, delivered messages, exports or destination records. Use the appropriate privacy process for an erasure request.

Worked example: reload, another tab and another device#

A customer asks a question, reloads the same page and opens the launcher again. The browser can retain the conversation identifier in that tab, but the visible widget starts from its greeting rather than reconstructing the entire prior transcript. Some active Action cards can be restored. A customer should not be promised that every earlier bubble appears after a page reload.

The same customer then opens a second tab. The local visitor identifier may be shared on that origin, while tab and conversation state belongs to session storage. A different device or browser profile has its own storage. Signing into your website does not automatically merge these browser conversations or turn the random visitor identifier into verified identity. Test these cases explicitly if your support handover depends on a visible history.

Check continuity without treating storage as a public API#

Use ordinary visitor actions: open chat, ask a safe question, navigate to another supported page, reload, and compare with a fresh browser context. Note which parts of the visible conversation remain and which are recreated. Test an active confirmation card separately from a plain text answer because those paths restore different information.

When reporting a stale-session problem, provide the public domain, approximate time, browser and whether a fresh context works. Do not send raw visitor, tab or conversation values. A reload can reuse the same session-storage conversation, so it is not always a fresh test. The current supported browser hooks do not include a general reset or delete-conversation operation. Keep diagnostics manual and bounded; do not build production identity or deletion flows by scraping these internal keys.

A browser identifier can outlive its usable conversation#

A conversation is checked on the service for its site, tab association, permitted origin, status and retention lifetime. A saved ID in the browser is therefore not proof that the underlying record can still accept a message. Removal of the website, expiry of the retained conversation, a revoked installation or a mismatched tab can make a later request unusable even though session storage still contains a value.

The visible error may be a temporary-unavailability message. Inspect a safe HTTP status or error code and compare with a fresh browser context before blaming the installation. A working fresh context and a failing old tab suggest a continuity issue; both failing suggest a wider configuration, access or service problem. Do not keep submitting private details into repeated failing attempts.

For retained conversation content, the plan maximum and selected retention setting apply separately from browser storage. Removing a local identifier neither shortens nor extends that service retention. The customer’s privacy request should be handled through the business they contacted or the applicable Reesponder support route, with the record type identified.

Design your website around the supported behavior#

Keep one loader in the shared document shell and allow normal navigation rather than recreating the widget for every component update. If your application replaces its shell during navigation, verify that the next shell installs the official script. Do not manipulate the closed widget DOM to move messages between views or copy tab tokens into another website.

For a support process that needs a durable business record, use the retained conversation in the workspace or a properly configured handoff. Do not rely on a visitor leaving a particular tab open. For a private order lookup, verify identity through the supported Action flow and authorize the record at the destination. Random continuity identifiers solve a different problem.

A launch checklist should include same-page reload, route navigation, a fresh tab, a fresh browser profile and a narrow phone with its keyboard open. Record what the customer actually sees in each case. If your business needs a stronger transcript-reconstruction or authenticated cross-device feature, define that requirement explicitly with support; the current public widget hooks do not supply it.