Difference between the 'b' 'utag.data' and 'u.data' objects in the Template code

[Michael_Kim_shc]

What's the functional difference between the 'b' 'utag.data' and 'u.data' objects in the Template code?  

When I step through one of my templates js code in runtime, the utag.data object that I typically reference for object variables does Not have some data that i'd expect it to... whereas the 'b' object does.  

If it helps, this particular scenario i'm seeing is in a mobile single-page app environment.

Also, if it matters, I'm seeing a link/event call happen prior to a pageview call to utag.

[dan_george · Accepted solution]

Here is a high level overview of the Data Layer.

However, it may lack some specifics about what you're looking for so below is a breakdown that hopefully helps:

• utag_data is the global Tealium object that contains base page data as declared by your business
• utag.data takes utag_data and also adds the 1st party cookie, URL, Meta, and JS Variable data from the DOM
• The b object is either an alias or a local copy of the utag.data object
  • When a page load event occurs and we trigger a vendor template, we pass the event type (d.event) and a copy of utag.data (utag.handler.C(d.data))
    

    utag.sender[a].send(d.event, utag.handler.C(d.data));

    Within the template the event type is referenced as "a", and "b" is that copy of utag.data within the template
    

    u.send = function (a, b) {

  • Also, sometimes "b" is just short-hand for utag.data within the utag.js file
• u.data is typically a Tealium namespace and not meant to be used, it will reference vendor specific details like account ID and other data declared within the UI configurations

When to use one over the other?

• If you are using a SPA, typically you'll always reference the "b" object because it's specific to that event
• If you're using an extension scoped to all tags, both "utag.data" and "b" will work though we suggest "b" since it's shorter
• If you're configuring a jQuery extension, use "utag.data" since "b" will not exist
• If you're creating a variable within a tag scoped extension, and you want that variable to stay scoped to that vendor template, use "b"
• If you're creating a variable within a tag scoped extension, and you want that variable to be globally scoped to all vendor templates, use "utag.data"
• If you're using a Preloader scoped extension, none of these will exist

This may or may not cover all scenarios, but it basically comes down to scoping requirements. In your scenario for the SPA, you should be referencing "b" because it is specific to the new event, whereas "utag.data" is specific to the page load event.

Hopefully this helps!

Cheers,
-Dan

[Michael_Kim_shc]

Thanks Dan, that does help. Greatly!  

One clarification - the template that this is affecting (unforutnately) has a lot of customization within it, and currently that customization is priarmily using the utag.data object instead of the b.  It sounds like switching the customized bits to the 'b' object would be the correct way of doing things (and makes sense with what I'm seeing in stepthrough).  Just wanted to makes sure that your scenarios/use-cases apply to template coding as well as extension.

Is there also a nice doc or writeup explaining when and where the extension code gets aggregated on compile depending on how it's scoped?  i.e. if itt's scoped to all tags, if its pre-loader, before load rules, after load rules, scoped to 1 tag, to multiple tags, etc?  sometimes i've seen the code in the utag.js file, and other times it's been in the template files.(utag.js123, etc)

[dan_george]

@Michael_Kim_shc

Yes, switch to "b" and that should resolve a majority of the issues. The scenarios/use-cases mentioned will apply to both template code and extensions.

I don't know of any such documentation, but maybe @kathleen_jo does. Though I can tell you that extension scope fully effects where the code is pulled into.

• If the extension is scoped to anything other than a specific tag, the code is output to utag.js - though where within utag.js the code runs depends on the scope selected - for example pre-loader extensions will run immediately upon utag.js loading whereas DOM Ready extensions won't run until the DOM Ready event occurs.
• Otherwise, the code is output to the vendor tag(s) utag.N.js the extensions is scoped to.

[Michael_Kim_shc]

Awesome!  Thanks Dan.  super helpful as usual.

[Srinivasan]

@dan_george Thank you so much for elucidated precisely intended to diff between 'b' 'utag.data' and 'u.data' object

[Michael_Kim_shc]

@dan_george, I'm finding some scenarios where on a breakpoint set during execution of Before Load Rules js code, I have  valid value for a data layer variable "pageType".  

However, at the same time, when I look at utag.data["pageType"], it shows something different.  Then also after I finish that pageload where the valid value call was the last call to tealium - if I look at utag.data then it's still showing the invalid value.

When does the utag.data get updated during execution?  Based onyour previous answer, I would have expected it to populate between preloader and before load rules, and then again also when I update it using the 'b' object pointer within the utag.js extensions.

[dan_george]

@Michael_Kim_shc 

Just for clarification purposes, if you search utag.js for utag.loader.initdata, that is the exact function that declares utag.data in the first place based off of utag_data. This is called, as you assume, after Preloader extensions are ran but prior to Before Load Rule type extensions. For the most part utag_data and utag.data should mimic each other from this point forward.

That being said, I'm a bit stumped. When your Before Load Rule breakpoint hits, everything that has been added to the data layer is of global scope to Tealium so if you update utag_data it will update utag.data, and visa versa.

My initial thought is that there is a utag.link or utag.view that is being triggered on the page causing this. For example, let's say you set utag_data.pageType="home" on page load. But you also trigger a utag.view via jQuery onHandler extension for when some dynamic content loads, and the extension uses custom code to pass utag.data.pageType="dynamicContent". Within your breakpoint you may see this mismatch, though post page load, utag_data.pageType and utag.data.pageType should still be equal.

Hmm, @TealiumJustin any ideas?

This is one of those scenarios where having access to a URL including steps to reproduce the issue is the only clear way to provide exact guidance on the issue, otherwise we are making assumptions. :) If that information cannot be provided here then I recommend submitting a support ticket. 

Cheers,

-Dan

[Michael_Kim_shc]

Thanks @dan_george!  We found the issue with some more debugging.  We had some custom js that was persisting the values unexpectedly.  Thanks however for the additonal thorough details on the data layer movements though!