Migrate Tracking SDK v1 -> v2
This section is aimed to touch on the most important topics related to migrating from our old tracking SDK to the new SDK. If there are any questions/uncertainties in the process of migration, please reach out to the CrossEngage support.
Exchange the HTML snippet loading the tracking SDK with our tracking template or with the updated HTML snippet visible in the System Setup section of your CrossEngage instance and apply the same trigger logic as previously used.
Please read the setup section of our documentation for information around using the GTM-Template as well as further information on additional options and configurations.
The new Tracking SDK opts any user out from tracking by default. This means that no user tracking will occur until the configuration
ce({trackingOptIn: true}); has been set.Formats and payloads of the tracking data has not changed. Only the API to provide these is slightly different.
Please make sure to visit all your tags triggering updates to CrossEngage and change the tags according to the documentation below.
Because identifying and updating are now separated, you might need to split a previous
analytics.identify where both was done in one API call. In that case, just send the update with the attributes after the identify.Tracking SDK v1 (Legacy) | Tracking SDK v2 |
|---|---|
Viewed Page tracking event analytics.page(); | Viewed Page tracking event ce('track', 'Viewed Page'); |
Any tracking event (default or custom) analytics.track('Added Product', {properties}); | Any tracking event (default or custom) ce('track', 'Added Product', {properties}); |
Identify a user by externalId analytics.identify('123-456'); | Identify a user by externalId ce('identify', '123-456'); |
Setting or updating user attributes analytics.identify({ name: 'Peter Smith', age: 59, city: 'Berlin' }); | Setting or updating user attributes ce('update', { name: 'Peter Smith', age: 59, city: 'Berlin' }); |
You might have used a global additionalOptions variable to make sure that certain properties always get added to the event payload of every tracking event.
In the new tracking SDK this functionality can be recreated by configuring it with globalEventProperties(see Configuration & Config Commands).
In the new tracking SDK this configuration is readable and can be set and updated at any time.
All properties within globalEventProperties will get added to the properties property of any track, identify or update event call.
When migrating this to the new SDK, make sure your additional properties are nested in the correct and desired way as they were before.
To provide a safer and more future proof way to maintain cookies and other forms of persistent storage, we strongly recommend to never read or write any cookies or other CrossEngage related storage values directly.
Instead the xngGlobalUserId and xngSessionId can be read and set as part of the configuration (see Configuration & Config Commands) if needed.
We have also changed and update various cookie names and references. Old cookies will be converted and deleted when the new tracking SDK detects them.
Tracking SDK v1 (Legacy) | Tracking SDK v2 |
|---|---|
xng.gid | ce.guid |
xng.sid | ce.sid |
xng.tracking-opt-out | ce.tracking-opt-in |
The old tracking library provided multiple methods to set the tracking optIn/OptOut status, like
xng.setTrackingOptOut() etc. and other methods to check the opt out status.
To ensure user privacy is handled correctly, the new tracking SDK will opt out from tracking by default and tracking opt in must be enabled via the configuration to enable tracking like this:
ce({trackingOptIn: true});
As the tracking optIn status is now a configuration, it can be set and read as described in Configuration.
Last modified 6mo ago