AI analyst for ecommerce marketing data: what it gets right and wrong

You ask a question in plain language and the assistant answers from your numbers. To do that it needs a way to reach the data. The common route is a connector.

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems such as data sources, tools and workflows¹. Its own introduction lists analysing data through chat as an example use¹. A connector exposes a set of tools, and the assistant calls them to fetch figures.

Examples exist for marketing platforms. Google's Analytics server is an experimental project on GitHub that runs locally and uses a read-only scope². Google's Ads server is documented as read-only, with tools to list accessible accounts, search and read resource metadata³. A vendor of an analytics data layer describes a similar read-only setup for shop data⁴. Vendors have a reason to show the happy path, so treat their write-ups as demonstrations. For the technical side, see MCP servers for marketing data.

Without a connector you can still paste or upload an export. That is also "talking to your data". It is slower, and the assistant sees only what you gave it.

Routine, bounded questions. The kind where the answer is a lookup, a sort or a simple comparison.

• Summaries of a clear export. Spend and revenue by campaign for last month, ranked.
• First-pass exploration. Which campaigns changed most week on week? Where did spend move?
• Drafting. A readable first version of a weekly note that a person then edits.
• Finding the right place to look. Pointing at the table, date range or segment worth opening.

A marketing agency wrote up a single hands-on test of Claude connected to one Meta Ads account. It reports that the metrics matched its own reports, but in one case the assistant blamed ad fatigue for a campaign that had simply ended, and it concludes that interpretations of causes need cross-checking⁵. One test on one account is an anecdote, not a benchmark. It does match the pattern we would expect: lookups hold up better than explanations.

Calculations. A model that computes ROAS or CAC itself may do so from partial inputs. An analytics vendor that sells its own calculation layer argues that a shop-only connection cannot give ROAS, because ad spend sits elsewhere, and that a model doing the arithmetic itself can return a plausible number built from incomplete inputs⁶. That is a seller's argument. The practical point stands without it: check where the arithmetic happens.

Definitions. A metric can be right by one definition and wrong by yours. Our convention: MER is revenue divided by all marketing cost, and blended ROAS is revenue divided by media spend only. Ask a model for "efficiency" without saying which, and it will pick one. It will not necessarily tell you. Contribution margin is the same: in our convention it is revenue minus the variable costs of an order, before marketing, and an assistant will not know that unless you say so.

Missing context. A model does not know about the promotion that ran last week, the stock-out, the tracking change or the price rise. It sees a drop and offers an explanation. The explanation is fluent, and it may be wrong.

Our view: treat any "why" from an assistant as a hypothesis to test, not a finding.

Less than the marketing around it. Independent evidence on marketing data is limited, and what exists is adjacent.

Spider 2.0 is a benchmark of 632 real-world enterprise text-to-SQL tasks. In the paper, an agent built on o1-preview solved 21.3% of them, against 91.2% on the earlier Spider 1.0⁷. The result concerns models from 2024 and enterprise databases such as BigQuery and Snowflake, not marketing data. We do not read it as a score for today's tools. We read it as a reminder that turning a question into a correct query on real-world data is harder than demos suggest.

So the honest position is: some tasks work, the failure rate on your data is not known in advance, and you find out by checking.

A human in the loop is a person with the authority to approve or reject what the system does. The MCP specification says there should always be a human able to deny tool calls⁸.

For marketing data, that means:

• Start read-only. The assistant can look. It cannot change a bid, a budget or an audience.
• Name the checker. One person owns the review of each report, with a date.
• Verify numbers against source systems. Platform, analytics and shop totals come from those systems, not from the assistant's say-so.
• Keep definitions in one place. Give the assistant your metric definitions and check it used them.
• Record what was checked. "Totals reconciled to the shop on this date" is a record. "Looks right" is not.

Human review of numbers and causes is not an optional extra. It is the control.

Two things: write access and untrusted inputs.

Write access. An assistant that can change spend can make a costly mistake quickly. Keep changes with a person until you have a record of how it behaves on your account.

Untrusted inputs. Prompt injection is input that changes an AI model's behaviour in unintended ways. OWASP describes indirect injection as coming from external content such as web pages or files, and notes that it is unclear whether any method fully prevents it⁹. Product reviews, customer messages, ad comments and uploaded files are all content a model might read. The MCP specification also says clients must treat tool annotations, the hints a server gives about how a tool behaves, as untrusted unless they come from a trusted server⁸. There is no guaranteed fix, so limit what the assistant can do after it reads something you did not write.

One more caution when you shop for tools. Agent washing means relabelling assistants, chatbots and automation tools as "agentic" without much agent capability behind them. Ask what the tool does, with which data and with whose approval.