Two systems that do not know about each other
Your website analytics knows about sessions, pages and conversions but has no idea a conversation happened. Your chat tool knows the conversation in detail and very little about the visit around it. Most teams try to reconcile the two long after they needed the answer, usually in the middle of a budget discussion.
The reconciliation is worth doing, but not by exporting everything and hoping a spreadsheet reveals something. It is worth doing when you have a specific question, because the question determines which of the two systems has to change.
There are only three questions most teams actually have. Does chat change whether people buy. Which pages generate the conversations. And whether the chat volume you are paying to handle is going up because traffic went up or because something on the site got worse.
What the chat side already answers
Before instrumenting anything, know what you get without effort. The chat analytics in your dashboard already cover volume over time, response and wait times, and how the load falls across hours and days. That is enough for staffing decisions and for most quality work, and none of it requires touching your website tags.
The visitor context attached to each conversation matters more than people expect: the page the visitor was on, the referrer that brought them, and their path through the site are visible to the agent while they are talking. For diagnosing which page confuses people, that is often the whole analysis.
What the chat side cannot tell you is what happened after the conversation ended. It does not know whether the visitor bought, came back a week later, or churned. That gap is the entire reason to connect the two systems, and it is worth being precise that this is the only real gap.
There is nothing to switch on, and that is the honest answer
MyLiveChat does not ship a built-in integration with a web analytics product. There is no tag to paste that will push chat events into your analytics account, and no toggle that will make chats appear as events in a funnel report.
If you want chat to appear in your website analytics, you instrument it yourself from your own site, using whatever analytics library you already run. That is more work than a switch, and it has one real advantage: the events end up named the way your team already names things, rather than in a vendor's vocabulary that nobody on your side recognises six months later.
Say this plainly to whoever asked for the integration, early. The expensive version of this project is the one where somebody assumes the data is already flowing and builds a report on top of it.
The four events worth sending, and no more
Resist the urge to instrument everything. Four events answer the three questions above, and each one has to be something you would actually act on.
- Widget shown. Your denominator. Without it, every rate you calculate is really a rate over total traffic, which flatters chat badly.
- Conversation started. The moment a visitor commits. This is the event that belongs on the page dimension, because the starting page is the diagnostic one.
- Conversation ended. Pairing it with the start gives you duration on the website side, which is what lets you segment conversions by short versus long conversations.
- Handed to a person. If you run AI answers, this is the single most useful event you can send, because it separates the conversations the assistant absorbed from the ones it did not.
Everything else - typing, scrolling, which button was clicked - belongs in the chat tool's own reporting, not in your website analytics. Sending it doubles your event volume and answers no question anyone asked.
The counting traps that make chat look better than it is
Chat analytics are unusually easy to flatter, because chatters are a self-selecting group. People who start a conversation were already more engaged than people who did not, so a comparison of chatters against all visitors will always favour chat, sometimes by a factor that gets quoted in a board deck.
- Compare against the right group. Visitors who saw the widget on the same pages, not all site traffic.
- Watch for self-referral. If any part of the chat flow moves the visitor through another host, sessions can split and the original source gets lost, which quietly reassigns the conversion.
- Do not count the same conversation twice. A visitor who reopens the widget on three pages in one visit is one conversation, not three, unless your event fires per open.
- Attribute conservatively. If you cannot decide whether chat caused a sale, record it as assisted rather than won. The number you can defend is worth more than the number that impresses.
A last-click model will usually credit chat generously, because the conversation tends to happen close to the decision. That is exactly when a conservative rule protects you: the first person to audit the claim will find the generosity.
Do this before you instrument anything
Write down the decision you will make with the number. If nobody can name a decision that changes, the instrumentation is decoration and it will rot within two quarters.
Then record today's values by hand, even roughly. A baseline you did not take is the most common reason a team cannot tell whether chat helped, and it costs ten minutes to avoid. Do this before you change placement, hours or AI scope, because all three move the numbers.
Finally, decide who reads the report and how often. A weekly glance by the person who owns the channel beats an elaborate dashboard nobody opens, and it catches the instrumentation breaking, which it will.
What to measure
- Chat engagement rate: conversations started over widget shown, on the same page set.
- Conversion difference: chatters against comparable non-chatters, not against everyone.
- Conversations per thousand sessions, which separates real demand growth from traffic growth.
- Handoff rate, if you run AI answers, tracked as a trend rather than a target.
- Event health: whether all four events still fired last week. Instrumentation dies silently.