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.
Where: Settings → Recommendation setup → Product Tracking (Article Tracking for content). A recommendation campaign’s Interactions step shows the same screen.
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 Interactions 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.