Consent Tracking in SFRA
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:
trueindicates that tracking is enabled;
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.
<span> tag is created by the template
This template is rendered by the
ConsentTracking-Check route in the
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
It checks the value of the session's
consent property. Regardless if the value of the property is either
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
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
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
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
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