Hard-coded UID value in utag.view() call - workaround opportunity?

Tealium Expert
Tealium Expert

Hello All - I'm in the process of migrating from Adobe Analytics "s" code over to Adobe App Measurement protocol. I have the conventional Adobe tag in Production and the AppMeasurement version is in Dev/QA.  When we added the AppMeasurement version of the Adobe tag to the profile, it naturally got a new UID value.  The problem is that some custom server-side work was done in the past which specifically references the conventional Adobe "s" code UID.  Is there a way that I can remap this value with an extension so that server-side code won't need to be revisited?

I am not completely sure why a specific UID value was used on the utag.view() calls, except that perhaps a previous developer didn't devise another way to prevent other tags in the profile from firing on the custom call. Certainly that decision has come back to haunt.

I tried searching for any previous forum entries on this topic, but may not have used the correct terms as I got no 'hits'.

Thanks for ideas!

 

2 REPLIES 2

Hard-coded UID value in utag.view() call - workaround opportunity?

Tealium Expert
Tealium Expert

Heck yes you can do that, though you may or may not like what it requires...

First thing to bear in mind is that utag.view is a relatively dumb function that just acts as a wrapper around utag.track, so all it does is this:

 

function(payload,callback,tag_uids){
  return this.track({
    event:'view',
    data:payload,
    cfg:{
      cb: callback,
      uids: tag_uids
    }
  });
}

 

So you can make changes to that code relatively easily. It's probably possible to change it within the master utag template, which is what I would have done in the past, but these days I much prefer using either a bundled custom tag template, or a DOM Ready extension, to make utag overrides, because it doesn't block your version upgrade path.

The difference between those implementations is that a bundled custom tag template is appended to the end of utag.js and runs almost immediately after the window.utag object is created, whereas a DOM Ready extension runs the risk of missing events that fire between the utag file loading and the DOMContentLoaded signal. But in general you're looking to do the same thing.

First thing to do is to consider whether or not this is a one time thing. Is there a risk that you'll have to do this again at some point in the future? Do you want to make it extensible? Let's pretend you do. So your code might start along the lines of:

 

window.utag.cfg.uid_remap = {
  71: 148,
  72: 153
};

 

What we're doing here is just creating an object under utag.cfg for simplicity's sake that describes a scenario in which calls to tag UID 71 should instead be directed to 148, and calls to 72 should be directed to 153.

Now all we have to do is to override the UIDs between them being passed into utag.view and ending up being submitted to utag.track. To do this, we're going to want to override utag.view, thus:

 

window.utag.view = function(payload,callback,tag_uids){

  var new_uids = tag_uids.map(function(old_uid){
return utag.cfg.uid_remap[old_uid] || old_uid;
}); return this.track({ event:'view', data:payload, cfg:{ cb: callback, uids: new_uids } }); }

 

So what we're doing here is replacing the array of UIDs with an array that contains either a remapped version, if the key existed in the remapping array, otherwise the original one. So any time a utag.view event is triggered that includes a hard-coded reference to a remapped tag, you'll pass the new ID into utag.track, and it'll be the new tag that fires. And any time you replace one tag with another, you can just update that remapping object to reflect the new IDs, without necessarily having to go through all the code that might refer to them and changing it all by hand.

Fun Bonus Feature:

You can also use this to give aliases to tags, in place of UIDs, which can be super useful when using a single tag in multiple profiles. So instead of mapping from numeric "old IDs", just use stringy names:

 

window.utag.cfg.uid_remap = {
  "analytics": 71,
  "webchat": 72
};

 

Then the code that was added to utag.view allows your events to pass an array of aliases instead of (or in addition to) tag IDs, so you could do:

 

utag.view(utag_data,null,["analytics"]);

 

And passing the "analytics" alias would do the same thing as passing Tag ID 71 instead. What that then enables is if your analytics tag is ID 1 in the "analytics" library, ID 17 in the "main" profile and ID 12 in the "test" profile, you could write some code along the lines of:

 

utag.cfg.uid_remap = utag.cfg.uid_remap || {};
var thisprofile = utag.cfg.utid.split("/")[1]; if(thisprofile == "analytics") utag.cfg.uid_remap["analytics"] = 1; if(thisprofile == "main") utag.cfg.uid_remap["analytics"] = 17; if(thisprofile == "test") utag.cfg.uid_remap["analytics"] = 12;

 

Then whichever utag file you've got loaded on the page, a utag.view call that specifies "analytics" in the list of UIDs will be automatically routed to the correct tag ID within that profile, giving you a consistent means of invoking a specific tag even if the UID changes between profiles.

Hard-coded UID value in utag.view() call - workaround opportunity?

Tealium Expert
Tealium Expert

Thanks @UnknownJ - that was a fantasic answer.  I will weigh my options as you laid out pros and cons very nicely.