What Data Does Amazon Personalize Need?

Amazon Personalize does not need your entire WooCommerce database. It needs a well-structured record of interactions between shoppers and products, with optional product and customer attributes to improve recommendations and support cold-start scenarios.

For most WooCommerce implementations, the quality of the interaction data matters more than the volume of unrelated customer fields. A smaller, consistent dataset of product views, add-to-cart events, purchases, and meaningful engagement is usually more useful than a large export containing incomplete or inconsistent records.

The core datasets Amazon Personalize uses

Amazon Personalize organizes data into dataset groups. The most common datasets for a WooCommerce store are Interactions, Items, and Users.

Interactions dataset

The Interactions dataset records what a shopper did with a product. This is the most important dataset for user-personalization use cases and is generally the starting point for a WooCommerce integration.

Typical interaction fields include:

USER_ID: The customer or visitor identifier.
ITEM_ID: The WooCommerce product or variation identifier.
TIMESTAMP: The time at which the interaction occurred, normally as a Unix epoch timestamp.
EVENT_TYPE: The type of action, such as view, cart, purchase, or remove_from_cart.
EVENT_VALUE: An optional numeric value, such as an order quantity, rating, or engagement score.
SESSION_ID: An optional identifier for grouping anonymous or browsing-session activity.

A historical interaction record might look like this:

USER_ID,ITEM_ID,TIMESTAMP,EVENT_TYPE,EVENT_VALUE,SESSION_ID
customer-184,product-742,1715000100,view,1,session-abc123
customer-184,product-742,1715000220,cart,1,session-abc123
customer-184,product-742,1715000900,purchase,2,session-abc123

For an agency, the key design decision is how to represent event meaning. A product view, add-to-cart event, and completed purchase should not automatically be treated as equally strong signals. Your event taxonomy should be documented before data is imported or sent through the Amazon Personalize event tracker.

Items dataset

The Items dataset describes the products that can be recommended. It is particularly valuable when the catalog contains new products with little or no interaction history.

Common item fields include:

ITEM_ID: The product or variation identifier used in the Interactions dataset.
PRICE: The current or representative product price.
GENRE, CATEGORY, or another categorical field: Product taxonomy values.
CREATION_TIMESTAMP: The time the product was created or published.
BRAND, COLOR, SIZE, or other attributes: Useful product metadata, provided the values are consistently formatted.
DESCRIPTION or another text field: Optional descriptive content for recipes and campaigns that can use item metadata.

In WooCommerce, agencies commonly map product_id or variation_id to ITEM_ID. Choose one strategy and use it consistently. If recommendations are displayed at variation level, variation IDs should be used in interactions and item metadata. If the storefront recommends parent products, parent product IDs should be used instead.

Products that cannot be purchased, are private, or are excluded from a particular storefront should normally be filtered before recommendations are displayed. Catalog eligibility is a WooCommerce business rule and should not be left entirely to the recommendation model.

Users dataset

The Users dataset contains customer attributes that can help Amazon Personalize identify patterns between user characteristics and product preferences. It is optional for many implementations and should not be populated simply because the fields exist in WordPress.

Potential user fields include:

USER_ID: The same identifier used in the Interactions dataset.
MEMBERSHIP_LEVEL: A stable customer segment or loyalty tier.
REGION or COUNTRY: Geographic information at an appropriate level of granularity.
ACCOUNT_CREATION_DATE: A timestamp or derived customer-age attribute.
CONSENTED_MARKETING: A carefully governed business attribute, if it is genuinely needed for the use case.

Do not send sensitive personal data, payment data, passwords, email addresses, postal addresses, or arbitrary WordPress user metadata unless the field has a documented purpose, an appropriate lawful basis, and a clear retention policy. In many cases, a pseudonymous customer ID and a small number of non-sensitive categorical attributes are sufficient.

Required data versus useful data

The exact required fields depend on the Amazon Personalize recipe and the type of solution being built. As a practical baseline, an interactions feed should contain a stable user identifier, a stable item identifier, and an event timestamp. The selected recipe may also require or benefit from event types, event values, session information, or additional metadata.

