Tealium Learning Center

Have you ever sat down to write something, or draw something and find yourself just staring at the empty page trying to force inspiration into being just by sheer will? I call it “Empty piece of paper syndrome” - it’s like the blankness is somehow contagious and gets into your head making everything seem foggy. It can be like this when it comes to thinking about data too, if there’s nothing to look at, it’s hard to think of what could be there. This is one of the reasons why AudienceStream, out of the box, comes with a whole bunch of useful attributes that are already configured. There are both Visit and Visitor attributes, and typically contain statistical information that may be useful to determine useful information about the visitor or visit. They don’t need any additional information from the visitor, just the standard web traffic data from the collect tag. Here is a list of all of the preloaded attributes (including the slightly contradictory “Unbadged” badge) as they are listed in the user interface. Visitor Attributes Visitor Attributes ID Type Description Average visit duration in minutes 26 Number Average visit duration in minutes Average visits per week 29 Number Average visits per week Fan 30 Badge More than two total visits and more direct visits than refers First visit 23 Date Date of first visit Frequent visitor 31 Badge Two or more average visits per week Last event URL 17 String Last event URL for visitor Last visit 24 Date Date of last visit Lifetime browser types used 57 Tally Tally of how many times each type of browser is used Lifetime browser types used (favorite) 56 String Captures the favorite metric for Metric Set: Lifetime browser types used Lifetime browser versions used 63 Tally Tally of browser versions used Lifetime browser versions used (favorite) 62 String Captures the favorite metric for Metric Set: Lifetime browser versions used Lifetime devices used 55 Tally Tally of devices used Lifetime devices used (favorite) 54 String Captures the favorite metric for Metric Set: Lifetime devices used Lifetime event count 22 Number Total number of events triggered by user Lifetime operating systems used 59 Tally Tally of operating systems used Lifetime operating systems used (favorite) 58 String Captures the favorite metric for Metric Set: Lifetime operating systems used Lifetime platforms used 61 Tally Tally of platforms used Lifetime platforms used (favorite) 60 String Captures the favorite metric for Metric Set: Lifetime platforms used Lifetime visit count 21 Number Total number of times user has visited site Returning visitor 27 Badge Return visitor Total direct visits 15 Number Total direct visits Total referred visits 16 Number Total referred visits Total time spent on site in minutes 25 Number Sum duration of all user visits Unbadged 32 Badge The visitor has not been assigned any badges Weeks since first visit 28 Number Weeks elapsed since first visit Visit Attributes Visit Attributes ID Type Description Active browser type 44 String The browser actively being used by the visitor Active browser types 49 Set of strings Deduplicated list of browser types used this visit Active browser version 48 String The browser version actively being used by the visitor Active browser versions 53 Set of strings Deduplicated list of browser versions this visit Active device 46 String The device actively being used by the visitor Active devices 51 Set of strings Deduplicated list of devices this visit Active operating system 45 String The operating system actively being used by the visitor Active operating systems 50 Set of strings Deduplicated list of operating systems Active platform 47 String The platform actively being used by the visitor Active platforms 52 Set of strings Deduplicated list of platforms Direct visit 14 Boolean The user navigated directly to the site Entry URL 5 String URL of the first page visited Event count 7 Number Total number of events in visit Exit URL 6 String URL of the last page visited Referred visit 13 Boolean The user was referred from another site Visit duration 12 Number Visit duration in minutes Visit end 11 Date Visit end date Visit start 10 Date Visit start date How to use them? Well, you can use them like any other attribute, in rules and enrichments for other attributes. So for example, you could use the frequent visitor badge directly to drive an audience to send an email saying “Thank you for being a regular visitor” or you could use “Total Direct Visits” and “Total Referred Visits” to work out the ratio for direct/referred visits for a user, and therefore how they engage with the site. You could potentially use the favorite lifetime operating system to perhaps alter the placement of specific downloads, making more relevant apps appear first. Or of course you can always just fire the data out for reporting purposes. Can I modify the preloaded attributes? We sometimes like to think of attributes like lego bricks to build whatever you need. Well, for preloaded attributes the lego bricks are kind of glued down so that the models can’t be broken. However - although the preloaded attributes themselves are fixed solid, you can duplicate them. The duplicate then contains all the enrichments and rules for you to modify as you need. For example here is a copy of the Frequent visitor badge: As you can see the rules are now visible, and you can modify them as you need to. If you have any questions or perhaps you’ve done something spectacular using just the preloaded attributes - please let us know! ... View more

