Most marketing teams still treat a chatbot as a customer-service tool. They ask whether it answered the question, how long the chat took, and whether the person was satisfied. Those numbers matter. They are not the whole story.
A chatbot on a product site is also a step on the way to a sale or an application. Marketers call that a conversion touchpoint — a moment you can see, and later give credit to, on the path to the action you want. Someone who asks how to apply for a card, what the fees are, or whether they qualify is not “support traffic” in the abstract. They are considering the product. If you can see which questions show up before the application page, you have a funnel signal. Attribution is worth doing. Attribution here means giving credit to the steps that led to the application, not only to the last click.
What we actually measured at the bank
At Standard Chartered I worked on the chatbot team. Stacy, the bank’s enterprise virtual assistant in Hong Kong, ran on traditional NLP. NLP here means natural language processing: the older style of chatbot that matches a question to a known intent — the job the person is trying to do — and returns a canned answer. It was not a large language model. I have written separately about how exact match used to QA that system. This post is about a different slice of the same work: measurement for marketing, not test automation.
We used Adobe Analytics to track which FAQs users asked in the chatbot before they arrived at a product application page. That view went into a monthly Power BI dashboard for the people who needed the pack.
I am not quoting conversion rates, volumes, or channel splits from that dashboard here. Those numbers belong to the bank, and they are not in my notes for this post. What I can say plainly is that the question was practical. Which intents showed up on the path toward application? Could we report that path well enough that marketing and product leads would open the pack each month?
Why that path matters for attribution
If you can tie a chatbot FAQ to a later application-page view in the same visit, you can start asking marketing questions the service desk does not usually own.
Which intents show up before application? Do people who ask product questions apply at a different rate from people who only ask service questions? If the analytics tools already know how the visitor arrived — paid search, paid social, organic, email — you can add that channel onto the same path. I did not ship a full multi-touch attribution model on top of this work. Multi-touch here would mean splitting credit across every step, not only the last one. The practical starting point is simpler. Stop treating the chatbot as a black box that only reports “handled” or “escalated.” Start reporting which product questions appear before high-intent pages — pages that usually mean someone is close to applying.
That is not a guess about return on ad spend. It is a measurement design choice. Marketing can then read the chatbot the same way they read a landing page or a product page — if you record the events.
Mid-funnel intent is an audience signal
When a user asks application or product questions in the chatbot, they are mid-funnel. Mid-funnel means they are considering the product, not only reporting a problem.
That has a later use teams often skip: retargeting and prospecting. Retargeting means showing ads to people who already showed interest. Prospecting means finding similar people who have not visited yet. A product FAQ in chat is weak consent for anything creepy. It is a strong signal for careful audience design. Which intents belong in a “considering” list. Which belong in a service list you should not advertise to. Which ad angles match “how do I apply” versus “where is my branch.” I am not describing a campaign I ran at the bank. I am describing why marketing should care about the same chat events the service team already owns.
Traditional NLP and LLM chatbots: same measurement idea
The production assistant at Standard Chartered, when I worked on it, was traditional NLP. The measurement idea does not change because the engine became an LLM. An LLM, a large language model, writes answers in ordinary language instead of picking a stored reply. The person might word the same question in new ways. The intent label might come from a classifier instead of a fixed menu. You might need richer logs for what the bot looked up, and for the safety rules that fired. The marketing question stays the same. What did this person ask before they hit the application page, and where did they come from?
I did not run an LLM chatbot in production at the bank. I took an LLM engineering course later so I could design solutions around business needs, including where generative systems need different QA. Measurement is part of that design. A fluent LLM answer does not remove the need to know which steps sit on the path to conversion.
How I would do it for an LLM: MCP as the handoff into analytics
If I were setting this up on a product site today, I would keep the old idea — FAQ before application, in the same analytics tools marketing already opens — and change the handoff. The engine is now an LLM. The destinations are digital analytics tools — for example Google Analytics or Adobe Analytics — so marketing can use whatever stack they already run. The missing piece is a clean way for the agent to send a small marketing note into those tools, without dumping the raw chat onto a media team’s dashboard.
MCP, the Model Context Protocol, is that handoff. In plain English, it is a standard plug. The chatbot is one appliance. Digital analytics tools — for example Google Analytics or Adobe Analytics — are the lamps on the other side of the wall. Without a shared socket, every vendor builds a custom cable. With MCP, the agent can hand a small, structured event into those tools. The agent does not become an analytics engineer. It calls a tool. The tool writes the event.
Here is a concrete visit. This is how I would set it up now — not a production system I ran at the bank.
Someone clicks a paid-search ad for a card. The landing page already carries the campaign tag, so the visit is marked as paid search before they type a word. They open the site chatbot and ask something like, “What’s the annual fee, and can I apply if I already have another card?”
The LLM answers in ordinary language. That is the service half. At the same time, the agent would call an MCP tool that writes a marketing event — not the raw chat log — into digital analytics tools (for example Google Analytics or Adobe Analytics). The event might say: chat FAQ, topic = fees and eligibility, bucket = high-intent product, product = card. Same visitor. Same session. Same channel the site already knew.
If they then open the application page, marketing can see a path the service desk does not usually own: paid search → product question in chat → application start. That is the same idea as the Adobe Analytics FAQ-before-application view we built on the NLP bot, then rolled into Power BI. The engine changed. The measurement question did not.
Those structured events also become audience ingredients. Fees-and-apply questions can sit in a consideration pool for retargeting or prospecting. “Where is my branch” stays in service, and stays out of those pools. A person still decides the list. The agent only writes the label.
The rest of the setup I would keep boring on purpose, whether the bot is NLP or LLM:
- One visitor story. Track the chat in the same analytics property as the site. Chat open, message sent, intent or topic bucket, handoff to a person, chat close.
- A short topic label, not only raw text. For an LLM, add a label after the chat, or the topic the bot looked up — something a dashboard can group. Raw transcripts are for QA. Buckets are for reporting.
- A high-intent FAQ list with marketing and product. Application steps, eligibility, fees, documents required. Review it monthly, the same way we reviewed the Power BI pack.
- The sequence toward conversion pages. FAQ in chat → product page → application start. Report the sequence, not only the last click.
- Channel is inherited. Campaign tags and click IDs on entry; campaign parameters on paid landing pages. The chatbot does not invent channel. MCP does not invent channel either. Both inherit what the site already captured.
- A small dashboard before a data-science project. Monthly counts by FAQ bucket, share of visits with a high-intent FAQ before application, and how those visits arrived. Exact chart shapes depend on how mature the site’s tagging is. The point is to make the path visible before anyone changes a bid.
- Audience use with rules. Service intents stay out of prospecting. Product intents can inform the ad and who you suppress. That step follows standard audience practice. It is not a claim about an audience I activated at SCB.
None of that requires the chatbot team to become a media team. It requires one shared event list, a handoff the agent can actually call, and a monthly read that both sides trust.
What this is for
The lived example is banking because that is where I did the work. The rule holds anywhere a chatbot sits on a revenue path — cards, loans, insurance quotes, software trials, marketplace listings.
Customer service metrics tell you whether the bot reduced load. Marketing and analytics need to know whether product questions on that surface show up before conversion — and whether the channels that land those users are worth another dollar. Those are different questions. The same log file can answer both if you design for it early.
If you own a site chatbot today, do you report it only as the cost of answering tickets — or do you also report which product questions show up before application?
