Track Storefront Next Activity with Analytics

Monitor your storefront activity by collecting analytics data. Storefront Next provides a built-in solution for analytics, which is integrated with Einstein and Active Data. Implement analytics by using the analytics hook and events. Also, you can create integrations with other analytics systems.

Storefront Next pages invoke the analytics hook to trigger the creation of AnalyticsEvent objects.

For example, on the product details page, you see this script.

The trackViewProduct method creates a ViewProduct AnalyticsEvent that’s passed into an internal track function. This track function sends the AnalyticsEvent to registered EngagementAdapters that handle the process of sending the event through to a target analytics system.

No analytics events are sent until a shopper grants consent, which helps you avoid tracking that violates privacy regulations such as the General Data Protection Regulation (GDPR).

Storefront Next supports a two-layer consent model:

• Binary consent (default): A consent banner asks the shopper to accept or decline all tracking. This choice is persisted through the SLAS token (stored in the dw_dnt cookie). This is the default behavior.
• Per-adapter consent categories: Each engagement adapter can declare the consent category it requires (for example, analytics or marketing). An event reaches an adapter only if the shopper has granted that category, which supports GDPR-style, category-level consent.

When a shopper accepts the consent banner, Storefront Next builds a set of consent preferences (the granted categories) and forwards them to every adapter. Each adapter checks those preferences before sending an event. Until the shopper accepts, the consent preferences are undefined and no events are sent.

Enable tracking consent and declare the categories your storefront supports in config.server.ts. The consentCategories array defines which categories are granted when a shopper accepts the consent banner.

The default configuration defines four categories that align with common consent-management conventions:

• necessary: Essential cookies and tracking required for site functionality
• analytics: Usage analytics and performance measurement
• marketing: Advertising, retargeting, and campaign tracking
• personalization: Product recommendations and personalized experiences

Category values are arbitrary strings, so you can define whatever categories match your consent-management platform (for example, OneTrust, Cookiebot, or Usercentrics). There’s no hard-coded set.

To send events to an adapter only when the shopper has granted a specific category, set the consentCategory field on that adapter in config.server.ts.

This table shows when an adapter that declares a consentCategory fires.

If you omit consentCategory, the adapter doesn’t apply its own category check and fires for every event that reaches the adapter. No events flow until the shopper accepts the consent banner, so omitting consentCategory doesn’t bypass consent. This is useful for adapters that manage consent internally, such as a Google Tag Manager adapter that uses Google Consent Mode.

By default, neither the Einstein nor the Active Data adapter sets a consentCategory, so after the shopper accepts consent, both adapters fire for all event types.

To receive Einstein Activities events, set up Einstein Activities.

1. Set up Einstein by using the Einstein Configurator. See Einstein Activities in the B2C Commerce Einstein API Guide.

2. In config.server.ts, update the Einstein configuration. In the einsteinId field, specify the ID of the API client you created in the Einstein Configurator.

To receive Active Data events, set up Active Data in Business Manager. Active Data in Storefront Next supports product views on the Product Detail Page (PDP) and product impressions on a Product List Page (PLP) or recommendation.

• Configure Active Data in Business Manager by following the steps in the next sections.

Open a support case asking Salesforce Customer Support to enable data collection.

1. Log into Business Manager.
2. Click App Launcher and then select Administration > Sites > Manage Sites.
3. Confirm that the status is Online for the sites for which you want to track metrics. Active Data is collected only for live (online) sites.

1. Log into Business Manager.
2. Click App Launcher and then select Merchant Tools > Site Preferences > Privacy.
3. Confirm that Tracking (Default for New Storefront Session) is set to Enabled. Active data events are sent from Storefront Next to the __Analytics-Start controller in B2C Commerce. One way you can confirm that active data tracking is working is by viewing network requests and checking if the request to __Analytics-Start is responding with an HTTP 200 code.

1. In config.server.ts, enter the Active Data host. In the host field, specify the URL of the B2C Commerce instance.