At this time of year, thoughts turn to The List Everyone’s on it, no one is missed. Your whole year laid out, with all your behaviour, If you started off bad, then good deeds could save ya (Sorry) But.. Whether naughty or nice, let’s be realistic Santas list wouldn’t work if it was probabilistic. That’s device fingerprinting and screen resolution, Location to show nearest great institution,   Using statistical modeling - personas implied, Working out what was done, and what things were tried. All useful data, but the List needs to say “Who” Otherwise how will Santa know quite what to do? “Someone in Paris, who has lots of horses, Raised lots of money for charity causes, We know this because of device metadata We just don’t know who.. We’ll have to guess later? Someone in Belgium with this IP address, might have been bad, and caused some distress. We know they were there. And what WiFi was near.. We just can’t be sure who.. It just isn’t clear” You need certainty when you’re building The List, And Identities need to be sure, and not missed. That’s why Tealium uses deterministic IDs For visitor stitching, it’s the solution, you see. We still can store all the ‘probably’ data And things that might become relevant later But “Email”, “phone number”, “user ID”, something specific that relates to just me. That’s what we match on, that’s just the thing To super power your market.. ing. ... View more

What is an audience? When we talk about audiences in Tealium, we’re not talking about a theatre full of people watching the same movie. We actually mean more like “target audience”. According to Wikipedia “A target audience is the intended audience or readership of a publication, advertisement, or other message catered specifically to said intended audience.” So - at its core, when we refer to an Audience in Tealium, it is a group of individuals to which we want to send a specific message. Yes, ok, but what *is* an audience, technically? Technically, inside the system an audience is like a super-powered, actionable rule. It’s a set of criteria that, when people match that criteria we can trigger something to happen. Let’s say we wanted to set up a “Super fan” audience, for people who love to visit your website. We could set the audience criteria to be “Lifetime visit count is greater than or equal to 20” - meaning that it’s checking to see when people have visited the website more than 20 times. Now, all audiences are evaluated on every event to see if the individual’s data now matches the criteria for each audience. Imagine I’ve discovered your awesome website and I just keep coming back. I arrive on the site for my 20th visit, and the page view event gets sent through to the server-side systems. As the event attributes from the page view event get processed, the “Lifetime visit count” in my visitor profile gets incremented by one, and so ticks over from 19 to 20. After the processing of all of the event attributes from my arrival on the site, the visit and visitor attributes are enriched with any new relevant data, and then all of the audiences are evaluated to see which of their criteria my updated profile now matches. Because my lifetime visit count is now ‘greater than or equal to 20’ I have joined the audience for the first time. I’m now a “Super Fan”. (All that said, best practice would actually be to set a badge called Super Fan, and then set the audience criteria to “Badge ‘Super Fan’ is assigned.) Ok, great, I understand that.. How do we use it? Easy - use Audience connectors. Just some of the connectors available. Audience connectors are the route out from CDH to other third party systems. When I joined that “Super Fan'' audience it could be set to trigger an audience connector to send selected bits of data to Google or Facebook, or update Salesforce, or to an email vendor, or any one of a myriad of our other 3rd party pre-built connectors. Alternatively you can build your own webhook connector to connect to another system to do pretty much anything you need. From sending an SMS, updating a EPOS database system or making a bell ring in your sales office* Simply put - joining an audience can trigger a connector action, from which you can talk to the world. You can also trigger a connector action when someone is in an audience at the start of a new visit, or when they leave an audience, or, crucially, if they’re in an audience at the end of a visit. Using a combination of Joined Audience and Left Audience triggers, you can effectively synchronise audiences between AudienceStream and their equivalent audience in Facebook or similar. Wait - “End of visit ?!” They’ve gone by then, surely? Well, yes, they’ve left the website, or at the very least they’ve been completely inactive for 30 minutes (this can be changed, by the way) Perhaps they’re asleep or eating pizza - the point is when they left, we have a complete view of what they did during their visit, or possibly more importantly what they didn’t do. This is especially useful for Abandoned Basket or Abandoned Process scenarios, which I will go into further detail in a future blog post. Basically though, if they added to a basket in their visit but by the end of the visit they haven’t completed the purchase - we can re-target them using a connector action to an email vendor to say “Hey, you forgot to buy stuff! Please come back!!” If it’s a non-retail site, perhaps it could be starting the process to sign up for a test-drive of a car, or beginning to go down the route of signing up for a webinar but never actually pressing that final commit button - whatever the process, if they don’t finish it by the end of the visit, we can add them to that audience. Also just being able to update 3rd party systems at the end of a visit is super useful, even if it’s just to update “Favourite category over last 30 days” in your CRM system. In summary... An audience is like a special set of rules to determine that someone has met a certain set of criteria, and then the process of joining or leaving that audience can be used to trigger an action, and send data out to the world to make all kinds of things happen. ... View more

