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

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?). 

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.

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"?

the question is if you need a "clearVariables" at the end of all rules? otherwise I think it will keep the old variables/events and messing up tracking (eg. you set a specific event on s.t() and it will appear on the subsequent s.tl() call...

Intriguing, thanks for letting me know! I'll have to test and see if this has, in fact, been resolved!

FYI I've never encountered this problem since using Launch in October 2019.

My setup:

• Adobe Analytics extension: include all global variables to be set with all AA hits.
• Rules: include variables that should be set in those rules.

Result:

All of my AA hits include my global variables, including s.tl() hits.

I do have the same issues on custom event calls. Solved it by a helper function, which sets all global variables on events. I once define the global variables in this function, and then call it in the AA Set Variables component (on every rule) in custom code and works perfectly. But yes, this should be handled without custom code.

even if I move all s.tl beacons to rules, this is still an issue.... my global variables don't fire on my s.tl rule-based beacons either.

I can see this working and is a good solution in the current set up, but I still definitely would like a way to do it without having to make sure my "global" rule gets triggered for ALL rules/beacons.

I've achieved this by stacking rules, and pushing all analytics track events down through a single direct call which has a number of different rules listening, in a specific order. Some rules are conditional, some aren't - so this way, I can control certain variables that apply to everything, and certain variables that are conditional. The last rule fires the beacon. Maybe not ideal, but it works well for us.

This also allows us to reference analytics variables in a specific order: for example, we set hierarchy variables based on s.pagename (with some modification), if I do this in the extension I cannot control the order in which it is evaluated and therefore I end up with incorrect variable settings, but by doing this in stacked rules I can easily control the order of evaluation and ensure the result is correct. Even if we had the ability to choose when the global variables are evaluated (s.t vs s.tl / etc), it would not address my requirement to control the order of evaluation as that would be unique to my implementation and each property.