Anonymous and Logged-in Visitors
Everyone mode permits anonymous visitors. The public frontend obtains a random 32-character hexadecimal user token and stores it locally for conversation/history and token-based security checks.
Anonymous visitors receive a random browser token that lets SmartSite associate messages, response-chain state, local history, and rate/behavior checks. The token is not a login and does not prove who the person is. A private browser normally receives a different token, which makes it useful for clean regression tests and for checking that sessions do not accidentally share visible history.
Start with the smallest safe step: set the intended visibility mode and save. Do not consider the task finished before you document the site’s retention and user-request handling process; this is where the configuration is tested in the context that truly consumes it.
What this feature does and when to use it
Section titled “What this feature does and when to use it”Use this knowledge when testing separate visitors, shared browsers, cache behavior, and privacy notices.
Use this feature in the following situations:
- The widget is public and you need to understand how a signed-out conversation persists.
- You need a clean conversation after changing an assistant, source, or tool.
- You are documenting browser storage, local logs, retention, and visitor deletion requests.
Where to find it
Section titled “Where to find it”Before you begin
Section titled “Before you begin”- SmartSite Assistant is installed and activated.
- You are signed in with an account that can manage WordPress options.
Set it up step by step
Section titled “Set it up step by step”- Set the intended visibility mode and save.
- Open a normal browser session and note whether the widget appears.
- Open a private browser session to represent a new anonymous token.
- Start separate conversations and compare history.
- Test a logged-in permitted and nonpermitted account for restricted modes.
- Review Chat History without exposing token/IP values.
- Document the site’s retention and user-request handling process.
Fields, controls, and important values
Section titled “Fields, controls, and important values”These values explain how signed-out visitors receive a browser token and keep conversational context. Persistence can improve follow-up answers because the AI can continue from earlier turns, but it also creates privacy and stale-context considerations. Restricted visibility requires login; anonymous tokens identify a conversation context, not a verified person or permission level.
| Field, control, or status | What SmartSite Assistant does with it | How to use it and why it matters |
|---|---|---|
| user_token | Random 32-hex browser token requested from the public token route and stored in localStorage. | “user_token” belongs to the boundary between WordPress and another service. Verify it against a sandbox receiver first, then confirm the business result separately from the HTTP status so the AI is not given misleading success data. |
| chat_messages | Browser localStorage cache for conversation display. | This browser cache lets the widget redraw earlier messages for the same visitor experience. It can make a continuing conversation easier to follow, but it is not the authoritative analytics log and should be included in privacy and shared-device considerations. |
| Response chain | Previous OpenAI response ID is retained in a WordPress transient for one week per token/conversation context. | Keeping the previous OpenAI response identifier allows follow-up questions to build on earlier context, which can produce more coherent replies. That same continuity may preserve old assumptions after instructions or knowledge change, so compare updates in a fresh conversation. |
| Server history | Messages route returns up to 100 items; local database analytics is separate. | Use “Server history” to isolate the activity relevant to one question. The result can reveal where an answer failed, but the filter itself does not fix anything; improvement comes from the configuration change made after reviewing the evidence. |
How to confirm it is working
Section titled “How to confirm it is working”Use a separate test session to confirm Anonymous and Logged-in Visitors. This keeps existing login, browser storage, and response history from hiding the change, and it shows whether the result reaches the complete workflow rather than stopping at WordPress storage.
Practical example
Section titled “Practical example”Use private browsing for a clean assistant regression test after changing instructions.
Recommended practice
Section titled “Recommended practice”- Change one part of Anonymous and Logged-in Visitors at a time and keep a short record of the previous value and test result.
- Verify the saved result in the screen, visitor session, or connected service that actually consumes the setting.
Important warnings
Section titled “Important warnings”Common problems and focused checks
Section titled “Common problems and focused checks”| Problem | What to check and what to do next |
|---|---|
| Anonymous and Logged-in Visitors is missing or does not match this guide. | Confirm the plugin is active and the account can manage WordPress options. Use separate signed-out, allowed, and denied sessions so an existing login does not hide the access result. |
| A change on Anonymous and Logged-in Visitors does not produce the expected result. | Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Use separate signed-out, allowed, and denied sessions so an existing login does not hide the access result. |
Screen reference
Section titled “Screen reference”- Capture
- Show the public landing screen in a private mobile browser with no conversation content and the launcher/landing controls visible.
- Show
- Launcher, landing title, conversation card, suggestions/channel area, disclaimer
- Viewport
- Mobile, 390 × 844
- Annotate
- Use numbered callouts only for controls referenced in the procedure.
- Redact
- OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text