> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/intelligence/product-recommendations/prepare-your-data.md).

# 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](/integrations/data-sources/google-bigquery.md) or [Snowflake](/integrations/data-sources/snowflake.md) 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](/models/overview.md) on that source, with stable [primary keys](/models/primary-keys.md) 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](/integrations/data-sources/google-bigquery.md#product-recommendations-access).
* **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](/integrations/data-sources/snowflake.md#product-recommendations-access), 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](/intelligence/product-recommendations/recommendation-use-cases.md#item-availability).

A numeric field used to [weight audience allocation](/intelligence/product-recommendations/audiences-and-allocation.md#distribution-between-targets) 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](/intelligence/product-recommendations/recommendation-use-cases.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dinmo.io/intelligence/product-recommendations/prepare-your-data.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.