We are facing an issue with rule firing, DOM ready event fires first and the pageview event (which sends data to adobe analytics) fires 3 seconds slower most of the time.
Ex: I've configured DOM ready event for Adobe analytics setting variables and used direct call event to send pageview to Adobe analytics, order value details are mentioned below
DOM ready order value set as 50
Direct call order value set as 99
Is this an issue with order value or event need to be changed as page bottom or top load to make this rule fire properly without any delay?
Mainly we are seeing a @data discrepany between Google and Adobe, Google analytics shows different page view data which is comparatively higher than Adobe Analytics. GA tag is configured via GTM and it will fire the tag when the page loads. Whereas Adobe launch setup has DOM ready to set variable and direct call to send pageview with different order value.
It would be very helpful if someone provides an answer to this query, facing this issue since long.
The delay that you're experiencing is not due to the "Rule Order" (rule order is only effects a process within a single trigger - you are using two different triggers: DOM Ready, and Direct Call('value') ). Instead, the strange delay is actually due to the cascading effect of using a Custom Code Action Block via postscribe to initiate the Direct Call. (in order for the code to execute, it may be further delayed by other things happening in the window (since you doing all this prior to onLoad).
Because your current DOM Ready rule does not have a trigger of Page Top or Page Bottom, the custom code for the action block is not embedded in the library itself, you are seeing the results of using postscribe to execute the custom code. It's also important to know that this code is executed outside of the timing control of Launch (meaning other Rules and Actions may happen before this postscribed code fully completes, yikes! ).
There's no way I could explain it better than Aaronius9er9er9er : So I'd recommend reading his post to grasp how and when postscribe is used. (link below)
You have a few options to eliminate the postscribe inefficiency:
Option 1 (if you want to continue using the direct call)
Take your custom code, and place it inside the setVars action block -> custom code area. This will ensure that your direct call can execute as soon as the variables have been set, without requiring the postscribe methods.
Option 2 (If you want to utilize Rule Order and standard Launch Trigger procedures)
- Have your first Rule on DOM Ready set the variables
- Make a second Rule also have the trigger of DOM Ready for sending the beacon. And then give it a Rule Order value greater than the first.
(This method works because DOM Ready is the same trigger used for multiple rules. It will initiate both of the rules, but do them in the correct "Rule Order")
Example of how this works:
"MyPage SetVars Rule" - DOM Ready Trigger (rule-order-01) - actions: setVars
"MyPage SendBeacon Rule" - DOM Ready Trigger (rule-order-02) - actions: SendBeacon + clearVars
Option 2 (if you can execute all actions from within the same rule)
Use your DOM Ready Rule for everything. Have a setVars action block, followed by a sendBeacon, followed by anything else you need.
Option 3 (i personally don't recommend it, but it would work)
If your rule had a trigger of Page Bottom instead of DOM Ready, then the code would be included in the library itself, and not need to make use of postscribe to execute.
This could be a few things, but would take some debugging to figure out for your particular scenario. The first thing that comes to mind is that AppMeasurement is not bundled into the main Launch library and is instead loaded as a separate file after one of the Adobe Analytics extension actions runs (Clear Variables, Set Variables, Send Beacon). It may be that the additional request for loading Adobe Analytics is leading to the extra time it takes for the beacon to be sent.
@gflare mentioned some things regarding custom code, but I'm not sure if you're using a Custom Code action. If you are, that could play a part.
Thanks a lot gflare for the brief answer and solutions.
Would be great if you could give any example or more clarity on the option 1.
"Take your custom code, and place it inside the setVars action block -> custom code area. This will ensure that your direct call can execute as soon as the variables have been set, without requiring the postscribe methods."
Thanks a lot Aaronius for sharing your review on this.
How do we check if appmeasurement.js is bundled properly or not ?
We are using "Manage the library for me"
We have below tags firing on every page refresh – is this standard practice or something needs to be changed.
[Adobe Analytics] Loading AppMeasurement script
[Adobe Analytics] Creating AppMeasurement tracker with the report suites
[Adobe Analytics] Setting the tracker as window.s
[Adobe Analytics] Setting MCID instance on the tracker
[Adobe Analytics] Setting version on tracker
[Adobe Analytics] Calling custom script after settings.
[Adobe Analytics] Set variables on the tracker.
[Adobe Analytics] Applying the properties on tracker:
Rule "Send Pageview" fired.
[Adobe Analytics] Firing page view beacon.
If your rule consists of 2 action blocks:
Go into the custom code block, copy that code.
Then open the Set Variables action block, scroll to the bottom and paste it in the custom code section at the end.
Now your custom code will be executed at the end of the Set Variables action, without needing to be written into the DOM first.
It's always loaded asynchronously and never bundled. If you'd like to see a feature where you could choose for it to be bundled, I would recommend posting it as a feature request here: Launch - Feature Requests
It looks pretty standard to me.
Would be great if you could clarify this questions as well,
1. Whether Adobe analytics collects data only when the cookies are enabled and it will not collect data if it's diabled?
Below screenshot shows that Analytics data displays only when cookie support is enabled
2. We tried by creating two rules sending pageview beacon, one with DOM ready event and the other with "library loaded (page top) and verified in the website. Library loaded (page top) fires first and it sends beacon and then DOM ready fires and it sends beacon.
Ultimately we are trying to atleast map 80% of the traffic numbers to match with GA as well, instead of having more than 40% difference in between two tools.
Please let me know your suggestion on this.