Prepare your data

Product Recommendations learns from relationships between users and items. Prepare those relationships before configuring an intelligence.

Technical prerequisites

• Access to Intelligence in your DinMo workspace.

• A connected BigQuery or Snowflake source. These are the supported warehouses for Product Recommendations.

• Permissions to read the input models and create or update DinMo's working and output tables. Follow the source setup guide for the required grants.

• User, item, and interaction models on that source, with stable primary keys and the relationships described below.

Warehouse access checklist

Check the credentials configured in the DinMo source, not the permissions of your own administrator account.

• BigQuery: the BigQuery and BigQuery Storage APIs must be available. The service account needs query/load job permissions, access to input tables, write access to working/output datasets, and Storage Read API permissions: bigquery.readsessions.create, bigquery.readsessions.getData, and bigquery.readsessions.update. Grant session permissions on the project used by the connection: the Internal project ID when configured, otherwise the Project ID. BigQuery User already includes these session permissions when granted there; BigQuery Job User alone does not. See the BigQuery permission checklist.

• Snowflake: there is no separate Storage Read API or read-session role to enable. The configured service role needs warehouse/database/schema USAGE, input SELECT, and permission to create and load DinMo working/output tables and temporary file formats. It must retain OWNERSHIP of the tables used for publication, which swaps or renames them. See the Snowflake permission checklist, including temporary staging and network access.

A successful connection test or table preview does not validate the complete training-to-publication path. Before a full rollout, validate a small representative training run and recommendation output using these same credentials, through publication and a subsequent refresh.

Required data

Model	Required information	Good practice
Users	One unique, non-null user ID per person or profile	Use the same identity in interactions and activation. An email address is not required for learning.
Items	One unique, non-null item ID per recommendable entity	Choose the business grain: a product, a deal, a donation campaign, or another item.
Interactions	A unique event ID, user ID, item ID, and event timestamp	Link each event to one user and one item. For multi-product orders, use order lines rather than one row per order.

Map each interaction source to an event type, such as purchase, contribution, or view. A source can have a constant event type or use values from an event-type field. An optional positive interaction strength can represent quantity or another meaningful weight; otherwise, interactions use a strength of 1.

A deal ID and its vendor are not interchangeable. To recommend individual deals, keep the deal ID as the item identity and map vendor as an attribute.

Useful optional mappings

• Vendor and category: item attributes that add affinity signals and enable recommendations at those levels. Use consistent values across the catalog.

• Availability start and end: item lifecycle dates. A missing end date means the end is unknown, not that the item is confirmed active.

• User known-at date: when available, helps establish which users were known at historical evaluation dates.

These mappings do not replace commercial eligibility rules. Public visibility, stock, blocked status, minimum revenue, or recent activity belong in the item segment used by a recommendation scenario.

A numeric field used to weight audience allocation is a separate commercial parameter. It is not automatically a training feature or an interaction strength.

Check before training

1. Check key uniqueness, duplicate events, missing IDs, and user/item references.

2. Align timestamp types and time zones, and inspect the oldest and newest interactions.

3. Check lifecycle dates and the share of items with an unknown end date.

4. Review the amount of repeated user behavior. Millions of one-off guest IDs do not provide the same personalization signal as recurring identifiable users.

Unmatched event references and invalid required values can lead to excluded interactions and data-quality warnings. Inspect the admitted event count, not just the size of the source table. Do not invent identity links to retain guest events.

Use the useful history you are authorized to process for training. Separately restrict campaign audiences to contactable, eligible users. An opt-in list is an audience input; absence from that list does not, by itself, prove an opt-out.

Next: Choose a recommendation use case.