[AAE] Have Adobe Analytics Global Variables fire on all AA rules

[#1]

The variables set in the Analytics extension's Global Variables seem to not fire on all rules/rule types (see Global Variables - Direct Call Rule ). This is similar to how it was in DTM.

It would be great if we had some control over this (maybe give me the ability to say "fire for all beacons" or "fire for all s.t beacons" or "fire immediately before any beacon, but after other rules" or something), or by default they DID fire anywhere the Analytics Extension was in a rule. Otherwise, folks still have to resort to using doPlugins, or setting up a rule for global variables that somehow fires on all other AA rules/beacons.

[#2]

and what happens if you have two (or more) s.tl() on the same page (without page reload an clear vars)? will it keep all the variables/events or always start "from scratch"?

[#3]

Correct, I don't use s.clearVars() because it's so destructive.

Instead, I use s.registerPostTrackCallback() like so:

s.registerPostTrackCallback(function(requestUrl, s) {

  _satellite.logger.warn('s.registerPostTrackCallback() called');

  // unset variables and events that are not needed after sending a beacon

  // BUT LEAVE BEHIND variables that should remain, e.g. those that are set in the Adobe Analytics extension itself

  var doNotUnsetVariables = [

    // list of variables to keep between hits, including pageName, hierN, server, channel, etc.

  ];

  var doNotUnsetVariablesRegExp = new RegExp('^(' + doNotUnsetVariables.join('|') + ')$');

  // find and erase all unneeded variables: eVar's, hier's, prop's, products

  var setVariables = Object.keys(s).filter(function (k) {

    return /^((eVar|hier|prop)[0-9]+|products)$/.test(k);

  });

  var unsetVariables = setVariables.filter(function (k) {

    return !doNotUnsetVariablesRegExp.test(k);

  });

  unsetVariables.forEach(function (v) {

    s[v] = '';

  });

  // erase all success events

  s.events = '';

}, s);

I'm not sure if there's a better way to clear variables selectively, but this works for me.

However, due to Launch's asynchronous firing, if I fire two s.tl()'s together, there's a very high chance that the subsequent s.tl() will send variables that were in the first s.tl(), even though I don't want them to be.

[#4]

I only just got around to testing this and for me, the global variables still not fire on on an s.tl beacon (if I had set clearvars on the page view beacon- I suspect this might be the difference?). 

[#5]

After testing, I can confirm- the global variables only fire on s.t beacons. They may hang around until an s.tl beacon, but they're not freshly set for s.tl beacons. If you fire clearvars after a page view, you will not have the global variables on subsequent s.tl beacons. 

[#6]

This feature removes like 500 lines of custom code in my implementations. Let's get it done. 

[#7]

Sorry, Have you ever tried s.manageVars() function where it will not clear all the variables but only the selected ones?

[#8]

FWIW, this question came up again and I just retested, and it really is problematic as it is. Take a look at https://digitaldatatactics.com/test/testGlobalVars.html, which walks through the problems, which essentially boils down to:

1. Global Variables only evaluate once, on page view, which is bad if you use clearVars, and particularly bad on a single page app.
2. Global Variables don't get added to linkTrackVars and won't appear in any s.tl beacons.

I have plenty of workarounds, all of which basically come down to "don't count on Global Variables". Which means for something that I want on EVERY beacon, I either set it in doPlugins (making sure it's added to linkTrackVars), or I make sure every beacon has at least one rule that sets eVar15, potentially making either one rule with dozens of triggers, or dozens of rules that all set eVar15. 

[#9]

@Jennifer_Kunz playing devil's advocate:

As the name implies, "Global variables" are variables that are tracked with every beacon. And Adobe's interpretation of "global" probably also means to track those same variables with the same values in every beacon.

If a variable were to have a different value, it would be because there are certain expected conditions that result in the new value. So the "Launch-y" way of doing things is to have a Rule for such expected conditions, and that Rule has a Set Variables action to set that same variable with the new value.

So in your example, you can set eVar15 with a default "not logged in" value in the extension's "Global variables" section. But your Rule gets triggered by the user's login, then your Rule should have a "Set Variables" action to update eVar15 with "logged in".

[#10]

I see what you're saying, but... they're not tracked with every beacon. They're never tracked on s.tl beacons, and if you ever clear out variables (as is best practice) then they're not tracked on that DOM ever again. I think calling them "global" is very misleading, because they really are just "global, once for each DOM load". 

Which I really wouldn't mind if there were some other way (other than doplugins) to have a set of variables that truly fire on every beacon.

[#11]

@Jennifer_Kunz I'm not able to replicate your experience. In my Launch properties, global variables are set with every beacon call with the same variables and values, both pageview s.t() and custom/download/exit links s.tl(). I don't use clearVars() nor "dynamic" values in data elements (i.e. for all intents and purposes, the data elements always have the same values for the lifetime of the page). clearVars() would, correctly, unset all variables, including global ones.

The nomenclature could be better, or maybe a description stating how global variables are set in the context of Launch rules and beacons.