Tag Archives: 33 sticks cross-post

Industry Docs Series #1: the Solution Design Reference (the not-so-secret sauce)

33 Sticks Logo- Orange Circle with 3|3 in it

(This is cross-posted from the 33 Sticks blog)

Almost every organization that uses Digital Analytics has some combination of the following documents:

  • Business Requirements Document
  • Solution Design Reference/Variable Map
  • Technical Specifications
  • Validation Specifications/QA Requirements

All of the consulting agencies use them and may even have their own special, unique versions of them. They’re often heavily branded and may be closely guarded. And it can be very difficult to find a template or example as a starting point.

In my 11 years as a consultant who focuses on Digital Analytics implementation, I’ve been through MANY documentation templates. I’ve used the (sometimes vigorously enforced) templates provided by whoever was my current employing agency; I’ve used client’s existing docs; I’ve created and recreated my own templates dozens of times. I’ve used Word documents, Google Sheets, txt/js documents, Confluence/Wiki pages, and (much to my chagrin) Powerpoint presentations (there’s nothing wrong with Powerpoint for presentations, but it really isn’t a technical documentation tool). I’ve in turn shared out templates and examples both within agencies and more broadly in the industry, and I’ve now decided it’s time to stop hoarding documentation templates and examples, and share them publicly in a git repo, starting with the most foundational: the Variable Map (sometimes called a Solution Design Reference, or SDR).

The Variable Map

You may or may not have a tech spec or a business requirements document, but I bet you have a document somewhere that lays out the mapping of your custom dimensions and metrics. Since Adobe Analytics has up to 250 custom eVars, 75 custom props, and up to 1000 custom events, it’s practically essential to have a variable map. In fact, the need for a quick reference is why I created the PocketSDR app a few years ago (shameless plug) so you could use your phone to check what a variable was used for or what its settings are. But when planning/maintaining an implementation, you need a global view of all your variables. This isn’t a new idea: Adobe’s documentation discusses it at a higher level, Chetan Gaikwad covered it on his blog more recently, Jason Call blogged about this back in 2016, Analytics Demystified walked through it in 2015, and even back in 2014, Numeric Analytics discussed the importance of an SDR. Yet if you want a template, example, or starting point, you still generally have to ask colleagues and friends to pass you one under the table, use one from a previous role/org, or you just start from scratch. This is why 33 Sticks is making a generic SDR publicly available on our git repo.

The cats out of the bag

There are various reasons folks (including me) haven’t done this in the past. For practitioners, there is (understandably) a hesitance to share what you are doing- you might not want your brand to be associated with how good/not good your documentation is, and/or you may not want to give your competitors any “help” (more on that in an upcoming podcast). For agencies, there may be a desire to not show “the man behind the curtain”, or they may believe (or at least want their clients to believe) that their documentation is special and unique.

So why am I sharing it?

  • Because I don’t think the format of my variable map is actually all that special- a variable map is a variable map (but that doesn’t mean we should all have to start from scratch every time). This isn’t intended to be the end-all-be-all of SDRs, but rather, as a starting point or an example for comparison. Any aspect of it might be boring/obvious to you, overkill, or just not useful, but my hope is that there is at least a part of it that will be helpful.
  • Because while I DO think I have some tricks that make my SDRs easier to use, I recognize that most of those tricks are things I only know or do because someone in the industry has shared their knowledge with me, or a client let me experiment a bit to find what worked best.
  • Because 33 Sticks doesn’t bill by the hour and I have no incentive to hoard “easy”/low-level tasks from my clients. If a client comes to me and says “I used your blog post to get started on an SDR without you”, I can say, “Great! That leaves us more time to get into more strategic work!”
  • Because where I can REALLY offer value as a consultant isn’t in the formatting/data entry part of creating an SDR, but rather, in the thought we put into designing/documenting solutions, and in how we help clients focus on goals and getting long-term value out of data so they don’t get stuck in “maintenance mode.”
  • And finally, because I’m hoping to hear back from folks and learn from them about what they’re doing the same or differently. We all benefit from opening up about our techniques.

Enough with the pedantry, let’s get back to discussing how to create a good SDR.

SDR Best Practices

It’s vitally important you keep your variable map in a centrally-accessible location. If I update a copy of the SDR on my hard drive, that doesn’t benefit anyone but me, and by the time I merge it back into the “global” one, we may already have conflicts.

It should go without saying, but keeping it updated is also a good idea. I actually view most types of Digital Analytics documentation as fitting into one of two categories: primarily useful at the beginning of an implementation, OR an ongoing, living document. Something like a Business Requirements Document COULD be a living document, but let’s be honest: its primary value is in designing the solution, and it can have a high level of effort to keep it comprehensively up-to-date. Technical specifications for the data layer are usually a one-time deal: after it is implemented, it goes into an archive somewhere. But the simple variable map… THAT absolutely should be kept current and frequently referenced.

Tools for Creation/Tracking

If you’re already using Adobe Analytics, then you probably need to get an accurate and current list of your variables and their settings. Even if you have an SDR, you should check if it matches what’s set up in your Analytics tool. You could always export your settings from within the Admin Console, but I’ve found the format makes the output very difficult to use. I’d recommend going with one of the many other great industry tools (all of which are free):

These tools are great for getting your existing settings, but they don’t leave a lot of room for planning and documenting the full implementation aspects of your solution, so usually I use these as a source to copy my existing settings into my SDR.

What should an SDR contain?

On our git repo, you’ll see an Excel sheet that has a generic example Variable Map. Even if you have an SDR that you like already, take a look this example one- there may be some items you might get use of (plus this post will be much more interesting if you can see the columns I’m talking about).

Pretty much ALL Variable Maps have the following columns (and mine is no different):

  • Variable/Report Name (eg, “Internal Search Terms”)
  • Variable/Report Number (eg, “eVar1”)
  • Description
  • Example Value
  • Variable Settings

But over the years I’ve found a few other columns can really make the variable map much more use-able and useful (and again, this all may make more sense if you download our SDR to have an example):

A “Sorting Order” or Key

If, like me, you love using tables, sorting, and filtering in Excel, you may discover that Excel doesn’t know how to sort eVars, props and events: because it isn’t fully a number or string, it thinks that the proper order is “eVar1, eVar10, eVar2, eVar20”. So if you’ve sorted for some small task and want to get back to a sensible order, you pretty much have to do things manually. For this reason, I have a simple column that has nothing other than numbers indicating my ideal/proper/default order for my table.


This is for those who live their lives in analytics beacons rather than reports, like a QA team. It’s nice to know that s.campaign is the variable, and it is named “Tracking Code” in the reports, but it’s not exactly obvious that if you’re looking in a beacon, the value for s.campaign shows in the “v0” parameter.

Variable Type

Again, I love me some Excel filtering, and I like being able to say “show me just my eVars” or “show the out of the box events”. It can also be handy for those not used to Adobe lingo (“what the heck is an eVar?”). So I have a column with something like the following possible values:

  • eVar- custom conversion dimension
  • event- custom metric (eg “event1”)
  • event- predefined metric (eg “scAdd”, “purchase”)
  • listVar- custom conversion dimension list (eg, “s.list1”)
  • predefined conversion dimension (eg, “s.campaign”)
  • predefined traffic dimension (eg, “s.server”)
  • products string
  • prop- custom traffic dimension

