Closed jonathanstegall closed 6 years ago
I kind of assume that not all of the tracking will be identical to how it is in Drupal. But I think it's important to document whatever differences there are as part of this issue.
Custom things we need to track that do not require a plugin:
User status: ✅
Object info: ✅
Category is DirectedMessage. Action is dismiss, close button, login link, or click. Label is the current URL with the message ID. Ex: window.location.hostname + '/node/' + message.nid
.
Still have to build these.
For users who cannot access, we currently track. Category is MinnPost+, Action is Blocked, label is the URL they were trying to access. This is maybe redundant with the dimensions, but that is what it currently does. We could probably also track users who do access.
I've changed this to: Category = Member Content; Action = Blocked or Shown; label is URL they're trying to access. This allows us to also count the other benefit pages.
For users who fill out the form that submits via Ajax, the Category is Newsletter, the Action is Signup or Fail, the Label is the URL where the user was when they filled out the form.
When a user clicks a share button, the Category is Share - Top or Share - Bottom, the Action is the text of the button, and the Label is the URL where they clicked the button.
If it is a Twitter or Facebook button they are also tracked as "social" events.
When user submits the form on /support or /support/member-benefits, the Category is Support Us, the Action is Become A Member, and the Label is the URL where they clicked.
(this gets setup in analytics)
(cms doesn't manage this)
Note that we don't need to store the URL path on ScrollDepth events because we can just use it as a secondary dimension. Probably should've always done that, but whatever.
Custom things to track that require a plugin:
'.minnpost-ads-ad-Middle', '.fieldlayout-region-bottom-detail', '#comments', '#footer .clear-block', '.minnpost-ads-ad-Middle3', '#block-minnpost_ads-Right1', '.minnpost-ads-ad-BottomRight', '#block-minnpost_ads-x01', '#block-minnpost_ads-x02', '#block-minnpost_ads-x03', '#block-minnpost_ads-x04', '#block-minnpost_ads-x05', '#block-minnpost_ads-x06', '#block-minnpost_ads-x07'
.ad-middle, .m-form-in-body, #comments, #footer, .ad-middle3, .ad-right1, .ad-bottomright, .ad-x01, .ad-x02, .ad-x03, .ad-x04, .ad-x05, .ad-x06, .ad-x07, .ad-x08, .ad-x09, .ad-x10
It would really be nice to use https://github.com/googleanalytics/autotrack but I think it won't do everything we need, if only for scrolling. It does not appear to allow tracking when users scroll to specific HTML elements.
If we continue to use the ScrollDepth plugin, we should pass this link around so everyone understands it better. https://medium.com/google-analytics/hacking-google-analytics-24762924fbf8
Maybe also this: http://www.ryanpraski.com/scroll-depth-tracking-analysis-with-google-analytics-r/
Autotrack will work fine because it has a different plugin from the scroll plugin that tracks when elements are visible. But not really because it is just too complicated to deal with configuring everything within WordPress right now.
Hash links ✅
I'm inclined to think the remaining custom event tracking should go into its respective plugins, or into the theme, because they're not generic enough to be universal to this plugin.
At least do what we're currently doing in Drupal.