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.
... View more
Expand/CollapseMenu
