Track new requests as Google Analytics virtual pageviews. #3392

Merged
merged 1 commit into from Aug 8, 2016

Conversation

Projects
None yet
5 participants
@crowbot
Member

crowbot commented Jul 19, 2016

@crowbot crowbot referenced this pull request in mysociety/whatdotheyknow-theme Jul 19, 2016

Merged

Add new request as Google Analytics event. #329

@garethrees garethrees self-assigned this Jul 19, 2016

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Jul 19, 2016

Coverage Status

Coverage increased (+0.002%) to 91.5% when pulling 0975cbf on add-analytics-event into da061ca on develop.

coveralls commented Jul 19, 2016

Coverage Status

Coverage increased (+0.002%) to 91.5% when pulling 0975cbf on add-analytics-event into da061ca on develop.

app/views/request/show.html.erb
@@ -11,6 +11,10 @@
<% if flash[:request_sent] %>
<%= render :partial => 'request_sent',
:locals => { :info_request => @info_request } %>
+ <% content_for :analytics_events do
+ raw track_analytics_event(AnalyticsEvent::Category::REQUEST_ACTION,

This comment has been minimized.

@lizconlan

lizconlan Jul 29, 2016

Member

It would be good to be know which request the event belongs to so we could capture in as an event label with something like:

raw track_analytics_event(AnalyticsEvent::Category::REQUEST_ACTION,
                          AnalyticsEvent::Action::NEW_REQUEST,
                          :label => @info_request.url_title)
@lizconlan

lizconlan Jul 29, 2016

Member

It would be good to be know which request the event belongs to so we could capture in as an event label with something like:

raw track_analytics_event(AnalyticsEvent::Category::REQUEST_ACTION,
                          AnalyticsEvent::Action::NEW_REQUEST,
                          :label => @info_request.url_title)
@lizconlan

This comment has been minimized.

Show comment
Hide comment
@lizconlan

lizconlan Aug 1, 2016

Member

Comment about capturing detail inline.

For info - from a quick look at analytics goals, it appears that an Event based goal is a single step rather than a funnel

Member

lizconlan commented Aug 1, 2016

Comment about capturing detail inline.

For info - from a quick look at analytics goals, it appears that an Event based goal is a single step rather than a funnel

@crowbot

This comment has been minimized.

Show comment
Hide comment
@crowbot

crowbot Aug 5, 2016

Member

Hmm..I think you're right - that's annoying - what we really want is our existing funnel with an event-based goal at the end.

Member

crowbot commented Aug 5, 2016

Hmm..I think you're right - that's annoying - what we really want is our existing funnel with an event-based goal at the end.

@crowbot crowbot changed the title from Track new requests as Google Analytics events. to Track new requests as Google Analytics virtual pageviews. Aug 5, 2016

@lizconlan lizconlan self-assigned this Aug 8, 2016

@lizconlan

This comment has been minimized.

Show comment
Hide comment
@lizconlan

lizconlan Aug 8, 2016

Member

At the moment this will still create a duplicate analytics line for /new if you navigate to /new manually (or click on an old link) as completing a new request and visiting the page sends the same data to Google Analytics.

We can either get around this by altering the virtual pageview to append something like "-event" to the url and edit the funnel to match, or change the view code to something like:

  <% if flash[:request_sent] %>
    <%= render :partial => 'request_sent',
               :locals => { :info_request => @info_request } %>
    <% content_for :ga_pageview do %>
      ga('send', 'pageview', '<%= show_new_request_path(@info_request.url_title) %>');
    <% end %>
+ <% else %> # log manual hits on /new as standard views
+   <% content_for :ga_pageview do %>
+     ga('send', 'pageview', '<%= show_request_path(@info_request.url_title) %>');
+   <% end %>
  <% end %>

  <% if @info_request.prominence == 'hidden' %>
Member

lizconlan commented Aug 8, 2016

At the moment this will still create a duplicate analytics line for /new if you navigate to /new manually (or click on an old link) as completing a new request and visiting the page sends the same data to Google Analytics.

We can either get around this by altering the virtual pageview to append something like "-event" to the url and edit the funnel to match, or change the view code to something like:

  <% if flash[:request_sent] %>
    <%= render :partial => 'request_sent',
               :locals => { :info_request => @info_request } %>
    <% content_for :ga_pageview do %>
      ga('send', 'pageview', '<%= show_new_request_path(@info_request.url_title) %>');
    <% end %>
+ <% else %> # log manual hits on /new as standard views
+   <% content_for :ga_pageview do %>
+     ga('send', 'pageview', '<%= show_request_path(@info_request.url_title) %>');
+   <% end %>
  <% end %>

  <% if @info_request.prominence == 'hidden' %>

@lizconlan lizconlan removed their assignment Aug 8, 2016

@crowbot

This comment has been minimized.

Show comment
Hide comment
@crowbot

crowbot Aug 8, 2016

Member

Gone with the latter suggestion.

Member

crowbot commented Aug 8, 2016

Gone with the latter suggestion.

app/views/request/show.html.erb
+ <% content_for :ga_pageview do %>
+ ga('send', 'pageview', '<%= show_new_request_path(@info_request.url_title) %>');
+ <% end %>
+<% else %> # log manual hits on /new as standard views

This comment has been minimized.

@lizconlan

lizconlan Aug 8, 2016

Member

my bad - that comment is outside the ruby tag /o\

@lizconlan

lizconlan Aug 8, 2016

Member

my bad - that comment is outside the ruby tag /o\

@lizconlan

This comment has been minimized.

Show comment
Hide comment
@lizconlan

lizconlan Aug 8, 2016

Member

One last thing - which is entirely my fault - then it's ready to go 👍

Member

lizconlan commented Aug 8, 2016

One last thing - which is entirely my fault - then it's ready to go 👍

Track new requests as virtual pageviews.
This is to prevent the 'new request' URL tracking being polluted
with visits from people with whom the URL has been shared. Now the
new request URL is only virtual in Google Analytics.

@crowbot crowbot merged commit c9c1375 into develop Aug 8, 2016

1 check passed

hound No violations found. Woof!

@crowbot crowbot deleted the add-analytics-event branch Aug 8, 2016

@equivalentideas

This comment has been minimized.

Show comment
Hide comment
@equivalentideas

equivalentideas Nov 4, 2016

Collaborator

We recently setup goals on Right To Know using a config exported from WhatDoTheyKnow in March 2016.

We're getting the problem of getting lots of false positive goal completions with the tracking based on the path.

Also, I find the difference between the funnel and the overview pretty confusing :)
screen shot 2016-11-04 at 1 06 36 pm
screen shot 2016-11-04 at 1 06 51 pm

We don't have this commit deployed yet, but this sounds really promising. Have you updated your Goal in GA to use this event? I'm keen to fix this for us, so if you’re getting better results with this solution I’d love to know 😍

We're tracking Follows as an event this way.
screen shot 2016-11-04 at 1 07 57 pm

While you can't get a funnel visualisation for an event based goal in GA, you can get the event flow, which can be really useful. I've used that to identify problems in a funnel and make improvements in PlanningAlerts.

I’ve actually added a few different events to Right To Know. I'd be up for putting in a PR to core with that stuff and expanding it to cover more things we want to track that have the non-distinct path problem (annotations for example). It strikes me that this is something all the Alaveteli implementations would benefit from.

screen shot 2016-11-04 at 1 14 49 pm

Collaborator

equivalentideas commented Nov 4, 2016

We recently setup goals on Right To Know using a config exported from WhatDoTheyKnow in March 2016.

We're getting the problem of getting lots of false positive goal completions with the tracking based on the path.

Also, I find the difference between the funnel and the overview pretty confusing :)
screen shot 2016-11-04 at 1 06 36 pm
screen shot 2016-11-04 at 1 06 51 pm

We don't have this commit deployed yet, but this sounds really promising. Have you updated your Goal in GA to use this event? I'm keen to fix this for us, so if you’re getting better results with this solution I’d love to know 😍

We're tracking Follows as an event this way.
screen shot 2016-11-04 at 1 07 57 pm

While you can't get a funnel visualisation for an event based goal in GA, you can get the event flow, which can be really useful. I've used that to identify problems in a funnel and make improvements in PlanningAlerts.

I’ve actually added a few different events to Right To Know. I'd be up for putting in a PR to core with that stuff and expanding it to cover more things we want to track that have the non-distinct path problem (annotations for example). It strikes me that this is something all the Alaveteli implementations would benefit from.

screen shot 2016-11-04 at 1 14 49 pm

@crowbot

This comment has been minimized.

Show comment
Hide comment
@crowbot

crowbot Nov 7, 2016

Member

Hi @equivalentideas! This commit has Alaveteli record a virtual page view, rather than an event, so we didn't have to change our goal in GA. It just removes the false positives for the page view goal by making sure it's only recorded when a requester is seeing their request for the first time. Thanks for the offer of a PR that adds more event tracking in GA - that definitely sounds like it would be a good addition. lib/analytics_event.rb'](https://github.com/mysociety/alaveteli/blob/develop/lib/analytics_event.rb) has some minimal structure we've been using so far to try and ensure a consistent use of events - you can see an example of use in [app/views/general/_responsive_footer.html.erb`.

Member

crowbot commented Nov 7, 2016

Hi @equivalentideas! This commit has Alaveteli record a virtual page view, rather than an event, so we didn't have to change our goal in GA. It just removes the false positives for the page view goal by making sure it's only recorded when a requester is seeing their request for the first time. Thanks for the offer of a PR that adds more event tracking in GA - that definitely sounds like it would be a good addition. lib/analytics_event.rb'](https://github.com/mysociety/alaveteli/blob/develop/lib/analytics_event.rb) has some minimal structure we've been using so far to try and ensure a consistent use of events - you can see an example of use in [app/views/general/_responsive_footer.html.erb`.

@equivalentideas

This comment has been minimized.

Show comment
Hide comment
@equivalentideas

equivalentideas Nov 7, 2016

Collaborator

It just removes the false positives for the page view goal by making sure it's only recorded when a requester is seeing their request for the first time.

Ah cool. I don't understand how that works, but I'll look it up :)

