Closed qqmyers closed 5 years ago
(UPDATED: 3/20) Got a few events showing up in Google Analytics with the provided analytics-code.html but did not see all of the events that I triggered clicking around on my localhost.
Export Metadata is missing. (Did not test Compute or Preview.)
Will attempt some further analytics event testing, to see if I can figure out why those missing events weren't recorded. Should be able to also provide some documentation guidance.
Hmm - I've tried those three and seen events in the Real Time/Events view. It's possible that something in my selectors is dependent upon the DV options we have running though. I know, for example, that the explore won't work yet if there's more than 1 tool per mimetype and explore becomes a menu.
@qqmyers I have been digging a little further into the event analytics I am able to capture on my localhost. I have updated my comment above earlier with a screenshot to include everything I was able to capture.
Just now, I was finally able to get Export Metadata wired up. But it appears it is only working on the file pg and not the dataset pg. Here is the revised click function I was using for that btn.
// Export Metadata button
$('.btn-export + ul.dropdown-menu li a').click(function() {
var category = 'Export Metadata Link Text';
var label = 'Unknown';
if($('#fileForm').length > 0) {
label = stripId($('#fileForm').attr('action'));
} else {
if($('#datasetForm').length > 0) {
label = stripId($('#datasetForm').attr('action'));
}
}
gtag('event', 'Export Metadata',{'event_category' : category,
'event_label' : label});
});
I believe the disconnect on the dataset pg is related to clicking on the dataset pg's Metadata tab, and it's tabChange ajax event that have been known to wreak havoc with jQuery $(document).ready(function() { ... });
.
Tomorrow I will investigate further. Just wanted to drop this note here before I left for the evening, to see if you encountered anything similar with your efforts to track Export Metadata events on the dataset pg.
@qqmyers I have created a new branch 5627-example-analytics-code-redux
(https://github.com/IQSS/dataverse/compare/5627-example-analytics-code-redux) with revisions to analytics-code.html, as well as some changes to how the custom analytics code gets inserted into dataverse-template.xhtml, which also required a workaround added to dv_rebind_bootstrap_ui.js in order get around an issue with PrimeFaces ajax updates to the pages, which breaks jQuery binded to elements on the page.
Here is bunch of notes I jotted down, in response to your questions, as well as a run down of what I've added in the new branch.
FEEDBACK
/conf/analytics
might be more appropriate to include with other branding files are in /doc/sphinx-guides/source/installation/files/var/www/dataverse/branding/
btn-access
is a style class used for "white" action btns that require permissions and won't need trackingbtn-copy
is a style class used for clipboard.js + compute cloud access name and won't need trackingREVISIONS
downloadCitation
btn-share
(see bug #4538, these revisions will resolve the request to fix social media tracking, but that plug in is still outdated)TO-DO
buttonEvents()
function added to dv_rebind_bootstrap_ui.js~We will still need to collect more community feedback to fine tune this further. I know that folks at Odum are interested from Jon's comments in the last community call. Maybe we get some comments here from @donsizemore on their requirements.
I am going to move this issue back into our Community Dev column. That said, I'd be happy to help contribute more code to get this feature up and running.
UPDATE: @qqmyers my PR was briefly discussed with the dev team, to determine a better approach than my use of the new buttonEvents()
function in dv_rebind_bootstrap_ui.js (first bullet in TO-DO list). I am going to take this issue back into IQSS team dev and revise it to be more configurable.
With recommendations from @pameyer and @pdurbin it was suggested that we could expand the custom config settings we provide to include a custom javascript file, that has a built-in hardcoded rebind function in dv_rebind_bootstrap_ui.js that would provide a more scalable workaround for the ajax vs jquery issues in our UI.
Since the very existence of dv_rebind_bootstrap_ui.js came up to tech hours today I thought I'd point out that it was discussed a bit back in #2176
@mheppler - I'm confused since my original code is working for btn-export, on both the file and dataset pages, and with the metadata tab popping up. The key line is 47:
$( document ).on( "click", ".btn-export",function() {$(this).parent().find('a').click(function() {
which watches document for clicks on current and future .btn-exports. Just setting a function directly on .btn-export fails as you said because the ajax replaces the button with a listener with the new one, but I had no trouble with the line above.
I'm not sure if this is significantly less efficient somehow, or if it might be a solution for the general rebinding problem, but I think it works here.
@qqmyers I have just returned to this branch and will take a look at your original code again. Thanks for clarifying. It is very likely that my localhost was choking on something else.
@qqmyers Was able to confirm the $(document).on("click", ".<CLASS-NAME>", function() {...
approach worked and have committed those revisions and updated my comment above to strike-through that to-do item.
I am sure there are further refactoring opportunities with the jquery code in dv_rebind_bootstrap_ui.js with this approach, but that's another issue.
Going to pass this issue back to the community dev column.
@mheppler - I've just updated the original #5628 PR and want to see if there's anything else that's needed to get this out:
W.r.t. $(document).onClick() - I think this is only needed for the metadata downloads (this is the only set of buttons that gets replaced by PrimeFaces ajax calls), but, investigating the tradeoffs, it seems like doing this is almost preferred to setting handlers on each element and, at the scale we have, neither way should be a performance issue. So - I kept your changes to do all the buttons this way.
W.r.t. including jquery - as of now, I still need to include this for it to work - I added a comment at the top of the file that noting that it may not be needed going forward...
W.r.t. additional buttons from #5028 - it should be straight forward to add support for these. It might be easier to add additional css classes rather than overloading the existing ones (just so we don't need logic to distinguish file versus dataset level .btn-explore for example).
Also one additional note: with the Download selected files button, afaik, the list of selected files (which can be in multiple pages when there are many files) is only available on the server, so I've set the label to 'file(s) from
@qqmyers thank you for the updated sample code and clarifying those points. The results in Google Analytics were recording as expected.
After reviewing the proposed documentation approach with @scolapasta we agreed that using the :WebAnalyticsCode
setting for the event tracking code is not what we want to recommend due to it requiring the analytics-code.html duplicate the link to the jquery library on every page.
My plan is to take your PR, and spin off updates to your sample code and documentation that suggest the ::FooterCustomizationFile
setting is used provide a separate file from the analytics code that contains the event tracking code.
When that PR is ready, I will update this issue before moving it along to QA.
@mheppler - I don't think breaking things apart is necessary. First, as is, the jquery library is only loaded once - the earlier link in the analytics-code.html just loads it earlier. If that's still a concern, it is easy to replace the $(document) .ready(...) method with a window.addEventListener("load", setupAnalyticsEvents, false); That delays running the parts of the script that require jquery until after the later jquery link has been loaded, so the jquery link in the analytics-code.html is no longer needed.
If the latter is useful, I can add it to the PR.
@qqmyers It appears to be working but please note I did find one issue. When I first used your analytics-code.html, it appeared to be broken. Mike identified where there was a missing script tag. I needed to add the Githubissues.
Building on the changes in #4660, it should be possible to configure Google Analytics to track clicks of the new btn-* css classes. I'm going to submit a proof-of-concept PR that does some basic capture.
Some notes: