Purchase and Interaction Logs for Recommender System Training

What grain recommender interaction logs need

The usable grain is one row per interaction: a pseudonymous account or user key, an item key, an event timestamp, an event type, quantity, and the unit price at the time of the event. Anything coarser, such as monthly SKU totals, belongs to forecasting rather than recommendation; see sales and order histories for demand forecasting for that aggregate use. Recommenders learn from who interacted with what and when, so per-account sequences must survive delivery intact.

Ask for these fields explicitly, because sellers often export order headers without lines or lines without timestamps:

• Keys: stable account_id (and user_id under it for B2B buyers with multiple purchasers), item_id, and order_id or session_id so baskets can be rebuilt.
• Event semantics: an enumerated event_type (impression, view, add_to_cart, remove_from_cart, order, return, cancel) with a data dictionary stating how each is triggered.
• Commercial context: quantity, unit_price_at_event, discount or promotion flag, channel (web, app, EDI, sales rep, punchout), and fulfillment status.
• Time: event timestamps with time zone, plus order_created versus order_shipped where both exist, since the gap changes what "next basket" means.

The tabular data license specification guide covers grain, keys and history in general; this page focuses on what changes for recommenders.

Consumer clickstream versus B2B reorder histories

Consumer clickstream and B2B reorder histories are different learning problems, and a dataset should be labeled as one or the other before you price it. Consumer logs are dominated by anonymous or lightly identified sessions, high item churn and sparse repeat purchase. B2B logs are dominated by known accounts buying contract items on a cadence, often through EDI 850 purchase orders or punchout catalogs, with negotiated price lists.

That difference drives model choice. Next-basket methods such as TIFUKNN, DREAM and Sets2Sets behave differently depending on basket length and on how much of each basket is a repeat of earlier orders, so a model chosen on public grocery baskets may not transfer. A B2B reorder model that mostly predicts "the same 40 SKUs again" can look strong offline while adding little value; ask the seller for the share of order lines that are repeats versus first-time item purchases per account.

Catalog snapshots as of interaction time

Every interaction should join to the item's attributes as they were at event time, not as they are in today's catalog. Items get renamed, re-categorized, discontinued, repriced and merged, and a current-state join quietly gives the model information it would not have had. Ask for a slowly changing dimension (type 2) item table with valid_from and valid_to, or dated catalog snapshots at a fixed cadence.

The pattern is the same point-in-time join that feature stores enforce: Feast treats each row's event_timestamp as an inclusive upper bound and returns only feature values stamped at or before it [4]. Apply that rule to price, category, availability and description. For item content itself (titles, attributes, images), the owner page is licensing product catalogs and descriptions; for cross-seller item identity, see product matching data.

Offline evaluation without temporal leakage

Offline evaluation should use a global temporal split, where all training events precede a cutoff and test events follow it. Leave-last-one-out splits, still common in recommender papers, hold out each user's final event but leave other users' later events in training, so the model can learn about items and trends that did not exist at the test user's moment. This is a case of what Kapoor and Narayanan call temporal leakage, one of the recurring ways ML evaluations overstate performance [1].

Relational benchmarks have adopted the time-based protocol: RelBench links interaction tables to user and item entities and evaluates with temporal splits [2], and its second version adds consumer-platform datasets built the same way [3]. The practical consequence for sourcing is that you need enough contiguous history to hold out at least one full seasonal period after the cutoff. If a seller can supply only 9 months, a December holdout will test a model that never saw a prior December.

Write the split into the data request so the seller does not pre-shuffle, deduplicate across periods or drop "inactive" accounts in a way that leaks future status. Treating the history as a multi-table relational problem is covered in multi-table relational data for relational deep learning.

Illustrative interaction schema and request template

The schema below shows the minimum structure to request; field names are examples, not a standard.

Illustrative example: invented to show structure; it does not describe an available dataset.

interactions (one row per event)
  event_id            string    unique
  account_key         string    salted hash; stable across the full window
  user_key            string    nullable; buyer within a B2B account
  item_key            string    joins to item_versions.item_key
  event_type          enum      view | add_to_cart | remove_from_cart | order | return | cancel
  event_ts            timestamp UTC, with source time zone recorded
  session_or_order_id string    rebuilds sessions and baskets
  quantity            decimal   null for view events
  unit_price_at_event decimal   currency in a separate column
  channel             enum      web | app | edi | rep | punchout
  promo_flag          boolean

item_versions (type 2 history)
  item_key, valid_from, valid_to, category_path, brand, uom, list_price, status

accounts (static or slowly changing)
  account_key, segment, region_bucket, first_order_month

A matching request template:

1. Source type: consumer sessions, B2B accounts, or both, labeled separately.
2. Window: at least 24 contiguous months, with no backfilled gaps.
3. Volume floor: accounts with at least N orders in the window, and how many accounts fall below it.
4. Catalog: item version history or monthly snapshots covering the same window.
5. Exclusions: bot traffic filter rule, internal test accounts, cancelled-order handling.
6. Split: global temporal cutoff named by date; no shuffling by the seller.
7. Documentation: a data card covering collection, event definitions and known gaps [7].

Privacy, consent and permitted use for behavioral logs

Consumer behavioral logs carry the heaviest privacy load in this category, because a sequence of purchases can identify a person even after names and emails are removed. Under the CCPA, information counts as deidentified only if it cannot reasonably be linked to a consumer and the business holding it meets the statute's conditions, including commitments not to reidentify [5]. Ask how account keys were generated, whether salts are rotated, and whether rare-item purchases or free-text fields (gift messages, delivery notes) remain.

Permitted use is a separate question from de-identification. The FTC has warned that quietly expanding data practices to include AI training may be unfair or deceptive [6], so ask what the seller's privacy notice and customer contracts said when the events were collected. B2B logs reduce the consumer exposure but often embed buyer names, phone numbers and PO notes in line-level comments.

SourceX removes or replaces personal details such as names, emails, phones and account numbers before delivery, records the method and checks a sample; no de-identification method is perfect, so keep your own reidentification review. Health-adjacent purchases (pharmacy, medical supplies) need specific treatment, and health records require HIPAA de-identification by Safe Harbor or Expert Determination.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Diligence questions before you license an interaction log

The fastest way to avoid an unusable purchase is to ask questions that expose silent transformations in the export. Use this checklist with any supplier:

• Were any events sampled, capped per account or deduplicated, and by what rule?
• Do item keys stay stable through SKU merges and replacements, and is there a crosswalk?
• Are returns and cancellations linked to the originating order line?
• Which period had tracking changes (new analytics tag, app launch, ERP migration) that shift event volumes?
• Is price at event recorded, or reconstructed from today's list price?
• Are recommendation impressions logged, so you can correct for exposure bias from the incumbent recommender?
• What did customer notices and contracts permit when the data was collected?

For adjacent uses of the same commerce data, see subscription and usage histories for churn prediction and product search relevance data, and return to the tables, time series and transactional data hub for the full cluster.

How SourceX sources recommender interaction data

SourceX sources operational datasets from US companies on request, including the sales histories that recommenders are built from; nothing is held in stock and a request does not guarantee a match. Buyers describe the data they need, SourceX looks for US businesses that hold it, and every release is approved by the supplying company. The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. E-commerce teams can see how this applies to their sector on the e-commerce buyers page, or submit a data request with the schema above.

Request recommender system training data

Describe the interaction grain, catalog history and split rule your recommender needs, and SourceX will look for US businesses that hold matching data and manage the licensing process. Diligence materials on source, rights, preparation and allowed use are prepared per dataset. Start your recommender data request.