Recommendations learn from three events: product viewed, added to cart, and purchased. Views and carts drive the ranking; purchase does two jobs — it attributes revenue to your campaigns and completes the picture of what actually converts. (Content sites track article viewed the same way.) This page covers every way to wire these events, from zero-code to API.
Watch the 1:35 walkthrough: Product Tracking — the three ways to send what shoppers do, the developer route and its live check, uploading past orders, and the tracking screen.
Article tracking has its own film: Watch the 1:02 film: setting up Article Tracking with the line your developer adds, checking that reads arrive, and uploading past reads.
Where: Settings → Recommendation setup → Product Tracking (Article Tracking for content). A recommendation campaign’s Product events step shows the same screen.
Guided setup
While nothing is set up, the yellow card on Product Tracking offers Guided setup; a recommendation campaign’s Product events step offers it as Set up product tracking. It asks How does your site tell us what shoppers do? — Google Tag Manager (the shopping events your store already sends to Google Analytics; no code), Read it from your pages (we find the product ID on your product pages, and you point at your Add to cart button and your thank-you page) or Your developer adds it (one line of code per event; Email to my developer sends the instructions). It turns tracking on, then Check it works ticks each event live as it arrives. Each row of the tracking screen ends with Set up (not set up: the guided setup for that one event) or Check (set up but silent: its live check), a gear for its settings, and ⋯ More options: Settings, View tracked events, Guided setup and, on Product Purchased, Upload past orders. The tabs are All, Healthy, Needs attention and Not set up. Content tracking has the same, with Read it from your pages (the article ID from the page address) and Your developer adds it.
On Check it works, Open my site opens a page of the site your visitors are on — your newest product page (an article, for content tracking), or the site itself — and its tooltip names the page. The arrow beside it lists that page, your site’s pages and Another page… (a full address, or a path like /pricing). Picking one opens it at once.
Pick your route
| Route | Best for | Setup |
|---|---|---|
| Platform integration | Shopify / WooCommerce stores | Shopify events (and the cart extension), or the WordPress plugin’s add-to-cart and purchase toggles. |
| Google Tag Manager | Sites already sending GA4 ecommerce events | A switch on each interaction — “no code — reads the GA4 ecommerce events you already send” (view_item, add_to_cart, purchase). The data layer settings are shared by every interaction. See Google Tag Manager. |
| From your site | Any site, no code | Personyze reads the product ID off the page — a CSS selector, meta tag, JavaScript variable, or the page URL. Added as Site sources on each interaction; for product views the panel can read one of your product pages and suggest the source. |
| From your code | Single-page apps, custom carts | One line of JavaScript at the moment the event happens (below). Download instructions for your developer hands it over. |
| REST API | Server-side and offline events | products_interactions — also the road for historical transactions. |
The JavaScript pushes
(self.personyze=self.personyze||[]).push(['Product Viewed', "PRODUCT_ID"]);
(self.personyze=self.personyze||[]).push(['Product Added to cart', "PRODUCT_ID", 'Quantity', QUANTITY]);
(self.personyze=self.personyze||[]).push(['Product Purchased', "PRODUCT_ID", 'Quantity', QUANTITY]);
(self.personyze=self.personyze||[]).push(['Products Purchased']);PRODUCT_ID is the catalog’s Internal ID; to send a SKU instead, add 'key', 'sku' after it. Products Purchased turns every item in the cart into a purchase at once — useful when the confirmation page can’t list them.
The Product Tracking screen
Each interaction is a row with its status; click one to see how it is detected. The rows come in three groups: What the visitor does (Product Shown, Product Added to cart, Product Removed from cart, Product Added to favorites, Product Purchased), What we learn while they browse (Categories), and Additional tracking, optional (Interests, User name for social proof widget).
| Status | Meaning |
|---|---|
| Receiving | An event arrived in the last 24 hours. |
| Nothing recently | It is set up and has received events, but none in the last day. |
| Never received | It is set up, but nothing has ever come through. |
| Not set up | No source, and GTM detection is off. |
| Capturing / No items yet | Categories and Interests: values are arriving / a source is set up but nothing has been captured yet. |
History can be loaded too: Upload past events on an opened row, and Upload past orders on Product Purchased — see Uploading Past / Offline Transactions.
Categories & interests
Beyond the product events, two things describe what a visitor is into. Categories are the taxonomy paths visitors browse on your site (Apparel > Tops > T-Shirts). Interests are broader themes a product can belong to — fitness, vintage — for when a category isn’t enough (Interests for Recommendations). Both drive the category & interest recommenders and can be targeted on.
On Product Tracking each is a row of its own. The Categories row’s tip says why it matters:
Fire “Category viewed” on category pages: it is the anchor for category recommendations, and the only reliable way a visitor gets a category. Product views add categories only where the catalog link is set to update visitor interests.
“The catalog link” is its Update visitor’s interest when setting — the default for feeds imported since 2026-09; older feeds have it empty. So report the category on category pages. Three ways to capture it:
| Method | When | How |
|---|---|---|
| The URL path | The category is plain in the address, e.g. /shop/footwear/. |
Site sources → a source that reads the URL: its path, one path segment, or a URL parameter. |
| A page element | The page shows the category — a breadcrumb, a heading. | Site sources → a CSS selector (or a meta tag or JavaScript variable). |
| A JS push from your CMS | Your CMS knows the category when it renders the page. | From your code — on a category page:(self.personyze=self.personyze||[]).push(['Category', "CATEGORY_NAME"]);or several at once: ['Categories', "Books", "Sports inventory"]. |
If your data layer already reports it, the row has a Google Tag Manager switch too. Interests are captured the same way from the Interests row — (self.personyze=self.personyze||[]).push(['Interests', "Books", "Sports inventory"]);, up to 15 per call.
QA — proving events arrive
- Open Live visits, browse your store in another tab, and watch your own view / cart / purchase events appear within seconds.
- On Product Tracking (or the campaign’s Product events step) each row shows its status; View tracked events lists what arrived.
- Product IDs must match your catalog — an event whose id isn’t in the catalog can’t attach to a product. That mismatch is the most common “tracking works but recommendations don’t learn” cause.