For a WooCommerce agency, the minimum viable implementation is usually:

Export or stream product interaction events.
Use stable IDs that remain consistent between WooCommerce, the data pipeline, and Amazon Personalize.
Include timestamps that reflect when the shopper action occurred.
Define event types for the actions that matter to the business.
Filter invalid, duplicated, test, and administrative traffic.
Validate the resulting schema before training a solution version.

Product and user metadata are enhancements, not substitutes for interaction history. A detailed product feed cannot compensate for missing views, carts, purchases, or other behavioral signals.

Real-time events and historical imports

Amazon Personalize can use both historical data and real-time events. Historical data provides the initial behavioral foundation. Real-time events keep recommendations current as shoppers browse and buy.

A WooCommerce event integration might send a view event after a product page is loaded, a cart event after an item is added, and a purchase event after payment has been confirmed. A real-time event typically includes the event type, user ID when available, item ID when relevant, session ID, and event timestamp.

{
  "eventType": "purchase",
  "itemId": "742",
  "properties": "{\"quantity\":2,\"order_id\":\"wc-9021\"}"
}

The exact API request also includes the event tracker context and identifiers required by the Amazon Personalize runtime. Order identifiers can be useful for deduplication in the integration layer, but they should not be confused with the product identifier used as the item ID.

For logged-in shoppers, use a stable pseudonymous customer ID. For anonymous shoppers, use a consent-aware session ID or another temporary identifier. When a visitor logs in, decide whether and how anonymous activity should be associated with the known customer, and document that identity-resolution policy before implementation.

Data quality issues to address in WooCommerce

Product and variation identity

WooCommerce stores parent products and variations separately. Mixing parent IDs and variation IDs can create recommendations that cannot be rendered correctly or that point to unavailable products. Define the recommendation unit first: parent product, variation, or another catalog entity.

Duplicate and reversed orders

Order status changes can produce duplicate purchase events. A payment retry, refund, cancellation, or failed order should not be treated as a new completed purchase. The integration should have an event deduplication strategy and a policy for handling refunds and cancellations.

Bot and internal traffic

Exclude crawlers, site administrators, QA sessions, staging traffic, and automated catalog checks. These records can distort popularity and personalization signals.

Inconsistent categories

Normalize category and attribute values before loading the Items dataset. Values such as Men's Shoes, mens-shoes, and Mens Shoes may represent the same business category but will be treated as different values when supplied inconsistently.

Missing timestamps

Do not replace missing event times with the import time. That makes old behavior appear recent and can affect recency-sensitive recommendations. Quarantine records with invalid timestamps until they can be corrected or intentionally excluded.

Consent, privacy, and retention

Personalization data should be designed with the same care as other customer data. Use pseudonymous identifiers where possible, send only fields required for the use case, and align collection with the store’s consent, privacy, deletion, and retention processes.

An agency should also define what happens when a shopper requests deletion or when a customer opts out of personalization. The WooCommerce integration, data store, and Amazon Personalize datasets should be included in that operational process. Do not assume that removing a WordPress user automatically removes every historical interaction already exported to another system.

A practical data checklist

Use a stable identifier for every recommended item.
Use a stable, privacy-conscious identifier for each known shopper.
Record timestamps in a format that can be converted reliably to Unix epoch time.
Separate views, carts, purchases, and other event types.
Choose whether the recommendation unit is a parent product or variation.
Include item metadata for categories, brands, prices, and new-product handling where useful.
Include user attributes only when they have a clear modeling or business purpose.
Remove test, bot, duplicate, invalid, and unauthorized records.
Validate that every interaction item exists in the catalog used for recommendations.
Document consent, retention, deletion, and identity-resolution behavior.

The first production dataset should be simple enough to audit. For many WooCommerce stores, a clean Interactions dataset with product metadata is a better starting point than an ambitious export of every customer and order field. Once the identifiers, event definitions, and data-quality checks are reliable, additional attributes can be tested against a measurable recommendation objective.

Table of contents :