Webclat / Tealium Practice

What's the equivalent Adobe Launch (_satellite.track) call for a given Tealium utag.link event?

Answer

There's no 1:1 function signature match. utag.link({...}) passes a flat object of key/value pairs that Tealium's own load rules and tag mappings interpret, while _satellite.track("event-name", {...}) fires a named Direct Call Rule that your Launch property must already contain - and that rule's own logic, not the call itself, decides what happens with the passed data. Migrating a call means recreating the equivalent Direct Call Rule in Launch with its own conditions and actions; copying the call syntax without rebuilding the rule and data-element mapping on the Launch side does nothing.

Why this happens

Tealium's utag.link() is a generic tracking call whose behavior is entirely defined by load rules and tag configurations that inspect the object you pass it - the call itself has no fixed meaning. Adobe Launch's _satellite.track() is a lookup: it finds a Direct Call Rule registered under that exact event name and runs whatever actions that rule contains.

Treating the two as interchangeable - literally search-and-replacing utag.link({...}) with _satellite.track("...", {...}) - leaves you with a call that either matches no rule (does nothing) or matches a differently-configured rule (does the wrong thing), because the object shape and each platform's own mapping/governance layer are fundamentally different.

Fix it

  1. In Tealium, list every load rule and tag currently wired to the utag.link() call you're migrating, and document what data from the passed object each one actually reads - not just that the call exists, but what consumes each field.
  2. In Adobe Launch, create a Direct Call Rule with an event name your application code will call via _satellite.track("your-event-name"). This event name is arbitrary but must match exactly what your code calls.
  3. Recreate each Tealium load rule's condition logic as the Direct Call Rule's own conditions (if any), and recreate each tag's data-consumption logic using Launch data elements that read from event.<key> - Launch's equivalent access pattern - inside the rule's actions.
  4. Update application code to call _satellite.track("your-event-name", {...}) in place of utag.link({...}), keeping the same field names in the passed object only if you also update every data element on the Launch side to expect those names - otherwise rename consistently on both sides.
  5. Run both platforms in parallel on a staging page during migration - Tealium trace alongside Launch's debugger - rather than cutting over blind, since the two systems have no shared verification tool that confirms a migrated call behaves identically.

How to verify it worked

  • Trigger the interaction on the migrated page and open Adobe Launch's debugger (or the browser console with Launch's debug flag) to confirm the Direct Call Rule actually fired - a call to an event name with no matching rule fails completely silently, with no console error.
  • Cross-check the same interaction's old Tealium trace log (from before cutover, or from a parallel-run staging page) against the new Launch debugger output, field by field, to confirm every value that used to reach a tag through Tealium still reaches the equivalent Adobe Analytics/Launch action.
  • Check the Network tab for the actual outbound beacon and confirm the parameters populated match what the old Tealium-driven tag used to send - this is the only step that proves the downstream reporting platform sees the same data, not just that a rule fired.
  • Decommission the old utag.link() call and its Tealium load rule only after this confirms clean, and leave a note in both systems' documentation pointing to the other side - the next reader of either profile has no way to discover the migration happened otherwise.

Moving off Tealium onto Adobe Launch?

We map every load rule and tag dependency before touching a line of application code, so nothing goes silently missing mid-migration.

Scope My Migration