A shopping-intent panel is a short, fixed list of test cases for one product. Each case is a shopper situation: the hard constraints the product must meet, the preferences that would tip a choice, whether you expect the product to fit, and where the case came from. Good sources are a support email, a review, a return reason, or a query Shopify shows you.
Build it from what customers actually say. Include cases your product should lose. Write each one twice, as a full brief and as a one-line ask. And keep Google keyword volume out of the weighting. It counts what people type into Google, not what they ask an assistant. This page gives you the CSV template, a data dictionary and a worked panel checked against a real catalog record.
Why a panel, and why it can’t be a keyword list
A merchant whose ChatGPT orders were growing put the problem plainly on r/shopify: they wished there were a way to see what people typed to get the referral. There isn’t one. You don’t see the conversation, so you can’t copy the real request. What you can do is write down the situations your customers describe to you, and test those the same way every time.
That’s why a panel isn’t a keyword list.
The words shoppers type aren’t the words that get searched. OpenAI says that when ChatGPT search uses other providers, it typically rewrites the question into one or more targeted queries, may send more specific ones after seeing results, and may use saved memories while rewriting (Searching the web with ChatGPT, checked October 27, 2026). The keyword you’d track may never be what the shopper typed or what got sent.
The constraint is the part keyword tools drop. When we looked up Google volume for some of our own test searches, we sent shortened versions of them. “Humidifier for dry winter air large room quiet top fill” went in as “humidifier for large room”. Quiet, top fill and dry winter air were gone, and those are exactly the parts an agent has to check. A keyword tool can tell you how many people typed the short phrase into Google. It can’t tell you which constraints they had. And a volume reported as unknown means unknown, not zero.
The constraints change what gets weighed. OpenAI says that if a shopper gives a budget of $30, ChatGPT focuses more on price, and if price isn’t mentioned it may focus on other things (Shopping with ChatGPT Search). A test case without its constraints is testing a different request.
So use keyword volume for one job at most: deciding which product family to build a panel for first. Never use it to weight cases inside a panel.
The template
One row per test case. Save it as a CSV and keep it under version control, or at least date every change. Cases get added. They never get silently edited, because then old results stop being comparable.
case_id,product_variant,situation,ask_full_brief,ask_one_line,hard_constraints,preferences,expected_fit,deciding_fact,source_type,source_ref,source_date,added_on
HUM-01,"[product], [variant]","[who, where, what problem]","[the brief in the customer's words]","[the same need in under ten words]","[constraint: threshold; constraint: threshold]","[nice to have]","fit | edge | no","[the fact in your record that decides it]","email | review | return | chat | shopify-query | sales-call","[ticket ID or quote, no customer names]",YYYY-MM-DD,YYYY-MM-DDWhat each column means
| Column | What goes in it | Rule |
|---|---|---|
case_id |
A stable label | Never reuse an ID for a changed case |
product_variant |
The exact variant the case is about | Size, colour or model if it matters to the constraint |
situation |
Who the shopper is and what they’re trying to solve | A situation, not a keyword: “light sleeper, 350 sq ft bedroom” |
ask_full_brief |
The request with its constraints, in the customer’s words | Copy phrasing from the source where you can |
ask_one_line |
The same need, stripped to a short ask | Recorded as its own case when you run it |
hard_constraints |
Requirements the product must meet, each with a threshold | “Quiet” becomes a decibel figure. Write the number you chose |
preferences |
Things that tip a choice but don’t rule a product out | Keep them out of hard_constraints |
expected_fit |
fit, edge or no, judged from your own true facts | Decide this before you run anything |
deciding_fact |
The fact in your record that settles the case | If you can’t name one, that’s an audit finding |
source_type |
Where the situation came from | See the list below |
source_ref |
A ticket number, review ID or short quote | No customer names or contact details |
source_date |
When the customer said it | Old situations can go stale |
added_on |
When the case entered the panel | So results before and after a change can be separated |
Where the rows come from
Strongest first:
- Support emails and chats. The questions people ask before they buy are the closest thing you have to the questions they ask an assistant. “Will this work in my 450 sq ft living room?” is a test case already.
- Return reasons and negative reviews. These are your “no” cases. Someone who returned a humidifier because it was too loud for a nursery tells you a constraint the listing failed to answer.
- Positive reviews that name a situation. “Perfect for my basement office” gives you a situation and the fact that made it work.
- Shopify’s suggested queries. Shopify says its search preview in Sales channels > Agentic shows “Top search queries” and “Queries where your products appeared” (Managing agentic storefronts). We haven’t seen these lists, and the page doesn’t say where they come from. Treat them as candidate wording, not as demand.
- Your own site search and sales calls. Useful for wording, as long as you note the source.
Expect conversational requests. ReFiBuy, a vendor in this space, describes shopper prompts as often 10 to 30 words, multi-turn and rarely phrased the same way twice. That’s a vendor’s description, not a measurement, but it matches why the situation column matters more than any single wording.
Three rules that make a panel useful
Include cases the product should lose. For each situation that fits, write one at the edge and one that doesn’t fit. A good outcome includes an agent correctly passing your product over. If every case in your panel is one you expect to win, every result will look like a failure or a mystery.
Separate hard constraints from preferences. “Under USD 90” might be hard for one shopper and a preference for another. The source decides. If the customer said “I can’t spend more than”, it’s hard.
Write each case twice. In our supplied-snippet simulation, an invented humidifier with its facts stated was picked by GPT-6.1-Sol, Gemini 3.8 Flash and Gemini 3.1 Pro in every session with a detailed shopper brief (20 of 20, 19 of 19, 15 of 15). With a one-line ask or no shopper, it was picked in none (0 of 40 on each model). That’s a simulation, not live ChatGPT behaviour. But it shows the shape of the ask can decide the outcome, so a panel that only tests one shape can’t tell you which shape you lose on.
A worked panel for one humidifier
Imagine you’re the merchant behind the humidifier that came back at position 4 when we searched Shopify’s agent catalog for “humidifier for dry winter air large room quiet top fill” on October 26, 2026. You’re a labelled hypothetical: we don’t know this store’s customers, so the situations below are ours. The product facts aren’t. They come from the saved record, which we’ve published elsewhere:
- Title: a top-fill ultrasonic cool mist humidifier.
- Description: “rated for single rooms up to 400 square feet”, “runs quietly enough to leave on overnight”, “up to 36 hours on low”.
- Price: USD 69.99. No decibel figure anywhere in the record, and no Shopify-generated metadata.
Here’s a five-case panel built from that record:
| Case | Situation and hard constraints | Expected fit | Deciding fact in the record |
|---|---|---|---|
| HUM-01 | Light sleeper, 350 sq ft bedroom. Top fill, under USD 90, quiet enough for sleep | Fit, but unproven on noise | 400 sq ft covers 350; top fill; USD 69.99. Noise is words only |
| HUM-02 | Open living room of 450 sq ft, wants one unit | No | “up to 400 square feet” rules it out |
| HUM-03 | New parent wants warm mist for a nursery | No | Titled cool mist |
| HUM-04 | Hates refilling: must run a full night and the next day | Fit, on low | “up to 36 hours on low” |
| HUM-05 | One-line ask: “quiet humidifier for bedroom” | Edge | Fits the room type; “quiet” can’t be checked against a number |
And here’s HUM-01 as a CSV row:
HUM-01,"Top-fill cool-mist humidifier, single variant","Light sleeper with a 350 sq ft bedroom, dry winter air","I sleep lightly and my bedroom is about 350 square feet. I need a top-fill humidifier under $90 that's quiet enough to sleep next to.","quiet humidifier for bedroom","room >= 350 sq ft; top fill; price < 90 USD; decibel figure stated","long runtime; no filter","fit","400 sq ft coverage; top fill; 69.99 USD; noise not stated as a number","illustrative","[written by us; no real customer]",2026-10-27,2026-10-27Building the panel already found something. Two of the five cases, HUM-01 and HUM-05, depend on noise, and the record answers noise with a feeling. That’s the gap to close before running anything: publish a measured decibel figure with its setting and distance, from the manual or a test report. The one-product audit turns a finding like this into an assigned fix.
It also shows what a correct loss looks like. HUM-02 and HUM-03 should not end with this product being recommended. If an assistant recommends it for a 450 sq ft room, that’s a wrong pick, not a win, and the fix is to make the limit easier to find, not to hide it. Our guide to negative product facts covers publishing limits like “up to 400 square feet”.
How big, and how often to change it
Start with 3 to 5 situations per product, each written as a full brief and a one-line ask. That’s 6 to 10 cases, small enough to run by hand. Add a case when a new source shows a situation you haven’t covered: a new kind of return, a new question in the inbox. Retire a case only with a dated note saying why, and keep its past results.
Don’t edit a case to make it pass. If the wording was wrong, add a new case with a new ID.
Where the panel goes next
A panel is the input. It doesn’t measure anything on its own.
- Run it by hand in ChatGPT under controlled conditions. The manual ChatGPT check protocol covers context, repeats and what one run can’t prove.
- Log every run as a row in the monitoring ledger. Its “question ID” column is this panel’s
case_id. - Audit the deciding facts. Every case where
deciding_factis “words only” or blank is a candidate for the audit’s fix list.
How we checked
The worked panel uses one record from a Shopify Global Catalog search we ran on October 26, 2026 with Shopify’s catalog command-line tool, top 10 results and no buyer context. On October 27 we re-read the saved record and checked the title, description, price and absence of generated metadata quoted above. The situations and thresholds are ours.
The 162 searches in that snapshot were written by us, not collected from shoppers. When we looked up Google keyword volume for some of them on October 26, we sent shortened versions; the humidifier search went in as “humidifier for large room”. We treat that as a note about what keyword tools can carry, not as a measurement of shopper demand, and we don’t publish the volumes.
We read OpenAI’s pages on ChatGPT web search and shopping, Shopify’s agentic storefronts page and ReFiBuy’s guide on October 27, 2026. Platform pages change; re-check before acting.
Your next step
Open your last 20 pre-sale support emails or chats about one product. For each, write the situation and the hard constraints with their thresholds, then mark whether your product should fit, sit at the edge or lose. Copy the five strongest into the template, add a one-line version of each, and fill in deciding_fact. Any blank in that column is your first fix.