Price dropped
Trail Runner 2.0 · $128 to $99
Back in stock
Merino Base Layer
New product
Winter Insulated Jacket
Price raised
Daypack 22L · $74 to $82
Out of stock
Camp Stove Kit
Each row is a Product Event recorded when a refresh finds a change. Values shown here are an example.
Who it is for
Product Monitoring is built for growth, ecommerce, and founder teams who already open competitor stores to see what launched, what sold out, and what changed price. Doing that manually across several stores is slow and easy to forget.
Content Radar keeps that watch in one place. You add the stores once, and each refresh reports the product changes worth reviewing, next to the competitor publishing you already track.
The manual version
Getting a store in
Adding a store follows three stages. The first two happen once, and the third runs every time you check for changes.
You paste a store URL and Content Radar runs a bounded check that reads the storefront and looks for a supported catalog. Stores that are blocked, password protected, or do not expose readable product data are reported and not saved.
For a compatible store, Content Radar imports the current catalog once as Store Products. The baseline records what exists today, so it does not create any change events.
Run Check for changes yourself, or let the daily scheduled refresh compare the store against its saved state. Each refresh writes Product Events for what actually changed.
What a refresh detects
After the baseline, each refresh compares the store to its saved state and records these change types as Product Events.
A product that was not in the saved catalog is recorded as an added product.
A product is only marked removed after it is missing from three consecutive complete catalog scans, so a single failed or partial scan never removes it.
A higher price is recorded when both the old and new price share a known, matching currency.
A lower price is recorded on the same known-currency basis as an increase.
A product that moves from available to unavailable is recorded from stable public availability signals.
A product that becomes available again is recorded the same way, ignoring unknown states.
Supported stores
Product Monitoring supports three store types. Being on one of these platforms does not guarantee support on its own. Every store passes a compatibility check first.
Shopify
Compatible public Shopify stores that expose a readable catalog.
WooCommerce
Compatible public WooCommerce stores with server-visible product data.
Structured custom stores
Compatible structured custom ecommerce stores that publish product data a server can read.
A store is monitored only when
Blocked, password-protected, rate-limited, and unsupported stores are reported during the check and never saved as monitored stores.
Reviewing changes
Detected changes land in views built for scanning a store and its Product Events, all inside the same workspace.
Browse imported Store Products, search by name or SKU, and filter by availability to see the current catalog you are tracking.
Every detected change is stored as a Product Event with its type and timing, giving you a persistent record of how a store changed over time.
The Recent changes views collect the latest Product Events for a store and across the workspace, so you can scan what moved without opening each store.
Product changes appear in the same in-app alerts feed as content detections, with read and unread state. Email, Slack, and webhook alerts are not part of Product Monitoring.
Is it a fit
Product Monitoring does a specific job well. It is worth knowing what it is not before you rely on it.
A good fit when
Not the right tool when
Current limits
Compatible public Shopify, WooCommerce, and structured custom ecommerce stores. Support depends on the store being publicly accessible, using a catalog structure Content Radar can read, and exposing product data in the server response. Stores that fail the compatibility check are reported and not saved.
You can run a manual Check for changes at any time, and a daily scheduled refresh compares each monitored store against its saved state. Checks do not fire the moment a store changes, and the frequency is not user-configurable.
A product is only recorded as removed after it is absent from three consecutive complete catalog scans. A single missing, partial, failed, or rate-limited scan does not remove a product.
No. Product Monitoring records price increases and decreases on compatible product pages. It does not compare your prices to competitors, match products across stores, or make pricing recommendations.
No. Product change history is kept as immutable Product Events. Product Stores, Store Products, and Product Events are separate from the seven-day Workspace History restore window, which covers other entities.
Source Monitoring watches public publishing sources such as RSS, Atom, sitemaps, and manual URLs and produces Articles and Candidate URLs. Product Monitoring watches compatible ecommerce stores and produces Store Products and Product Events. They are separate pillars on the same workspace.
Keep exploring
Product Monitoring is part of the free workspace. Add a compatible store, run the baseline import, and review the first refresh.