Migration from the serverside v1 feature (platform 7 to platform X)
Severside v1 (aka SSv1) is the serverside tag management feature of the old platform (v7). It is now deprecated. In this section, we'll see how to migrate from a SSv1 setup to the new platform (aka SSv2)
Send data to serverside v2 (aka Platform X)
How to migrate from the old platform (v7) to the new platform (Platform X)
On the new platform (aka Platform X), everything is Source/Event/Destination. Sources (your website, app or server) collect your user actions by sending events. These events are sent to the platform servers and are then enriched, normalized and translated in each tool (Destination) format, so that they can be sent to your chosen destinations. You can learn more in the Concepts section.
From a server, use our HTTP tracking API.
Your data has to be sent to a new url, following a new format.
From a mobile application, you can either use one of our SDK (Android, IOS, ...) or use our HTTP tracking API if you don't want to use a SDK.
Events are the new format of your data. As explain in the event documentation, common events have to be sent in the standard format (name and properties) to benefit from plug&play features.
For specific events, custom events name is possible. Nevertheless, please use standard properties in custom events, as far as possible, to benefit from automatic mapping, automatic QA, and plug&play features.
Standard event format can be found in our event reference documentation
Go through this example, based on the ssv1 format : purchase event example
How to migrate to the old platform sdk (Platform 7) to the new platform (Platform X)
To track mobile app on the new platform, you can either install our new SDK ( and ) or use our .
In the Sources Catalog, create your new Sources.
Sources > Overview > Add Source
At the last step of the Source setup, you will obtain a Source Key, required for the initialization methods of our SDK
Our SDK files have changed. You must replace the old ones. Get our latest versions :
Some names of our modules have also evolved, here are their correspondences :
TCSDK -> TCServerSide
TCPrivacy -> TCConsent
The way you initialize our SDK is now different, your old methods will not be recognized anymore.
You don't need container ID anymore, all is on the same site ID. Instead of a container ID you'll need a specific key to define the source.
You don't need to put any TCServerSide instance in your Consent implementation anymore.
You might need to use the TCUser class to forward relevant information about your users.
There’s a code example you can check here:
If your mobile app use our SDK modules only for Privacy your migration is done at this point.
If you want to benefit of all the advantages of tracking with server-side destinations, or if you were using server-side v1 containers to send data to your partners, please follow the next steps!
With the old platform, you were used to send a container call, with all the variables. It's not compatible anymore. Instead, you have to send events with properties.
Here’s a code example of how to execute an event:
The new platform is using standard properties, so we recommend to upgrade your mobile application’s data layer by using our standard properties as much as possible
A Quality Assurance Test & validation is strongly recommended before launch in production ! Here’s a few references to help you on this point:
Testing => tips how to test
Common errors list
Your migration is done !
Maybe you have some specific needs ? Don’t forget to check the following FAQ
It’s a good practice ! We strongly recommend to have the same data layer for web & mobile application Main benefit: setup only 1 destination for both sources! Your destination’s setup will be recognized by web and mobile
Our SDK doesn’t collect automatically the IDFA/AAID anymore, but we offer a simple method to track this information:
Yes it’s possible !
Yes it’s possible ! If you need to send more data then just the required properties, simply use the "additional property" method, as follow:
Yes it’s possible !
Persisting variable’s definition: it’s a key/value which will remains the same as long as the app is opened (example : Google account ID)
It’s not required ! Your current json is still valid for our new SDK
It’s not required ! Your current setup is still valid for our new SDK
Here are an example of a serverside v1 hit : Booking Confirmation :
It should be sent to the serverside v2 in this format (adding maximum of recommanded properties) :
Cookies should be sent through thedevice.cookieparameter.
For example, if you use Facebook CAPI, you'll have to send _fbp and _fbc cookies
RGPD: User consents have to be sent in each events, inside the user.consent_categories parameter
Android : iOS :
You can have a look on all events code's examples For more information about events specificity, please refer to of our documentation.
For technical documentation about how integrating events, please visit to our GitHub:
You can now use our platform to and send data to your partners
Debugging => list of methods to display logs in your app
ServerSideInstance.addAdvertisingIDs());
[ServerSideInstance addAdvertisingIDs];
For further information, have a look to this part of our documentation:
If you need to set a persistent variable, please refer to this doc:
Other standard recommanded parameters should be added to the purchase event, following the
