How to manage multiple SiteCatalyst distinct configurations?

[alessandro_pell]

Hi, if we have to send requests to multiple SiteCatalyst report suites configured in different ways, how can I do it? Let's assume I have report suite A where prop4 is "url" and prop5 is "pageName backup". In report suite B, instead, prop4 is "search terms", prop6 is "url" and prop8 is "pageName backup". How can I handle them? At the moment, I have a SC tag configured for report suite A in the tags section of Tealium, with data sources mapped for A http://i.imgur.com/fTgA5PV.png How can I declare a mapping for B too? Keep in mind that in the worst case scenario we have a responsive page (same url) that has to send to rep suite A if desktop, B if mobile (let's assume that the logic based on desktop/mobile is just ready). So we can't duplicate the tag and activate them with specific load rules. Thank you, Alessandro

[roshan_gonsalko]

Hi Alessandro, Thanks for your email. In order to trigger data to one report suite for mobile and one for desktop (for example) you should be able to do this via load rules as long as your UDO (i.e. utag_data). I'd have two separate tags: 1. your existing one (using 's' as the object) 2. a new one - (using something else as the object (e.g. 'sc')) Then, you just map the relevant data sources to the relevant vars in the two tags. If you need to ensure each tag only fires on some pages then yes - if you can't detect whether you need to fire it from the URL you'll need to have something available on the page that will tell you. e.g. if it's desktop vs mobile you'll need a var in your UDO (utag_data) to tell you OR you'll need to be able to grab something from a JS var on the page etc I have a feeling you know all of this already and can't differentiate mobile from desktop. If this is the case, you cant' handle this particular use-case for mobile vs desktop tags. However, having two tags fire on the same page with different object names and different mappings should work in all other cases. I'm not sure whether I've answered your Q so let me know if not! Cheers, Roshan

[alessandro_pell]

Hi Roshan, thanks for answer, it's clear; we have the mobile check in an extension. You are telling me that my only way to manage this is to use two tags (and have different variables like s and sc). In case of need, can i send a request to the report suite B if: * I stop the standard.utag_view with the config override * I use utag.view(data, []) to send only my mobile tag ? Because the check is in an extension (as said before) and I can't fit it in a load rule, right? Load rules are executed before extensions, or there is a specific scope for that? Another question: there's no way to change the mapped data sources at runtime in an extension right? I'm asking it because report suite A and B differ very slightly. Thanks, Alessandro

[roshan_gonsalko]

Hey Alessandro, Yes, that's right. Think of how you would do it with a standard SiteCatalyst implementation - you'd need two s_code.js files and two objects on the page (and trigger the s.t() and s.tl() separately I believe). Good news - if you're using a later utag version than 4.28 then you can run a bit of code in a pre-loader which will ensure load rules run AFTER extensions: https://community.tealiumiq.com/t5/Tealium-iQ/How-to-evaluate-load-rules-AFTER-extensions/ta-p/13745 So, you can use load rules to decide when to trigger tag A and tag B based on your extension. On the 'noview' config override - yes, you could have some logic to trigger a specific tag with the utag.view() syntax you mentioned above. Be sure to run the the utag.view() code in an 'all tags' or 'DOM Ready' scoped extension (i.e. no a pre-loader) as utag.view() won't exist when a pre-loader is running. Are you in Europe or the US? Thanks, Roshan

[jared_hislop]

Alessandro, A couple other points. 1)There is the possibility to determine what type of device the user is using based on User Agent or Screen Width. This would go into a JS Code Extension Scoped to PreLoader then use the output in the Load Rule (PreLoader Exts run before Load Rules) to determine which tag to fire. 2)Another way to do this would be to use Extensions to manipulate the data for certain criteria. Using your example above you could do: Let's assume I have report suite A where prop4 is "url" and prop5 is "pageName backup". In report suite B, instead, prop4 is "search terms", prop6 is "url" and prop8 is "pageName backup". This could get really messy, but you could create a Set Data Values Extension that sets data sources specific to SC: NOTE: I would not use the "prop" or "eVar" names in data sources but for simplicity sake I am using them in this example. Set Data Values Extension 1 (pertaining to Report Suite A): Set: sc_prop4 To: Variable: URL Set: sc_prop5 To: Variable: page_name Condition: Report Suite A Condition* Set Data Values Extension 2 (pertaining to Report Suite B): Set: sc_prop4 To: Variable: search_terms Set: sc_prop6 To: Variable: URL Set: sc_prop8 To: Variable: page_name Then you would use the "sc_xx" variable in the mapping for the tags. Like I said, I don't condone using "prop" or "eVar" in the Data Source names :) but not knowing all your use cases it is difficult to come up with a naming strategy.

[alessandro_pell]

Hi Roshan, i've read the article. That's an interesting and very powerful option (load rules evaluated after all tags extensions). It's clear also that I can't use in load rules variables set in tag scoped extensions because load rules are there to load tags conditionally, and tag scoped extensions go hand in hand with their tags. It's kinda of "chicken or egg" problem at that point. We may be able to use it because luckily we are on v 4.28. I could use pre-loader scope, but it's run only once in the page, and in case of custom links and virtual pageviews, that's not what we want. Thanks, Alessandro PS: I'm in Europe - Italy!

[alessandro_pell]

Hi Jared, for 1) yes, we already have an implementation of device detection based on a mix of User Agent / Device witdh (media queries like) / Touch events, placed in an extension! Probably we will set it to the pre-loader phase, but the context it's complicated by the fact that not every page needs to have device detection enabled. We will think and come up with something. 2) It's clear, but that's not exactly what I meant. We have UDO variables named like page_name, page_hierarchy etc, no prop and vars named in there (and I'll agree with you that it would not be a great idea) But the two SiteCatalyst report suites differ for some variables (sitecatalyst variables), as said before. So, I'm asking myself if I may have this scenario: * I have only one SiteCatalyst Tag, with one mapping. Example: page_name_backup (UDO) is mapped to exit as prop5 in the SiteCatalyst request for report suite A. * At runtime, i tell to my tag to remap some data sources. For example, since I want to send to report suite B, i'll want to remap page_name_backup (UDO) to prop8 instead of prop5. I don't think this is currently possible, but I'm not afraid to ask anyway :) Thanks Alessandro