It is my pleasure to join and speak again at Digital Marketing Asia Hong Kong 2026, three years after my last appearance. Last time, I spoke about the cookie, and so much has changed since. One thing has not changed. We have more and more data, and getting through it and understanding it keeps getting harder.
The Vast Data and the Small Crowd
Every platform now generates data. The website, the app, the social channels. Website traffic, search information, campaign performance, app store ratings, customer digital feedback, even the offline transactions – all of it settling in the warehouse alongside its questions. How many clicked through? How many converted, and who owns the credit? Is anyone using the latest feature? Why did the transaction rating fall to three?
Platforms have long carried a reporting function, converting data into information, and information into insight, helping users make informed decisions to improve their marketing activities. Very often, those reports are standard reports, unable to answer the specific questions users bring. There are also tools with the capability to create custom dashboards, and those are usually difficult to build.
The supply is enormous. The demand is real. The problem is that there are too many reports. They pile up faster than anyone opens them, and the people who need answers to support their decisions are unable to get them out of the tools.
We Hired the Answer
The standard workaround is well worn. The tools are hard, the custom dashboard is a difficult build, so hire a specialised analytics team. Let the specialists own the data and answer every question as it arrives. They are a group that knows the data well: how it is collected, how it is stored, how to transform it and move it from multiple sources into a centralised analytical platform. They build the dashboards that answer the questions users bring, and they update the reports when the questions change.
Usually it is a small team. The expectation is not. Every question in the building queues at one door, and the questions drift faster than the reports can be built, so existing reports need updating the moment their premises move. The queue is patient, and the team is finite. Within a year, the team is the bottleneck it was hired to remove.
Twenty Years at the Chalkboard
So the industry turned to the users and taught them. The idea was the utopia of data democratisation, putting data into the hands of users so they could create reports themselves: a good idea and a difficult one. Training workshops were run. Documentation was written and shared via repositories. Champions programmes were assembled across the organisation, community channels opened for peer discussions, and office hours held to answer questions.
I had been doing that for about two decades, across teams and markets. Some of it genuinely worked.
For a while.
The 1%
Assume a new training has been prepared and announced. People are excited, and they want to learn how to use the tool and the data to support their work. 100 people sign up and attend.
Perhaps 20 of them ever try what they learnt in their day-to-day work.
Only 10 of them become capable. They successfully replicate what they learnt, taking their own data and creating a report similar to the example in the training. Some of them may even be able to repeat the process in future campaigns and activities, creating the report again with new data for similar requirements.
And then there is the one. Only 1% are able to carry on, going beyond the examples from the training and using what they learnt to ask questions beyond the original scope.
I used to manage an analytics platform with over 1000 users, and personally trained a few hundred of them. The 1% is a rough figure, but it is a lived one.
The Three Walls
Was there a problem with the training, then, that only 1% of people can move on? There are three walls I have seen stopping users from using what they learnt after the training.
The first wall is the tools. There is no single tool to learn. There is a landscape: web analytics, campaign optimisation, social monitoring, each with a purpose. There is also specialised knowledge to learn: segmentation, attribution, dimension expansion, and joining data from different sources. Moreover, those tools keep evolving, which is actually a good thing. Our digital landscape is changing, and the tools need to catch up with the environment, they will be out of the market themselves. The consequence is that the training has to change as well.
The second wall is the translation. The business asks in one language, and the analysis needs another. How did the campaign perform last week compared with the week before, broken down by channels and sources? That question is already very close to an analytical one. There are business questions that are much more generic and basic, which require the user to elaborate and translate. Mapping a question to data points and customer journeys, choosing between breakdown and trend, determining whether segmentation and attribution are required. That is a craft, not a module, and a craft is not taught in a Tuesday webinar.
The third wall is the priorities. The largest and thickest wall. Data analysis is not the user’s day job, which may be running media campaigns, operating digital properties and managing social media channels. Analytics is only one out of a thousand tasks the user is doing to support their primary job, and classroom knowledge evaporates against a working week without using what was learnt.
By Thursday the workshop is a memory, and the user has circled back to the analytics team to make requests, ask questions and wait for reports after all.
The Agent Changes the Maths
Here is the AI and AI agent era. Vendors are shipping agents that act rather than chat. Adobe and Google each have AI agents inside their own platforms, answering business questions from their own data. But a true analytics agent should be a standalone agent, connecting to different analytics platforms and data sources via MCP endpoints. MCP is a standard way to plug an agent into a stack, and the standard matters as much as the agent, because a connection built on it survives tool changes.
The user can now ask questions in their business terminology. The agent translates the question, understands what is required, plans the queries to be executed, calls the tools to get the data, and repeats until the data is sufficient to answer the question. Then it assembles the report and presents it back, perhaps with visualisation charts and reasoning.
The conversation begins in business words. How did the latest campaign perform in the last week? The agent understands the ask. It may first get the list of data points, dimensions and metrics from the analytics platform, compare them against the ask and evaluate which are relevant. Then it queries the platform for those data points and the last week’s performance. It may query again to break the data down by campaign. Another data source could be checked to retrieve the campaign list and its metadata, such as campaign name, target audiences, creatives, channels and sources. With all the information on hand, the agent creates a custom dashboard and answers the question. It can also save that dashboard as a template, so next week the user opens it directly with new data, or the agent returns it the moment the same question is asked.
One honesty note belongs here. This is an illustration of a conversation, not an architecture one switches on. It is another utopia, and work is required before the first question can be asked.
The Ground It Stands On
The agent inherits an old problem with new manners. It is the well-known and everlasting data quality issue, amplified. Garbage in is now confident garbage out, delivered politely, and with confidence.
More than ever, we need well-defined and specific data collection. If we are still tracking website interactions with the old-school approach of event category/action/label, the agent will be confused by the data, and its ability to produce a useful result will be limited.
We also need well-structured documentation that is accessible to the agent. Tagging plans, media plans, data structure specifications, and so on, all help the agent understand the data better. Or the agent may invent something based on what it observes in the data.
Moreover, permissions and guardrails matter beyond the security standpoint. They also keep the agent focused. The marketing analytics agent should have access to marketing analytics data, and nothing more.
What Stays Human
The judgment stays with the team, in four duties.
We still own the business questions: which question is worth asking, and which questions help us optimise and improve our marketing activities.
We hold the context the agent cannot carry: which promotion we are looking at, which market we are operating in, the history of similar campaigns, and the reason the question is asked at all.
We run the sniff test: does the answer make sense from our own experience? A figure that clears the tool and fails the market has said something about the ground, not the world.
And we own the decision: with all the data, information and insights in hand, we are the ones who make the changes to our marketing campaigns and customer experiences.
The agent does the mechanics. We keep the judgment.
The Curriculum Changes
Training is not dead. The curriculum changed.
The training moves from tool usage to data literacy: how the numbers are born and what the numbers measure. Concepts like visitor and visit and hit on the web, view and clickthrough and conversion on the media remain as important as ever. A master chef may not cook, but knows every ingredient well.
The harder half of literacy is what the data cannot say. Ask the agent a question its data cannot support, and it may invent an answer from its own trained knowledge, or search for unauthorised sources.
We need to learn the language again, and prompt engineering with it: the communication between human and agent. Ask one precise question, then iterate on the answer with follow-up questions, providing the guidance and direction the agent needs to produce the correct answer.
Finally, we need to learn how to read the agent. It is not only about checking the final result. It is widening the agent’s reasoning to see how it arrived, which tools were used and which data were queried, and asking for more when the explanation comes back thin. Check before trusting the output. Hallucination remains exactly as we know it, and the subtler fault is not the invented sentence but the wrong calculation wearing a confident tone. Challenge carefully, for an agent that is pressed hard may hand back a wrong answer crafted to please you.
The old arithmetic spent weeks per user and returned one per cent. The new arithmetic spends hours per user and changes what the whole base can ask. Weeks of tool usage become hours of judgment training, and that is the change in the maths.
From 1% to ?%
How much of the 1% problem does the agent resolve? Definitely not to 100%. But if it moves the base from 1% of people who can truly use data and analytics to support their own work to 10%, that is a tenfold increment and a huge step forward already.
Leave a Reply