Consent Tracking in SFRA | SFRA Features and Components | B2C Commerce Storefront Reference Architecture

You can implement consent tracking on a storefront based on SFRA. Merchants can track personal information about their shoppers to improve the shopping experience. The merchant can collect and honor shoppers’ consent preferences when they are using the site.

The following example shows one way to implement consent tracking on a storefront adapted from SFRA and is provided for informational purposes only. As always, merchants can consult their own legal department or advisors to review and consent management process.

The implementation uses:

A content asset for displaying a consent request message to the shopper
The site-specific preference Tracking to disable tracking by default
A session-specific flag to allow tracking if the shopper grants consent

To display a consent message to the shopper, a content asset whose internal ID is tracking_hint is used. You can replace the placeholder text in the content asset with your own message.

The Tracking site preference determines the default tracking behavior. When set to Opt-in, personal information is not tracked by default for all shoppers visiting the site; when not set to Opt-in, personal information is tracked.

To set this preference, select Merchant Tools > site > Site Preferences > Privacy.

The example assumes the Tracking preference is set to Opt-In.

The example presents a consent request message to the shopper, who can choose to allow tracking. If the shopper allows tracking, it is enabled during the shopper’s session. For more information, see Browser-Based Local Data Storage.

To enable tracking on a session:

dw.system.Session.setTrackingAllowed(boolean) ― If the boolean value is true, tracking is enabled for the current session; if false, tracking is disabled.

To check the current value of the session's tracking flag:

dw.system.Session.isTrackingAllowed() ― true indicates that tracking is enabled; false, disabled.

The sample implementation adds a <span> tag to every page in the storefront. The <span> tag stores information about the shopper’s consent choices and makes the information available to client-side code running in the browser. If the shopper has not yet given consent, the client-side code inspects the <span> tag and displays a Tracking Consent window.

The <span> tag is created by the template app_storefront_base/cartridge/templates/default/common/consent.isml.

This template is rendered by the ConsentTracking-Check route in the app_storefront_base/cartridge/controllers/ConsentTracking.js controller.

This route is called every time a storefront page is rendered. In the route, the middleware step consentTracking.consent is invoked before the consent.isml template is rendered.

This middleware step is implemented in the server-side script app_storefront_base/cartridge/scripts/middleware/consentTracking.js.

It checks the value of the session's consent property. Regardless if the value of the property is either true or false, it calls the setTrackingAllowed() method on the session to record the shopper’s choice.

It then adds the value of the consent property to the response's view data, storing it in the tracking_consent property. The tracking_consent property is made available to the consent.isml template via the pdict property.

The first time this code is executed in a session, the value of the session's consent property is null, so the tracking_consent property is also null. Because the value of the tracking_consent property is null, the first line in the consent.isml template:

Outputs the following HTML:

In this output, the consented attribute value is absent, and its absence indicates to the client-side code that the shopper has not yet consented to tracking. The absence of this attribute causes the client-side code to display the Tracking Consent window, prompting the shopper to grant or deny consent.

After the shopper grants or denies consent, subsequent invocations of the consentTracking.consent middleware step set the tracking_consent property to a non-null value. As a consequence, the resulting HTML output looks like this code snippet:

In this output, the consented attribute value is present, which indicates to the client-side code that the shopper has either granted or denied access to tracking. Whichever choice the shopper made, it is no longer necessary to display the Tracking Consent window.

Every time the consent.isml template is rendered, the consentApi property is passed into the template via the pdict property. The value of the consentApi property is the result of the following call:

The call checks if the session has a setTrackingAllowed property. If it does, this call resolves to true; otherwise, false. This call always evaluates to true for Salesforce B2C Commerce version 18.4 and later.

The client-side script, app_storefront_base/cartridge/client/default/js/components/consentTracking.js, inspects the <span> tag created by the consent.isml template.

This script constructs a section of HTML, stores it in the variable htmlString, and appends it to the <body> element of the DOM. The script then performs an Ajax call to get the value of the tracking_hint content asset. If the call is successful, the script inserts the value of the content asset into the <div> tag whose class attribute is modal-body. If the call fails, the script removes the entire section of appended HTML from the DOM.

The script then creates an event listener on both <button> elements in the appended HTML. If the shopper clicks either button in the Tracking Consent window, the script makes a second Ajax call, either enabling or disabling tracking on the session. The script then removes the Tracking Consent window from the DOM.

Lastly, this script exports a function whose purpose is to conditionally call the showConsentModal() function. The exported function is invoked in two situations: after each storefront page is fully loaded in the browser window, and when the shopper clicks Consent to Track in the Edit Profile form on the My Account page. For more information, see the app_storefront_base/cartridge/templates/default/account/editProfileForm.isml template.