Tracking Product Views for Personalization

Product-view events are the foundation of useful personalization in a WooCommerce store. A product view indicates current intent, but it is only valuable to Amazon Personalize when the event is recorded with a consistent user or session identity and an itemId that matches the item identifier in the Amazon Personalize dataset.

What a product-view event should contain

For Amazon Personalize, a view is commonly sent as a real-time event with an event type such as View. The important fields are:

• userId: A stable customer identifier. For signed-in shoppers, this can be a non-sensitive internal WooCommerce customer ID.
• sessionId: A short-lived identifier for the browsing session. This is especially important for guest shoppers.
• itemId: The identifier of the viewed product or variation. It must use the same value as the item ID in the Amazon Personalize Items dataset.
• eventType: A value such as View that is consistent across the event schema and model training data.
• sentAt: The event timestamp, when supplied by the integration.
• properties: Optional context such as product category, device type, page type, or traffic source.

Do not send a display SKU in one integration and a WooCommerce post ID in another. Choose one canonical identifier and apply it when exporting the catalog, rendering recommendations, and recording events.

Creating stable identities in WooCommerce

Logged-in shoppers should receive a stable pseudonymous ID. A WooCommerce customer ID or an internal UUID is generally preferable to an email address because it avoids sending directly identifying data to the personalization service.

Guest traffic requires a first-party session identifier. Generate it when the shopper first visits the site and retain it in a consent-approved cookie or server-side session. When the shopper signs in, your integration can associate subsequent events with the customer identity. Decide how identity merging will work before enabling personalization; changing identifiers later can make historical interactions difficult to interpret.

A practical identity policy might look like this:

1. Use a pseudonymous customer ID for authenticated users.
2. Use a random UUID for guests rather than an IP address or email address.
3. Send the same session ID for all product views in one browsing session.
4. Do not create a new identity on every page load.
5. Document the identity mapping so that catalog exports, event tracking, and recommendation requests use the same rules.

Capture views at the product-page layer

WooCommerce agencies commonly add the product identifier to the product-page data layer and send the event after the page has loaded. The identifier should be generated from the same canonical product mapping used by the Amazon Personalize catalog.

<script>
window.personalizationContext = {
  itemId: "product-12345",
  userId: "customer-67890",
  sessionId: "session-uuid"
};

window.addEventListener("load", function () {
  const context = window.personalizationContext;

  if (!context.itemId || !context.sessionId) {
    return;
  }

  fetch("/wp-json/store-personalization/v1/events", {
    method: "POST",
    credentials: "same-origin",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      eventType: "View",
      itemId: context.itemId,
      userId: context.userId || null,
      sessionId: context.sessionId,
      sentAt: new Date().toISOString()
    })
  });
});
</script>

The browser should normally call a WordPress endpoint owned by the site rather than exposing AWS credentials. The endpoint can validate the request, apply consent rules, resolve the user identity, and forward the event to Amazon Personalize using an IAM role or server-side AWS credentials.

Forwarding the event to Amazon Personalize

The server-side integration uses the Amazon Personalize Events API and the event tracker associated with the event-interactions dataset group. The request contains the tracking ID, identity values, and an event list. The event properties are represented as a JSON string inside the request.

const input = {
  trackingId: process.env.PERSONALIZE_TRACKING_ID,
  userId: "customer-67890",
  sessionId: "session-uuid",
  eventList: [
    {
      eventType: "View",
      itemId: "product-12345",
      sentAt: new Date(),
      properties: JSON.stringify({
        pageType: "product",
        productType: "simple"
      })
    }
  ]
};

await personalizeEventsClient.send(new PutEventsCommand(input));

Use the AWS SDK on the server and grant only the permissions required by the integration, such as permission to call personalize:PutEvents for the relevant event tracker. Keep the tracking ID in configuration rather than embedding it in editable page content.

Preventing duplicate and low-quality views

A product page can be rendered several times by AJAX navigation, caching layers, variation selectors, or frontend frameworks. Decide what a view means for the business and enforce that definition consistently.

• Send one view when the product detail page becomes meaningfully visible, not once for every component re-render.
• Use a short client-side suppression window if navigation can trigger duplicate events.
• Do not count recommendation impressions as product views unless the shopper actually visits the product page. Record recommendation impressions as a separate event type if they are useful.
• Do not send an event when the product ID is missing, invalid, or not present in the Amazon Personalize catalog.
• Keep bot traffic, health checks, and internal staff browsing out of the event stream where possible.
• Queue transient failures for retry, but do not retry indefinitely or create duplicate bursts after an outage.

For high-traffic stores, a queue or event gateway can protect the WordPress application from waiting on an external API call. The shopper should not experience a slower product page because an analytics or personalization request is delayed.

Handling consent and privacy

Product views may be personal data when they can be linked to an identifiable shopper or used to infer interests. Integrate the event call with the store’s consent-management platform. Before consent is granted, do not create a personalization identity or send the event unless the site’s documented legal basis and configuration allow it.

Use pseudonymous IDs, avoid putting email addresses in userId, and do not place order notes, search terms containing personal data, or arbitrary customer metadata in event properties. Provide a documented deletion and retention process that covers the WooCommerce identity mapping, queued events, and Amazon Personalize data.

Variation products and canonical item IDs

Variation tracking needs an explicit business rule. If recommendations are made at the parent-product level, send the parent product’s canonical ID for every variation page. If color, size, or other variations are separate recommendation items, send the variation ID and export each variation as an item.

Do not mix these approaches. A catalog containing parent IDs cannot be trained reliably with view events that use variation IDs that do not exist in the Items dataset. If the site switches from parent-level to variation-level tracking, update the catalog export, event mapping, recommendation display logic, and validation tests together.

Testing the integration

Before sending production traffic, test the complete path from a WooCommerce product page to the Amazon Personalize event tracker:

1. Open a product page as a guest and confirm that one approved session ID is created.
2. Open the same page again and verify that the event uses the expected item ID and does not duplicate unexpectedly.
3. Sign in and confirm that authenticated events use the documented pseudonymous customer ID.
4. Inspect the WordPress endpoint logs without recording sensitive request data.
5. Verify that the server sends eventType: View, a valid itemId, and the correct tracking ID.
6. Test products, variations, discontinued items, cached pages, AJAX navigation, and consent changes.
7. Compare event counts with page-view telemetry while allowing for consent rates, bots, blocked requests, and deliberate deduplication.

Operational monitoring should track rejected events, missing item IDs, unknown catalog IDs, API throttling, queue age, and the percentage of product pages that produce a valid view event. These checks catch integration regressions before they reduce the quality of recommendations.