Personyze Wiki Personyze Wiki docs
Open Personyze
Docs/ Product Recommendations/ Uploading Past/Offline Transactions for Product Recommendations
Product Recommendations

Uploading Past/Offline Transactions for Product Recommendations

Beyond the online transaction data that Personyze can be set to track in real-time, you also have the option to integrate external data about your past or offline transactions into Personyze. Since recommendations are…

4 min read Updated 23 hours ago

Beyond the online transactions Personyze tracks in real time, you can feed it your past or offline transactions. Because recommendations are built on transaction statistics, uploading history enhances your recommendations and lets you leverage sales from physical stores, phone orders, or any channel Personyze doesn’t see on-site.

Why upload past transactions?

Usually to give a new Personyze account a jump-start. Otherwise recommendations take a while to become relevant, because they build up as Personyze tracks customer interactions from the day you install it. Feeding in which users bought which products in the past reaches relevance much faster.

Why upload offline transactions?

To enhance recommendations with sales Personyze can’t observe on your site — in-store purchases, POS data, phone orders. Because this is usually an ongoing source rather than a one-time load, it’s best delivered as a recurring feed (RSS/Atom, a URL feed, or SFTP) that keeps updating.

What each row needs

Each row says who bought what, when. In the wizard, the required fields are marked with an asterisk:

  • Transaction time or ID (required) — the date/time of the purchase, or an order ID. If multiple items share one order ID, Personyze learns they were bought together (and recommends them together once that happens often enough). For a timestamp use a standard date-time such as 2026-07-21 14:30:00 or a Unix epoch like 1751389200.
  • User Email or User Internal ID (one is required) — the key that ties every transaction to one customer. Email doubles as the key for email recommendation campaigns (e.g. cross-sell emails based on what was purchased). A CRM/internal ID works just as well; you only need one of the two.
  • Product Internal ID (required) — the ID unique to each product. It must match how your product catalog is keyed; if there’s no product ID, the product-page URL can stand in.
  • Quantity and Amount (optional) — include them if you have them; otherwise Personyze reads product details like title and price from your catalog.

Where to upload it

Go to Settings → Recommendations → Product Tracking and open the Upload past purchase events wizard. It has three steps.

The four ways to send transaction data to Personyze: upload a file, a URL/RSS/Atom feed, SFTP, or JSON API
Step 1, Upload source — pick how the data arrives. The choice is really about how often it changes.

Step 1 — Upload source. Choose how the data reaches Personyze:

  • Upload a file — a CSV or TSV from your computer (up to 50 MB). A one-off snapshot; best for a historical back-fill.
  • URL feed — an HTTP(S) URL that returns CSV/JSON (or an RSS/Atom feed). Personyze polls it on a schedule, so new transactions keep flowing. Best for offline sales that keep coming.
  • SFTP drop — upload your file to sftp://upload.personyze.com using the credentials in your account settings; it appears in the wizard once detected. Best for large nightly exports.
  • JSON API — POST records directly from your backend to the transactions endpoint (social_site_db_products_interactions_archive). See the API docs.
The Choose columns step, mapping each source column to a Personyze field
Step 2, Choose columns — map each of your columns to a Personyze field. Required fields are marked with *; a sample of your data is shown so you can confirm it parsed correctly.

Step 2 — Choose columns. Personyze reads your header row and auto-maps what it recognizes; adjust anything it didn’t. Map at least the three required fields (Transaction time or ID, Product Internal ID, and User Email or User Internal ID). Each column has optional preprocessing (for example, stripping a currency symbol or thousands separators) and a live sample preview.

Step 3 — Ready for import. Confirm and start. A file loads once; a URL, SFTP, or API source can be kept as a recurring feed — it re-imports on a schedule and appears under Active feeds on the Product Tracking screen, where you can re-import, edit the mapping, or change its settings at any time.

The Product ID in your feed must match the key your product catalog uses. An import that completes but “matches no products” is almost always a key mismatch — the transactions loaded fine, they just don’t line up with the catalog.

Related

Did this page answer your question?
Thank you — that goes to whoever maintains this page.