"Translate" utag.link (tealium tracking function) into _satellite.track (Adobe Launch tracking)

Question

we are migrating Tealium web analytics tracking into Adobe Launch.

Part of the website is tagged by utag.link method, e.g.

utag.link({
"item1" : "item1_value",    
"item2" : "item2_value",
"event" : "event_value"})

and we need to "translate" it into Adobe Launch syntax, to save developers time, e.g.

_satellite.track("event_value",{item1:"item1_value",item2:"item2_value"})

How would you approach it? Is it doable?

Many thanks Pavel

Answer 1

In general, agree with BNazaruk's answer/philosophy that the best way to future-proof your implementation is to create a generic data layer and broadcast it to custom javascript events. Virtually all modern tag managers have a way to subscribe to them, map to their equivalent of environment variables, event rules, etc.

Having said that, here is an overview of Adobe's current best practice for Adobe Experience Platform Data Collection (Launch), using the Adobe Client Data Layer Extension.

Once you install the extension, you change your utag calls, e.g.

utag.link({
    "item1" : "item1_value",    
    "item2" : "item2_value",
    "event" : "event_value"
})

to this:

window.adobeDataLayer = window.adobeDataLayer || [];
window.adobeDataLayer.push({
    "item1" : "item1_value",    
    "item2" : "item2_value",
    "event" : "event_value"
});

A few notes about this:

1. adobeDataLayer is the default array name the Launch extension will look for. You can change this to something else within the extension's config (though Adobe does not recommend this, because reasons).
2. You can keep the current payload structure you used for Tealium and work with that, though longer term, you should consider restructuring your data layer. Things get a little complicated when dealing with Tealium's data layer syntax/conventions vs. Launch. For example, if you have multiple comma delimited events in your event string (Tealium convention) vs. creating Event Rules in Launch (which expects a single event in the string). There are workarounds for this stuff (ask a separate question if you need help), but again, longer term best path would be to change the structure of the data layer to something more standard.

Then, within Launch, you can create Data Elements to map to a given data point passed in the adobeDataLayer.push call.

Meanwhile, you can make a Rule with an event that listens for the data pushed, based on various criteria. Common example is to listen for a Specific Event, which corresponds to the event value you pushed. For example:

And then in the Rule's Conditions and Actions, you can reference the Data Elements you made. For example, if you want to trigger the Rule if event equals "event_value" (above), AND if item2 equals "item2_value", you can add a Condition like this:

Another example, Action to set Adobe Analytics eVar1 to the value of item2:

Answer 2

Okay, this is a bit more complex than it looks. Technically, this answers your question completely: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-platform-launch/satellite-track-and-passing-related-information/m-p/271467

Hooowever! This will make the tracking only accessible by Launch/DTM. Other TMSes or even global env JS will end up relying on Launch if they need a piece of that data too. And imagine what happens when in five years you wanna migrate from Launch like you do now with Tealium? You will have to do the same needless thing. If your Tealium implementation had been implemented more carefully, you wouldn't need to waste your time on this migration now.

Therefore, I would suggest not using _satellite.track(). I would suggest using pure JS CustomEvents with payloads in details. Launch natively has triggers for native JS events and the ability to access their details through CJS: event.details. But even if I need to use that in GTM, I can deploy a simple event listener in GTM that will re-route all the wonderful CustomEvents into DL events and their payloads in neat DL vars.

Having this, you will never need to bother front-end devs when you need to make tracking available for a different TMS whether as a result of migration or parity tracking into a different analytics system.

Answer 3

I would advise to remove any dependencies to TMS from your platform code and migrate to use a generic data layer. This way you developers will not have any issues in future to migrate TMS.

See this article about generic data layer not TMS provider specific: https://dev.to/alcazes/generic-data-layer-1i90