2. If you have a hybrid storefront, specify the site UUID in the siteUUID field. In SFRA, get the site UUID from the value that comes after dwac_ in the cookie in SFRA. This cookie appears only when a user is logged into SFRA.

   If siteUUID isn’t set for the hybrid storefront, all Active Data events are treated as having come from anonymous guest users. In pure Storefront Next and PWA Kit Composable implementations, there is no dwac_ cookie, so all events are treated as coming from anonymous users.

Storefront Next provides these built-in event types.

• ViewPageEvent
• ViewProductEvent
• ViewSearchEvent
• ViewCategoryEvent
• ViewRecommenderEvent
• ClickProductInCategoryEvent
• ClickProductInSearchEvent
• ClickProductInRecommenderEvent
• CartItemAddEvent
• CheckoutStartEvent
• CheckoutStepEvent

Each event type defines different fields corresponding to the data required by that specific event.

All types extend BaseEvent, which provides the customer fields that are shared across all events, such as usid or customerId. All events also define a string eventType field that EngagementAdapters use during event handling. All types are included as part of the union type AnalyticsEvent.

For example, a ViewProductEvent Analytics event triggers both an Einstein ViewEvent and an Active Data product view with the default setup. The ViewSearchEvent and ViewCategoryEvent Analytics events similarly send the ViewSearch and ViewCategory Einstein events alongside Active Data product impressions.

Storefront Next uses typescript module augmentation to extend existing events and add new event types. To add new event types, use the AnalyticsEventExtensions interface. Types added to AnalyticsEventExtensions are included in the AnalyticsEvent union type.

For example, let’s add a new CartItemRemove event that triggers when a shopper removes items from the basket.

1. In a TypeScript declaration file, define our new event type. The new event must extend BaseEvent and define the eventType field. We also include a cartItems field for the items we’re removing from cart.

2. Update the analytics hook to support the new event.

The trackEvent function creates the CartItemRemove event from the event type, handles Do Not Track, and adds session information such as the usid to the event.

3. Update engagement adapters to handle the new event type.

The track function sends CartItemRemove events to all registered engagement adapters. Therefore, the adapters need to know if they must handle or ignore CartItemRemove events.

4. Configure Engagement adapters to handle or ignore an event in config.server.ts. To have the Einstein adapter process CartItemRemove while having the Active Data adapter ignore the event, make the following changes inside config.server.ts.

5. Next, update the existing adapters that process CartItemRemove. Each adapter handles the event differently. For example, if we want to send CartItemRemove to a non-existent Einstein activity called removeFromCart, make this change.

6. Update the pages that fire the new event.

Now, our CartItemRemove event is ready to be used. The next steps are to update the components that handle cart item removal to invoke the analytics hook and test.

Engagement Adapters define how an event are sent to an analytics system. Storefront Next includes adapters for Einstein Activities and Active Data.

Engagement adapters follow the EngagementAdapter interface:

The key method used by the analytics system is the sendEvent function. The internal track function invokes this method when an event is received. The sendEvent function takes an AnalyticsEvent and converts that event into a payload that can be sent to the target analytics system.

As a best practice, Storefront Next uses the Beacon API (navigator.sendBeacon) to send analytics events to target systems because it’s non-blocking.

Keep the following in mind when implementing your own EngagementAdapter.

• Use eventToggles to determine which events the adapter processes. This helps fine-tune the adapter to only handle the events the target analytics system supports.

• sendEvent has two main tasks. Consider implementing these tasks as separate functions that sendEvent invokes. These tasks are:

• Converting an AnalyticsEvent object into the appropriate payload for the target analytics system
• Sending the payload to the target system

• Register the EngagementAdapter so that it receives AnalyticsEvents from the internal track function. To register an EngagementAdapter, modify the src/adapters.index.ts file and invoke the addAdapter method.

As a best practice, adapters provide a function for creating the adapter so you’re more likely to see this script.

Einstein Activities Active Merchandising