In the wonderland of digital commerce Apps we need to integrate a lot of tracking partners for the sake of understanding the behavior, wishes and preferences of our users. Usually on the web we would use a Tag Management System (TMS) to easily deploy and manage our partners tags.
On the App it is slightly different given that there are not lot of choices for apps TMS and most tracking partners are rather based on SDK integrations.
The dark sides of SDK’s are that you don’t really know what the code within the SDK is, it increases the size of your applications and finally you have less control on the data you share through them.
This article aims to share how we manage and iterate on using a tracking solution to test a TMS like approach for the App. We choose Tealium for our test but other options like Segment would have been very similar.
Why using an app TMS?
As usual when dealing with e-commerce either on web or apps we have lots of partners for tracking, personalization, various analysis and testing new features. We need to find an efficient way of integrating them in our applications to allow the business to test new partners as easily as possible and ideally without having to deploy a new App version in stores.
The idea is to give the ability to send (simple) events without changing the app code to avoid deploying the app for every new partner.
When you must be included in a development roadmap to add a partner, you are competing with other projects and fighting to fit in every sprint free space. It creates latency for the business and might discourage you and them on the long term.
By using a TMS solution, it allows you to add as much destination events as you wish without affecting the app roadmap, as long as you are satisfied with the current data received within the TMS.
There is no magic if you need to grow the data pool sent by the app to the TMS you need to affect the app itself. But the good point is once, added it’s available for all of your partner connected to the TMS
The benefits you will have with such a TMS approach
So first it fastens your event additions or partner inclusions, but it also reduce the code related to events within the app, and so consequently minimizing the risk of bug and regressions.
The good point is also that it reduces the number of SDKs you onboard in your App. Well, if you already have developed an app, you know that partners will do everything when discussing with you to include their SDK.
Sometimes it’s justified because they bring real users features you don’t have to develop on your side, sometimes it’s not. Further, you might also know that adding an SDK, is equals to more “unknown” code in your App code base, more crash & bug risks that your cannot control.
And even sometimes, dependencies that’ll block you for a release or an OS version upgrade. If you use an SDK for tracking purpose only then it’s the opportunity to drop it. And if you have any other usage for it, it might just be an opportunity to challenge this SDK, because your partner may have an API available so let’s go light.
The user point of view
Now another advantage is that your dear users will also appreciate the change. Sure he might not really notice it during is app usage experience, but firing thousands of events at each session is both consuming the data and the batterie of the user.
And as an App developer you are for sure aware that phones do warn users about applications that ruins the batterie and send lot of data. And we can guess that with privacy pressure it will continue.
How does it work
Now how to make this work. Our current partner had the great idea to make his solution available through API’s. So that’s one less SDK to add first good point.
How it work well nothing more simple:
On the App Side
Build a GET url with the needed parameters and fire it on the events you want to track!
The end.
Event configuration on Tealium side
Now this is where the magic really happens. You’ve sent all your events from the App and your see them within the Tealium console. Now you need to pass the right data to your partners. There you have two options.
Option 1: The Clickodrome
Tealium opted for a very visual and intuitive solution with some partner. Basically, they call it the native integration it means that Tealium and these specific partners worked together to have an easy integration between the two parts.
The good point here is that someone from the marketing with a minimum technical skill (formatting an event with attributes) can manage and maintain the integration, allowing the IT teams to keep their focus where they have more value.
Option 2: The Webhook
Well, nothing really complicated here, but it’ll require a minimum technical skill on API calls and a partner API documentation to fulfill the integration. Which from one partner to another can range from relatively complex to simple? This is an interesting integration mode that allows for partner testing quite easily if the partner have some APIs.
It’s all about App Event structure
The main point is to be able to manage the different events and data that our partners need to receive, to think of them as a generic one that will be the source.
Fire once, shoot many
While you implement the TMS within your app you will want to remind that everything you will send is meant to be used by several partners.
Accordingly, you will try as much as possible to avoid “specifics”. For instance, a view event on one page should, or dare I say, “must be” the same for every partner. Also, to reduce back and forth, and allow the team working within Tealium to embrace all the power of a TMS, you want to make a complete tour of the required data.
Some could say: “Easy: Send everything”. Well, this is not really the GDPR and privacy way of doing things. So, you need to make this work by selecting and filtering the “really” required data.
GDPR compliance management is a key point. Since some data can be used for several purposes for ads, for personalization, for tracking etc. The TMS must receive and manage the user choices regarding her privacy.
Designing your events for a TMS
Well now that you know everything about this not-so-mysterious TMS, let’s talk about what we can do within the app to keep things simple over time.
First, you want to have fixed variable naming! If your product id is called product_id in your page list, but ProductId in the detail page, this is the beginning of a nightmare for data management!
In few months you’ll have ten ways of calling a product id, and an awful number of false bugs because a user won’t find the correct variable within the event. It will also potentially create disparities between Android and iOS.
What we suggest in our implementation is a list of fixed variables that can contain data. Shared between OS and obviously checked by the whole team within a review process when changes occur.
Limitations for specific partners settings
Everything has some downside! For instance, here, when a partner has specific custom data requirements, you’ll have to send these specific data from the App and affect the application code and therefore the roadmap to include them.
Currently we do not have a fully satisfying solution for such partners, but over time we might use internals Redoute ids, or anonymous ids to manage these cases. Many things remain to be built, and the future does not present only issues and bugs, but also improvement and this will be part of it.
Another downside is the SKAdNetwork included for iOS 14 and over. Currently some of our partners manage themselves this sdk, now if we decide to use these partners through a TMS, we must handle ourselves the attribution process with apple. This makes the TMS less easy to implement. Now of course this is only for advertising and acquisition partner.
| Pros | Cons |
|
|
In Conclusion
Despite the few limitations that we saw above, using a TMS within your app will save you some development time.
It will also allow you to have a centralised way of handling your hits.
Give more freedom and reduce the dependencies over release for each team and partner that require a tracking plan.
And move the tracking responsibility on the team that actually needs it!
Whether you start a new app, or already have one, this is a solution that’ll make your life easier.
Guilherme Filho 
Daniel Olival