Adobe Client Data layer extension - Datalayer incorporation

[SwatiPa]

When making use of the Adobe Client DataLayer extension and aiming to avoid direct integration of the data layer into the website's code, the question arises: Where should the data layer be included? Additionally, could you provide guidance on retrieving conversion variables within Omnibug?

[Jennifer_Dungan · Accepted solution]

I'm not really sure what you mean by "avoid direct integration of the data layer into the website's code".. 

The purpose of a data layer is to surface information / data into an object that your tracking can read, extract information from, and potentially trigger tracking events...

If you have variables on the page that contain the information you want to track, you don't need a data layer (you're just duplicating those values into another format but that data already exists....) And using Launch to build a data layer from information that you can already see is somewhat redundant.

On top of this, if you want to be able to track information that you can't see already; how are you planning on getting that information without having it come from your website/developers? (things such as backend ids, or keywords that are used to drive display element on the page, etc)

Short story is, if you can extract the data from the page when it loads, you can use that data directly without a data layer, and if you can't see that data then there is no way to get it.

Data Layers are handy to pull all the data (what you can see and what you can't) into one centralized easy to use location... but if you are trying to build your own data layer using Launch (so as to not have this code integrated) you are doing a log of extra work, since you will have to do the initial extraction, then push it into the Data Layer, then extract from the Data Layer for your actual tracking.

Now, as for your Omnibug question... this completely depends on what your implementation is doing and what you are trying to track.

eVars or "Conversion Variables" are used in a variety of ways, and most current implementations use them for more than just "conversions"... Adobe themselves have been trying to encourage people to consolidate to using eVars in an effort to try and simplify the tagging system.

Now, that said, eVars have the complication of having a default expiry of "Visit", meaning that the value, once set, will continue to be set in the eVar until the end of the Visit (or the custom expiry that it's configured to) or a new value is set on it (again remaining until expiry)... but you won't see the "carry forward" value in Omnibug; you will only see the call where the value is set.

• Page 1
  • eVarX is set with "value" (Omnibug will show "value")
  • Instance of eVarX (evar instance metric) is set
  • Page View metric is set
• Page 2
  • eVarX is not set, but the value ("value") remains in Adobe (Omnibug will not show eVarX)
  • No instance of eVarX (as this is only when a value is specifically placed into the eVar)
  • Page View metric is set
• Action 1
  • eVarX is not set, but the value ("value") remains in Adobe (Omnibug will not show eVarX)
  • No instance of eVarX (as this is only when a value is specifically placed into the eVar)
  • No Page View Metric set (this is an action)
  • Custom Link Instance is set (this is an action)
• Page 3
  • a new eVarX is set with "value2" (Omnibug will show "value2")
  • Instance of eVarX (evar instance metric) is set
  • Page View metric is set
• Page 4
  • eVarX is not set, but the value ("value2") remains in Adobe (Omnibug will not show eVarX)
  • No instance of eVarX (as this is only when a value is specifically placed into the eVar)
  • Page View metric is set

To quote a friend:

• eVars are like chewing gum on the sidewalk, once you step in it, it sticks to your shoe and stays with you until you dislodge it
• Props are like a banana peel, you set on it with an immediate result, then you carry on forgetting about it

eVars can be set up to act like Props (Hit Expiry), and for a lot of uses now, when they are not being used as conversions, Hit is the proper expiry (Page level dimensional data like Page Title, URL, etc)

Now, there are also metrics that you might fire on a conversion... some of these are standard (purchase, scAdd, etc) but there are also custom events (event1, event27, etc)

Events are passed as a comma separate list in the events item on the action that you can see in Omnibug:

events = "event1,event27,purchase"

Other standard events like Page Views and Occurrences aren't passed specifically in the tracking, they are calculated during the process of the data.

[yuhuisg]

Your web page's HTML can be like this:

<html>
<body>
  <script>
    var adobeDataLayer = adobeDataLayer || [];
    adobeDataLayer.push(...);
  </script>
  <script src="URL-of-your-Launch-snippet" />
  ...
</body>
</html>

i.e. define your "adobeDataLayer" before the Launch snippet script. When your Launch script runs, it loads the ACDL extension, and the extension will use the "adobeDataLayer" from your web page's HTML code.

[TLFish]

@yuhuisg Shouldn't the adobeDataLayer and the launch snippet be in the header of the page to work properly across a site? Or is this example simply referring to if only a single page is being tracked?

Thanks in advance for your response.

[yuhuisg]

@TLFish you're right, ideally, it should. As long as it's near the "top" of the page, then it should still work well, since it would be one of the first things that the browser executes before the rest of the page content.

BUT the order must remain:

1. Declare adobeDataLayer, optionally with some initial values.
2. Call the Launch snippet.