It is possible within Tealium iQ to add a javascript extension to get the battery status from the browser, much like it is within the mobile SDKs. This is a relatively easy custom extension that adds battery status (i.e. charging or not), percentage of charge and the time until the battery is flat to the data layer, for use within other tags or to send to the CDH.  The Tech The extension uses a javascript function called navigator.getBattery() to get the details from the battery manager API. This is currently supported by Chrome, Edge, Opera, and many other browsers, although not by Firefox or Safari. See https://caniuse.com/battery-status for more information on which browsers support it. However, rather than thinking of this as data that you sometimes can’t get, think of it as data can get which provides additional useful and interesting insight into a site visitor’s status. Setting Up the Code Add a new javascript extension, call it something useful like “Get Battery Status” and set the scope to “Pre loader”. This means the extension will run before any of the tags or load rules, and as it’s updating the on-page data layer, it will be available for use when all of the load rules fire and determine which tags to trigger. This will prove useful if you want to stop some tags from running if someone’s battery is going flat. The code below creates the default utag_data object* if it doesn’t already exist, then sets up the updateBatteryStatus function which sets three variables within the utag_data object. (*If your default data layer object is called something else, you can just change it in the code) These are: device_ischarging - set to either ‘charging’ or ‘not charging’ device_battery_percent - set to the percentage of charge remaining device_dischargeTime - How much time is remaining until the battery goes flat. The initial promise setup triggers the first updateBatteryStatus to update the variables on the page load event, and then sets up listener functions for onchargingchange to track changes in the charging status, onlevelchange to track changes in the charge and ondischargingtimechange to track the amount of battery time remaining. utag_data= utag_data || {}; function updateBatteryStatus(battery) { utag_data['device_ischarging'] = battery.charging ? 'charging' : 'not charging'; utag_data['device_battery_percent'] = battery.level; utag_data['device_dischargeTime'] = battery.dischargingTime / 60; } navigator.getBattery().then(function(battery) { // Update the battery status initially when the promise resolves ... updateBatteryStatus(battery); // .. and for any subsequent updates. battery.onchargingchange = function () { updateBatteryStatus(battery); }; battery.onlevelchange = function () { updateBatteryStatus(battery); }; battery.ondischargingtimechange = function () { updateBatteryStatus(battery); }; }) The Use Cases Ok, so it’s kind of cool to be able to get the data, but what can we actually do with it? Example 1: Don’t serve battery hungry tags. Everything on a webpage uses power, which if the battery is low, is actually surprisingly important. On my phone, Chrome is currently the app which has used the most power over the last 7 days and accounts for 7.2% of the total. (The next hungriest is Messenger with 2.5%) Once you know the battery status, if you are using iQ to serve any power-hungry tags such as some that push in video adverts or similar, you can add the details to the load rules to make sure that you don’t push that content in if it will drive their battery flat. Example 2: Battery data to CDH Does the visitor often use their device while not charging - this could indicate that they are more ‘mobile oriented’ and used to moving around rather than sitting at a desk, and could be useful in campaigns. Or it could be that they always let it get to 2% before charging, which may indicate a “just in time” type of personality trait. ... View more