You match the same product across two stores variant by variant, not product by product. In PriceToolKit you attach a competitor URL to one of your variants, the app reads the price from the most reliable source that store offers, and when a link breaks it searches that retailer again by barcode, asking you whenever it isn't sure.
In Ep. 01 I said matching is where most price trackers quietly go wrong. In Ep. 02 I covered the guardrails that stop a bad price reaching your store. This one is about the step before both: making sure the price you compare against belongs to the same thing you sell.
Why isn't product-level matching enough?
Because shoppers don't buy products, they buy variants. Your store might list "Serum 30ml" as its own product. A competitor lists "Serum" with a 30ml and a 50ml option on one page. Match product to product and the tracker can end up comparing your 30ml price with their 50ml price.
Every number downstream inherits that mistake: the cheapest/competitive/expensive badge, the suggested price, the explanation behind it. So PriceToolKit stores matches at the variant level. One of your variants, one competitor URL, compared like with like.
If you'd rather keep a product's variants priced together, that's a setting: variants can be priced independently, or all take the lowest or the highest suggestion. The matching stays per variant either way.
How do you add matches for a whole catalogue?
One at a time from the product, or by CSV import when you're setting up hundreds. The app can also suggest matches; a suggested match only becomes tracked once you accept it.
Where does the competitor's price come from?
The app tries sources in order of how reliable they are.
- The store's own product data, if it runs Shopify. Every Shopify store exposes product and variant data in a structured form, with each variant's price and availability. That's the same data the store's own theme uses, so it's the most reliable source there is.
- Structured data. Most retailers already publish schema.org product data so Google can show prices in search results. It looks something like this:
{ "@type": "Product", "name": "Serum 30ml", "gtin13": "0123456789012", "offers": { "@type": "Offer", "price": "24.00", "priceCurrency": "USD", "availability": "https://schema.org/InStock" } }
- The page itself. Only when neither exists. For unusual pages the app works out where that site shows its price once, then remembers it, so repeat checks are fast.
From each page it reads three things: price, currency and stock status. An out-of-stock competitor price isn't a price you're competing with, so the rules can ignore it.
What happens when a competitor link breaks?
Pages move, products get renamed, stores change platform. A link is marked broken when it stops resolving, or stops showing a price, three checks in a row. One failed check isn't enough; that's usually a slow server, not a missing product.
Then the app searches that retailer for the product again, by barcode where your variant has one, by title otherwise. Barcodes are the closest thing ecommerce has to a shared ID, which is why it's worth filling them in on your own products even if no shopper ever sees them.
- A confident match replaces the URL automatically.
- An unsure match is proposed in Activity for you to confirm.
Retailers that block automated requests are a separate case: they're marked blocked and retried daily rather than abandoned.
Why ask instead of guessing?
Because a wrong match is worse than a missing one. A missing match shows up as a gap you can see. A wrong match shows up as a confident, well-explained price suggestion built on the wrong product. The same principle runs through the whole app: when it isn't sure, it tells you.
What's next?
Next episode: how often to check competitor prices, and why more often isn't better.
PriceToolKit is in development. Join the waitlist to hear when it's ready, or read the docs for how tracking works today.