Shopify Plus integrations and product data

Most product data problems get reported as storefront bugs. A variant shows as out of stock when the warehouse has forty. A barcode is missing from the shopping feed. A price changed in one market and not another. Someone opens the theme to look for the cause, and the cause is two systems upstream.

So I start from the other end. Where does each field come from, which system is allowed to change it, and what happens to it on the way to Shopify?

ERP, PIM, Shopify: who owns what

The arrangement that holds up best gives each system one job.

The ERP owns the operational facts. SKUs, cost, stock by location, and usually the base price. It's the system finance trusts, and nothing else should edit it.

The PIM owns the product as the customer sees it. Titles, descriptions, attributes, images, compliance data, categories and how products relate. It enriches what the ERP creates and sends the result to every channel, Shopify included.

Shopify owns presentation and selling. How the product looks, which market sees it at what price, and what the cart and checkout do with it.

Problems start when those lines blur. A merchandiser edits a title in Shopify because it's quicker, the next PIM sync overwrites it, and the fix gets made twice more before someone asks why. Writing down which system owns which field, and enforcing it in the integration, prevents most of this.

Modelling the product properly

Identifiers. SKU, GTIN or barcode, MPN and the ERP's own item number are different things and each needs its own field. The shopping feed, the marketplace listing and AI assistants all want a GTIN. The warehouse wants the SKU. Getting each into the right Shopify field, at variant level, is dull and it matters.

Variants and options. An ERP thinks in items. Shopify thinks in products with up to three options, now extended by combined listings. Deciding how a range of blade lengths, handle materials and finishes becomes products and variants is a merchandising decision with technical consequences, best made once, before the sync is built around it.

Attributes as metafields. Materials, dimensions, weights, specifications and care information belong in structured metafields and metaobjects. There, they drive filtering, comparison, structured data and search. Buried in a description, they do none of that.

Prices and stock. Base prices from the ERP, market prices from Shopify Markets or a price list, and stock by location. Each needs a clear direction of travel and a known sync frequency, so nobody is surprised when a price change takes an hour to appear.

When it goes wrong

My method is the same whatever the systems are. Take the one product that's wrong and follow it from the ERP record to the PIM to the Shopify API to the page, comparing the value at each step. The step where it changes is the step with the problem. It sounds obvious, and it's faster than reading integration code hoping to spot the bug.

Across a whole catalogue, the same comparison runs as a script: export each system, match on the identifier, and list every product where they disagree. That report is usually the most useful single document in a data clean-up, because it turns "the data's a bit messy" into a list with a length.

The integrations around the store

A Plus store at scale usually carries several integrations, each with its own data and its own assumptions.

Subscriptions and loyalty. At Brew Tea Co, Recharge subscriptions, LoyaltyLion's Brew Coins and one custom customer account talk to each other through their APIs, so the store behaves as one system. In its first year, net sales rose 28%.

Cross-border. Shopify Markets, Managed Markets or Global-e, depending on where you sell and who should be merchant of record. Each changes how prices, duties and returns flow, and each has to agree with the catalogue and pricing coming from upstream.

Site search and merchandising. A search platform indexes the catalogue and ranks it, and it's only as good as the attributes it's fed.

Tracking and analytics. Server-side tracking, so conversion data reaches the ad platforms intact, with product IDs that match the feed. When the IDs in the pixel don't match the catalogue, attribution quietly breaks.

Configurators and 3D. Product customisers need options, pricing rules and stock that agree with the cart, so the configurator and the checkout reach the same price.

AI shopping assistants. On-site assistants answer from the catalogue, so gaps in the product data become wrong answers in front of customers.

The tools vary by brand. The method stays the same: find out which system owns each field, check the data where it crosses between systems, and make sure every sync reports when it fails.

Knowing when something stops

Integrations fail quietly. A sync that stopped on Tuesday shows up as a stock complaint on Friday. Every integration I build reports its own failures to someone who'll act on them, and comes with a written note of what it does, what it depends on and how to restart it, written for whoever maintains it next, including your own team.

Where my work starts and stops

Choosing and configuring an ERP is a specialism of its own, and I leave it to the people who do it. My job is making the systems you already have agree with each other and with the storefront, and building the Shopify side of each integration properly.

If you're not sure where your data problems start, the Shopify Plus audit includes an integrations section, or book a call.