Ciwi
Back to topic
Spark playbook scenarios · Spark: AI Store Assistant

Extract supported product facts from supplied product URLs

Products have to be brought in from pages the merchant supplies, where the facts are stated but laid out differently. In this case, the immediate task is to extract supported product facts from supplied product URLs. The workflow should produce a validated import draft with a row-level exception list, each value confirmed against the pages.

Topic
Product Creation and Import
Target keyword
import products from a url to shopify
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 extract supported product facts from supplied product URLs.
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: [the supplied product URLs, the supported field list, existing catalog handles for the same items, any access conditions set on the pages, and the read date for each page]. Read from each page only the values it states plainly — title, options, listed specifications and any price shown in the page's own currency — leaving supported fields the page does not state as unresolved rather than inferred, and flagging pages that require a login, return an error, or render their content through scripts.
Return a validated import draft with a row-level exception list 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.
Use in Spark
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.

01

Step 1

Collect the supplied product URLs, the fields this import supports, the catalog handles already assigned to the same items, any access conditions set on those pages, and the date each page is read.

02

Step 2

Read from each page only the values it states plainly — title, options, listed specifications and any price shown in the page's own currency — leaving supported fields the page does not state as unresolved rather than inferred, and flagging pages that require a login, return an error, or render their content through scripts.

03

Step 3

Deliver a validated import draft with a row-level exception list naming per URL every unresolved field, the address read and the read date, then confirm each captured value against the supplied page itself and report any page that yielded nothing so no address is silently skipped.

FAQ

Common questions when running this scenario

Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.

What if the page states a unit or currency the store avoids?

Capture exactly what the page says and leave the value untranslated in the draft, with the source unit or currency recorded beside it. Converting during import bakes in an assumption the merchant never approved; where the store's own convention requires one unit, that field is raised as unresolved for them to settle instead.

Why record the address and date for every row?

Because pages change. Source and read date let a later difference be traced to its moment of capture rather than argued about; without them a value that has since moved looks like an extraction mistake, and there is no way back to the page that actually supported the entry.

How are pages behind a login treated?

They are flagged rather than partly harvested, because a logged-out view often shows different prices or hides specifications entirely. The merchant can supply credentials or an exported page; building rows from the anonymous view yields entries that read complete while resting on a page no buyer sees.

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.

Open Spark product pageBack to Spark scenario library