"Do Not Track" mechanism

Privacy protection regulations may require that you let the visitors on your website decide that they don’t want their activity history to be tracked and associated with their browser or device and let the mobile app users decide that they don’t want their activity history to be tracked in the application.

In Synerise, you can do this by:

creating a cookie that tells our SDK to stop tracking visitor activity, but you can still serve campaign content to those visitors (variant of the do not track feature for web SDK)
enabling the do not track method that tells our SDK to stop tracking mobile app user activity (variant of the do not track feature for mobile SDK).

Main assumptions

Web

If the do-not-track cookie exists:

With each page refresh, the Web SDK generates a random UUID.
This UUID isn’t saved in the database or associated with a profile. It’s only need for Dynamic Content requests.

Important: Don’t use the random UUID as a profile identifier in API requests!
No Synerise cookies are created.
Dynamic Content is only displayed if:
- the audience is set to “everyone”
- Jinjava inserts in the content don’t require a profile context
Only Dynamic Content with the audience set to “everyone” is displayed.
Using SDK methods doesn’t generate any events.
The SDK doesn’t automatically generate any tracking events (such as page.visit).
If the cookie is deleted, tracking is re-enabled after the page is refreshed. In such cases, you should make it possible for a visitor to opt-out again.

Mobile SDK

Tracking is disabled by running the do not track method.

If the do not track method is executed, then Synerise mobile SDK works in the following way:

A new random UUID will be generated for the token stored in the mobile app, however a proile isn’t created. This may affect the API implementation. In such case, review what API endpoint they use and adjust accordingly (some endpoints may create profile in Synerise, in such case the call should not be performed).
IP and uuid will be available on our access log.
Using SDK methods doesn’t generate any events.
The SDK doesn’t track any user activity in a mobile app, so the events won’t be generated (such as screen.view).
If the tracking is re-enabled after the application is reopened, you should make it possible for a mobile app user to opt-out again.

Impact of Do Not Track on features

Feature	Do Not Track enabled
Client login methods
Web push notifications (web) /Push notifications (mobile)	If the token exists, it will be removed from the profile, which prevents sending notifications;
Dynamic content (web) / In-app messages (mobile)	but: - Capping won’t work, - ABx testing or control group assignment won’t work, - Global control group behavior for dynamic content: doesn’t work; a user with enabled do not track option will be displayed dynamic content only if the content is set to Everyone and/or the Include first visitors setting is enabled - Global control group behavior for in-app messages: global control group won’t work for users with enabled do not track option - Interactions with dynamic content and in-app messages are not tracked, - Jinjava is rendered as for an anonymous profile
Documents and screen views	but: - Activities are not tracked (such as generating `screen.view` events), - Jinjava is rendered as for anonymous profile
AI Search	but: Search results will be returned as for an anonymous profile
Jinjava: catalogs
Jinjava: aggregates and expressions
Jinjava: vouchers	but: - `Assign=false` flag does not work, - Event of assigning voucher will not be generated
Jinjava: promotions
Jinjava: recommendations	but: - Recommendations implemented using Jinjava are rendered as for an anonymous profile, - Interactions with recommendations are not tracked.

Enabling Do Not Track

Web

WARNING: Before enabling the feature, make sure you know the main assumptions and impact on the features.

Decide the cookie name:
- If you want to use the default _snrs_dnt cookie, go to step 2.
- If you want to use a different cookie, add its name to the SDK initialization script, in the dntCookieName variable:
```
SR.init({
    trackerKey: "xxxxxxx",
    dntCookieName: "your_cookie_name"
});
    
```
When a visitor rejects the category of cookies where you include Synerise:
1. Create the do-not-track cookie with a value of 1 or true
2. Force refreshing the page to enable Do Not Track.

Result:
After the page refreshes, Synerise JS SDK deletes all its cookies and local storage.

Mobile

The Do Not Track feature can be enabled in the following ways:

By defining the following parameter to true in the settings of the application (this can be defined at any moment):

Parameter Type Default

Synerise.settings.sdk.setDoNotTrack(true) Boolean false

Parameter Type Default

Synerise.settings.sdk.doNotTrack Bool false
By applying the following method during the initialization of the application; this method lets you set the initial value of the Do Not Track feature to any value (true or false);
- This is a one-time setting that is only applied during the first initialization; not each time the application starts.
- If you need to change this setting later, you can do so by adjusting the parameter mentioned in the previous point.
- In case the parameter has already been set to false (as described in the previous point), any modifications made using the method during initialization will not impact the Do Not Track status.
.initialDoNotTrack(true) in the application Builder
let config = InitializationConfig() config.initialDoNotTrack = true Synerise.initialize(apiKey: clientApiKey, baseUrl: syneriseBaseURL, config: config)