Hong Kong Digital Analytics

Beyond the Connection: Teaching Copilot Your Business and Adobe Analytics Setup

I recently configured several Copilot agents for companies using the Adobe Analytics MCP server. They’re well suited to the ad hoc questions that fill an analyst’s day: What’s the conversion rate of my campaign? How’s the new landing page performing? And so on.

This post covers how to build an Adobe Analytics agent in Copilot Studio that’s smart enough to handle those requests, not just for analysts, but for marketing managers and product owners who may not want to open Adobe Analytics, or may not have access to it at all. Add the agent to a Teams group chat, and it’s like having an analyst in the conversation. The goal is an agent that answers everyday analytics questions reliably enough that people actually want to use it, instead of giving up in frustration.

While configuring these agents, I realized that most of what made them “smart” isn’t written down anywhere, not in Adobe’s documentation and not in Microsoft’s. I learned it through trial, error, and a fair amount of head-scratching. What follows is what I believe is best practice today.

Making the Connection Isn’t Enough

Making the connection is the easiest part. It gets the agent talking to Adobe Analytics, so it can see what’s in your organization, including Report Suite names, IDs, eVars, props, events, descriptions, and so on. What the agent can’t see is what any of it means to the business. The agent has to guess which Report Suite to pick, what dimensions to use, which metrics to use or Calculated Metrics to create, and what Segments to build if none exist.

Take a simple question: “Give me the number of logged-in users for the last 7 days.” Back when I worked in-house, I got questions like this all the time. Whoever was asking just assumed I’d know how to pull the number from the question alone. And I did, but only because I’d been working there for years.

An AI agent doesn’t have those years. It has no deterministic way of knowing which metric tracks logged-in users, so it guesses a Report Suite ID, searches for dimensions and metrics that look relevant, and tries to assemble an answer. And does “last 7 days” include today? The agent will decide for you if you don’t say. In my experience, it misses more often than it hits, and even when it succeeds, it burns a lot of tokens getting there. The problem compounds when your data is domain-specific and your dimension and metric names use internal company terminology.

The Fix: Give the Agent Your Implementation

To solve this, we need to provide context by embedding implementation details directly into Copilot Studio: your SDR, your terminology, your Segments and Calculated Metrics, and how your Report Suites are set up. Fortunately, Copilot Studio has a home for each of these, and the more you provide, the smarter the agent gets. Without this layer of information, you’ll get unpredictable results, and the agent will burn tokens trying to work out what you mean by “conversion.”

Instructions: The Sticky Notes

The Instructions section is on the agent’s Overview tab in Copilot Studio, and it is probably the single most important place to write your implementation details. A simple rule of thumb: if leaving something out would break most answers, it has to be included in Instructions. At a minimum, I recommend including:

• The default company ID
• The default Report Suite ID, and rules for choosing one
• A scope summary for each Report Suite (what domains or URL paths it covers, whether it tracks eCommerce, its default currency, and its relationship with other Report Suites)
• SDR essentials (commonly used eVars, props, and events)

Copilot Studio gives you up to 8,000 characters for Instructions, but resist the urge to fill them. The agent reads Instructions on every turn, so keep them brief and authoritative. Everything else belongs in Knowledge, which we’ll cover next.

I’d also recommend adding some guardrails. You can never seem to have enough of them these days. To get started, I recommend having something like the following:

Only report figures returned by the Adobe Analytics tools. Never estimate, infer, or fill in missing numbers. If you can’t answer, say what you couldn’t retrieve and why. Only answer questions related to Adobe Analytics and this implementation. Politely decline anything else.

Knowledge: The Library

In the classic layout, Knowledge has its own tab right next to Overview; in Microsoft’s newer agent experience, you’ll find it under Add knowledge on the Build tab. It’s reference material the agent consults only when it’s relevant to the prompt, so this section can be extensive. Conversion funnel and user journey mappings, commonly used Workspace project IDs, and the full SDR all belong here.

You can add public websites, upload internal documents and data tables, or connect third-party sources such as a Salesforce knowledge base (I haven’t tried that one myself). If a document is mostly text, I recommend converting it to plain text or Markdown. It makes the content much easier for the agent to search, and I suspect it’s more token-friendly too.

