Tealium Learning Center

You have three choices that would technically work: Before Load Rules This scope manipulates the data very early in the Tealium event flow and as a result the updated data would be available to load rules, which would allow you to conditionally load a specific tag based on the revised data. Based on how you're describing this, I don't think that's the right fit for you After Load Rules This scope manipulates the data after load rules have been evaluated and is the default scope for this type of extension. The updated data will be available to all tags that are configured to receive this data type (given that it's a utag.link call that probably won't be every tag, but it might be more than just the Adobe tag) Tag-Scoped Extension Scoping the extension to just the Adobe tag, the data manipulation would run as that tag executes as part of it emitting the data, and ensures that the changes you're making are only available to the Adobe Analytics tag Both options 2 and 3 feel like they'd be suitable here. You should select option 3 if other tags need to receive the same data without the modifications you're proposing to make, and you should select option 2 if you want to be able to make the modified data available to other tags (for example to maintain consistency across different reporting mechanisms). In general I find it better practice to maintain a single event payload across multiple tags so that there aren't vendor-specific overrides that potentially put data out of sync across different technologies, but if it really needs to just be changed in the Adobe tag, then the tag-scoped extension is best. ... View more

Depends on how your cookie manager is integrated, but hypothetically, one way to do it would be: Use a Before Load Rules tag to store inbound events in an array utag.cachedEvents = utag.cachedEvents || []; utag.cachedEvents.push([a, JSON.stringify(b)]); Create a function that will run through those and re-send them utag.sendCachedEvents = function(){ // Nothing to do if nothing is cached if(utag.cachedEvents.length === 0) return; // Effectively disable sending on all tags that already loaded // There will be smarter ways of doing this! Object.keys(utag.sender).forEach(function(tagId){ var tagObject = utag.sender[tagId]; if(tagObject.ev){ tagObject.ev_old = tagObject.ev; tagObject.ev = {}; } }); // For every cached event we've got utag.cachedEvents.forEach(function(event,eventIndex,eventArray){ // Grab the original event details from the cache var eventType = event[0]; var eventPayload = JSON.parse(event[1]); // Flag if this is the last cached event so we can re-enable those tags if(eventIndex == eventArray.length - 1) eventPayload.finalCachedEvent = true; // Trigger a send for each of the events utag[eventType](eventPayload); }); }; Then you'll want an After Tags extension that will fix up the mess we created of the tag event objects above: if(b.finalCachedEvent){ Object.keys(utag.sender).forEach(function(tagId){ var tagObject = utag.sender[tagId]; if(tagObject.ev_old){ tagObject.ev = tagObject.ev_old; } }); } Then just hook the function in step #2 into the cookie consent update So what we're doing here is first storing events as they come in in case we need to replay them later, then when we attempt to replay them we hack the existing set of loaded tags to disable sending (this is a terrible way to do it and won't work on bundled tags that are subject to consents because it'll disable them even though they didn't fire yet, there's ways to code around that but this is just a quick and dirty demo..), so that we can replay those events back through in sequence (you may wish to async/await some delays between the sends if you feel you need it) without them re-triggering any of the tags that already loaded, in theory then only firing against tags that were previously out of scope and have now come into scope. And then finally, once the last of those payloads passes through the event process and hits the After Tags extensions, we put the tags' event flags back where they were before and all future events will run against them just fine. There's all kinds of edge cases that this doesn't accommodate, particularly if any of your global extensions have side effects, or are intended only to run once, but broadly speaking, in a simple implementation, it disables any tags that already fired, re-runs the events so far, and then re-enables everything, in a way that does what you're after.. ... View more

In terms of rollback in a profile that has library inheritance, I guess my issue is that it does not technically exist. You can fix-forward by reverting to older snapshots of various libraries / the profile itself but the concept of a true rollback is not one that's been implemented, but presumably could be..? Each publish produces a distro bundle, to enact a genuine rollback you would simply need to push an older distro to the CDN, perhaps sensibly constrained such that only a previous prod build could be pushed to prod. Then for the more granular stuff, when to inherit etc., for me I think it makes the most sense to have some sort of timeline tool not unlike the current client-side versions feature, which in a profile would give you the ability to look across all the inherited libraries, and using a master slider pick a point in time at which to inherit the latest (at that point) version that's eligible for inheritance. And then beneath that, library-level sliders that would allow the user to set custom inheritance on a specific library if they so wished. The default would always be "current", and maybe the standard behaviour would be that the slider snaps to profile publish events, so the simple-mode experience is that you can simply drag the whole set of inherited libraries to their state at a given publish within your profile. But the complex-mode experience would let you pick any moment in time, and split those timings by library. Use case would be - three days ago I performed a production publish and one of the tags that's been configured in an inherited library is leaking a data item to a vendor that they should not be receiving, and it's severe enough that I want to be able to perform a fix without reverting the entire publish. But time has passed, new features have dropped in other inherited libraries ready for the next scheduled publish, but I need to perform a hotfix now to sort this one issue and I'm not intending to launch any new features. The owners of the affected library have ensured that what's published there today is what was in the last release, plus the fix, nothing else, but I can't go around another five teams' libraries reverting everything they've done this week, perhaps I shouldn't even have the access to do so. So, I go into the Timeline view in simple-mode, drag the master slider back to our last production publish, enable complex-mode, and then find the affected library and drag its slider to "current". Now the content of my publish is the inherited libraries at their position at my last publish except for the one library that requires an update, which is inherited in its current state. The way I'm envisaging it working in the backend would be effectively that each library publish is in effect a commit to the branches (environments) to which it's published. From my profile I don't see details of the development branches that users within the library are using to manage their own code, but I do see a stream of commit/publish events that I can roll back to a specific point in time for the purposes of what I'm inheriting. I'm probably just reinventing Git submodules or something, so this might all be terribly derivative, but you get the idea.. Bonus feature: The ability to specify for a given publish what the minimum version of other libraries/profiles within the account needs to be for that publish to work. Because interdependencies between inherited libraries do exist and they're awkward. If I make a change to my Webchat library to enable a new supplier and my Analytics library contains code that adds event listeners to the new webchat dialog, I need to be able to specify within my Analytics library that a given publish expects that the Webchat library will be at least as recent as insert date here. Or use tags as sort of feature flags so that you have a dependency on a specific tag being present in the other library, I dunno.. but what you want to avoid is a scenario in which an interdependency between two libraries is a) not made visible to users and could be forgotten about and b) cannot cause weird side-effects if one library is rolled back and another that depends on now-reverted code isn't rolled back. And finally, the feature I'm describing above would also work for maintaining stable releases vs nightly release tracks etc., wherein you might have a main profile that takes the most recent version of every library it inherits, and a near-identical main-stable profile that has all its sliders fixed at a given point in time, only moved when a new version is considered stable having been shown to be issue-free in production. "Can't you just do that already, freezing the stable version by not publishing the profile?" you might ask, and not quite, because at the point of publishing that profile, you're getting all the absolute latest versions of the libraries, which might not be the versions that you want to include in your stable release. Furthermore, if you needed to make any reference data changes (e.g. update a marketing tag campaign ID that has expired) without functional code changes, you'd have to re-inherit the whole set of libraries at their current state including all code. ... View more

Yeah, so, this is how I do it in a Collect Tag scoped extension: (function (tagConfigObject) { if (typeof tagConfigObject.validateProtocol_legacy !== "function") { /** * Store the original validateProtocol function somewhere safe, we'll invoke it later */ tagConfigObject.validateProtocol_legacy = tagConfigObject.validateProtocol; /** * Replace the existing validateProtocol function with one that allows us to inject * runtime config overrides into the execution process */ tagConfigObject.validateProtocol = function (address, force_ssl) { /** * Override 1 * If u.data has the loader.cfg property, blank it out - it's used to send tag completion * statuses to EventStream, but that's not part of our use-case. */ if (tagConfigObject.data && tagConfigObject.data["loader.cfg"]){ tagConfigObject.data["loader.cfg"] = {}; } // Return the original result of this function expression return tagConfigObject.validateProtocol_legacy(address, force_ssl); } } })(u); I forget the precise order of operations within the tag, and of course you could just modify the tag template to fix it if you wanted, but something along these lines effectively allows you to insert your own processor into the payload processing downstream of where a bunch of superfluous data is added to the tag. I also have an extension which removes any variables that aren't part of an explicit mapping object, which means that by default none of the cp.* parameters are sent (can't tell you how much I don't want any tags hoovering up the entire cookie record for a customer) and only items on an allow-list are sent. ... View more

Yeah, like, this used to deeply upset me that I couldn't do cool branching stuff while still supporting library inheritance, but in a sense I think it sends the right message, which is that library inheritance sits in complete opposition to meaningful version control. I'm not saying it would be impossible to blend the two things together, but fundamentally when you work with library inheritance you give up the ability to roll back changes in a straightforward fashion because the changes in question might sit within one or more inherited libraries, and rollback involves going into each, rolling those back, and then going back and republishing your main profile, and it's not that you can't do that, you just can't do it while holding in your head the belief that you're doing effective version control. Essentially, what it then boils down to is how to adopt one pattern whilst retaining as many of the benefits of the other as possible. In my case, that's been to keep library inheritance but to offload more of the TIQ work to JS extensions whose code can be managed in Git and either pasted, loaded via the UI integration with Github, or via the new profile update APIs. It doesn't give you the ability to encapsulate interface-level config (such as tags and load rules) into a branch with your code, but if the bulk of the complexity of a large deliverable sits within JS extensions, it gets you at least part-way there to version control and delivery of completed features into a main branch. The inverse then of that is to run with monolithic profiles and to find ways of separating and potentially reusing components using methods other than library inheritance. There's a sort-of-undocumented Automator tool that can do some of the heavy lifting if you needed a given component to be present in multiple published profiles that would allow you to master it in one place and programmatically copy it to others, which at least starts to solve for the "build once, use in many places" feature of library inheritance. The user access rights angle is harder to replicate - in my head, I've got this idea that you could hypothetically retain child libraries with specific access rights, and then use the various APIs and tools available to take snapshots of those libraries and insert them into a main profile that's not linked to them within TIQ but which would effectively inherit those configurations via that copying process. I could imagine that adding a whole heap of tech debt to your implementation, creating awkward dependencies on non-standard automations that make it harder for Tealium (and colleagues) to support your setup, and creating some potentially uncomfortable dependencies on very specific API methods that aren't guaranteed to work forever. So like, no easy answers. For my part, I really like turning everything into pure JS and then mastering it via Git, and treating version control and branching as something that's done upstream of TIQ itself. But if you use a lot of the interface-led extensions or need to bundle tags, load rules, UDO elements and extensions into overarching branches, it's not going to work out so well.. ... View more

Or, if you want an absolutely nuclear way of doing this stuff.... var perfTotals = {}; function pwrap(owner,fname,rname){ var original = owner[fname]; owner[fname] = function(){ var perfStart = performance.now(); var r = original.apply(this,arguments); var perfEnd = performance.now(); perfTotals[rname] = (perfTotals[rname] || 0) + perfEnd - perfStart; // if(perfEnd - perfStart > 10) console.log(rname,perfEnd-perfStart); return r; } }; var exclusions = [window,utag.o]; function rwrap(obj,prefix,depth){ if(depth > 4) return; if(exclusions.indexOf(obj) >= 0) return; for(var k in obj){ if(typeof obj[k] === "function"){ pwrap(obj,k,prefix + "." + k); } else if(Array.isArray(obj)){ obj.forEach(function(item){ rwrap(item,prefix + "." + k,(depth || 0) + 1); }); } else if(typeof obj[k] === "object"){ rwrap(obj[k],prefix + "." + k,(depth || 0) + 1); } } } rwrap(utag,"utag"); utag.view({}); var maxlength = 0; for(var k in perfTotals){ if(k.length > maxlength) maxlength = k.length; } console.log( Object.keys(perfTotals) .sort(function(a,b){ return perfTotals[b] - perfTotals[a]; }) .reduce(function(c,v){ c += v; c += (function(stringToPad){ var output = ""; for(var i = stringToPad.length; i < maxlength + 2; i++) output += " "; return output; })(v); c += Math.floor(perfTotals[v]); c += "\n"; return c; },"") ); This will recursively wrap all the functions found within the utag object or its descendants up to a depth of four, and then fire an event, and tell you how long everything took (with repeat invocations adding to the total): utag.view 937 utag.track 937 utag.handler.trigger 937 utag.handler.RE 203 utag.sender.928.send 146 utag.tagsettings.adobe.visitorAPI.getInstance 131 utag.sender.1428.send 115 utag.sender.1428.o 106 utag.handler.C 106 utag.sender.1216.send 93 utag.sender.1216.o 92 utag.sender.928.o.t 68 utag.handler.LR 66 utag.sender.1024.send 50 utag.sender.1024.o 49 utag.loader.loadrules 46 utag.sender.928.o.Ea 41 utag.sender.928.o.d.querySelectorAll 40 utag.sender.1459.send 39 utag.ut.typeOf 33 utag.loader.GV 31 utag.loader.RD 30 utag.sender.911.send 29 utag.sender.928.o.isReadyToTrack 27 utag.sender.928.o.pb 26 utag.handler.extend.59 26 With the evident caveat that if function a invokes function b, the total execution time for b will be included in a, hence why utag.view, utag.track and utag.handler.trigger have roughly the same duration here - view invokes track, track invokes trigger, but the end to end execution time remains 937ms.   ... View more

The only way you'd be able to do that is by adding event handlers to the Tealium script reference itself, and then using those to detect whether the script was correctly loaded and if not send that information somewhere (keeping in mind that anybody blocking Tealium is likely to be using a fairly strict ad blocker which would prevent most normal data collection endpoints associated with web analytics). There's nothing Tealium can do to detect that blocking because they never receive the network request in the first place. ... View more

Hi @pedrochristobal, If the data is stored in a first party context relative to the page the user is on, you should be able to pick up that cookie value within the UDO, it'll be called: cp.aam_something So it'll be accessible in extensions as b["cp.aam_something"], and if you add the item to the UDO in TIQ, you'll be able to map it to other tags. If the data is truly a third-party cookie, you won't be able to access it client-side because web security depends upon not being able to access cookies cross-site. Hope that helps. Cheers, James ... View more

I don't necessarily recommend this, but..... Identify the tag that you want to be portable, and edit its template via the top-right menu. Practically the last line of the tag code should in theory be: }('##UTID##', '##UTLOADERID##')); Replace this with: }(window.portableTagId, (function(u){ for(var k in u.o) return k; })(utag))); Next, in the profile to which that tag usually belongs, add the following pre-loader scoped JS extension: window.portableTagId = 1072; // replace this number with the ID of the tag in this profile In the profile you want the tag to newly appear in, create a new tag, and select "Tealium Custom Container" as the type Under advanced settings, for Custom Script Source, select the full URL of the tag file in its normal location, e.g. https://tags.tiqcdn.com/utag/account/original_profile/prod/utag.1072.js // look up the ID from the profile that owns the tag Make a note of the ID of the new container, and add a pre-loader scoped JS extension as follows: window.portableTagId = 16; // replace this number with the ID of the container tag in this profile And that should. in theory, do it. You can repeat steps 4-6 to put the tag into other profiles if you so wish. What we're doing is effectively instructing the tag to load itself into whichever profile it finds on the page (rather than the hard-coded injection of ##UTLOADERID##), using a dynamic tag ID so that it registers itself against the ID that corresponds to the right config (e.g. load rules) in the profile in which it finds itself. Then in each target profile, you're configuring that dynamic tag ID, and creating a container as a placeholder for the tag against which to create load rules etc. You won't be able to vary tag-scoped extensions between profiles, nor mappings, at least not without some custom code, but it should be sufficient to make a tag portable between compatible accounts (e.g. same UDO etc.) ... View more

Hi @surabhi_sharma2, If I'm reading this correctly, is the problem that s.clearVars() isn't being run between events, causing values to be persisted through successive events? If so, there should be an option within the tag configuration to clear variables between calls, but if you already have an existing implementation that otherwise works, then be careful enabling it - it could be that other behaviours within your Adobe tag are dependent on not running s.clearVars(), and enabling it might break things that otherwise work, so lots of regression testing required.. ... View more

The proper way to do this within Tealium would be to add a custom tag that references the MailChimp JS. That said, the quick way would be to simply inject the script, and then use its onload attribute to execute the code in the second snippet. If you try to load it as it's presented below, what'll happen is that the first script will be loading asynchronously while the second snippet is trying to execute, which causes nasty race conditions that are likely to make the tag fail. You'll want code along the following lines: (function(d, script) { script = d.createElement('script'); script.type = 'text/javascript'; script.async = true; script.onload = function(){ window.dojoRequire(["mojo/signup-forms/Loader"], etc... }; script.src='//downloads.mailchimp.com/js/signup-forms/popup/unique-methods/embed.js'; d.getElementsByTagName('head')[0].appendChild(script); }(document)); This places the second snippet into a function that executes only upon the load of the first script. This example doesn't include the dojo-config attribute because both usePlainJson=true and isDebug=false are the defaults, so there seems to be little need.. ... View more

My suggestion here: https://community.tealiumiq.com/t5/Tealium-iQ-Tag-Management/Hard-coded-UID-value-in-utag-view-call-workaround-opportunity/m-p/25129/highlight/true#M7632 Would work for this.. You could put a wrapper around utag.view, effectively replacing the function, and then conditionally abort it (i.e. fail to call utag.track) if the conditions for "do not send" were met. ... View more

I've created the following feature suggestion, which I think would work around the problem: https://community.tealiumiq.com/t5/Product-Ideas/Enable-CNAME-aliasing-to-create-appearance-of-local-utag-hosting/idi-p/27188 At least until the blocking got smarter, anyway.. From my perspective, we too use Tealium to deliver functionality like Webchat, which wouldn't be blocked by an ad blocker, so it's unfortunate that the delivery vehicle is. Other alternatives include locally hosting your Tealium instance - bundle all tags, and mirror utag.js onto your own domain, but it's not ideal for a whole bunch of reasons... ... View more

I might be wrong, but.. extObj.codeDevData.queue4Publish[sId].color = extObj.codeDevData.queueSeq % utui.customizations_template[100040].q4pColors.length; Basically, the colour of any given queued item is just based on its sequence number in the queue, cycled through an array of colours: q4pColors: ["regal-rose-base", "melon-mambo-base", "rich-razzelberry-base", "tempting-turquoise-base", "old-olive-base", "daffodil-delight-base", "pumpkin-pie-base", "tangerine-tango-base", "real-red-base"] So unless I'm mistaken, it means absolutely nothing..? Just variation for variation's sake.. ... View more

Hi @Anasooya, Typically in a single page application that's expected to fire multiple tags, those tags will have either load rules or dynamic lookup values scoped to data layer variables as opposed to being URL based as per traditional site tags. The easiest way to test specific points in the journey without navigating to them would be to simulate the contents of the data layer expected at that point. So for example, if you had a credit card journey and you wanted to check that your tagging configuration for the "customer declined" page is correct, you could open the JS console and run the following: utag.view({ JourneyName: "applyccc", JourneyStep: 4, JourneyAction: "Credit Decline", ApplicationState: "Declined" }); Or equivalent. You would then be able to validate that the tags you'd expect to see fire on the decline page are indeed firing. The trick of course is to ensure that you have the precise spec for what data should be present in the datalayer on the decline page, but arguably if you don't have that then you wouldn't have been in a position to set up the tags in the first place - one assumes that if you're testing that you've configured everything correctly, then your starting point was having a spec to build load rules / lookups from. In terms of validating that the contents of the datalayer matches what's in the spec for a given page in a journey, arguably that falls to the developers and the team that define the data requirements - nobody should be asking you to add tags to a page until it's been validated that it's generating the right data. Hope that helps. ... View more

Hi @sujani_koya, My understanding is that document.write can only be invoked while a page is being rendered and its content is effectively being composed by the rendering engine. So it suits synchronous injections of content in, for example, utag.sync.js. However, it's not appropriate for tags that fire after the DOM content has been loaded - at that point, nodes should be injected into the completed DOM using the relevant methods, and using document.write will overwrite the entire page (usually leaving it blank). ... View more

Hi @SKammerlocher, This is almost certainly due to an extension attempting to use utag.DB (the debug logging function) before the utag object has been created. The likely culprit is a pre-loader extension - these run before the utag object is initialised, so attempts to invoke utag.DB return an error stating that the utag object is undefined and as such has no property "DB". ... View more

Hi @davidmolina, I think there are two steps here: Adopt a design pattern that suits your rollout approach, and Migrate to that pattern With that in mind, rather than using a boolean true or false against a single variable, I would instead partition my users with a (randomly assigned) number from 0-99 and use that to drop them into the appropriate treatment. You can get a random number from 0-99 with the following JS expression: Math.floor(100*Math.random()) So let's say you've got a variable test1, which takes value from 0 to 99 - to run a 5% sample, simply use a condition: test1 < 5 Now all you need to do is migrate your existing customers bsased on their wave1 value. You could do that with the following logic: if(wave1 === true){ // wave1 is set and the customer is in the first 5% sample test1 = Math.floor(5*Math.random()); } else if(wave1 === false){ // wave1 is set and the customer is in the 95% remainder test1 = 5 + Math.floor(95*Math.random()); } else { // wave1 isn't set and the customer should be placed at random test1 = Math.floor(100*Math.random()); } This should then give all your existing wave1 members a number from 0-4, all the wave1 non-members a value from 5-99, and all new customers a value from 0-99, evenly distributed. Then you simply need to update your test condition to ensure that the right number of customers are included. Give me a shout if any of that is unclear. Cheers, James ... View more

You don't need to use multiple extensions for multiple variables. Simply use a single one, and have it set "myVariable" to the following JS code: b.myVariableA || b.myVariableB || b.myVariableC || b.myVariableD Chain as many as you need, and the first defined value will be returned. So if you're dealing with naming convention problems across different parts of the site, you might do something like: Set bestProductName to JSCode: b.productName || b.product_name || b.product Without intending to be rude, it sounds like the problem isn't the way in which the lookup table extension works, it's the consistency of the data layer that's an issue here. Personally I would use extensions to try to arrive at a consistent data layer prior to performing any lookups, so that all downstream mappings etc. are working to a common definition (after all, the U in UDO stands for universal..). ... View more