Enables support for Tealium's Universal Data Hub (UDH) suite of products. When enabled, an HTTPS request will be sent directly to Tealium's servers for processing for each tracking call implemented in your app. This single HTTPS request can be used to power one or more of the following products simultaneously:
If you are not licensed for one of these products, you should disable the Tealium Collect service in your app, which can be done through the remote publish settings. For Swift, you will need to make sure the module is disabled, as it does not currently utilize the remote publish settings feature.
This feature may be used in conjunction with the Tag Management feature, but please ensure that you do not also have the Collect Tag set up through Tealium iQ, as this will lead to double-counting (1 hit from the native Collect service, and one from the Tealium iQ Collect Tag).
If you are already using Tealium iQ in your app, then using the Collect Tag offers some advantages over the native Collect module. The main benefit is that you have the ability to manipulate data using Extensions in Tealium iQ before the data is transmitted to the UDH. You can also use load rules to filter which events are sent to the UDH. If you are using the native Collect module, all events are sent to the UDH, and there are no options to manipulate the data, apart from by using Enrichments in the UDH.
If, however, you do not need to use Tealium iQ for tag delivery (e.g. you are using EventStream to deliver your data to 3rd party tag vendors), then the Collect module offers some advantages; exclusively using the Collect module and disabling Tag Management will result in fewer HTTP(s) requests being made from the app, since instead of sending data to multiple vendors directly from the device, only a single request is sent to Tealium per tracking call implemented in the app. This may help to reduce battery and data consumption, resulting in a better experience for your end-users.
Remote Commands (also known as TagBridge/Dynamic Triggers) provide the ability to trigger native code blocks from within the Tealium iQ non-rendered web view. For this reason, they can only be used if you have implemented/enabled the Tag Management feature/module in your app. Only remote commands that have been explicitly enabled will be able to run (there is no way for Tealium iQ to execute arbitrary code on the device).
This feature is primarily used for cases where data held inside the non-rendered web view needs to be passed back to the native code for further processing (e.g. you may need to access a value stored in a cookie or localStorage inside the Tealium iQ web view). Another use for this feature would be to personalise parts of your app, for example, you may wish to trigger a survey in the app once the user has been through a particular journey, such as making a purchase.
The flow for this particular example would be:
There are many other potential uses for Remote Commands, including remote configuration of 3rd party SDKs in your app. Speak to your account manager/deployment engineer if you have any questions.
Each platform has its own Lifecycle module, which enables automatic tracking of app lifeycle events (launch, wake, sleep) and associated data.
Mobile Publish Settings allow you to remotely control some aspects of the Tealium SDKs' functionality, without needing to deploy an app update. You can read full details in this article: https://community.tealiumiq.com/t5/Mobile-Libraries/Mobile-Publish-Settings/ta-p/13633
In addition to passing specific data layer variables with each tracking call, some variables need to remain consistent throughout your app's lifecycle. Instead of manually sending these variables with every request, you can use one of our storage APIs to automatically add the data to each request.
Items added to volatile storage are kept until the app is cleared from memory (i.e. force-closed/restarted). From the point you set a volatile data variable, it will be sent on every subsequent request automatically until it is cleared. Volatile data is not stored on disk, so will not contribute to the app's disk usage footprint on the device.
Items added to persistent storage are kept for the lifetime of the app (until the user uninstalls the app or manually clears the app's data), or until you clear the variable via the API. Like volatile variables, persistent variables are sent with every tracking call until they are cleared. An example of a variable you might like to keep in persistent storage is a visitor id, such as a user's email address.