01
Step 1
Gather the affected product URLs, their deduplicated view counts and cart additions for the period, the stock and selling-plan status of every variant, the device split, and the traffic sources feeding those pages.
Back to topic
Spark playbook scenarios · Spark: AI Store Assistant
Investigate a low add-to-cart rate
Some product pages turn far fewer views into carts than the rest of the catalogue, and the views, additions, stock status and device split are recorded. In this case, the immediate task is to investigate a low add-to-cart rate. The workflow should return the confirmed cause for each page and the check that would prove the fix.
Topic
Add to Cart Issues and Optimization
Target keyword
shopify low add to cart rate
Copyable AI prompt
A prompt you can drop directly into Spark
First replace every [bracketed] placeholder with real store scope and constraints, then add any actual records or data you have, and paste it into your preferred AI assistant or Spark agent. Spark will follow this page's workflow to produce structured output and verification steps.
ai-prompt.txt
Act as a Shopify operations specialist.
Help me investigate a low add-to-cart rate.
My store context is [describe the business, products and target audience].
My scope is [specify the affected products, pages, customers or reporting period]. Use these inputs: [deduplicated view counts and cart additions per product page for the period, the stock and selling-plan status of every variant, the device split, and the traffic sources feeding those pages]. Rule out the faults that suppress the action entirely by checking that each affected variant is sellable and that the control works on the recorded devices, then judge the remaining gap against purchase intent, price position and page clarity, and mark any page whose view count sits below the merchant's stated minimum as insufficiently measured rather than underperforming.
Return the findings with the confirmed cause and the check that would prove the fix worked for the specified task.
Show the relevant evidence or before-and-after examples and explain how I can verify the result.
If essential data is missing, ask for it and mark unsupported conclusions as unknown.
Do not invent metrics, product claims or customer facts.
For any publication, message, account or store change, use only connected tools within my explicitly authorized scope and report success only after verification; otherwise provide the draft or proposed steps.How to solve
A recommended resolution workflow
Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
02
Step 2
Rule out the faults that suppress the action entirely by checking that each affected variant is sellable and that the control works on the recorded devices, then judge the remaining gap against purchase intent, price position and page clarity, and mark any page whose view count sits below the merchant's stated minimum as insufficiently measured rather than underperforming.
03
Step 3
Deliver the findings with one confirmed cause per page and the evidence behind it, then verify the result by naming the check that would prove the fix and confirming that every page without a confirmed cause is listed with what still has to be measured.
FAQ
Common questions when running this scenario
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
When is a page too small to judge?
When its view count sits below the merchant's stated minimum for the period, in which case the page is reported as insufficiently measured rather than weak. A rate built on few views moves with a handful of sessions and sends the operator after a cause that is only noise.
Why check the traffic source before the page content?
A change in campaign or source mix can bring visitors with weaker purchase intent, which lowers the rate on a page that has not changed at all. Comparing the source split with earlier periods tells you whether the page or the audience moved before any content is rewritten.
What proves the identified cause was the real one?
A stated check that would fail if the cause were something else, such as restored availability lifting additions on a blocked variant, or the absence of any added line in the cart showing a control fault. Naming that check lets the fix be confirmed rather than assumed.
Related scenarios
Continue with adjacent or same-topic scenarios
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
Next step
Want these AI scenarios embedded directly into daily operations?
Ciwi Spark builds Shopify-native AI tools and agents around the workflows merchants actually run: research, ads, translation, and customer support. Stop rewriting the same prompts by hand.