Tealium Learning Center

As ad blockers gain in popularity, so do the number of work-arounds, and the number of questions from Tealium customers about how this affects their installation. In this post I cover the popular ad blockers, how websites are reacting, and most importantly, how Tealium is affected by all of this. In this article: AdBlock and Adblock Plus The most popular ad blockers are AdBlock and Adblock Plus , which are available for every major browser. Yes, these are separate products, which makes the names confusing, but the teams behind these separate projects recently joined together to work on their shared mission to "make the internet a better place." As part of this effort, AdBlock lists the following features for its plugin for Google Chrome: Block annoying video ads and banners Block pop ups Stop tracking and give yourself more privacy Fight off destructive malvertising that can hide in ads Give yourself faster browsing (as resources are blocked from loading) Customize features, like whitelisting for favorite sites Get free and constant support Give yourself simply more control of the experience you want The primary goal of the plugin is to block ads, pop-ups, and tracking. However, they make it clear that they won't block all tracking all the time. In fact, some ads, such as those determined to be acceptable, will still appear when using the default settings. And to go beyond ad blocking and block tracking pixels, you have to opt-in to a more aggressive blocking setting.  For more information, see Allowing acceptable ads in Adblock Plus. The Adblock Plus EasyList, which is not used by default and requires opt-in, doesn't include any domains or patterns that match Tealium endpoints, with one minor exception. There is one entry for /utag.loader . This is probably a reference to the first Tealium endpoint URL from 2011, which is no longer in use. Historically, these tools had only been used by technical people. For example, there is an EasyList forum discussion that has links to help you learn regular expressions. This was knowledge you would need to be able to customize your filter rules with advanced syntax. But the ubiquity of browser plugins has made these ad blockers commonplace now. A quick visit to the Chrome Web Store and you're only a couple clicks away from installing an ad blocker. Workarounds for Website Owners The most common workaround is to detect ad blocking software and display a message to the user that the ad blocker needs to be disabled to use the site. This works really well at filtering out your visitors who use ad blockers, but it might work too well. This workaround has the risk of decreasing traffic to your site as more people use ad blockers. However, for a visitor that really wants to use your site, the ad blocker plugins make it easy to make an exception for the current site. However, to avoid the disruptive user experience, website owners are simply using ads from the list of approved advertisers and hoping that their visitors are using the default settings mode. How do ad blockers affect Tealium? The first thing to understand is that Tealium is not an advertiser, so in general, the Tealium endpoints will not be targeted by these lists. On the other hand, Tealium iQ Tag Management is a flexible platform that can be used to implement just about any kind of JavaScript solution, including installing an ad vendor's code snippet. But even in that case, the ad blockers should be targeting the offending ad vendor directly, not the container tag hosted by Tealium. For example, the Google Publisher Tag allows a site to asynchronously fill in ad slots with ads from Google.  This tag is easily configured and added to your site from the tag marketplace in iQ Tag Management, but the ads themselves are not loaded from Tealium domains. The ad blockers will detect the Google domains that serve the ads, not the Tealium domains that loaded the container JavaScript. For a more detailed look at how Tealium is affected by ad blockers, here are the two main Tealium endpoints: Tealium Multi-CDN Product: Tealium iQ Tag Management Endpoint: tags.tiqcdn.com There are so many ad blocking lists in use that you will eventually find an obscure one that contains tags.tiqcdn.com . However, the more popular lists are focused on blocking advertisements, so they shouldn't have any reason to block tags.tiqcdn.com . Tealium Collect Product: Tealium EventStream and Tealium AudienceStream Endpoint: collect.tealiumiq.com Tealium Collect is a data collection endpoint, so blocking this will not affect the user experience. It doesn't serve ads nor does it run JavaScript code, so it's very unlikely to end up on an ad blocking list. However, this endpoint could be affected by someone attempting to block tracking. For this reason, the Tealium Collect endpoint is a good candidate for using a CNAME. A CNAME would change the endpoint to something on your own domain, such as collect.example.com .  And yes, ITP in Safari can detect CNAMEs, but this is used to limit cookies not to block requests.. Popular Ad Blocking Lists Here are some popular ad blocking lists and how they reference Tealium: uBlock Origin This list has tags.tiqcdn.com blocked for the following two sites: @@||tags.tiqcdn.com^$script,domain=bild.de @@||tags.tiqcdn.com^$script,domain=pch.com YoYo Peter Lowe Block List This list contains the following: 127.0.0.1 tags.tiqcdn.com 127.0.0.1 tealium.com 127.0.0.1 tealiumiq.com It’s not clear if tealium.com will still work if you have this list or if only cookies are blocked. EasyList Cookie List This list appears to have these div IDs in the allow section, indicating it will allow the Tealium Consent Manager to run. online.no,telenor.no#@##__tealiumGDPRcpPrefs online.no,telenor.no#@##__tealiumGDPRecModal EasyPrivacy This list blocks the following: /tealium-analytics. /tealium-api/* /tealium-udo. /tealium-web/* /tealium.html? /tealium.js Tealium uses the tealium.js JavaScript inside Google Tag Manager (GTM) integration for data collection inside GTM. The other patterns do not match any Tealium endpoints. URLhaus Malicious URL List This is a malicious URL list. Tealium domains are not on this list. URLhaus Malicious Hosts List This is a malicious site list. Tealium domains are not on this list. Final Thoughts Here are some key takeaways: Most ad blockers require the user to opt-in to get a more aggressive setting. The more aggressive ad blocking setting used, the more likely the site will break. Website owners can use an ad block detector to ask the user to whitelist or disable ad blocking while the visit the site. You can even ask the visitor to use a different browser. Tealium is not an ad vendor and does not provide an endpoint that returns ads or an iframe with ads inside. Every site should be evaluated on an individual basis to understand how ad blockers are impacting the traffic and the user experience. What percentage of your website visitors are blocking tags.tiqcdn.com or what percentage do not allow tracking calls to collect.tealiumiq.com ? What browsers are they using when this happens? After you have this data, you can explore your options. You may need to install an ad blocker detector or find a simple workaround for a specific use case. If only 2% of your visitors use ad blockers, then implementing a workaround may not be worth it. But if a larger percentage of your traffic is affected, then it's worth the effort for a more robust solution. Additional Resources Tealium First-Party Domains (CNAME solution) Use a reverse proxy to set first-party cookies ... View more

Tealium provides an HTTP API endpoint for collecting event data from any location.  This means that you can collect data from events that happen in your app or, in the case of Alexa, events that happen in a cloud provider. This example shows an AWS Lambda function used for an Alexa skill that tracks usage of that Alexa skill.  Alexa developer tools allow you to create the Lambda function without the traditional AWS setup and permissions. Alexa Skill Using AWS Lambda The following is the AWS Lambda code to send data to Tealium's HTTP API endpoint. This code runs inside an Alexa skill to POST a data layer in JSON to Tealium Collect. My code that includes sample tealium.track function call and definition is found here: https://gist.github.com/tygavin/5a0ccae21995067d79ff0edd633058d6 This same event tracking code can be placed inside a function such as GetNewFactHandler .  Watch this short video demonstration of how to add Tealium Collect to an Alexa skill:  The Power of Server-to-Server From there, you can send data server-to-server from Tealium EventStream to one or multiple vendors (such as an Analytics vendor). This means you only need one implementation code snippet for data collection in your AWS Lambda -- as opposed to one snippet of code for each every vendor you have.  A single tracking implementation for all events opens up a world of server-side integrations and a lighter-weight AWS Lambda function. References General tutorials on creating skills for Alexa can be found here Build An Alexa Fact Skill with NodeJS Hello World Alexa app Tealium HTTP API Endpoint Tealium Alexa Skill Sample App Gist ... View more

