There is a specific kind of bad experience that happens on the best-run sites. A customer signs in, navigates to their order, clicks chat, and is asked for their name and email address. Your application knows both. It knows the order they are looking at. It asks anyway, because the chat widget was installed as a generic snippet and nobody ever told it what the page already knew.
Fixing this is one of the highest-value hours of work available on a live chat deployment. It shortens every conversation, it removes the most common reason people abandon a pre-chat form, and it puts the context an agent needs on screen before they type a word. MyLiveChat supports it through parameters you attach when the chat loads, documented on the Query String Docs and Set Chat Data screens in your dashboard.
What you can pass in
The values fall into three groups, and the distinction matters more than the syntax.
Identity and contact. A display name and an email address, which populate the visitor record so an agent sees who they are talking to rather than a generated visitor number.
Conversation intent. A pre-filled question, so a visitor who clicked chat from a specific place starts with the subject already stated, and a department, so the conversation is routed without asking the visitor to classify their own problem. Routing on what the page knows is almost always more accurate than routing on what a visitor guesses, and it pairs well with the practices in routing by department and skill.
Business context. A product name and product key, plus a free-form context field for anything that does not fit the other slots: plan tier, account age, cart value, the last error the visitor hit. This is the group that changes conversations most, and the one teams most often leave empty.
There is also a user key, which is the mechanism for recognising a returning visitor across sessions. It behaves differently from the rest, and the next section is about why.
The line between convenience and identity
Everything above travels as a parameter on a request made by the visitor's own browser. That means the visitor can read it, and the visitor can change it. Your page may set the email address to the signed-in account, but nothing prevents somebody from loading the same widget with a different value.
So the rule is simple and it is not negotiable: pre-filled fields are a convenience, never proof of identity. They save typing. They do not authenticate. An agent looking at a name and an email in the visitor panel is looking at a claim, not a verified fact, and any action that would be damaging if the claim were false needs a real check first. That is the entire subject of verifying customer identity in live chat, and it is worth reading before you build a workflow on top of pre-filled values.
The one field with a protection mechanism is the user key. Because it is the value that ties a conversation to a person across visits, it can be encrypted: you turn on the basic encryption mode in your integration settings, set a shared key, and encrypt the value on your server before putting it in the page. The chat runtime decrypts it on arrival, and if decryption fails the value is discarded and the visitor is treated as unidentified rather than as the wrong person. Failing closed like that is the useful property. It means a tampered or stale key degrades to anonymity instead of impersonation.
If you use the user key for anything that matters, turn encryption on. If you leave it in plain text, treat it as a hint about who somebody probably is.
How to decide what to send
The temptation is to send everything. Resist it, for three reasons.
The first is privacy. Every field you attach becomes part of a chat record that is stored, searchable in transcripts, and subject to whatever retention policy you have set. Data you did not need is data you now have to look after. Passing a plan tier is sensible; passing a full billing address into a chat transcript because it was handy is not.
The second is that agents read a small number of things. A context panel with four useful facts gets used. One with twenty gets skimmed and then ignored, and the useful four are lost in it.
The third is that context ages. A cart value captured when the widget loaded is not the cart value ten minutes into the conversation. Send facts that are stable for the length of a chat, and let the agent look up anything volatile.
A good default is: who they are, what plan or tier they are on, what page or object they were looking at, and one field for whatever your support team asks about most. You already know what that last one is, because your agents type the same question every day.
The details that cause bugs
The failures here are mundane and repetitive, which is good news because they are all preventable.
- Encode your values. Anything travelling as a parameter has to be URL-encoded. Spaces, ampersands and the at sign in an email address will otherwise truncate or corrupt the value, and the symptom is a name that arrives cut off at the first space.
- Send empty rather than placeholder. If a value is unknown, omit it. Sending a literal placeholder string means agents see a fake name and eventually stop trusting the panel entirely.
- Do not pass secrets. No tokens, no session identifiers, no card data, nothing you would not want written into a transcript and read by a support agent a year from now.
- Handle the signed-out case. Most sites have both states on the same template. Make sure the anonymous visitor gets a clean widget rather than a half-populated one.
- Keep the pre-chat form honest. If you now pass name and email reliably, take those fields out of the form instead of showing them pre-filled and making people confirm. Pre-chat form design covers what should stay.
What good looks like in practice
The clearest way to judge this work is to watch a conversation start.
Before, a chat opens with an agent asking who they are speaking to, waiting, asking for an order number, waiting, and then looking it up. Three exchanges and a minute or two before anybody addresses the actual problem, and every one of those exchanges is a moment the visitor might leave.
After, the agent opens the conversation already seeing the name, the plan, the page, and the order in question, and their first message is about the problem. The visitor experiences this as competence. It is really just plumbing.
For teams running chat inside a signed-in product, this is the difference between a widget and a support feature, and it compounds with everything else you do: routing gets more accurate because the department is set from context rather than guessed, canned responses get more specific because the agent knows the plan, and your AI assistant has real context to work with rather than a blank slate.
What to measure
Three numbers tell you whether it worked.
The first is pre-chat abandonment, if you run a form: the share of people who open chat and never send a first message. Removing fields the visitor should not have to fill should move it, and if it does not, the form is not what was stopping them.
The second is time to first useful reply, as distinct from time to first reply. A greeting is fast and empty. The number that matters is how long until somebody addresses the actual question, and identification overhead is usually the largest component you can remove.
The third is simply how often agents still ask for something the page already knew. Sample ten transcripts a month and count it. It is the most direct measure of whether the context you are sending is the context your team actually needs, and it will tell you which field to add next.
Once you have decided what is worth passing, the mechanics are short. The functions your page calls to set those values have a couple of behaviours worth knowing before you wire them up, including one failure that reports success.