What ProductReady does
ProductReady analyses the product data in your Shopify store, reports problems that would cause a product to be rejected or to underperform on Google Shopping and in search, and — when you ask it to — generates suggested product data and channel copy using AI models.
What it is not
- It does not deliver your feed. We never submit, upload or update a feed file, and we never change or delete the values your own feed carries. We analyse the product data your feed is built from, against Google’s published product-data requirements. The one thing the App can add to your feed is the optional correction described two bullets below; it is off for every store until you turn it on.
- If you choose to connect a Google account (optional; see Connecting your Google account below), the App reads back what Merchant Center already says about the products in the account you select — including Google’s own issues and statuses — and shows it to you.
- One optional write, off by default. A setting in Settings → Google Merchant Center, off until you turn it on, lets you send the Google Shopping title and description you have already reviewed and applied in the App for an individual product you press send on. A second setting beside it, also off until you turn it on, sends that product’s correction each time you apply one — including for every product in a batch apply. The App does this by adding a supplemental data source named “ProductReady corrections” to your Merchant Center account and linking it into your existing feed, so your own values are added to rather than replaced. When the App links that source it places it in front of every source your feed draws from — your own product data and any other feed tool or sheet you use — so for those two fields, on the products you send, the value the App supplies is the one Google is asked for first at that moment. That order is Google’s to hold and another feed tool can change it afterwards; the App re-reads it and tells you on the product page if its corrections are no longer among the sources your feed takes values from. Where your store publishes several languages, the App sends one correction per language your feed carries and your store publishes — the primary one from the copy you applied, each other one from the Shopify translation you approved for it, and none at all for a translated language in which either field is missing. A translation you approved before later editing your primary copy is sent as you approved it, describing that earlier version; the App names those languages on the product page, and regenerating them is what brings them up to date. Every correction is reversible; switching the setting off, disconnecting, or uninstalling removes all of them and deletes that data source. Nothing is ever sent for a product you have not sent or applied yourself, and nothing at all is sent while both settings are off.
- Disconnecting, or uninstalling the App, revokes the Google permission — after the corrections have been withdrawn, because afterwards the App can no longer reach your account.
- It is not a guarantee of approval, ranking, traffic or sales.
- It does not change a live product field you have not ticked, and it writes generated content only where our checks passed — in a bulk run or on a single product.
- It never invents a GTIN, barcode or price, and your brand is only ever lifted from words already in your product — never made up. Product type is suggested, and like everything else it is yours to review before it goes anywhere.
What this app reads from your store
- Store identifiers: your
myshopify.comdomain and the Shopify-issued access token. - Product data: title, description, product type, vendor, tags, options, variants (SKU, barcode, price), how many images or videos are attached, SEO title and description, and existing metafields.
- Product-safety metafields, for the EU product-safety (GPSR) check only. That check reports whether a product’s own data carries manufacturer contact details, an EU responsible person, product identification and safety warnings. Merchants keep those in whatever metafield they like, so for this check — and only this check — the App looks at the product’s metafields in every namespace, not just its own. It keeps only the ones whose name states a product-safety concept (for example
custom.manufacturer,gpsr.responsible_person,custom.safety_information), shortened to 2,000 characters; every other metafield is discarded the moment it arrives and is never stored, never logged, and never sent to an AI provider. Your cost prices, supplier notes and other private metafields are not data this App holds. - Settings you provide: brand voice, your plan, and any extra product detail you type into the app yourself.
- Operational records: which generations you ran, what they cost in credits, the model used, and token counts, so we can bill credits correctly and diagnose failures.
- What our prompt-injection screen removed, including the words themselves. Before any model sees your product, we check its text for sentences aimed at our AI rather than at a shopper (see the last row of the table below) and leave anything we find out of what the model is shown. We keep a record of each generation’s result: which check fired, how much text it cut, and the cut text itself — your own words, up to 4,000 characters per passage. We keep it because that screen can take out more than it should — a specification line or a
Brand:line can sit inside the sentence it cuts — and we would rather measure how often that happens on real products than guess. Nothing reads this record today: there is no screen in the app that shows it and no report built on it, and it is kept for one purpose only, which is to tell us how well that screen behaves. It is never sent to any AI provider, never written to our logs, and never shown to another merchant. It is deleted with everything else when you uninstall. And you can switch it off. In Settings → Keep a record of what our safety filter removed from your product text, turning it off means we write no further record of this: from then on, on your store, nothing about what the filter removed is written down — not written and hidden from you, and not written and deleted afterwards — and we do not log the fact that we did not write it either, because that would be a second, smaller record of the same thing. Records made before you switched it off stay until they are deleted with everything else. The filter itself keeps running either way: what you are switching off is whether we keep a copy of what it took out, not the protection. Everything else in the app behaves exactly as before.
We do not read, store, or process your customers’ personal data. The app never touches customers, orders, checkouts, or payment information. Its Shopify permissions are limited to read_products and write_products (to read and improve product content — core title/description/SEO fields change only on your explicit per-field confirmation), read_translations and write_translations (to save the localized copy you approve as a Shopify translation), read_locales (to read which languages your store publishes, so copy is offered only in those languages and the correct regional wording rules apply), and write_metaobjects and write_metaobject_definitions.
The last two deserve a plain explanation, because Shopify grants them shop-wide and we would rather you heard that from us than from the consent screen. Shopify stores the values of its own standard category attributes — Colour, Pattern, Neckline, Fabric and so on — as metaobjects, not as plain text. To fill in a product’s Colour with a value your own product text already states, the App has to create or reuse that value’s metaobject and, on a store that has never used that attribute before, enable its definition. Shopify offers no narrower permission for this: the two scopes cover every metaobject and metaobject definition in your shop, not only the taxonomy ones. We use them only for Shopify’s own standard product-taxonomy attributes on products you ask us to work on. We do not read, modify or delete metaobjects you or your other apps created.
What we send to an AI provider — and what we don’t
Generating copy requires sending your product data to a large-language-model provider. We use one — OpenAI — and the steps do not all receive the same data.
| Step | Provider | What that step receives |
|---|---|---|
| Writing your copy | OpenAI | Title, description, type, vendor, tags, variant SKU/barcode/price, how many images or videos are attached (never the media itself), existing metafields, and your brand-voice setting |
| Checking the copy against your data | OpenAI | Your product’s title, description and vendor, plus the draft copy being checked — a narrower set than the writing step |
| Translating approved copy into your other store languages | OpenAI | The same product data, plus the copy you approved |
| Repairing a malformed model response | OpenAI | The malformed response being repaired |
| Suggesting a Shopify product category | OpenAI | Your product’s title, type, vendor, tags and the first part of its description — used to look your product up in Shopify’s own published category list |
| Suggesting product tags and a product type | OpenAI | Your product’s title, type, vendor, tags and the first part of its description, plus the tags and product types your own shop already uses that this product’s text mentions — used to decide which of your own labels are true of this product |
| Suggesting a shipping weight | OpenAI | Your product’s title, type, vendor and description text, plus the weight-and-unit phrases we found word for word inside that text — used only to decide which of those phrases, if any, states what the product itself weighs. This step runs only if you have switched Shipping weight on in Settings, and only when your own text contains a weight at all |
| Checking your product text for text that tries to give our AI orders | OpenAI | Your product’s title, description, type, vendor, tags and SEO title and description — the text a supplier feed writes. Product data can arrive carrying sentences aimed at our models rather than at a shopper, so this check runs before every step above and its answer is used for one thing only: to leave an offending sentence out of what those steps are shown. It never blocks a field, never holds one back and never changes anything on your product page. On a store using its own AI key this step runs on that provider with that key, exactly as the claim check does |
- What is never sent: customer data (we never read it), your Shopify access token, your billing details, the content of products you did not ask us to generate for — no other product’s title, description, copy, price, images or metafields — or the product-safety metafields described above: the EU product-safety check runs entirely on our own servers and its results are shown to you, never sent to a model.
- One narrow exception, and it is the tag step. To suggest a tag your shop already uses, that step has to know which tags your shop uses, so it receives a list of your own tag and product-type names. Nothing else about those products travels with them, and the list is cut first to the ones this product’s own title or description already contains — so every name sent is a phrase that was going to reach the model in this product’s own text regardless.
- We do not use your product data to train models, and neither provider’s commercial/API terms permit them to do so on our behalf.
- Your data is not shared between stores. A generation is built from one product, in one store.
- Your product data is public storefront content, not personal data. Because the app never receives customer information, none reaches either provider.
Which company processes your data is a disclosure we keep current, not an implementation detail — this table is updated whenever a model provider changes.
AI output is a suggestion, not a fact
- Generated content is written to the app’s own metafields (
ai_product_managernamespace), which are not your product’s own fields and are not shown to shoppers. Your product’s own title, description and SEO fields change only where you have ticked that specific field. In a bulk run that tick is a single choice made for the whole batch, named in the confirmation, and it defaults to none — a batch with nothing ticked changes no product page at all. - Two other kinds of product data are written, and only ever on a field you confirmed: Google Shopping feed values (the
mm-google-shoppingnamespace, on the product and on its variants — this is the data feed apps read), and Shopify’s own standard category attributes (theshopifynamespace, e.g. Colour or Fabric), which requires creating or reusing the taxonomy metaobject that represents that value. Both are snapshotted and reversible on the same terms as everything else. - To tell you when a product has changed since we wrote its copy, the App keeps a small record per product it has written to: the title, description, product type, vendor and tags as they stood when you approved the copy and immediately after we wrote it. It is compared against later versions of the same product so we can say “you changed this — the copy may no longer match”. It contains no customer data and is deleted with the rest of your data.
- Claims that require verification only you can give — waterproof, organic, medical grade, certified, FDA, CE, food safe, compatible with, and similar — are marked as requiring your confirmation whenever we cannot find them in the product information you gave us, and are never applied automatically. Where such a claim is already present in your own product data — for example because it came in with a supplier’s description — we treat it as yours: we carry it through as written, and we do not verify it. Checking that it is true remains yours.
- Every change is snapshotted beforehand and can be rolled back — a single product from its own history, or an entire batch in one act. How far back you can go depends on your plan: 7 days on Free, 30 on Starter, 90 on Growth, 365 on Pro, and no limit on Scale. Older versions are not deleted when the window passes; they are hidden until you move to a plan whose window reaches them. A bulk run does not register translations; publishing a generation into another language stays a per-product action. You remain responsible for the accuracy of your product listings.
Connecting your Google account (optional, and you start it)
ProductReady can show you what Google Merchant Center says about each of your products. This is optional — everything else in the app works without it, and nothing happens until you connect.
What we store if you connect. A Google refresh token and a short-lived access token for the account you choose, both encrypted at rest (AES-256-GCM with a per-value random initialisation vector and an authentication tag verified on every read); which Merchant Center account you selected; and, for the products in it, what Google returns about them — the item’s Google resource name and offer ID, its title, its landing page, its feed label and content language, whether it declares a manufacturer identifier, and Google’s own issues and destination statuses. We store what Google returns so your product pages can show it without contacting Google again.
What the connection does by default: it reads. We ask Google two questions — which Merchant Center accounts your Google login can see, and what Google says about the items in the account you picked — and we store the answers so your product pages can show them without contacting Google again. Nothing is written to your Merchant Center account unless you switch sending on.
The one thing we can write, and only if you switch it on. In Settings → Google Merchant Center there is a setting, “Let ProductReady send corrections to Merchant Center”, which is off for every store until you turn it on. With it on, you can press Send to Google on an individual product to send the Google Shopping title and description you have already reviewed and applied inside ProductReady — and a second setting beside it, “Send the correction whenever I apply a product”, also off until you turn it on, sends that product’s correction each time you apply one, including for every product in a batch apply. Google receives those two fields together with the offer ID, feed label and content language it gave us for that item, and nothing else about the product travels with them. We do that by creating a supplemental data source named “ProductReady corrections” in your Merchant Center account and linking it into your existing feed, so the values are added on top of your own rather than replacing them. When we link that source we place it in front of every source your feed draws from — your own product data and any other feed tool or sheet you use — so for those two fields, on the products you send, the value we supply is the one Google is asked for first at that moment. That order is Google’s to hold and another feed tool can change it afterwards; we re-read it and tell you on the product page if our corrections are no longer among the sources your feed takes values from. Nothing is ever sent for a product you have not sent or applied yourself, and nothing at all is sent while both of those settings are off.
If your store publishes more than one language, we send one correction per language. Your feed can carry the same product several times, once per language. We send a correction for each of those languages that your store itself publishes — the primary one from the copy you applied, and every other one from the Shopify translation you approved for it. Three limits are worth stating plainly. We never send a language your store does not publish. We never send a half-translated product: in any language other than your store’s primary one, if either the title or the description is missing, that language is skipped entirely rather than sent as a mixture of your copy and ours — in your primary language there is no translation involved, so we send whichever of the two fields you have applied. And where you changed your primary copy after approving a translation, that language is sent as you last approved it, which describes the earlier version of your copy rather than the current one — we do not hold it back, because holding it back would not remove a correction Google has already accepted; the app names those languages on the product page and tells you that regenerating them is what brings them up to date.
What we never do, in either state. We never upload or submit a feed file, never change or delete your own feed’s values, never send Google any product data you have not reviewed and applied, and never ask Google to fix anything on your behalf.
Taking it back. Every correction is reversible from the product it came from. Switching the setting off removes all of them and deletes the “ProductReady corrections” data source, and so do disconnecting and uninstalling — the removal runs before we hand the permission back, because after that we would have no way to reach your account at all.
A permission wider than our use, and you should hear it from us rather than from the consent screen. Google publishes no read-only permission for this data. The only scope that reaches it is https://www.googleapis.com/auth/content, which Google describes as “Manage your product listings and accounts for Google Shopping”. So the consent screen will say manage while, unless you switch sending on, the app only reads — and even switched on it uses a narrow slice of what that permission allows. This is the same situation as the two shop-wide Shopify metaobject permissions above, and we treat it the same way: state it plainly, use it narrowly.
Ending it. Disconnecting in Settings, or uninstalling ProductReady, revokes our permission at Google and deletes everything we stored from it. A standing permission on someone else’s Google account is not ours to keep. It is also deleted on a data-erasure request — see Retention & deletion below.
Credits & billing
- Billing runs through the Shopify Billing API. We never take a payment outside Shopify.
- Paid plans include a 14-day free trial: 30 evaluation credits, enough for 10 full products. Your plan’s monthly credits begin at your first charge. Plan credits reset each billing cycle and do not roll over. Top-up credits are valid for 12 months and are spent only after plan credits are exhausted; they require an active paid plan.
- A full product generation costs 3 credits; a single-channel generation costs 1. Regenerating costs the same again.
- Applying, editing by hand, and rolling back are free. A failed generation is never charged — reserved credits are returned.
- Monthly or annual. Every paid plan can be bought monthly or annually; the annual price is ten months for twelve (about 17% less). Annual plans are charged once a year, and your product allowance still arrives every month — never as one yearly lump sum.
- You cannot switch between monthly and annual inside the App in this version. If you are on a paid plan, changing billing interval is refused rather than performed, because a mid-term interval change can produce a proration we would rather not apply to you by accident. To change it, cancel the current subscription and choose the interval you want when you resubscribe. Changing plan within the same interval — Starter to Growth, say — works normally.
Retention & deletion
- We keep your store’s data only while the app is installed.
- Version-history snapshots are kept while the app is installed. Snapshots older than your current plan’s history window (Free 7 days, Starter 30, Growth 90, Pro 365, Scale unlimited) are hidden — you cannot see or roll back to them until you upgrade to a plan whose window covers them. They are not deleted at the window; they are deleted only on uninstall (below).
- On uninstall, Shopify sends a
shop/redactrequest (~48 hours later). In response we delete everything we hold for your store: settings, any connected Google account and everything we stored from it, credit ledger, generation records and all version snapshots (including any that were hidden). - One exception, for fraud prevention: we retain a one-way cryptographic hash of your store domain together with two dates — when your one-time free credits and any free trial were first granted. This record contains no personal data and your domain cannot be recovered from it; we keep it under legitimate interest so the one-time free grant and trial cannot be farmed by repeatedly reinstalling.
Subprocessors specific to this app
In addition to the common subprocessors on the main Privacy Policy:
| Subprocessor | Purpose |
|---|---|
| OpenAI | Writes the product copy you request; checks the generated claims against your own product data; looks your product up in Shopify’s published category list; suggests tags and a product type from the vocabulary your own shop already uses; and, if you have switched it on, reads the weight phrases already present in your own product text; adapts copy you have approved into your store’s other published languages; and repairs a malformed model response when one occurs. |
| Google LLC | Only if you connect a Google account, and what it receives depends on a setting you control. While sending corrections is off — which is where every store starts — no product data and no ProductReady output reaches Google; the connection only asks which Merchant Center accounts your login can see, and what Google says about the items in the account you picked. While you have sending switched on, Google also receives the Google Shopping title and description you have already reviewed and applied in the App — for a product you pressed send on, or, with the second setting on, applied — alongside the offer ID, feed label and content language Google itself gave us for that item. Where your store publishes several languages, it receives one such pair per language your feed carries and your store publishes, each being the copy you approved in that language — which, for a translation you approved before later editing your primary copy, is that earlier version. |
OpenAI acts on our instructions, on the product data described above, and only when you ask for a generation. Google is different on both counts: it receives nothing from us until you choose to connect it, and what it then receives is not part of a generation at all — it is the correction described above, sent only while you have switched sending on. No subprocessor named here receives customer data, because the app never reads any.
Google is on this list under a condition, and that is deliberate. A subprocessor is a company we send your data to so it can do a job for us. A connected Google account starts as the opposite of that — we read your own Merchant Center account with the permission you granted — and while sending corrections is off, that is all it ever is. Because one setting you control turns it into a company we send data to, we name Google in the table rather than leave it to a footnote. What that connection involves, including the credential we store for it, is set out in Connecting your Google account above and in section 4 of the Privacy Policy.