Do I need a data layer or can i use direct call for everything?

Question

Apparently there's a really old JavaScript way of updating props of an `s` variable. DTM is the more recent old way and Adobe Launch is the newest way. I'm using Adobe Launch. For a SPA, the docs suggest I can update my data layer then set up rules in the portal to copy the props from my data layer into adobe analytics for tracking pages. I also see that there's a way of doing a direct call using `window._satellite.track(eventName, payload)`.

What I'm wondering is if I need to bother with the data layer approach or if I can just direct call everything with `window._satellite.track` and configure in the portal which one is a page and which is an event/link? Currently I've got code that will use the data layer to track pages and a direct call to track things like specific click events. Ideally I can just do it all one way.

Thank you!

Garretth · Accepted Answer

Great question. I want to clarify a few points to check my understanding and ensure I am addressing your question.

A Direct Call rule is essentially a type of page event to trigger a Launch Rule. Whereas the data layer is meant to make the data you would send on the request more easily accessible. SPA implementations prefer Direct Call rules because the normal hooks, such as page load or page top, are less applicable as the page is not refreshing as the end user navigates the site. So a direct call rule placed in your code that simulates a new page load for example can help to track user navigation on an SPA.

In short they do not need to be mutually exclusive options. If you are able to access the data and set the variables within the rule without a data layer then that is fine.

Urs_Boller · Answer

while I mostly agree with the previous answers, I would like to write some words about those solutions and write, why I prefer a good data layer instead of direct call rules.

first, lets have a look at the two solutions:

direct call rules with additional parameters

direct call rules are very useful, since you can just trigger a specific rule in Adobe Launch and providing additional information (parameters). this additional data can then be used within the rules to set the Adobe Analytics variables/events just as needed.

additionally read great articles from jennkunz Direct Call Rules in Launch have a new power: passing additional info in _satellite.track - 33 Sticks or jexnerW4D https://webanalyticsfordevelopers.com/2018/09/18/quick-tip-passing-data-into-launch-rules/

data layer with event information

in this case the website doesn't call Adobe Analytics directly, it just writes information to a javascript object (or something similar). from there Adobe Launch can pickup the values as needed and trigger rules, similar to the direct call rules above.

there has been a big discussion recently by several experts, eg. Jim Gordon https://jimalytics.com/governance/you-need-a-data-layer/

and Search Discovery offers a handy extension to work with event-driven data layers (stewarts16448458) https://www.searchdiscovery.com/solutions/partners/adobe/adobe-launch/data-layer-manager/

my preference: data layer

having done some implementation both with DCR and the data layer manager, I strongly believe that the EDDL (event driven data layer) is my preferred solution.

here are just some points why I would go this way:

1) independent: the data layer lives in the application without a connection to the analytic tools. IT really loves it to skip the analytic tool and doesn't have any impact on the website. and if you once change your analytic tool, you do not have any impact on the website itself (just exchange the data layer manager)

2) access event stack: I love the "computedstate" of the data layer manager. basically it gives you the last value of a certain variable at any point. this would be much more work with DCRs.

I'm sure there are points for both solution, but I recommend using a data layer. and this doesn't mean the other solution is a "no go", just my preference.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded