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 (Android and iOS) or use our HTTP tracking API.
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 :
Android : https://github.com/CommandersAct/AndroidV5#latest-available-versions iOS : https://github.com/CommandersAct/iOSV5#latest-available-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:
https://github.com/CommandersAct/AndroidV5/tree/master/TCServerSide#example https://github.com/CommandersAct/iosV5/tree/master/TCServerSide#example
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:
For technical documentation about how integrating events, please visit to our GitHub: https://github.com/CommandersAct/iOSV5/tree/master/TCServerSide#executing-events https://github.com/CommandersAct/AndroidV5/tree/master/TCServerSide#executing-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
You can now use our platform to create new destinations and send data to your partners
A Quality Assurance Test & validation is strongly recommended before launch in production ! Here’s a few references to help you on this point:
Debugging => list of methods to display logs in your app https://github.com/CommandersAct/AndroidV5/tree/master/TCServerSide#debugging https://github.com/CommandersAct/iosV5/tree/master/TCServerSide#debugging
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:
Android ServerSideInstance.addAdvertisingIDs());
iOS [ServerSideInstance addAdvertisingIDs];
Yes it’s possible !
For further information, have a look to this part of our documentation: https://github.com/CommandersAct/AndroidV5/tree/master/TCServerSide#custom-events https://github.com/CommandersAct/iosV5/tree/master/TCServerSide#custom-events
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 !
If you need to set a persistent variable, please refer to this doc: https://github.com/CommandersAct/AndroidV5/tree/master/TCServerSide#persisting-variableshttps://github.com/CommandersAct/iosV5/tree/master/TCServerSide#persisting-variables
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.cookie
parameter.
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
Other standard recommanded parameters should be added to the purchase event, following the