Analytics extension Plugin support

[danielv92670241]

One of the feature requests we see the most for the Analytics extension is Plugin support. This is something we want to bring to Launch in 2019 and we would love to get your input.

As we start researching how to best go about doing this we would love to hear your thoughts on what things will be most valuable. We understand that Plugins can still be used through custom code but we want to reduce your need for customization where possible and allow you to control this within the extension configuration.  We would appreciate it if we could get some comments on how you are currently using Plugins and what controlling Plugins from Launch would look like for you.

[josh_donley]

AppMeasurement Plug-in Support

crossVisitParticipation - AKA "campaign stacking".   Launch interface config should include fields for:

• The value to push to the stack
• How many days the stack should persist
• Maximum stack size
• Stack value delimiter
• AA event(s) that will clear the stack
• Flag for whether consecutive duplicate values will be appended to the stack
• (The plugin also accepts a cookie name but I think this *probably* isn't a necessary option if doing it as a Launch interface config)

getTimeParting - The config for this involves lookup tables for daylight savings time start/end dates (btw, the map objects end next year.. ).

• Would like for Launch to handle this automatically (including keeping the DST tables current / future proof).
• Launch interface config should have a hemisphere and timezone field.
• Bonus points: I would also like the plugin to be expanded to allow you to specify the return value format. In the past, I've hacked this plugin for various clients who had specific formatting conventions.

getDaysSinceLastVisit - Out of the box, this plugin only accepts a value to specify cookie name. As a Launch interface config, it would be nice to see this extended to allow me to specify the following:

• The time-frame buckets/categories
• An expiration to drop the cookie after x days

Cookie Combining Utility - I don't think there is really any interface config needed for this. I guess be able to specify the consolidated cookie names (s_sess and s_pers). That's a thing I had to do for a client one time, because reasons. Pretty edge case, though.

[Stewart_Schilling]

This is a tough one for me.  Please note - These are my professional opinions and may vary from others'.

So many AA plugIns get added to configurations without real consideration of the value that they provide. As we move toward the measurement of our customer as a Person rather than a selection of disjointed devices, I feel that many AA plugins do more harm than good.

Many AA plugins are carried forward by edict from analysts who have simply gotten used to having a certain dimension or metric on their dashboards and would rather keep that data flowing in than consider how flawed or misleading it might be.

Any plug in that uses cookies for persistence across visits is reporting on a Browser on a Device (not on a Person and all her browsers and apps on all her devices).  Based on this, unless the purpose of implementation is to understand cookie clearance rates or the number of browsers in use, I would discourage the use of:

• getVisitNum
  • If a Person uses multiple browsers on multiple devices, she will return visit number 1 multiple times.
  • If a Person clears cookies on a browser, the count of visits is lost and the next visit will be visit number 1.
  • If a Person visits on a browser that disallows cookie setting or does not persist past the session (i.e. Safari Private, Chrome Incognito, FF ITP), "First Visits" the extension will return visit number 1.
  • Derivable in from the data stream and a more informed view of the customer is available with ECID implementation.
• getNewRepeat
  • Totally cookie based. Subject to the same limitations as getVisitNum.
  • Better provided from the data-stream.
• getDaysSinceLastVisit
  • Totally cookie based. Subject to the same limitations as getVisitNum.
  • This is provided as a dimension in Workspace, derived from the data stream, so there is very little reason use cookie-based code.
• campaignStacking (no link to source)
  • Totally cookie based. Subject to the same limitations as getVisitNum.
  • Derivable in from the data stream.
  • Better view of the customer is available with ECID implementation.
  • I'm sure I could find the source for this plug-in but it wouldn't be a kind thing to do.

The next set of plugIns had their day in the sun but have largely been replaced by DTM and now Launch.

• getAndPersistValue
  • Same or better functionality is provided by Data ELement persistence.
• getPreviousValue
  • Same or better functionality is provided by Data ELement persistence.
• getQueryParam
  • Same or better functionality is provided by Launch Core extension Data Element type
  • s.Util.getQueryParam replaced this plugIn in 2017 Adobe Analytics Help | getQueryParam versus Util.getQueryParam
• getLoadTime
  • I've never seen valuable, trustworthy data from this extension.
• trackTNT
  • Largely replaced by A4T

So what's left?

• appendList (& s.split as a dependency)​
  • Not needed on its own, but used in AA custom code for managing things like s.linkTrackVars, s.linkTrackEvents, s.events.
  • I'd rather see the reasons for needing "s.apl" solved in extensions... but, barring that, I would vote for s.apl to be provided as a native function of the s object.
• getPageVisibility​
  • Still in beta.
  • Interesting idea.
  • Probably better provided as a self-contained Launch extension.
  • https://www.simoahava.com/analytics/track-content-engagement-part-2/ (more thought on content engagement)
• getVisitStart
  • Required by getPageVisibility.
  • Provides data that is derivable from the data stream.
  • Functionality is easily replicable in Launch if needed for triggering client-side actions.
• getPercentPageViewed
  • Great candidate for rewrite into a Launch extension (could provide events as well as data).
  • Could feed more than just AA.
• getTimeParting
  • Great candidate for rewrite into a Launch extension
  • DST configs could be managed in the extension source centrally.
  • Could feed more than just AA.
• hitGovernor
  • The general topic of bot detection and defeat would make a great extension
  • Including reCAPTCHA v3  |  reCAPTCHA  |  Google Developers could aid in detection.
  • Again, this extension could serve more than just AA
• performanceTiming
  • Beta plugin.
  • Great Idea. Wish I had thought of it.
  • Would be a great launch extension
  • Should probably send info in context variables and unpack it on the collection server.
  • Having some standard metrics and dimensions in workspace would make the data more accessible.

So, I probably missed a few. Sorry about that.

Beyond my opinion of the value that each plugin provides, there is the audience of existing clients using them. Perhaps do a survey of installations and see what's in use.

What's left is the general value of the s_doPlugins hook.  I find it incredibly useful to have the ability to have one last go at a beacon before it goes across the wire.  Today, I take full advantage of it in code.  In the future, it would make sense to have this hook as a lifecycle event that is provided to Launch against which rules could be built.  One little wrinkle in this plan is that the AA Send Beacon action would need to be aware of its event context and not actually send a beacon if triggered by the "doPlugins" event.

[Lukáš_Čech]

I totally agree with Stewart.

At the moment we are trying to get rid of Plugins (heavily inspired by the series from Jan Exner: https://webanalyticsfordevelopers.com/2018/07/31/with-launch-you-dont-need-doplugins-part-4/ ...etc.).

There is a couple of use cases where I still consider doPlugins pretty useful:

• adding extra logic/variables to Download/Exit links (this should be also somehow re-built into Launch Extension, so these signals are available to other tools as well)
• setting some default variables for all tracking beacons - in this case I tend to like that it is in custom code - this is something that should be hidden from the regular user (and JavaScript code scares them off - not like having that in a separate global rule with just "Set Variables" Action)

[thomas_amsler]

I have the exact same use cases as Lukas: Exit and Download link special cases and many global variables where some of them are based on plugins.

And as Launch will never be as good ad creating a diff between versions as git, we also store this code in our git repo. This also has the advantage of a good code editor without the lag of the browser editor but with some better syntax check.

[Jennifer_Kunz]

Beautiful list!
I do disagree on one point, though:  I'd say getPreviousValue is NOT replaced by data element persistence, unless you're VERY careful about timing- if I want to set the previousPageName, my PageName data element is going to return the CURRENT pageName, regardless of how long I told it to persist. I'd say this is still a needed plugin.

[Jennifer_Kunz]

Add my votes to:

• crossVisitParticipation
• timeParting (note- the DST values need to be updated, we're going in to 2019)
• getPercentPageViewed (not my favorite, but lots of folks still want it)
• appendList
• hitGovernor
• getPreviousValue (see my note above as to why I still see this as needed)
• getValOnce (I'm surprised I don't see that yet in this thread)

I agree with Lucas- merely being able to set some global variables on ALL beacons would help a lot- see . Have Adobe Analytics Global Variables fire on all AA rules . Access to a baseline s.linkTrackVars and s.linkTrackEvents would also help get things out of doplugins.

As for download/exit links, I definitely prefer using rules for those these days.

[Soyouz]

I saw something new in the core extension when creating a new dataElement (or maybe I missed it before) The data element type (Visitor behavior) offers a similar getNewRepat, or VisitNumber plugin function. I think this would be the best way to handle those plugins by integrating them as dataElement options to capture - no code alteration, just create the dataElement and assign it to your specific dimension in the Adobe Analytics Extension

[keithb81089125]

Quick Question, is the appendList DTM plugin still supported in launch bexcause I have been experiencing overwrites on my launch implementation where custom script variables overwrite UI variables