This article describes the Tealium Collect integration for AMP websites and applications using the amp-analytics element. In this article: Table of Contents Placeholder Requirements Tealium account enabled for EventStream How It Works This solution uses the amp-analytics element to implement user activity tracking with Tealium Collect. This JSON configuration object sets up basic page view tracking and a simple example of click tracking. You may adjust these as necessary. The "triggers" section defines the types of events to track. The "defaultPageview" section will trigger on page views and the "links" section will trigger on clicks of page elements coded with the "tealium" class. Adjust this as necessary for your AMP site. Data parameters with a name prefix of dom. passed in the query string of the collection endpoint will not be accessible as event attributes in EventStream. Read more about amp-analytics. Tealium Collect JSON for AMP (amp-analytics)  <script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>   <!-- Begin Tealium Collect tracking --> <amp-analytics id="tealium_collect"> <script type="application/json"> {   "vars": {     "account": "##TEALIUM_ACCOUNT##",     "profile": "##TEALIUM_PROFILE##", "datasource": "##TEALIUM_DATASOURCE##", // optional     "visitor_id": "CLIENT_ID(AMP_ECID_GOOGLE)"   },   "extraUrlParams": {     "page_name": "home",     "page_topic" : "news",     "page_platform": "amp"   },   "transport": {     "beacon": false,     "xhrpost": false,     "image": true   },   "requests": {     "base_url" : "//collect.tealiumiq.com/vdata/i.gif",     "base" : "${base_url}?${tealium}&${dom1}&${dom2}&${datetime}&tealium_event=${tealium_event}&tealium_event_type=${tealium_event_type}",     "tealium": "tealium_account=${account}&tealium_profile=${profile}&tealium_vid=${visitor_id}",    "dom1": "url=${sourceUrl}&domain=${sourceHost}&pathname=${sourcePath}&title=${title}",    "dom2": "viewport_width=${viewportWidth}&viewport_height=${viewportHeight}",    "datetime": "timestamp=${timestamp}&tz=${timezone}&lang=${browserLanguage}",    "pageview": "${base}&referrer=${documentReferrer}&screen_size=${screenWidth}x${screenHeight}",    "event": "${base}&scroll_y=${scrollTop}&scroll_x=${scrollLeft}" }, "triggers": {     "defaultPageview": {       "on": "visible", "request": "pageview",       "vars": {         "tealium_event": "screen_view" }     },     "links": {       "on": "click",       "selector": ".tealium",       "request": "event",       "vars": {         "tealium_event": "custom_click" }     }   } } </script> </amp-analytics> <!-- End Tealium Collect tracking -->     ... View more

These days there's no shortage of privacy and security issues to concern yourself with, and there's good reason for it. While the vast majority of online systems are secure, there's always a risk that one component in a system will get compromised. The way websites are built these days, with hundreds of components, many third-party JavaScript libraries have become ubiquitous and used by millions of sites. This is a great convenience to developers of websites, but it's also an attractive target for the "bad guys" that want to hack your site. Fortunately, the browsers we use everyday have built-in features to help protect us against hacked components like this. One of these features is called Subresource Integrity (SRI) and it's the topic of this post. I'll give you a brief description of SRI, tell you how it works, then share my opinion on how SRI fits into the world of tag management. What is Subresource Integrity? First off, "subresource" refers to the extra files that a web page fetches while the page is rendered in the browser. This includes all types of content, such as CSS files, font files, external JavaScript files, and many more. The "integrity" part just means that the page is receiving the exact file that it expects to get. I'll quote Mozilla's simple explanation to make it easy: Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch are delivered without unexpected manipulation. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity It's that last part about "without unexpected manipulation" where this becomes a security concern. What is the purpose of SRI? The goal of SRI is to protect your website from a compromised (i.e. unexpectedly manipulated) third-party JavaScript file. The idea is to create a hash of the known valid version of that file that the browser can use to verify that the file is unchanged each time it loads. This makes perfect sense for static files such as a specific version of jQuery. For example, all of the shared libraries that Google hosts have versioned URLs where the files are expected to remain unchanged. For jQuery 3.4.1 the URL is:   https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js A generated hash of that file is: sha384-vk5WoKIaW/vJyUAd9n/wmopsmNhiy+L2Z+SBxGYnUkunIxVxAv/UtMOhba/xskxh By including this hash in your page code that loads that JavaScript, you allow the browser to validate that the contents of jquery.min.js have not changed. If that file were to be hacked, or manipulated unexpectedly, the hash generated by the browser would differ from the one you coded in your page and the browser would actually block the file all together. Should you use SRI in your tag manager? I know what you're thinking: browsers have a built-in security feature to validate third-party JavaScript files and you use Tealium iQ Tag Management to manage many of those third-party JavaScript tags on your site, so isn't SRI the perfect way to add an extra layer of security to your site? Well, let's take a closer look at this. One of the big differences between JavaScript that's used for development and the script tags that are used for web analytics and marketing is the way they are versioned. For example, many websites all load the same Google Analytics tag from   https://www.google-analytics.com/analytics.js , but this file is not versioned. Google updates the contents of that file constantly to fix bugs and add features. If you add SRI for this file, it might work for a week or two, but eventually, once Google updates it, the hash will change, causing SRI to block the file in the browser. Unfortunately, this scenario applies to nearly all tag vendors that you load on your website. The security feature designed to protect you from maliciously altered files also prevents a frequently-changed file from loading, even when the changes are part of the software design. Tealium allows you to use SRI with TiQ on the bundled utag.js file. While this won’t mitigate the risk of any additional tags (utag.n.js) or third party scripts being told to load by those tags, it does help to mitigate the risk of utag.js being maliciously altered. Learn more about how to implement SRI with Tealium here. What can you do besides SRI? If you really need an additional level of security for your tag vendors then I recommend the following alternatives to SRI. These are ways to vet the security of the third-party JavaScript you load on your site. Scripts Loading Scripts Does the third-party JavaScript script load and then go on to load additional third-party JavaScript files? This is sometimes called "piggybacking" and it's not that uncommon. Be sure to understand what your tag vendor's code is actually doing. Scripts Modifying Global Namespace A common rule of JavaScript etiquette is to leave the global namespace as tidy as possible. Most vendors play friendly by creating a specific namespace for their tag and put all of their JavaScript logic there. Be sure to test your tag vendor's code to make sure there aren't unintended modifications to the global namespace. Use HTTPS This almost goes without saying, but make sure that every third-party file you load on your site is available via HTTPS. Use Content Security Policy (CSP) Use a CSP to help mitigate scripting attacks through your site. This requires some back-end changes to your web servers, but it's worth considering for the added security.   ... View more

Google decided with AMP HTML cache to copy the world's content to their own CDNs on google.com, effectively keeping visitors on the google.com domain even after clicking a Google search result. This creates an interesting analytics challenge when your visitors are viewing your content, but are still on google.com. And when that visitor clicks a link to eventually arrive on your original website, it becomes difficult to build an accurate visitor path report using traditional web analytics tools. To help reduce the impact of this issue, Google AMP provides an AMP-linker tool that enables a visitor ID (generated by Google) on the AMP page to be passed along to the source domain so that you can connect the dots and see a more complete visitor path. This is referred to as the Google Client Id (CID). Google Analytics tags automatically picks up this value, so the following describes how to use this ID in a non-Google Analytics use case. For a data collection use case where Tealium collects event data on your AMP pages (Tealium Collect AMP Analytics integration here), you can leverage the Google-generated CID value as your Tealium visitor ID for the rest of the visitor's engagement with your content. The primary use case is specifically for tracking a visitor that navigates from an AMP page to a non-AMP page (as opposed to the other direction, which is rare). This solution does not solve for all use cases (such as visitors moving between non-AMP to AMP pages by clicking back button and doing multiple Google searches). Google's legacy iframe tracking where the website hosts an HTML page that runs TMS inside of it may be better suited for more complex tracking scenarios. Here are the steps to make this work. 1. Enable the AMP-linker by adding a configuration entry. This is described here. <amp-analytics> <script type="application/json"> { // .. "linkers": { "enabled": true, "destinationDomains": ["example.com"], "linker1": { "ids": { "amp_cid": "CLIENT_ID(amp_cid)" } } } } </script> </amp-analytics> This lets the AMP HTML analytics vendor know that outgoing links to 'example.com' should be tagged with an amp_cid value.  More Details:  https://blog.amp.dev/2018/09/17/measuring-user-journeys-across-the-amp-cache-and-your-website/ https://support.google.com/analytics/answer/7486764?hl=en 2. Add a snippet of code to Tealium iQ. The next step is to read the value from the URL and use it as your visitor ID. In this case, we are only using this visitor ID for the case when we have a first-time visitor that is arriving from an AMP HTML page. Here is a simple JavaScript Code extension to accomplish this: Sort this as the first JavaScript extension scoped to "All Tags - Before Load Rules"   // Look for amp_cid value in URL query string // and check to see if this is the first-time visit if (b["qp.amp_cid"] !== undefined && b["tealium_session_number"] === "1" && b["tealium_session_event_number"] === "1") { // Set the utag_main_v_id cookie to persist utag.loader.SC("utag_main", {v_id: b["qp.amp_cid"] }); b["cp.utag_main_v_id"] = b["tealium_visitor_id"] = b["qp.amp_cid"]; } 3. Use tealium_visitor_id in EventStream connectors (server-side), or iQ tags (client-side) as a standard visitor identifier for your vendors. For more information on EventStream or client-side mapping, please visit here. While cross-domain tracking has never been an exact science, modern web browsers continue to make this more difficult.  For the specific Google AMP use case, you can use Google and Tealium features together help. Using Google AMP-linker and Tealium JavaScript Code extensions provide for a more robust tracking implementation in the modern web. ... View more

Implementing the Tealium Universal Tag (utag.js) on your website isn't rocket science, but it does require a fair amount of pre-planning and requirements gathering. We have a whole team of implementation specialists dedicated to guiding customers through this initial process. It's a non-trivial amount of work to get a robust implementation deployed to your production site. Which is why it's worth thinking about your long-term strategy for maintaining that implementation. First, we can all admit that imperfections are bound to arise in your Tealium implementation. As your site goes through weekly or monthly releases, it's inevitable that one of them will interrupt your data layer or tracking. Of course, the flexibility of the iQ Tag Management platform makes it easy to apply one-off fixes. For example, you can use extensions to add missing variables to the data layer, apply fixes to errant values, or set up event tracking -- all feasible tasks within a matter of minutes. But these patches add up over time and will clutter your iQ workspace, making difficult to maintain over the long term. So, you need better strategies to ensure that your implementation remains in tact after each release. So let's talk about unit testing! Entire software companies exist for this purpose (see ObservePoint). At the same time, adopting a test-driven development (TDD) approach to your Tealium implementation is now easier than ever with the available frameworks such as Mocha and Chai. The following is an example of how you could add a Mocha-based testing suite entirely inside your Tealium iQ workspace. Mocha provides unit testing in the browser using JavaScript. You set the test conditions and Mocha asserts them as true or false. The end-result is usually some kind of a "green check" that indicates everything is okay. While Mocha would generally be used to validate an entire web application, it can easily be used to verify that your Tealium installation is working as expected. How It Works This solution uses the following components: A Tealium Custom Container tag to load the Mocha and Chai JavaScript libraries. A JavaScript Code extension to define and run the unit tests. A load rule based on your testing condition. Mocha and Chai libraries. Copy the entire contents of the JavaScript libraries from these links: Chai Library: https://unpkg.com/chai@4.2.0/chai.js Mocha Library: https://unpkg.com/mocha@6.2.1/mocha.js Also copy this snippet that loads the Mocha CSS: document.body.innerHTML += '<div id="mocha"></div>'; // Inject CSS var mochaCSS=document.createElement("link"); mochaCSS.setAttribute("rel", "stylesheet"); mochaCSS.setAttribute("type", "text/css"); mochaCSS.setAttribute("href", "https://unpkg.com/mocha@6.2.1/mocha.css"); document.head.appendChild(mochaCSS); Then add a Tealium Custom Container tag and paste the contents of each library and the CSS into the tag template between lines 21 and 22 (yes, it's a lot of code, but you won't need to edit this file again): /* Start Tag Library Code */ // Paste Mocha and Chai code here /* End Tag Library Code */ Next, create a load rule for this tag that triggers the test. In this example, we will use a query string parameter called utest . When utest is set to "mocha" the Mocha/Chai tag loads. Finally, add a JavaScript Code extension for the actual unit test. In this example, we are testing the data layer on the product detail pages, so we added a condition on the extension to test when tealium_event='product_view' . Be sure to scope this extension to the Mocha/Chai tag so that it will only run when that tag loads. Using the condition on the extension allows you to create separate unit tests for each page type or event that you want to test. The product page extension tests that the product variables are arrays with a length of 1. It also tests the expected value of the page_type variable. Paste this code into the extension: var assert = chai.assert; mocha.setup('bdd'); // utag_data describe('utag_data', function() { var prod_vars = [ "product_id" ,"product_list_price" ,"product_name" ,"product_sku" ]; prod_vars.forEach(function(p) { describe(p, function() { it('is an array when defined', function() { assert.equal(utag.ut.typeOf(b[p]), "array"); //chai.expect(utag.ut.typeOf(b.[p])).to.equal("array"); }); it('has length 1', function() { assert.equal(b[p].length, 1); }); }); }); // page_type describe('page_type', function() { it('equals "product"', function() { assert.equal(b.page_type, "product"); }); }); }); // Run the tests mocha.run(); That's it! Now publish your changes and test it out. Demo Site You can see a working demo of this solution, but you'll need the Environment Switcher to switch to the demo account. Go to the demo product page: http://www.tealiumecommerce.com/linen-blazer-599.html Use the Environment Switcher to load the following file: tealium-ia/main/dev Trigger the test using the query string parameter "utest=mocha" : http://www.tealiumecommerce.com/linen-blazer-599.html?utest=mocha Scroll to the bottom of the page to find the Mocha test results: Hopefully this gives you some great ideas for how you can test your own implementation. ... View more

I've written a few posts on the topic of Apple's Intelligent Tracking Prevention (ITP) updates in the Safari web browser. Probably the most significant impact from these updates is ITP's restrictions around client-side cookies, specifically, that client-side cookies expire after seven (7) days. You can use iQ Tag Management to persist a visitor ID in local storage and then send the data to your vendor. This is likely the easiest solution to workaround the Safari limitation for those using client-side tag management. Many vendors support mapping of Visitor ID. You can use the tealium_visitor_id for mapping to override each vendor's visitor ID by configuring the mapping where needed. This solution does not attempt to write back over the current cookie value that may contain a different  tealium_visitor_id . The code examples provided below shows how to update the tealium_visitor_id to default to the value retrieved from local storage. The data layer will then contain the "most-likely-to-be-consistent" value. While this technique can be used for more than just an anonymous ID, remember that any PII information is best kept out of client-side cookies and local storage. Solution Use localStorage to store a visitor identifier value with a 1 year expiry. Use the JavaScript Code extension to read and write this value. Use tag data mappings to send this value to a vendor. Get the code: https://gist.github.com/tygavin/6d78c208e0663ac64ba9d78740dc31ac Example Code: Storing a Visitor ID in Local Storage The code provided is a simple way to store a value in local storage, in this case the Tealium Visitor ID. The code uses "teal_vid2" as the localStorage key as well as the attribute name in data layer object: var localStorageKey = "teal_vid2"; Update the number 365 (number of days) in the following example to persist the value for a different length of time: var durationInMS = 365*24*60*60*1000; function getVisitorIdFromLocalStorage() { var val = localStorage.getItem(localStorageKey); return val || ""; } The format of the value stored is {timestamp}_{value} , where the timestamp is the time the value was stored (in milliseconds), e.g. 1551462917775_1551a323423465325235aafbe29177fe75 . function copyVisitorIdToLocalStorage(visitorId) {    var currentTime = new Date().getTime(),       timeWritten,       temp; When the value is read, the timestamp is checked for expiration. If the time since writing the value is greater than the duration, then overwrite with new ID. If it is empty, then set for the first time.      temp = getVisitorIdFromLocalStorage();      timeWritten = parseInt(temp.split("_")[0] || 0);      if (temp === "" || (currentTime - timeWritten) > durationInMS)  {         localStorage.setItem(localStorageKey, currentTime + "_" + visitorId);      } } In the following example, the b object is a reference to the current data layer. copyVisitorIdToLocalStorage(b.tealium_visitor_id); b[localStorageKey] = getVisitorIdFromLocalStorage(); Keep this line to always use the localStorage value as the default: b.tealium_visitor_id = b[localStorageKey] || b.tealium_visitor_id Using the Code Example Provided You can use the code example provided as-is or adapt the code for your own purposes. To use the code as-is, follow the instructions below. Use the following steps to try it out: Open the above GitHub gist link, click Raw, and cut and paste the code your clipboard. Go to iQ Tag Management to add a new JavaScript Code extension. Paste the code into the extension. To enable, save and publish to your development (dev) environment for testing. To view the ID values in local storage, type localStorage in the web console. Map the tealium_visitor_id to a tag vendor, such as Google Analytics. For detailed information about data mapping in TiQ, see Data Mapping. Next, clear your cookies in the same browser and then view the visitor ID value sent to your tag vendor. Clearing out cookies effectively simulates Safari behavior when you have not visited the website in seven days. It is unknown when or if Safari will add restrictions to local storage as it currently does with cookies set using document.cookie . Unfortunately, work-arounds such as this will probably increase the odds of this happening sooner rather than later. At the same time, it is expected that the vendors that rely entirely on first-party cookies for anonymous visitors ID's will, at some point, implement their own solution to eliminate the need for work-arounds. Regardless, I hope you enjoy browsing this code even if it's for your own curiosity. Happy coding! ... View more

ITP Blog Series: Part 1 | Part 2 In my previous blog post, I covered how businesses use third-party cookies to identify users as they move across web sites. This practice is now being challenged by ITP 2.1 in Safari and by similar approaches in other browsers. I discussed two different workarounds that some vendors are using to combat the problem. But each workaround still has limitations, and this post is an overview of some other solutions we have seen our customers implement to maintain visitor identification for their website users. Authentication and Hashed IDs The first is authentication. If you have an authenticated user, you can use their username or email address to create a hashed ID. Hashed IDs are anonymous to the human eye and can be consistent across domains. A simple example would be: "example@example.com" MD5 hash: "23463b99b62a72f26ed677cc556c44e8". When done right, hashed IDs can provide a consistent identifier that is difficult to decode without information on your users. And if you have a visitor authenticating on multiple sites, you will have a 100% match, which gives you the ability to see the full customer journey. In fact, vendors like SAP’s Gigya specialize in helping clients login and authenticate with Google or Facebook IDs. As a result, many web sites now prompt users for a Facebook or Google login before they allow viewing content. As authentication becomes more common, it will be more accepted and less likely to be ignored, and visitor behavior tracking may become more accurate (if less private). Iframes and Post Message Another potentially effective solution is creating iframes in first-party domains. Evidence of achieving success with this approach is largely anecdotal and may run into legal and technology issues. Link Decoration Link decoration is a great way to carry visitor IDs from one site to the next as a user clicks from one site to another. Here's how it works: both the origin site and the destination site agree on a query string parameter to use to pass a shared identifier. This parameter is appended to all links from the origin site to the destination site. For example, instead of "http://example.com/page/link.html", the decorated link would be, "http://example.com/page/link.html?shared_param=VALUE_TIMESTAMP". As the origin site displays pages, this parameter is dynamically added to the links. The parameter value usually contains two values: the user's identifier and a timestamp. The identifier can be any unique value to the user, but it's best if it doesn't contain any personally identifiable information (PII), such as an email address. The timestamp ensures that the parameter values don't get shared between users. When the user lands on the next page, the destination site reads the shared query parameter from the URL, decodes the identifier and timestamp to validate the value, and stores the shared identifier for use. Visitor Stitching Sometimes, it's important to understand visitor behavior from a week or a month ago (across multiple sessions). To do this, you can stitch multiple IDs together. The most common use case for this is if your visitor is unknown and appears to be there for the first time. If this visitor later authenticates, you can connect one session to a previously-authenticated session. Ideally, the consumer would then be rewarded for logging in, with the reward being based on their previous behavior (i.e. a 15% off offer on items viewed before). Summary Uniquely identifying visitors as they move across web pages on your site or move between multiple sites has been relatively easy for many years. Apple's ITP in the Safari browser introduces technology that makes this more difficult. While many opportunities exist to potentially improve accuracy, there is no guaranteed or fool-proof solution in web analytics. The general rule with web analytics is keep an eye on the trends. Data’s great value is in understanding what behavior means and where you can take action. If and when you've found a technical solution, be sure that you are also complying with your company's privacy policy. It's also best to be open and transparent with your website visitors about how you track, why you track, and how it improves their experience. Check back with us soon for the next post in this series. You can also submit your own blog post about ITP or other trending industry topics by sending a line to community@tealium.com. ... View more

ITP Blog Series: Part 1 | Part 2 Why Third-Party Cookies is a Hot Topic This blog series explores the impact of data privacy regulation and third-party cookie blocking on data tracking techniques for anonymous and authenticated visitors on websites. The online advertising and marketing industry, that was built on a foundation of data collection, is now being challenged by new restrictions imposed by browsers to limit who and what data can be tracked. This series takes a look at the new restrictions and how technology vendors are responding with workarounds. The ITP blog series will continue throughout the upcoming months and include partner solutions or other custom solutions implemented by Tealium clients. To subscribe to the TLC Blog to get notifications of new posts, click the gear icon in the upper right-hand corner on this page, then click Subscribe. The Challenge Historically, third-party cookies (those typically set by advertisers in their own domains) have been an essential technique for tracking visitor behavior across multiple domains. This is used to measure advertisement impression and click counts, one of the main drivers in understanding the influence of those ads on visitor conversions on your site (purchases, sign-ups, etc.). Those third-party cookies connect the dots between what a visitor did before coming to your site and what they did after. Today, those same third-party cookies, that have long been an industry standard, are coming under scrutiny to address on-going privacy concerns. Recent updates to Intelligent Tracking Prevention (ITP 2.1) on Safari and anti-tracking on Firefox are creating new challenges for brands that rely on on that third-party tracking data to fuel their businesses. Now that Safari browser is not only blocking third-party cookies, but also expiring first-party cookies after 7 days of inactivity, the race is on to come up with creative workarounds. Current Industry Workarounds The livelihood of some businesses is at stake here, so tag vendors are finding increasingly complex and creative ways to accomplish what was previously done with third-party cookies. One approach is simply to pass an identifier via a query string parameter from the source domain the destination domain. This requires a bit more work by each domain to coordinate that exchange of data, but it's a relatively straight forward technical solution, especially when vendor's such as Google Analytics offer it as a plugin. Facebook has also taken notice and updated their tag to offer a similar workaround. Another technique that's shown promise is browser fingerprinting. Marketing vendors are developing patent pending algorithms that create a kind of fingerprint of visitors based on their unique browser information. This anonymous method of identification is a surprisingly good substitute for a third-party cookie and the more ingenious the fingerprint, the more likely it's a unique match to the visitor. But, of course, the browsers have caught on to these workarounds. Safari has already built-in "fingerprinting defense", a way to spoof browser information to thwart known fingerprinting techniques. It's a game of cat and mouse that won't be ending anytime soon. In the next part of this series we'll look at more workarounds that are being implemented with iQ Tag Management. Check back with us soon for the next post in this series. You can also submit your own blog post about ITP or other trending industry topics by sending a line to community@tealium.com. ... View more

The following describes the changes available in the SiteCatalyst templates released on Sept 2, 2015. The Tag names are "SiteCatalyst" and "SiteCatalyst AppMeasurement for JS."   How do I know that I have the latest template that has this feature? At the top of the template is a date (timestamp) that begins with the template ID and the date in format YYYYMMDD. This feature is added in "20150827" template. //~~tv:19004.h27.20150827 Note: This timestamp is the tag template update date (which will be earlier than the date this template is made available in production). You would also expect this feature in a later template (e.g. 20150929) Event Serialization If I have "myevent" in my data layer and this is mapped to "click:event5" in mapping toolbox then the following would trigger "event5" with the serialization number 12345. utag.view( { myevent : "click:12345" } ); Firing Multiple Events The updated template allows for two or more events by adding another mapping and using a comma-separated list of strings in the data layer. In the example below, we have "product-view:prodView" in mapping and also add a "product-view" string in the list of values in our data layer variable "myevent". utag.view( { myevent : "product-view,click:12345" } ); Because Javascript is nice enough to convert arrays to strings, and add a comma in the process, the following array works the same as a comma-separated list in a string: utag.view( { myevent : ["product-view", "click:12345"] } ); Note: If you expect spaces in your mapped variable then use an Extension to clean up the values, the template will not do any variable value manipulation (i.e. no string clean up). If there is a list of values and multiple matches in mapping, the event will only fire once (i.e. only added once to s.events). In the blog link below, it appears Adobe has another way of doing event serialization server-side. This feature appears to no longer be needed in the implementation and can be done with reporting configuration in Adobe's UI.     Additional Reading Event Serialization inside Omniture Sitecatalyst Event Serialization Say hello to On-Demand Metrics in Adobe Analytics   ... View more

The Tealium Collect service can be used by sending data directly to an endpoint associated with your account. The format is a simple URL with query string parameters, similar to many tag pixels you've seen before. This endpoint can be used in applications where you might be unable to implement on of our standard installation libraries (such as JavaScript or iOS). A newer Tealium Collect Pixel is available as the Tealium Collect HTTP API. Table of Contents Placeholder Resource URL  The Tealium Collect URL collects data via the query string parameters. The following parameters are required: tealium_account - The account name for AudienceStream/Tealium iQ tealium_profile - The profile name where you have AudienceStream configured for Audiences or EventStream tealium_vid - The Visitor ID or secondary ID such as Device ID from which the tracking request originates tealium_trace_id - [optional] - Only used when testing with the Trace feature All additional parameters added to the query string are treated as your data layer. //collect.tealiumiq.com/vdata/i.gif?tealium_account=ACCOUNT&tealium_profile=PROFILE&tealium_vid=ID&name1=value1&name2=value2 Examples Email Tracking Tracking email impressions usually requires manually adjusting the HTML code. And since JavaScript is not allowed in emails, using the Tealium Collect Pixel is the perfect solution to send email tracking data directly to the Customer Data Hub. Let's use a Cyber Monday Promotion email as an example, using the following data layer: { "page_type" : "email", "email_id" : "cyber_monday_2016" } The corresponding Tealium Collect Pixel would be: //collect.tealiumiq.com/vdata/i.gif?tealium_vid=1234567890&tealium_account=ACCOUNT&tealium_profile=PROFILE&page_type=email&email_id=cyber_monday_2016 This pixel can then be added as a 1x1 pixel to your HTML email to track impressions. Special Formatting Some integrations within the Customer Data Hub support variables in the form of an array of items in a  URI-Encoded JSON format. The expected format for a list of items (Array) would be as follows: Variable: product_id=["prod1","prod2","prod3"] Collect Pixel format:  product_id=%5B%22prod1%22%2C%22prod2%22%2C%22prod3%22%5D   ... View more

See also: Complete list of versions of utag.js. Update your copy of utag.js to take advantage of the latest fixes and enhancements. utag.js 4.46 (June 2018) Adds support for the following new built-in variables: tealium_session_number - a duplicate of the existing value in utag.data['cp.utag_main__sn'] tealium_session_event_number - the cookie value in utag.data['cp.utag_main__se'] that counts the number of tracking calls (utag.view(), utag.link()) in the current session (visit). This is useful for Single Page Apps (SPAs) where there is only one page load with many tracked events on that page. For pages using the 'noview' flag, the value will be '1' for both page load (load rule evaluation) and the first call to utag.view(). Adds support for an empty param list passed into utag.link/view/track calls.  In previous versions, calls to utag.link() or utag.view() would work fine, but would get an extra 'cfg' object added to the data layer. Calls to utag.track() would cause an exception in previous versions. For pages using 'noview' flag, there are two things to keep in mind: The data layer will have a '1' value for tealium_session_event_number for both page load (utag.js uses data layer to loads in tags) and first call to utag.view (which fires tags and/or loads in more tags.) Because cookies are used and initialized at page load time, if the utag.view call does not happen in time on the first page, and the page is refreshed in browser, it will move to '2' for the first utag.view call which happens on second page.  This should be an edge case as most implementations will fire utag.view immediately after utag.js executes. This update also includes fixes for the "OU" function used by legacy Privacy Manager Extension. The OPTOUTMULTI cookie is re-checked with each call to utag.view/link (no page refresh required) Tags fired directly by tag's UID will also check the OPTOUTMULTI cookie settings before firing utag.js 4.45 (January 2018) Fixes bug introduced in version 4.40 that added an extra entry in browser history for pages that loaded the same tag in an iframe more than once. This issue likely impacted Single Page Apps (SPAs) using iframe-based tag vendors. utag.js 4.44 (June 2017) Added support for visitor session counting for utag.js hosted on "tags.tiqcdn.cn" (China). Updated the default utag_main cookie domain logic for domains following the pattern "example.XX.jp" (where cookies cannot be set in the XX.jp domain, but can be set in "example.XX.jp" domain). utag.js 4.43 (June 2017) Removed use of global variable 'i' -- previously used in loop through global variable utag_cfg_ovrd (config override object) Removed legacy s2s support (as this was previously removed from Tealium iQ.)  Cloud Delivery supported in UDH. Adds support for error handler function passed into utag.ut.loader utility function.  This is only for modern browsers (older browser will likely call the standard callback "cb" function instead -- at least that's what I saw on IE7 and IE8) utag.ut.loader({ "src" : "https://www.example.com/path/file.js", "cb" : function(){console.log("CALLBACK")}, "error" : function(){console.log("ERROR IN LOADING")} }); utag.js 4.42 (August 2016) Add new built-in Tealium event attributes. These new attributes are added to the data layer with each Tealium view or link event. tealium_visitor_id: the Tealium-generated 1st party ID in the cookie "cp.utag_main_v_id" tealium_session_id: the epoch timestamp string of current session start in ms tealium_account: the account string value in the path to the utag.js file tealium_profile: the profile string value in the path to the utag.js file tealium_environment: the environment string value in the path to the utag.js file (i.e. "dev" or "prod") tealium_datasource: set to empty string (reserved for future use only) tealium_random: a random number as a string for use in cache busting tealium_library_name: the name of the library ("utag.js") tealium_library_version: the version of the utag.js (i.e. "4.42.0" for this release) tealium_timestamp_epoch: current epoch time in seconds as an integer tealium_timestamp_utc: current ISO string timestamp for UTC time zone (not available on older browsers) tealium_timestamp_local: current ISO string timestamp for browser's time zone (not available on older browsers) utag.js 4.41 (June 2016) Minor update to fix typo for the fallback function in utag.ut.encode. The "encodeURIComponent" call now falls back to use JavaScript's "escape" call for the exception when encoding badly-formed unicode characters. utag.js 4.40 (April 2016) Improvements in behavior in Single Page App (SPA) sites using utag.link and utag.view Previously, items in current data layer passed to utag.link/view were merged into the utag.data global object. This was required to re-evaluate load rules for each utag.link/view call. The utag.js 4.40 template takes advantage of a publish engine update so that this is no longer required. In version 4.40, the utag.data global object will not be updated with each utag.link or utag.view call. IMPORTANT: You may use the following JS Extension to test for backwards compatibility with v4.39 behavior before updating to v4.40.  // JS Extension scoped to "Before Load Rules" utag.ut.merge( b, utag.data, 0 ); utag.ut.merge( utag.data, b ,1 ); New "noconsole" flag. This flag can be set in utag_cfg_ovrd object to true and will stop any output from utag.DB from displaying in the web console. If debugging is enabled, the output will still persist in the utag.db_log array. Creating an iframe in DOM using utag.ut.loader function If an iframe with the same ID already exists, the iframe will not be added again. Instead, the iframe src is updated. Updating JS Page vars value for utag.view/link calls JS Page vars are now updated to their current value with every call to utag.view or utag.link. As a result the b["js_page.my_global_var"] will have the latest value in "window.my_global_var" each time utag.link is called. Bug fix to keep "cp.utag_main_ses_id" in the data layer with every utag.link/utag.view call The value is now updated with a new session id following a utag.link/view call that occurs when the visitor has been on the same page for 30 minutes with no activity. Removed trick to use "eval" to read the document.referrer value into the data layer's b["dom.referrer"] New utag.ut.encode function This function falls back to use escape when encodeURIComponent issues an exception (an exception is possible when attempting to encode Unicode characters that are incomplete or incorrectly formed). _t_visitor_id and _t_session_id are no longer available Auto-generated data layer values "_t_visitor_id" and "_t_session_id" are no longer available. These are replaced by "ut.visitor_id" and "ut.session_id". If still desired, you can add them back in as follows: // JS Extension scoped to "Before Load Rules" b["_t_visitor_id"] = b["cp.utag_main_v_id"]; b["_t_session_id"] = b["cp.utag_main_ses_id"];   ... View more

  As you know, SEO is not an exact science.  I'd love to get feedback from those who try out Tealium's new SEO (JSON-LD) tag:   Blog:   Tealium and SEO with JSON-LD   Documentation   Tealium SEO (JSON-LD) Tag Configuration ... View more