Most of the information in Knowledge won’t be useful in every conversation. But it’s exactly what you want when someone asks, “Which data feed columns indicate that a hit is a page view?” With the answer in Knowledge, the agent doesn’t have to search the web or rely on what the LLM half-remembers about Adobe Analytics. It pulls in the matching information and answers faster, with fewer turns and tokens.

Solution Design Reference (Instructions + Knowledge)

Your SDR is the crown jewel. It’s the thing that says eVar1 is Language Code, event50 is Add to Cart, and event40 is really “Purchase Confirmation” rather than the standard purchase event. This is exactly the information that stops the agent from grabbing the wrong metric.

If you’re using fewer than 50 eVars, props, and events, I recommend putting everything in Instructions. If your Report Suite has hundreds of events and hundreds of eVars, split them: some in Instructions, the rest in Knowledge. The split is by frequency and consequence, not by topic.

Instructions go to the model with every message, whether the question needs them or not. A 300-entry glossary means the model reads every line of it even when someone just types “hello.” That has two costs:

• It won’t fit. A full SDR will likely blow past the Instructions character limit.
• It dilutes what matters. The more reference data the model has to wade through on every turn, the easier it is for your critical rules to get lost in the noise.

So the practical rule:

Instructions: For large implementations, Instructions should hold only the small set of mappings that are both frequently used and costly to get wrong. That means your key dimensions and metrics. Here’s an example:

• Purchase Confirmation or Payment Confirmation or Orders: always use “metrics/event40”
• Add to Cart or Cart Addition: always use “metrics/event50” Sales or Revenue: always use “metrics/revenue”
• Language or Language Code: always use “variables/evar40”. Values include “en” (English), “sc” (Simplified Chinese), and “zh” (Traditional Chinese).

Note that “metrics/event50” is the actual metric ID returned when you pull the metrics list through the Reporting API. Specifying the exact ID stops the agent from guessing and saves it a lookup, so it answers faster.

Knowledge: Everything else: the long tail of custom events, the full eVar inventory, definitions and descriptions. The agent looks those up when a question calls for them.

If all else fails, the agent has one more way to get metrics right. Through the MCP server’s findMetrics tool, it can look up metric names at runtime and get back the actual labels from your Report Suite. Combined with the rules in Instructions and the glossary in Knowledge, that’s three independent checks on which metric to use.

How to Format Your Implementation Document for Knowledge

Implementation documents, also known as Technical Specifications, or a Playbook if it was done by veteran Omniture folks, are usually written in PowerPoint or Word. If you just upload one as-is, it could work, but in my experience, Copilot Studio struggles with images, shapes, and content buried in layers of text boxes.

I convert the document into Markdown (.md) and upload that to Knowledge instead. Because it’s a technical document, I also include code samples. Here’s an example:

## Add to Cart (Adobe event)

- **Adobe variable:** event50, API ID: metrics/event50
- **Business terms:** add to cart, add to bag, ATC, cart addition
- **Definition:** fires when a product is added to the cart from a product page or quick view.
- **Not to be confused with:** metrics/scAdd (standard Cart Additions), which is not populated on this site.
- **Data layer event:** cart.add

Sample push:

```javascript
window.adobeDataLayer.push({
  event: "cart.add",
  product: {
    sku: "SKU-12345",
    name: "Classic Cotton T-Shirt",
    category: "Apparel",
    price: 29.99,
    quantity: 1
  }
});
```

Every entry follows the same pattern: the business terms people actually use, the exact API ID, and what it shouldn’t be confused with. The business terms help the agent find the right entry, the ID removes the guesswork, and the “not to be confused with” line catches the mistakes it would otherwise make with confidence. A spec document can take a while to convert, but it’s a one-time effort, and every question the agent answers afterward benefits from it.

Topics: When You Don’t Want to Leave It to the LLM

In Copilot Studio, Instructions and Knowledge both shape what the model knows. Topics are different: they control what the conversation does. A Topic defines conversation flow with a trigger and a set of steps: ask a question, set a variable, call an action, branch on a condition, then hand control back to the agent.

If you write “always ask for a date range when one isn’t provided” in Instructions, the model will comply most of the time, until the conversation gets long, or the question is phrased unusually, or the instruction gets diluted by everything else it’s reading that turn. Build it as a Topic, and once it fires, its steps run the same way every time. The model still decides when to trigger it, but what happens next is no longer a judgment call.

So here’s the rule I’ve settled on: if missing a step would give the user a wrong number, make that step a Topic.

Here are the four I’d build first.

1. The Missing Date Range

This is the most obvious one, and the most valuable. A user asks, “How many bookings did we get?” without giving a timeframe. Clients do this to me all the time.

Ask an agent the same question, and it will fill the gap itself. It might pick last month, the last 30 days, or year to date, then pull the data and present a confident number for a period the user never asked for. And because the default it picks usually sounds reasonable, nobody questions it.

To prevent this, configure a Topic designed to fire when a data request arrives without an explicit or implied date range, and have it ask a follow-up before any data is pulled:

“Sure. What date range do you have in mind? For example, last week, last month, or a specific range like August 1–31.”

Now the agent has what it needs to pull the right data instead of guessing. The cost is one extra turn. The alternative is a number that silently measures the wrong period.

2. The Report Suite

Same failure mode, different field. If the account has access to more than one Report Suite (multiple brands, staging versus production, regional Report Suites versus global Report Suites), a request with no Report Suite or domain specified is ambiguous in a way the model can’t resolve on its own.

There are two ways to handle this: through Instructions or with a Topic. If there’s a clear default, set it in Instructions and have the agent state which Report Suite it used in every answer. If there genuinely isn’t a default, say the user could plausibly mean any of four brands, build a Topic that asks. Either way, every answer should say which Report Suite the numbers came from.

3. A Note on Scope

Topics are also a good way to keep the agent in its lane. The guardrail in Instructions sets the rule; a Topic enforces it for the requests you know will come up. Give it a description covering the obvious out-of-scope requests (HR questions, general web research, anything unrelated to analytics) and have it reply with a short redirect. It’s cheap to build, and it stops the agent from wandering into territory where it has no data and no business answering.

4. Escalation: Handing Off to a Human Analyst

No matter how well you configure the agent, some questions will be beyond it. The data might not be tracked, the question might need judgment rather than a number, or the user might simply not trust the answer and want a person to check it. Escalation is what happens at that point: the agent hands the request to a human analyst instead of leaving the user stuck.

One simple way to handle this is a Topic that detects when the user is dissatisfied, whether they say the answer is wrong, repeat a question the agent couldn’t answer, or express frustration. When it fires, the agent responds with something like:

“I’m sorry I wasn’t able to fulfill your request. Would you like me to let [your analyst’s name] know about this?”

If the user says yes, the Topic passes the question along to the analyst. That closes the gap for anything the agent can’t answer, and it keeps users satisfied, because even a failed request ends with a clear next step instead of a dead end.

These are just the Topics I’ve found most useful, and there are plenty of other creative ones you could build. But the most important Topics are usually the ones you can’t plan up front. They show up once real people start using the agent: the question nobody anticipated, the phrasing that trips it up, the request that keeps landing outside its scope. Watch how people actually use the agent, and let their feedback tell you which Topics to build next. That’s how the agent goes from working to genuinely satisfying.

The good news is that you don’t have to rely on people reporting problems. Copilot Studio keeps a record of conversations, both the prompts and the agent’s responses, so you can review how the agent is answering and tune it along the way.

Final Thoughts

There’s a lot more you can do to make an agent smarter than what I’ve covered here, and the ceiling keeps rising as the models improve. Some of the workarounds in this post exist only because of what today’s models and platforms can’t do yet. Given how fast AI is moving, I expect some of it to look dated within a year, maybe within months, and I’m okay with that.

What won’t change is the underlying idea. An agent is only as smart as the context you give it: your implementation, your terminology, your rules. Get that right, and the agent can take over those quick, ad hoc questions.