For things like this, where I have specific values I’ll be using repeatedly, I’ll keep an extra tab in the workbook titled “worksheet config”. Then I can use Excel’s “data validation” to pull a drop-down list from that tab.


This is my personal favorite- I use it every day. It’s a way to sort/group variables and metrics that are related to each other- eg, if you are using eVar1, eVar2, prop1, event1, and event2 all in some way to track internal search, it’s nice to be able to filter by this column and get something like this:

The categories themselves are completely arbitrary and don’t need to map to anything outside of the document (though you might choose to use them in your Tech Spec or even in workspaces). Here’s a standard list I might use:

  • Content Identification
  • Internal Search
  • Products
  • Checkout
  • Visitor Segmentation
  • Traffic Sources
  • Authentication
  • Validation/Troubleshooting

Again, I could create/maintain this list in a single place on my “worksheet config” tab, then use “Data Validation” to turn it into a drop-down list in my Variable Map.


This basically answers the question “is this variable currently expected to be working in production?” I usually have three possible values:

  • Implemented
  • Broken (or some euphemism for broken, like “needs work”)
  • In progress

Data Quality Notes

This is for, well, notes on Data Quality. Such as “didn’t track for month of March” or “has odd values coming from PDP”.

Last Validated

This is to keep track of how recently someone checked on the health of this variable/metric. The hope is this will help prevent variables sitting around, unused, with bad data, for months or even years. I even add conditional formatting so if it has been more than 90 days, it turns red.


Where would I expect to see this variable/metric? Is it set globally? Or maybe it happens on all cart adds?


I’m certainly not unique in having this column, and I’m probably not unique in how many SDRs I’ve seen where this column has not been kept up-to-date. I’d like to stress the importance of this column, though- you may think the purpose of a variable is obvious, but almost every company I’ve worked with has at least one item on their variable map where no current member of the analytics team has any idea what the original goal was.

Ideally, the contents of this column would align with the “Description” setting within the Admin Console for each variable, so that folks viewing the reports can understand how to use the data.

We ARE all setting and using those descriptions, right? RIGHT?

Logic/Formatting and Example Value

Your Variable Map needs to have a place to detail the type of values you’d expect in this report. This:

  • helps folks looking at the document to understand what each variable does (especially if you don’t have stellar descriptions)
  • lets developers/implementers know what sort of data to send in
  • provides a place to make sure values are consistent. For instance, if I have a variable for “add to cart location”, there’s no inherent reason why the value “product details page” would be more correct than “product view”… but I still only want to see ONE of those values in my report. If folks can look in my variable map and see that “product details page” is the value already in use, they won’t go and invent a new value for the same thing).

I often find it a good exercise to run the Adobe Consulting Health Dashboard and grab the top few values from each variable to fill out this column.

Source Type

What method are we using to get the value for the data layer? I usually use Excel Data Validation to create this list:

  • query param
  • data layer
  • rule-based/trigger-based (like for most events, which are usually manually entered into a TMS rule based on certain conditions)
  • analytics library (aka, plugins)
  • duplicate of another variable

Dimension Source or Metric Trigger

This contains the details that complement the “source type” column: If it comes from query parameters, WHICH query parameter is it? If it comes from the data layer, what data layer object is it? If it’s a metric, what in the data layer determines when to fire it (for instance, a prodView event doesn’t map directly to a data layer object, but it does RELY on the data layer: we set it whenever the pageType data layer object is set to “product details page”.)

Variable Settings

This is something many SDRs have but can be a pain to keep consistent, because every variable type has different settings options:

  • events
    • type
      • counter (default)
      • numeric
      • currency
    • polarity
      • Up is good (default)
      • Up is bad
    • visibility
      • visible everywhere (default)
      • builders
      • hidden everywhere
    • serialization
      • always record event (default)
      • record once per visit
      • use serialization ID
    • participation
      • disabled (default)
      • enabled
  • eVars
    • Expiration
      • Visit (default)
      • Hit/Page View
      • Event (like purchase)
      • Custom
      • Never
    • Allocation (note: this is less relevant these days now that allocation can be decided in workspace)
      • Most Recent (last) (default)
      • Original Value (first)
      • Linear
    • Type
      • Text string (default)
      • Counter
    • Merchandising
      • Disabled (default)
      • Product Syntax
      • Conversion Syntax
    • Merchandising Binding Events
  • Props
    • List Prop
      • Disabled (default)
      • Enabled
    • List Prop Delimiter
    • Pathing
      • Disabled (default)
      • Enabled
    • Participation
      • Disabled (default)
      • Enabled

As you can see, you’d have to account for a lot of possible settings and combinations- I’ve seen some SDRs with 30 columns dedicated just to variable settings. I tend to simplify and just have one column where I only call out any setting that differs from the default, such as “Expires after 2 weeks” or “merchandising: conversion syntax, binds on internal search event, product view, and cart add.”


This should list any classifications set up on this variable. This is a good one to keep updated, though I find many folks don’t.

GDPR Considerations

Don’t forget about government privacy regulations! Use this to flag items that will need to be accounted for in your privacy policies and procedures. Sometimes merely having the column can serve as a good reminder that privacy is something we need to consider when designing our solution.

TMS Rule and TMS Element

I find these very helpful in designing a solution, but I’ll admit, they often fall by the wayside after an implementation is launched- and I don’t even see that as a bad thing. Once configured, your TMS implementation should speak for itself. (This will be even more true when Adobe releases enhanced search functionality in Launch.)

Other tabs

Aside from the variable map, I try to always have a tab/sheet for a Change Log. If nothing else, this can help with version control when someone had a local copy of the SDR that got off sync from the “official” one. It also lets you know who to contact if you have questions about a certain change that was made. I also use this to flag which changes have been accounted for in the Report suite Settings (eg, I may have set aside eVar2 for “internal search terms”, but did I actually turn it on in the tool?)

If you have many Report Suites, it may be helpful to have a tab that lists them all- their friendly name, their report suite ID, any relevant URLs/Domains, and perhaps the business owner of that Report Suite.

Also, if you have multiple report suites, you may want to add columns to the variable map or have a whole separate tab that compares variables across suites (the Report Suite exporter and the Observepoint SDR Builder both have this built in).

What works for you?

As I said, I don’t think my template is going to be the ultimate, universal SDR. I’d love to know what has worked for other people- did I miss anything? Is there anything I’m doing that I should do differently? Do you have a template you’d like to share? I’d love to hear from you!

Enhanced logging for Direct Call Rules and Custom Events for Launch/DTM

33 Sticks Logo- Orange Circle with 3|3 in it

(This is cross-posted from the 33 Sticks blog)

UPDATE: The wonderful devs behind Adobe Launch have seen this and may be willing to build it in natively to the product. Please go upvote the idea in the Launch Forums!

As discussed previously on this blog, Direct Call Rules have gained some new abilities so you can send additional info with the _satellite.track method, but unfortunately, this can be difficult to troubleshoot. When you enabled _satellite.setDebug (which should really probably just be called “logging” since it isn’t exactly debugging) in DTM or Launch, your console will show you logs about which rules fire. For instance, if I run this JavaScript from our earlier blog post:

_satellite.track("add to cart",{name:"wug",price:"12.99",color:"red"})

I see this in my console:

Or, if I fire a DCR that doesn’t exist, it will tell me there is no match:

Unfortunately, this doesn’t tell me much about the parameters that were passed (especially if I haven’t yet set up a rule in Launch), and relies on having _satellite debugging turned on.

Improved Logging for Direct Call Rules

If you want to see what extra parameters are passed, try running this in your console before the DCR fires:

var satelliteTrackPlaceholder=_satellite.track //hold on to the original .track function
_satellite.track=function(name,details){ //rewrite it so you can make it extra special
      console.log("DCR NAME: '"+name+"' fired with the following additional params: ", details)
      console.log("DCR NAME: '"+name+"' fired without any additional params")
   //console.log("Data layer at this time:" + JSON.stringify(digitalData))
   satelliteTrackPlaceholder(name,details) //fire the original .track functionality

Now, if I fire my “add to cart” DCR, I can see that additional info, and Launch is still able to run the Direct Call Rule:

You may notice this commented-out line:

//console.log("Data layer at this time:" + JSON.stringify(digitalData))

This is for if you want to see the contents of your data layer at the time the DCR fires- you can uncomment it if that’d also be helpful to you. I find “stringifying” a JavaScript object in console logs is a good way of seeing the content of that object at that point in time- otherwise, sometimes what you see in the console reflects changes to that object over time.

Improved Logging for “Custom Event”-Based Rules

If you’re using “Custom Event” rules in DTM or Launch, you may have had some of the same debugging/logging frustrations. Logs from _satellite.setDebug will tell you a rule fired, but not what extra details were attached, and it really only tells you anything if you already have a rule set up in Launch.

For example, let’s say I have a link on my site for adding to cart:

Add To Cart!

My developers have attached a custom event to this link:

var addToCartButton = document.getElementById("cartAddButton"); 
addToCartButton.addEventListener("click", fireMyEvent, false); 
function fireMyEvent(e) { 
   var myCustomEvent = new CustomEvent("cartAdd", { detail: { name:"wug", price:"12.99", color:"red" }, bubbles: true, cancelable: true }); 

And I’ve set up a rule in Launch to listen to it:

With my rule and _satellite.setDebug in place, I see this in my console when I click that link:

But if this debugging doesn’t show up (for instance, if my rule doesn’t work for some reason), or if I don’t know what details the developers put on the custom event for me to work with, then I can put this script into my console:

var elem=document.getElementById("cartAddButton")
elem.addEventListener('cartAdd', function (e) { 
  console.log("'CUSTOM EVENT 'cartAdd' fired with these details:",e.detail)
}, false);

Note, you do need to know what element the custom event fires on (an element with the ID of “cartAddButton”), and the name of the event (“cartAdd” in this case)- you can’t be as generic as you can with the Direct Call Rules.

With that in place, it will show me this in my console:

Note, any rule set up in Launch for that custom event will still fire, but now I can also see those additional details, so I could now know I can reference the product color in my rule by referencing “event.detail.color” in my Launch rule:

Other tips

Either of these snippets will, of course, only last until the DOM changes (like if you navigate to a new page or refresh the page). You might consider adding them as code within Launch, particularly if you need them to fire on things that happen early in the page load, before you have a chance to put code into the console, but I’d say that should only be a temporary measure- I would not deploy that to a production library.

What other tricks do you use to troubleshoot Direct Call Rules and Custom Events?

Adobe’s performanceTiming plugin, with some improvements and an explanation

33 Sticks Logo- Orange Circle with 3|3 in it

(This is cross-posted form the 33 Sticks blog)

As Page Performance (rightfully) gets more and more attention, I’ve been hearing more and more questions about the Performance Timing plugin from Adobe consulting. Adobe does have public documentation for this plugin, but I think it deserves a little more explanation, as well as some discussions of gotchas, and potential enhancements.

How It Works

Adobe’s Page Performance plugin is actually just piggybacking on built-in functionality: your browser already determined at what time your content starting loading and at what time is stopped loading. You can see this in a JavaScript Console by looking at performance.timing:

This shows a timestamp (in milliseconds since Jan 1, 1970, which the internet considers the beginning of time) for when the current page hit certain loading milestones.

Adobe’s plugin does look at that performance timing data, compares a bunch of the different milestone timestamps versus each other, then does some math to put it into nice, easy-to-read seconds. For instance, my total load time would be the number of seconds between navigationStart and loadEventEnd:

1556048746779 (loadEventEnd) – 1556048745659 (navigationStart) = 1120 milliseconds, or 1.12 seconds.

Additionally, if I choose to, I can have the plugin grab information from the built-into-the-browser performance.getEntries(), put it into session storage (not a cookie because it can be a long list), and put it into the variable of your choice (usually a listVar or list prop) on the next page. These entries show you for EACH FILE on the page, how long they took to load.

Unfortunately, if I’m sending my analytics page view beacon while the page is still loading, then the browser can’t tell me when “domComplete” happened…. because it hasn’t happened yet! So the plugin writes all these values to a cookie, then on your NEXT beacon, reads them back and puts them into numeric events that you define when you set the plugin up. This means you won’t get a value on the first page of the visit, and the values for the last page of the visit won’t ever be sent in. It also means you don’t want to break these metrics down by page, but rather by PREVIOUS page- so often this plugin is rolled out alongside the getPreviousValue plugin. This also means that the plugin is not going to return data for single-page visits or for the last page of visits (it may collect the data but doesn’t have a second beacon to send the data in on). for this reason, your Performance Timing Instances metric may look significantly different from your Page Views metric.

What It Captures

Out of the box, the plugin captures all of the following into events:

  • Redirect Timing (seconds from navigationStart to fetchStart- should be zero if there was no redirect)
  • App Cache Timing (seconds from fetchStart to domainLookupStart)
  • DNS Timing (seconds from domainLookupStart to domainLookupEnd)
  • TCP Timing (seconds from connectStart to connectEnd)
  • Request Timing (seconds from connectEnd to responseStart)
  • Response Timing (seconds from responseStart to responseEnd )
  • Processing Timing (seconds from domLoading to loadEventStart)
  • onLoad Timing (seconds from loadEventStart to loadEventEnd)
  • Total Page Load Time (seconds from navigationStart to loadEventEnd )
  • Instances (for calculated metric- otherwise you only really get the aggregated seconds, which is fairly meaningless if your traffic fluctuates)

Which gets you reporting that looks like this:

…Which, to be honest, isn’t that useful, because it shows the aggregated number of seconds. The fact that our product page took 1.3 million seconds in redirect timing in this reporting period means nothing without some context. That’s why that last metric, “instances”, exists: you can turn any of the first 9 metrics into a calculated metric that shows you the AVERAGE number of seconds in each phase of the page load:

This gives me a much more useful report, so I can start seeing which pages take the longest to load:

As you can see, the calculated metric can use either the “Time” format or the “Decimal” format, depending on your preference.

Performance Entries

As mentioned previously, the plugin can also capture your performance entries (that is, a list of ALL of the resources a page loaded, like images and JS files) and put them into a listVar or prop of your choice. This returns a list, delimited by “!”, where each value has a format that includes:

The name of the resource (ignoring query params)!at what second in the page load this resource started loading!how long it took for that resource to finish loading!resource type (img, script, etc).

For example, on my blog, I might see it return something like this:


From this, I can see every file that is used on my page and how long it took to load (and yes, it is telling me that the last resource to load was my analytics beacon, which started .7 seconds into my page loading, and took .2 seconds to complete). This is a LOT of information, and at bare minimum, it can make my analytics beacons very long (you can pretty much accept that most of your beacons are going to become POST requests rather than GET requests), but it can be useful to see if certain files are consistently slowing down your page load times.

An Enhancement: Time to Interaction

Unfortunately, the plugin most commonly used by folks omits one performance timing metric that many folks believe is the most critical: Time to DomInteractive. As this helpful site states:

  • Page Load Time is the time in which it takes to download the entire content of a web page and to stabilize.
  • Time to Interactive is the amount of time in which it takes for the content on your page to become functional and ready for the user to interact with once the content has stabilized.

In other words, Page Load Time might include the time it takes for a lot of background activity to go on, which may not necessarily stop the user from interacting with the site. If your page performance goal is for the best user experience, then Time To Interaction should be a key metric in measuring that. So, how do we track that? It already exists in that performance.timing object, so I tweaked the existing plugin code to include it. I can then create a calculated metric off of that (Time to Interactive/Page Performance Instances) and you can see it tells a very different story for this site than Total Page Load Time did:

9.49 seconds DOES sound like a pretty awful experience, but all three of these top pages had a much lower (and much more consistent) number of seconds before the user could start interacting with the page.

Basic Implementation

There are three parts to setting up the code for this plugin: before doPlugins (configuration), during doPlugins (execution), and after doPlugins (definition).


First, before doPlugins, you need to configure your usage by setting s.pte and s.ptc:

s.pte = 'event1,event2,event3,event4,event5,event6,event7,event8,event9,event10,event11'
s.ptc = false; //this should always be set to false for when your library first loads

In my above example, here is what each event will set:

  • event1= Redirect Timing (seconds from navigationStart to fetchStart- should be zero if there was no redirect)- set as Numeric Event
  • event2= App Cache Timing (seconds from fetchStart to domainLookupStart)- set as Numeric Event
  • event3= DNS Timing (seconds from domainLookupStart to domainLookupEnd)- set as Numeric Event
  • event4= TCP Timing (seconds from connectStart to connectEnd)- set as Numeric Event
  • event5= Request Timing (seconds from connectEnd to responseStart)- set as Numeric Event
  • event6= Response Timing (seconds from responseStart to responseEnd )- set as Numeric Event
  • event7= Processing Timing (seconds from domLoading to loadEventStart)- set as Numeric Event
  • event8= onLoad Timing (seconds from loadEventStart to loadEventEnd)- set as Numeric Event
  • event9= Total Page Load Time (seconds from navigationStart to loadEventEnd )- set as Numeric Event
  • event10= Total Time to Interaction (seconds from connectStart to timeToInteraction)- set as Numeric Event. NOTE- THIS IS ONLY ON MY VERSION OF THE PLUGIN, OTHERWISE SKIP TO INSTANCES
  • event11= Instances – set as Counter Event

I’d also need to make sure those events are enabled in my Report Suite with the correct settings (everything should be a Numeric Event, with the exception of instances, which should be a Counter Event).


Within doPlugins, I need to just run the s.performanceTiming function. If I don’t want to capture performance entries (which is reasonable- not everyone has the listVars to spare, and it can return a VERY long value that can be difficult to get value out of), then I fire the function without any arguments:


If I DO want those performance entries, then I add the name of that variable as an argument:


Also, you’re going to want to be capturing Previous Page Name into a prop or eVar if you aren’t already:


(If you are already capturing Previous Page Name into a variable, you don’t need to capture it separately just for this plugin- you just need to be capturing it once somewhere).


Finally, where I have all of my plugin code, I need to add the plugin definitions. You can get Adobe’s version from their documentation, or if you want it with Time To Interactive, you can use my version:

/* Plugin: Performance Timing Tracking - 0.11 BETA - with JKunz's changes for Time To Interaction. 
Can you guess which line I changed ;)?*/
s.performanceTiming=new Function("v",""
+"var s=this;if(v)s.ptv=v;if(typeof performance!='undefined'){if(perf"
s.performanceWrite=new Function("",""
+"var s=this;if(performance.timing.loadEventEnd>0)clearInterval(s.pi)"
+"var pt=performance.timing;var pta='';pta=s.performanceCheck(pt.fetc"
+");pta+='^^'+s.performanceCheck(pt.loadEventEnd,pt.navigationStart);pta+='^^'+s.performanceCheck(pt.domInteractive, pt.connectStart);"
+"v!='undefined'){var pe=performance.getEntries();var tempPe='';for(v"
+"ar i=0;i<pe.length;i++){tempPe+='!';tempPe+=pe[i].name.indexOf('?')"
s.performanceCheck=new Function("a","b",""
+"ed(2);}else{return 600;}}");
s.performanceRead=new Function("",""
+"var s=this;if(performance.timing.loadEventEnd>0)clearInterval(s.pi)"
+";var cv=s.c_r('s_ptc');if(s.pte){var ela=s.pte.split(',');}if(cv!='"
+"'){var cva=s.split(cv,'^^');if(cva[1]!=''){for(var x=0;x<(ela.lengt"
+"[s.ptv]='sessionStorage Unavailable';}s.ptc=true;");
/* Remove from Events 0.1 - Performance Specific, 
removes all performance events from s.events once being tracked. */
s.rfe=new Function("",""
+"var s=this;var ea=s.split(s.events,',');var pta=s.split(s.pte,',');"
+"try{for(x in pta){s.events=s.rfl(s.events,pta[x]);s.contextData['ev"
/* Plugin Utility - RFL (remove from list) 1.0*/
s.rfl=new Function("l","v","d1","d2","ku",""
+"var s=this,R=new Array(),C='',d1=!d1?',':d1,d2=!d2?',':d2,ku=!ku?0:"
+"if(L[i]!=v&&C)R.push(C[1]);else if(L[i]!=v)R.push(L[i]);else if(L[i"
+"]==v&&ku){ku=0;if(C)R.push(C[1]);else R.push(L[i]);}C='';}return s."

You’ll also need to have s.apl and s.split.

You can see a full example of what your plugins code might look like, as well as a deobfuscated picking-apart of the plugin, on our gitHub.

Performance Entries Classifications

I recommend if you ARE capturing Performance Entries in a listVar, setting up 5 classifications on that listVar:

  • Resource/File
  • Starting Point
  • Duration
  • Duration- Bucketed (if desired)
  • Resource Type

Then set up a Classification Rule, using this regex string as the basis:


In our git repo, I have a full list of the classification rules and regex I used, including how to bucket the durations so you get less granular values like “0.5-1.0 seconds”, which can give you a report like this:

Implications for Single Page Apps

Unfortunately, this plugin will NOT be able to tell you how long a “virtual page” on a single page app (SPA) takes to load, because it relies on the performance.timing info, which is tied to a when an initial DOM loads. This isn’t to say you can’t deploy it on a Single Page App- you may still get some good data, but the data will be tied to when the overall app loads. Take this user journey for example, where the user navigates through Page C of a SPA, then refreshes the page:

As you can see, we’d only get performanceTiming entries twice- once on Page A and once on the refreshed Page C. Even without the “virtual pages”, it may still be worth tracking- especially since a SPA may have a lot of upfront loading on the initial DOM. But it’s not going to tell the full story about how much time the user is spending waiting for content to load.

You can still try to measure performance for state changes/”virtual pages” on a SPA, but you’ll need to work with your developers to figure out a good point to start measuring (is it when the user clicks on the link that takes them to the next page? Or when the URL change happens?) and at what point to stop measuring (is there a certain method or API call that brings in content? Do you having a “loading” icon you can piggy back on to listen to the end?). Make sure if you start going this route (which could be pretty resource intensive), you ask yourselves what you can DO with the data: if you find out that it takes an average 2.5 seconds to get from virtual page B to virtual page C, what would your next step be? Would developers be able to speed up that transition if the data showed them the current speed was problematic?

Use the Data

Finally, it’s important to make sure after you’ve implemented the plugin, you set aside some time to gather insights and make recommendations. I find that this plugin is one that is often used to just “check a box”- it’s nice to know you have it implemented in case anyone ever wants it, but once it is implemented, if often goes ignored. It is good to have in place sooner rather than later, because often, questions about page performance only come up after a change to the site, and you’ll want a solid baseline already in place. For instance, if you’re migrating from DTM to Launch, you might want to roll this plugin out in DTM well in advance of your migration so after the migration, you can see the effect the migration had on page performance. Consider setting a calendar event 2 weeks after any major site change to remind you to go and look at how it affected the user experience.

Could I be the next Analytics Rock Star?

33 Sticks Logo- Orange Circle with 3|3 in it

(This is cross-posted from the 33 Sticks Blog)

I’m honored to be included in the “Analytics Rock Stars 2019: Top Tips and Tricks” session at Adobe Summit this year in Vegas. I made my way onto the Rock Stars panel based on my entry for the inaugural Adobe Insider Tour stop in Atlanta, where I shared two tips:

  • Want to use Virtual Report Suites in place of Multi-suite tagging, but stuck on the need for different currency code settings? I’ve found a work-around that uses Incrementor Events so you can get local and report-suite-converted currency reports!
  • Copy and classify built-in Activity Map values to create automatic and friendly user navigation reports!

I don’t want to go into too much detail on this post- if you want more info, you’ll have to come to my session or ask me directly. Sign up for the session, then come introduce yourself!

Also, you may also want to check out Hila Dahan’s session on Advanced Calculated Metrics: Forecasting, Statistical Significance & Churn.

DTM-to-Launch Migration Series #3: The Migration Process

33 Sticks Logo- Orange Circle with 3|3 in it

(This is cross-posted from the 33 Sticks Blog)

Thus far in this series, we’ve discussed your options for a DTM-to-Launch Migration, and some potential areas you can improve upon your solution as part of a migration. As you can see from my previous posts, there are a lot of possible considerations for a DTM-to-Launch migration. So what might the actual process look like to get your company on Launch instead of DTM?

Figure Out How You’ll Roll Out

Does it make sense for your org to roll Launch out all at once to all of your properties? Or would you prefer to bite off one chunk at a time? (For instance, one client is currently updating their internal search single page app, so they’re going to roll out Launch there first, as a sort of guinea pig.) Keep in mind that even if you are only rolling out Launch to 3 pages first, ANY roll out is going to have to tackle some global logic- it may be that those first three pages are the hardest because you’ll need to tackle how to handle not just the requirements for those three pages, but also global items like authentication status or global marketing tags.
If you do want to roll out all at once, you can keep using the same DTM embed code you always have so your developers don’t need to make changes to the pages, but that’s an all-or-nothing option (once you switch to Launch, Launch will “own” that embed code unless you choose to re-publish from DTM), and it only works in prod (dev/staging environments will still need the new embed codes).

Also, if you’re considering having DTM and Launch run alongside each other on the same page…. don’t even consider this an option. It won’t work. Both tools use the _satellite object and one WILL overwrite the other and/or get very confused by the presence of the other.


Keep in mind the effort to validate things- even if you are doing a “simple lift-and-shift”, you will still need to validate that Launch is doing all the things that DTM had been doing. Depending on how well-documented your current implementation is, and/or what QA efforts are currently in place, this may mean figuring out what it is that DTM is currently doing so you know whether Launch is matching it or not. This is a golden opportunity to set up some QA processes, if you haven’t already.
If you don’t have a solid process already in place, you won’t be able to test every possible beacon for every possible user, but you should can set up a testing procedure in place for critical beacons on your most typical flows. Note, none of this is specific to DTM or Launch, but is a best practice regardless and will help with the DTM-to-Launch migration.

  • Establish key user flows and document each beacon in the flow’s expected variables
  • Use a tool like Observepoint or Hub’scan to automate testing
  • For your KPIs, in Adobe Analytics set up anomaly detection and/or alerts based on reasonable thresholds (alert me if revenue dips below $___ or visits climbs above ___)

This is all much easier if you used the migration as a chance to document your solution.

Audit What You’ve Got and What You Want

Unfortunately, Adobe does not provide a great way to document all of your current rules and data elements in DTM. Fortunately, there is a tool to help: Tagtician has a free chrome extension that can create a spreadsheet with a list of all your data elements, rules (including third party tags and what is deployed in the Adobe Analytics/Google Analytics section of each rule.) I cannot overstate how incredibly helpful this has been for every DTM migration project I’ve been on.
Depending on how ambitious our migration plans are (on a scale of “lift-and-shift” to “burn it down and start fresh”), I’ve used this as a basis for a new solution design, so we know on each user action what variables are expected, where those variables are set, and where they pull their information from:

Then I take that to figure out how to deploy it through Launch (which may or may not look anything like how it was deployed in DTM): for instance, if pageName is always going to get it’s value from the same data element, I can set that in a global rule that fires on all page loads. Whereas my search variables can get their own rule, which will combine with the global rule on the search results page to create one analytics beacon with all the variables I need. Now that you can control load order and when analytics beacons fire in Launch, you may be able to really compartmentalize logic based on scope and get rid of redundancy in your implementation.

Decide On Your Publishing Flow

Launch has a new publishing flow- it’s no longer just staging vs production. You now have development (as many environments as you need), staging, and production; no changes automatically get built into a library unless you set it up to; you can use libraries to group together changes and move a group through the flow. If you only have one person in Launch at a time, and that one person tends to do most approvals and publishes, then the flow can definitely seem like “too much.” But for a lot of bigger organizations, this new flow is a game changer.
Part of moving to Launch is figuring out how this flow should apply to your organization. For example, one client came up with something similar to this:

At the start of each sprint, they create a library with that sprint name, and link it to the main dev environment. Each member of their analytics team has their own permanent library in dev, linked to alternative dev environments (which aren’t referenced by any pages and are only really interacted with through the switcher plugin- basically a sandbox for them to build in, using the switcher plugin to see the effect of their efforts in dev). As changes are completed and pass their first round of validation, they get moved into the Sprint’s library, which at the end of the sprint moves into Staging, where it is validated by the developer/UX QA team before being approved and published. (This is just an example- there is no single “right way” to use this flow, it was designed to be flexible for a reason.)
Be aware, once a library has “claimed” an environment (which is linked to an embed code), no other library can claim that environment, so if you want multiple libraries you will need multiple dev environments.
Also, you can no longer use code in a developer console to switch between environments- currently, the only way I know to switch between environments is to use the Search Discovery switcher chrome extension or to use something like Charles Proxy Map Remote.

The Migration Project Plan

A DTM-to-Launch migration can become quite the involved project. For the simplest of migrations, it still may be 4-6 weeks to migrate within the tools, do any necessary validation, and publish your changes. It may only need to be one or two main analytics/TMS folks and/or a QA person working on it.
Or, it may be a 9 month project that involves devs, QA/UAT, data architects, analysts… don’t underestimate the resource cost of the migration (though at the same time, don’t undervalue the long-term resource savings if you take the time to get it right as part of the migration and (re)build a scalable, maintainable, well-documented solution.)
For instance, below is an example of how a Launch migration could go. This example does not include any changes to the data layer, but does include a substantial attempt to re-deploy analytics rather than merely shift the existing implementation with all the same rules and data elements.

Next Steps and Resources

As you can see, even a simple lift-and-switch to Launch can be a bit involved, and folks can feel daunted by all the considerations, options, and things to be aware of. I’ve tried to be as thorough and comprehensive as possible in this series, and I hope I hit the right level of detail to give practical guidance on how to tackle a DTM-to-Launch migration. There is a great community out there for folks who need DTM/Launch support- check out the following resources:

Hopefully this series helped, but feel free to reach out if you have questions or if you’d like to engage with us to make sure you get off on the right foot as you move to Launch.

DTM-to-Launch Migration Series #2: A Golden Opportunity

33 Sticks Logo- Orange Circle with 3|3 in it

(Cross-posted from the 33 Sticks blog)

Aside from all of the things that Launch handles better than DTM did (which I discussed a bit in my previous post in the series), a move to Launch provides an opportunity to clean up and optimize your implementation (to the point that even if you weren’t moving to Launch, you could still do this clean up within DTM). You can save yourself from headaches and regret down the line if you take the time now to define some standards, adopt some best practices, or apply some “lessons learned” from your DTM implementation.

Redo Your Property Structure

Many companies set up their DTM properties based on a certain understanding of how properties should be used, and realized a bit too late that a different set up might work better.
previous post of mine on this topic is still applicable in Launch: your properties should not be based on Report Suites or domains, but rather, on the three following questions:

  • How similar are the implementations between your sites (do they use the same data layer, for instance? Would the rules be triggered by the same conditions?)
  • How similar are the publication timelines (if you publish a change for Site A, would it also apply to Site B at that time?)
  • Will the DTM/Launch implementation be maintained/updated by the same folks? (Properties are a good way to control user access.)

Keep in mind Launch has an API for configuration, so if you have 15 properties and want to make a change to all of them at once, you now can (though that API is not yet super documented/supported, so it’s a bit of a wild west so far). In general, I’ve seen folks using Launch as an opportunity to move to fewer properties.

Define Standards and Best Practices

Now is a great time to take lessons learned from DTM and define the standards your company will follow within Launch. Some things are arbitrary- it doesn’t really matter if I name the rule “Product Details Page View” or “page: product details”, but if we are consistent from the start, it can save us a lot of head ache and cleanup down the road.

Tags With the Same Condition(s)/Scope Should Share the Same Rule

To keep your library light, and your implementation scalable and maintainable, I highly recommend basing your rules on their scope/condition, rather than the tags they contain. For instance, a single rule named “Checkout: Order Confirmation” is better than 10 different rules that fire on Order Confirmation- “Doubleclick Order Confirmation” and “Google Conversion Tags”, etc.
I’ve written previously about why this matters– it can have a surprising affect on page performance (not to mention it cane make your TMS impossible to navigate/maintain), and that still applies in Launch.

Delete redundant and unused stuff

Run an audit of your DTM property. Do you have redundant or unused Data Elements? Empty (or permanently commented-out) rules or Third Party Tags? Inactive rules or data elements that aren’t likely to ever be used again? Often folks are afraid to delete things within DTM, but this is a great chance to delete anything that isn’t still useful.

Institute a Naming Schema

This is your chance to have a nice, clean naming standard in your TMS. Consider all the following things you can name in Launch:

  • Data Elements: I try to keep to the same [category]:[details], though since Launch doesn’t show the DE type from the DE list like DTM does, I also like to include the type: “search: term: QP” (QP for Query Parameter) or “checkout: order total:DL” (DL for Data Layer). I also prefer keeping everything for Data Elements lowercase so I don’t have to worry/remember how I capitalized things.
  • Rules: In DTM I liked to do something like “[category]:[scope/condition]” (eg “Search: Results”, “Catalog: Product Details”, “Checkout: Cart View”.) In Launch, because DCRs, EBRs and PLRs now share the same interface, I like to take it a step further and include the rule type at the front: “Page: Search: Results” or “Click: Search: Filter”. If you have a lot of rules potentially firing into the same beacon, then I’d also include info about the order (eg, “Page: Global: All Pages #100” and “Page: Home #25” so you know that the #100 one would fire AFTER the #25 one on the home page.) I’ve also found it helpful to call out the rules which actually fire my analytics BEACON as opposed to rules that run higher in the order and only set variables (eg: “Page: Global: All Pages (s.t) #100”). Then within Rules, there are more naming considerations than there had been in DTM:
    • Events: Should be descriptive, and it may be worth including the load order (so “Page Top- #100” or “Direct Call: Add to Cart #50” might do the trick.)
    • Conditions/Exceptions: Conditions and Exceptions particularly should have some sort of custom naming (instead of a condition “Core – Value Comparison”, I might name it “pageName DE=’search results’”).
    • Actions: I’ve been leaving some with the default (eg, “Adobe Analytics – Set Variables”, though depending on how complicated my implementation is, I might want to change that to “Analytics- Content Identification variables”). Any Core/Code actions should have a descriptive name (“Yahoo pixel- expires 12/19/19” or similar.)

Fix Up Your Data Layer

This is perhaps a very ambitious task for most migrations, but if you’re already taking the effort to audit your DTM implementation, now might be a good time to also look at your data layer- do you have data layer objects that aren’t being used in DTM at all currently? (Be aware, of course, that data layers don’t always exist solely for a TMS’s sake- make sure no one else is using it either). Before you go creating a bunch of data elements, is there something you wish your data layer had that it currently doesn’t? Or do you wish it were structured differently? Now might be a good chance to optimize it! Especially if you are rolling Launch out to one part of your site at a time, you may be able to work with devs to break up a Data Layer rollout into reasonable chunks. You may be surprised by how many devs are on board with fixing up the data layer, particularly if your current on is messy/confusing.

Move Third Party Tags to Asynchronous JS

This is one of the biggest areas for improvement I’ve seen amongst my current and past clients- they’ve potentially been using DTM for years and haven’t always taken advantage of DTM’s ability to improve page performance by moving third-party tags to asynchronous javascript.All tag managements systems have inherent weight- you are adding a JS library to your site. If you don’t mitigate this weight by using the TMS to optimize your tags, your TMS may be having a net-negative affect on your site- a substantial one, in many cases. I’ve written previously about the approach I would recommend for third-party tags, but to emphasize the importance of this: I have seen the overall page load time improve by 15-30% by simply moving tags within DTM to async. Unless the vendor’s code affects the user experience (chat, survey or optimization tools, for instance), there is no reason for most tags to be anything other than non-sequential JS.

In Launch, you can take it a step further, and use extensions to further optimize your tags. For instance, if you use Facebook or Doubleclick, there are extensions in place that you can use to move those tags entirely out of custom code blocks. Or, if you are deploying a simple pixel tag and the vendor does not have an extension, you can use 33 Sticks’ Pixel Loader extension to easily change it from an html  tag to asynchronous javascript.

Document Everything!

Moving to Launch also provides the ability to get solid, current documentation on your solution. Aside from auditing your solution (I’ll take about that in a moment) so you know which rules are setting what or what is expected in the Data Layer on certain pages, I also recommend using this fresh start as a change to document and enforce your standards and best practices for TMS deployment. For instance, I’ve helped clients create a confluence document that anyone at thier company who might be within Launch can access, detailing:

  • Naming Strategy (see notes above)
  • Third Party Tag deployment standards (which tags are “approved” by your org for use- as in, “do not use one TMS to deploy another TMS like GTM, not unless you hate your site loading quickly”); deploying tags as asynchronous JS- see note above…)
    • I also recommend as part of the auditing/documentation process getting a list of all your third party tags, documenting who at your org “owns” that tag, and setting “expiration/renewal” dates (“Jan Smith owns this floodlight tag, deployed 8-5-18; on 9-5-18 we will contact her to see if the tag is still valid or can be deleted”).
  • Best Practices (don’t check “apply handler directly to element” without good reason, try to limit the number of Data Elements used in “Data Element Change” rule triggers, etc.)
  • Publication Flow (how is your org using libraries and environments? Who approves and who publishes? Will publishing happen with a specific cadence, like every other Wednesday? What is your QA/validation process? Do you want to implement an “all changes must be reviewed by someone other than the person who made the change” rule?)

I know this level of documentation can be daunting and seem like overkill, but your future staff/employees will thank you for it, even if it’s informal and/or a work-in-progress.

Change Your Deployment Method (Adobe-Managed vs Self-Hosted)

DTM had a few deployment options:

  • An Adobe/Akamai-hosted library (ie, your embed code starts with “//assets.adobedtm.com”)
  • An FTP self-hosted library (DTM would push changes through FTP to a location on your own servers)
  • A downloaded self-hosting option (you would manually download after changes and put onto your servers).

Now may be an opportunity to change this- if you’ve been doing the manual download option because of security concerns, now that the publishing flow in Launch is more flexible/powerful, might you be able to simplify by moving to another option?

Technically, all three of these options also exist in Launch, though the approach is slightly different. I’ve documented in a separate post how you can achieve each of the three methods in Launch- especially the download method, which may not be intuitive for users who had used the download option in DTM.

Update Your visitorID/appMeasurement Libraries

A TMS upgrade is also a good chance to update to the most recent stable Adobe libraries (for instance, as of this moment, the most current Analytics library is 2.10). Unless you are doing something very custom/weird in your libraries (or are stuck in the dark ages on H code), updating should be a relatively easy process, and offers benefits like improved page performance.

It may also make sense to examine your doPlugins function (if you are still using it): do you have functionality you can move out of doPlugins (eg, do you still really need getQueryParam when you can just use the DTM/Launch interface?) (Also, word on the street is that some folks at Adobe may be releasing an extension to handle many of the common plugins, so that may provide some extra room for enhancement.)

Update cross-Adobe Tool integrations

If you’re not yet on the VisitorID service, you really should be. Then once you are on that, now would be a good time to update your implementation for integrating analytics with other Adobe tools:

  • If you use Target, are you on at.js (and is it current)? Do you have Analytics 4 Target (A4T) set up?
  • If you use Audience Manager, have you transitioned to a server-side integration? Are you currently deploying your DIL at the bottom of your Analytics code in DTM, and might you be able to transition that to use the AAM extension?

What’s Next

By now, you should have a sense of what type of migration path you’re going to take, and what aspects of your solution you may want to change or improve upon. The next post in the series will walk you through the actual process and provide a rough framework for a project plan.

DTM-to-Launch Migration Series #1: Options and Considerations

33 Sticks Logo- Orange Circle with 3|3 in it

(cross-posted from the 33 Sticks Blog)

Adobe’s Launch is really building momentum (they just announced the plan to sunset DTM– editing abilities end December 31st, 2019 July 1st, 2020; read-only access dies June 2020 December 31st, 2020 (dates updated to reflect Adobe’s change)), and in the past few months, it feels like almost every day, I get asked “what does a launch migration look like?”

And I’m afraid I have a very unhelpful answer: it totally depends.

We’ve had visibility into about a dozen migrations now, and each one has been a completely unique case. But I figured I can at least defend my answer of “it depends” by clarifying what it depends on, what the options are, and what considerations should you make.


Preparing to Migrate
 Adobe DTM to Launch Migration Options
 Things to be aware when moving from DTM to Launch

Using the Migration as an Opportunity
 Redo your property structure
 Define standards within Launch
 Clean up redundant/unused items
 Best practices for Rule scope/conditions
 Institute a Naming Schema
 Fix up your data layer
 Optimize your third party tags
 Document everything
 Change your deployment method
 How to use the download option
 Update your visitorID/appMeasurement libraries
 Update cross-Adobe Tool integrations

The Migration Process
 How to roll out Launch
 Audit what you have (and figure out what you want)
 Decide on a publishing flow that works for your org
 Create a Migration Project Plan
 Other Resources and Next Steps

Disclaimer: Info in this series is accurate as of, October 29, 2018. We will try to update it as it makes sense to do so, but things can change quickly in the world of TMSes and iterative product releases.

You’ve Got Options

As far as we see it, if you’re considering a move from Adobe DTM to Launch, you have a few options:

  1. Use the DTM-to-Launch Migration tool (SEE: Adobe’s documentation), essentially just doing a lift-and-shift of your current DTM implementation.
  2. Use the DTM-to-Launch migration tool, but do a fair amount of clean up before/after.
  3. Use a tool like Tagtician to audit what you currently have, decide what you want to carry over, and set it up “fresh” in Launch (have Launch accomplish the same thing as DTM, but perhaps accomplish it in different ways).
  4. Use this as a chance to rebuild your solution from the ground up.

Most folks we’ve talked to or worked with are looking at somewhere in that 2-3 range. In most cases, we’d strongly discourage going with option #1, that straight-up lift-and-shift. I PROMISE there is some room for review and improvement in your DTM implementation.

First, not everything in DTM will work in Launch. Our friends at Search Discovery have a great tool for detecting places within DTM that you may be using code that will no longer work (goodbye, _satellite.getQueryParam). (NOTE: this detects places in your DTM library you are using those “forbidden” functions- if you are using something like _satellite.getQueryParam in your own javascript outside of DTM, it will not detect it.)

Technically, aside from the things that that tool will flag, everything that worked in DTM should work in Launch (actually, there are a few major differences you should be aware of). BUT, many of the workarounds you may have resorted to in DTM are no longer needed, so you can definitely optimize things. There are some broader differences between DTM and Launch that open the door for some changes to your implementation that could be really valuable.

Consider the following questions:

Are you currently using DTM for Single Page Apps? (if so, you’ve almost certainly had to use some workarounds that are no longer needed)

Do you have any repeated global logic (all of your DCRs or EBRs might be setting “eVar5=%auth status%” because you didn’t have a way to get that eVar included on all beacons otherwise)

Do you use Direct Call Rules heavily?

Do you have s.clearVars running in odd places?

Are a large portion of your Analytics variables being set in custom code blocks instead of in the interface?

Do you fire any Direct Call Rules from within your DTM implementation (eg, DCRs calling other DCRs to get around timing/scope issues?)

Are you currently firing Adobe Analytics beacons from outside of the Analytics Tool (eg, are you using a third party tag box to fire s.t or s.tl because of timing issues?)

If you answered yes to any of the above questions (and perhaps even if not), then you absolutely should be considering moving to Launch ASAP, for all the reasons discussed on these other blog posts:

Differences between DTM and Launch to be Aware of

33 Sticks Logo- Orange Circle with 3|3

(cross-posted from the 33 Sticks blog)

There’s a lot of talk about how Adobe Launch is backwards-compatible- that, aside from a few _satellite methods that may not still work (that were probably not supported to begin with), anything you had in DTM should still work in Launch. But, well, not EVERYTHING in DTM is still going to work in Launch, and some things in Launch may catch you off guard. Here are some things you should be aware of:

Far fewer things happen automatically. For instance, Adobe Analytics no longer automatically fires a beacon on page load (which I view as a wonderful thing, but you still need to be aware of it). You need to set it up (and things like loading Target or firing Mboxes) in a rule.

 The following _satellite methods (among others, but these are the most common) are no longer supported (or, in some cases, may never have been supported but now simply won’t work).

  • _satellite.getQueryParam/_satellite.getQueryParamCaseInsensitive
  • _satellite.notify (this still technically works, but you should migrate to _satellite.logger)
  • _satellite.URI
  • _satellite.cleanText
  • _satellite.setCookie (which is now _satellite.cookie.set) and _satellite.readCookie (which is now _satellite.cookie.get)

 There is some interface functionality in DTM that is not yet in Launch:

  • There is no “notes” functionality currently (though I hear that is coming soon)
  • It’s not easy to do a revision comparison (diff compare) currently (though again, I hear that is in the works).

 Launch still has console debugging, but it no longer alerts you to what “SATELLITE DETECTED” (which I used a lot to troubleshooting bubbling issues)- it merely tells you what rules are firing, etc.

 Some tools like Tagtician or Disruptive Advertising’s DTM Debugger are not yet fully Launch-compatible. (Tagtician supports Launch but is working on improving how it handles it; I don’t know if the DTM Debugger has any plans to become Launch-compatible).

 The Adobe Analytics extension does not support multiple Adobe instances, nor can you have multiple Adobe Analytics extensions installed. (Multi-suite tagging is still ok).

 The Google Analytics extension does not support multiple GA instances.

 Some things have been renamed in a way that may throw you off- for instance, you can still easily have a Rule condition be based on a Data Element value- it’s just named “Value Comparison” now.

 While Launch gives you much more control over the order things happen in, be aware that while actions within a rule will START in the specified sequence, they may not COMPLETE in sequence: Action 1 will start, then Action 2 will start whether Action 1 is finished or not. This is particularly significant if the actions are just code (for instance, I had my first action try to pull information from an API, and my second action then use that info to fire a pixel… but the pixel kept firing before the API had done its thing). I hear that users may eventually get more control over this, but for now this is how it is.

 Adapters can be confusing (fortunately Jimalytics clears it up nicely on his blog). These days, Adobe automatically creates a “Managed by Adobe” adapter, and that single adapter should work for multiple environments.

None of these are necessarily a reason to not upgrade- especially since Adobe now has a plan for sunsetting DTM. But hopefully you won’t be caught unaware by any of these items. Has anything else surprised you about Launch? Let us know!

How to self-host a Launch Library using the download option

33 Sticks logo- Orange Circle with 3|3

(Cross-posted from the 33 Sticks Blog)

As mentioned in my series on migrating from DTM to Launch, DTM had a few deployment options:

  • An Adobe/Akamai-hosted library (ie, your embed code starts with “//assets.adobedtm.com”)
  • An FTP self-hosted library (DTM would push changes through FTP to a location on your own servers)
  • A downloaded self-hosting option (you would manually download after changes and put onto your servers).

Technically, all three of these options also exist in Launch, though the approach is slightly different. Since I ended up having to get some clarification from Adobe on how to use Launch to copy these methods, I figured I’d document my findings here . When creating an adapter, you have the option of Managed by Adobe or SFTP:

If you select SFTP, it’s slightly different from in DTM, but the effect is the same.

How To Use the “Download” Method

If you want to go the download route, you still can, but it’s a bit hidden, so I’ll walk through it. Choose “Managed by Adobe” here, but then when setting up the corresponding environment, choose “Create Archive” and specify where the file will live on your servers (this is important because each file within the library package needs to know how to reference other files within the library package):

(You can even encrypt the file if you’d like extra security, so that a password would be required to open/view the archive).

Then, once you’ve built the library (and you MUST build it AFTER you’ve set it to “create archive”, or there won’t be anything to download), when viewing your environments click on the “install” icon:

This should give you a popup where you have the ability to “Download Latest Archive”:

This should download a .zip to your browser, the contents of which you can now put on your server. Be aware that the folder(s) within this zip may change names between builds (like the “BL1f0491fb5eb14ad3b60996dd31aedaa6” folder in my image below, in a previous build had been “BL92309a949e564f269ce6719b1136910f”), so if you are trying to merely paste one build over another, you may want to clean out the old subfolders afterwards to keep the overall folder clean.

Hopefully this helps fill some of the documentation gaps out there. Please let me know if you have any additional insight or questions!

Presenting at Observepoint Virtual Summit

(Cross-posted from the 33 Sticks blog)

Join us for Observepoint’s Virtual Analytics Summit on October 25th! I’ll have the opportunity to speak about measuring and improving not just your data quality, but also the value you get OUT of the data: your data ecosystem, your processes, and your team’s roles.

In our industry, there is (deservedly) a lot of attention given to the health and quality of our data. Yet many organizations aren’t getting value out of their data, not (just) because the data is unhealthy, but because the org doesn’t have the right processes, people or overall mindset to be truly data-driven. Many orgs are still REactive about their data, rather than PROactive- the product team announces a new site feature, and the analytics team has to squeeze in some tracking at the last moment. Or the analytics team is so busy managing pixels and dashboard requests that they don’t actually get to dive in and gather insight to inform business decisions.

This became even more apparent with the roll out of GDPR (General Data Protection Regulation) last Spring- many companies were not (and perhaps are still not) ready to comply by the May 25th roll out. Our industry’s ability to be proactive and get in front of such initiatives isn’t a data quality issue (though certainly, rolling it out will be easier if your solution is well-documented and reliable)- it’s a matter of ownership, support, governance, and priority.

My presentation will walk through specific questions you can ask yourself to measure where there are opportunities for improvement in your ecosystem, with your processes, and with your roles/resources/ownership, as well as specific recommendations for next steps you can take. It will end with a Q&A session- I’d love to hear from you! Sign up for free on the event site, and check out the other amazing speakers and topics for the day.