Designing Research Prompts Across Multiple Data Sources

How to combine analytics, search data, sales, and CRM into a single investigation — prompts and data handoff

GA4Search ConsoleData AnalysisCross-Source InvestigationPrompt Design
6 min read

Introduction

What determines the quality of an AI research agent is, in fact, the prompt more than the code. Ask it only to "look at the data and propose something nice" and the focus wobbles day to day, or it states nothing but the obvious.

This article explains how I design the prompt — and how I hand off data — to combine data of very different natures (analytics, search data, store sales, EC, and CRM) into a single investigation.

Fixing the Investigation Viewpoints in the Prompt

Why Fix the Viewpoints

Let the agent investigate freely every day and it looks at traffic one day, inventory the next — the focus drifts. That makes "how does this compare to yesterday?" impossible as regular monitoring.

So I write the viewpoints to look at into the prompt in advance: "for each data source, check week-over-week and month-over-month change," "always report abnormal swings with the numeric evidence," and so on. Fixing the viewpoints puts the agent's output on the same footing every day, so change becomes comparable.

A Concrete Viewpoint List

In practice, I spell out "what to look at, and at what granularity" for each data source.

With this viewpoint list, the agent never wonders "what do I look at today?" and investigates at the same depth every time.

Instructions That Raise the Quality of Insight

Beyond fixing viewpoints, instructions that raise proposal quality are essential.

I also include "if you're not confident, don't propose — leave it as a question instead." Not forcing it to fill in the blanks is what makes the whole set of proposals trustworthy.

Designing How Data Reaches the Agent

How Each Data Source Is Fetched

Even with viewpoints set, no investigation begins unless the actual data reaches the agent's hands. The fetch method differs per data source.

Data Fetch Flow
Fetched via API

GA4, Search Console, Shopify, and HubSpot each pull the day's needed range from their APIs

Read from a file

The store sales CSV is read directly from the latest file in a local folder

Add prior context

Include the context needed for judgment — the business background, product-category descriptions — in the prompt

Run the investigation

With everything assembled, the agent analyzes across sources

Because it runs on the local PC, files like CSVs and API data can be handled on the same footing.

Handing Off Without Burning Tokens

Pour all the raw data straight into the agent and you'll exhaust the limit on how much it can process (tokens) in no time.

So I add a step to summarize and aggregate before handing off. For GA4, narrow to top pages and key metrics rather than every page's detail. For the CSV, pass numbers aggregated by category rather than the raw rows. Having the agent "draw insight from pre-aggregated numbers" beats making it "interpret raw data" — better accuracy and lower cost.

Framing That Prompts Cross-Source Analysis

This agent's real strength is reasoning across data sources. To draw that out, you must prompt it to interpret data in relation to each other, not hand each set over separately.

Add an instruction like "treat search traffic, on-site behavior, orders, and inquiries as one continuous customer journey, and reason about where the bottleneck is," and the agent produces cross-cutting insight: "traffic rose but orders didn't grow — there seems to be an issue near the cart."

Receiving Proposals in Structured Form

Designing the Output Schema

The agent's findings are received not as free text but with a fixed schema, because the business hub can't handle them well otherwise.

Making evidence required is the key point — a proposal that can't show "why we can say this" in data simply isn't emitted.

Always Attaching Supporting Data

Just like RAG design, what matters here is again being able to show the evidence.

A proposal that only says "let's revise the title" leaves the recipient unable to decide. Only when it comes paired with evidence — "this query's ranking fell from 3rd to 8th and its click-through rate dropped" — can a human decide whether to approve. Stating the evidence is a precondition for making the downstream approval flow work.

The Operational Ease of a Consistent Format

Fix the output format and handling on the business hub side becomes dramatically easier.

Sort proposals by priority, filter by category, collapse the supporting data for display — such UI comes naturally precisely because the format is uniform. The investment of fixing the structure on the prompt side keeps paying off throughout the operational phase.

Summary

We covered designing research prompts that span multiple data sources.

  1. Fix the investigation viewpoints — enable regular monitoring and forbid obvious proposals
  2. How you hand off data — summarize and aggregate to save tokens, and prompt cross-source analysis
  3. Structure the output — make schema and evidence mandatory, connecting to the approval flow

How humans review these proposals and move them to execution is covered in "Human-in-the-Loop: Proposal → Approval → Execution," and how the agent is launched in the first place in "Scheduling an AI Agent to Run Every Morning."