@crowbot What do you think about the idea of extracting the tracking event triggers into a script file, like event_tracking.js in Right To Know (That file could definitely be refactored ;-) )? I find this really helpful as you can see everything being tracked in one place and it keeps the view files simpler.

Collaborator

equivalentideas commented Nov 7, 2016

It just removes the false positives for the page view goal by making sure it's only recorded when a requester is seeing their request for the first time.

Ah cool. I don't understand how that works, but I'll look it up :)

@crowbot What do you think about the idea of extracting the tracking event triggers into a script file, like event_tracking.js in Right To Know (That file could definitely be refactored ;-) )? I find this really helpful as you can see everything being tracked in one place and it keeps the view files simpler.

@equivalentideas

This comment has been minimized.

Show comment
Hide comment
@equivalentideas

equivalentideas Nov 18, 2016

Collaborator

It just removes the false positives for the page view goal by making sure it's only recorded when a requester is seeing their request for the first time.

@crowbot has this worked? E.g. is the data nice and clean now?

Collaborator

equivalentideas commented Nov 18, 2016

It just removes the false positives for the page view goal by making sure it's only recorded when a requester is seeing their request for the first time.

@crowbot has this worked? E.g. is the data nice and clean now?

@crowbot

This comment has been minimized.

Show comment
Hide comment
@crowbot

crowbot Nov 22, 2016

Member

@equivalentideas: @lizconlan is going to take a look and confirm.

Member

crowbot commented Nov 22, 2016

@equivalentideas: @lizconlan is going to take a look and confirm.

@lizconlan

This comment has been minimized.

Show comment
Hide comment
@lizconlan

lizconlan Dec 6, 2016

Member

Hi @equivalentideas, sorry for the delay - I was putting off looking into it as I realised I'd probably fall into playing with analytics for the entire day once I got started!

TL;DR - it works! Fiddly details below...

Recap

Back in May 2016 (to pick a month at random that definitely predates our code changes), our report on WDTK in Behaviour > Site Content > Landing Pages for visitors from a t.co referrer (filtered down to pages matching '/new$') looked like this:

screen shot 2016-12-05 at 23 39 27

With a conversion rate of over 99% but averaging fewer than 2 pages per session with a session duration measurable in seconds, there's something wrong with this picture. Tenative conclusion - we're counting anyone arriving on a request's /new page as a joyous success, even if they immediately close the browser.

And in our Goal Flow, another suspicious thing - particularly noticable from social media referrers (the report just shows t.co and facebook.com) - it's the wrong shape, more people are "completing" the third stage of the process than arrived at the second. A lot more.

screen shot 2016-12-05 at 23 56 28

Current stats

Last month (November 2016), our the Landing Pages report makes sense again - we've eliminated the single step false positive "conversions" completely.

screen shot 2016-12-05 at 23 57 51

And our Goal Flow looks much more plausible:

screen shot 2016-12-05 at 23 56 51

The 'secret'

With this piece of code, we're preventing the request-title/new page (aka show_new_request_path) from sending a pageview event to GA (it identifies as a standard view instead, which is a better indication of what's really happened) unless we know - from examining the flash message - that a request has been created. It's a bit messy but has the advantage that the Goal didn't need to change as it's still looking for hits on the request-title/new url.

So our Goal description remains:

screen shot 2016-12-06 at 00 19 37

Member

lizconlan commented Dec 6, 2016

Hi @equivalentideas, sorry for the delay - I was putting off looking into it as I realised I'd probably fall into playing with analytics for the entire day once I got started!

TL;DR - it works! Fiddly details below...

Recap

Back in May 2016 (to pick a month at random that definitely predates our code changes), our report on WDTK in Behaviour > Site Content > Landing Pages for visitors from a t.co referrer (filtered down to pages matching '/new$') looked like this:

screen shot 2016-12-05 at 23 39 27

With a conversion rate of over 99% but averaging fewer than 2 pages per session with a session duration measurable in seconds, there's something wrong with this picture. Tenative conclusion - we're counting anyone arriving on a request's /new page as a joyous success, even if they immediately close the browser.

And in our Goal Flow, another suspicious thing - particularly noticable from social media referrers (the report just shows t.co and facebook.com) - it's the wrong shape, more people are "completing" the third stage of the process than arrived at the second. A lot more.

screen shot 2016-12-05 at 23 56 28

Current stats

Last month (November 2016), our the Landing Pages report makes sense again - we've eliminated the single step false positive "conversions" completely.

screen shot 2016-12-05 at 23 57 51

And our Goal Flow looks much more plausible:

screen shot 2016-12-05 at 23 56 51

The 'secret'

With this piece of code, we're preventing the request-title/new page (aka show_new_request_path) from sending a pageview event to GA (it identifies as a standard view instead, which is a better indication of what's really happened) unless we know - from examining the flash message - that a request has been created. It's a bit messy but has the advantage that the Goal didn't need to change as it's still looking for hits on the request-title/new url.

So our Goal description remains:

screen shot 2016-12-06 at 00 19 37

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment