Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
There are several ways how to get your data into Commanders Act platform.
Commanders Act also offers connectors to third party tools, visit the source catalog to explore the full list.
It is possible to import data to Commanders Act through regular automated file imports (csv), such as:
Custom storage universe
You can send your specific data through our Data JSON APIs.
Sending an event from a web container is as easy as adding a tag : the OneTag.
If you haven’t already, you should read the platform explanations!
From your web container, add a tag from the tag library, searching Commanders Act OneTag
You will find 2 tags to choose from :
The OneTag - Builder: it will guide you without having to write code
The OneTag - Custom: for those who prefer to manually write complex event data using javascript
If you choose the builder version of the tag, you can go to the next step, you just have to follow the instructions.
If you choose the custom one, here is how it works:
The cact('trigger')
function is what allows you to record any actions your users perform, along with any properties that describe the action.
Each action is known as an event.
Here’s the format of a typical trigger
call:
Each event has a name, like page_view, and properties. For example, a page_view event might have properties like page_name
or page_type
.
Here is an example
config
and callback
parameters are optional
You can implement two types of events:
Recommended standard events are events that you implement yourself, but that have Commanders Act-predefined names and parameters.
We strongly recommend the use of standard events, as it allows you to benefit from plug&play features, automatic-mapping, automatic-QA-alerting, etc. but also future features/reporting.
Custom events are events that you name and implement yourself. Before implementing a custom event, check that there is not a recommended event that already provides what you need. With custom events, best practice is to use recommended properties that you can find in our event references (ex: revenue, currency, ...) beside your custom properties.
Inside a standard events, you can add custom properties beside standard properties
Inside custom events, it is recommanded to put standard properties. Of course, custom properties can also be added
If you use Commanders Act CMP, the user consent is automatically retrieved and put inside all events in the user
property.
If you use another CMP, you will have to add manually a property consent_categories
inside a user
property, following this example :
consent_categories
is the user's consents list and is mandatory to manage consents in each destinations (aka server-side consent) See how work server-side consent management.
There are 3 default parameters that you can override if needed:
collectionDomain
: if not set, the default value correspond to your first party domain (if you setup one) or collect.commander1.com
sourceKey
: if not set, the default value is the source key of the currently running web container.
siteId
: if not set, the default value is the site id of the last web container loaded (tC.id_site
)
To override a parameter, you can add a config object to your cact('trigger') function (4th parameter) like this:
You can also set globally these parameters for all triggered events with the cact('config')
method. See the Javascript API documentation for more information.
After configuring your OneTag (at lease one event triggered) and deploying your web container, you can refer to the Event Inspector tab for the Source to verify that it generates the expected event data.
The Source Event Inspector serves as a live tool that aids in validating the arrival of events originating from your website, mobile application, or servers to your Commanders Act Source. This enables you to promptly examine the reception of calls by your source and troubleshoot without the need to await data processing.
Once you have verified the inflow of data from your fresh source, it's the perfect moment to create your first destination:
Navigate to your Commanders Act platform, click on Destinations-> Overview, and select 'Add Destination' to list all the available destinations in the catalog.
Look for the destination of your preference. For example Facebook Conversion API.
Click on the card representing the destination to obtain more information about it.
Initiate the configuration by clicking on 'Configure'
Choose the source that you had previously setup, or select all sources.
In the settings screen, name your destination, choose an environment and enter required information.
Then in the filter tab, manage the user consent by selecting the appropriate consent categories for that destination (for example "Advertising" category for Facebook CAPI)
Save and go checking that everything is going well in the Event Delivery and/or Event Inspector tab, or directly in your tool.
When you add a destination (aka serverside tag), you manage the user consent by selecting the appropriate consent categories for that destination (for example "Advertising" category for Facebook CAPI). As a result, since each event entering the platform contains information about the user's consent, the event will only be sent to the destination if there is a match between the categories consented by the user and the consent's category associated to the destination.
How to migrate from the old platform (v7) to the new platform (Platform X)
Migration from the serverside v1 feature (platform 7 to platform X)
(aka Platform X)
On the new platform (aka Platform X), everything is Source/Event/Destination. (your website, app or server) collect your user actions by sending . These events are sent to the platform servers and are then enriched, normalized and translated in each tool () format, so that they can be sent to your chosen destinations. You can learn more in the section.
From a server, use our .
Your data has to be sent to a , following a .
From a mobile application, you can either use one of our SDK (, , ...) or use our if you don't want to use a SDK.
Events are the new format of your data. As explain in the , common events have to be sent in the standard format (name and properties) to benefit from plug&play features.
Standard event format can be found in our
Go through this based on the ssv1 format :
Web container (OneTag)
You can use the OneTag to send events via our tag manager system.
Javascript SDK
You can use the Javascript SDK to track events directly from your website code/CMS/TMS.
Google Tag Manager
If you are using GTM client-side container, you can use our serverside platform by using the Commanders Act GTM template
Mobile SDKs
The Mobile SDKs are the best way to simplify tracking in your iOS/Android apps.
Rest API
If you need to build your custom solution, have a look to the http tracking API.
How to migrate to the old platform sdk (Platform 7) to the new platform (Platform X)
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.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
To track mobile app on the new platform, you can either install our new SDK ( and ) or use our .
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