Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Mechanism for making analytics calls on next page #560
Example of usage replacing old approach in frontend:
(Once the frontend change is merged and deployed, the remaining shims within static can be deleted)
* Based on an existing technique that sets a GOVUK cookie but needed specific classic GA parameters set * Instead set the method to call on the `analytics` object and any parameters to pass in * Split array based on `|` so that commas in values don’t affect calls * Call the requested method before the initial pageview, allowing for custom variables to be set from a prior page (as is the current use case)
This seems mostly reasonable, but I'm wondering if there's actually a need (at present, or anticipated) for the flexibility of allowing a method name to be specified in the cookie? The method needs to be defined on all pages on our site - is there an easy way to ensure this is done right? In the example of usage on frontend, I can't see where the method is defined (but it couldn't be defined in frontend, anyway).
One problem we've seen with the existing implementation of this is that sometimes the cookie data gets loaded on the wrong page (presumably due to the target page failing to load, etc). I've wondered if it would be good to include the expected target page url (or a hash of it, for brevity) in the cookie data, and only perform the action on the target page if the url matches, to strip out this confusing data.
Finally, don't forget to update https://www.gov.uk/help/cookies with the new cookie name.
@rboulton Thank you for the review, some excellent points. The method provided needs to be a named method on the analytics object itself. In the frontend example it would call
Because this is only being used once, and because of the problems with
I did wonder if that was happening. Even with this bad data, is the technique and custom dimension still useful?
Ah yes, good point.
Even with the bad data, this dimension is invaluable for analysing search results. I previously estimated the bad data was occurring at most 5% of the time, probably less, but I can't now remember the methodology I used to get that estimate.
Making this be a specific solution for setting a custom dimension would be reasonable, I think. The current implementation isn't specific to setting any particular custom dimension, and I think it would be useful to preserve the ability to set other custom dimensions (or even expand that to allow setting multiple such dimensions at a time) - but I don't think we need more flexibility than being able to set a list of custom dimensions to particular values. I think @edds suggestion of using JSON should make it easy to avoid the problems with delimiters and coercion.
Finally, if you do include a hash of the target URL in the cookie, I'm not sure whether the best thing to do is to drop data where the URL doesn't match the expected value, or whether we should be including that in the custom dimensions so we can do some analysis of how often the URL will mismatch. There's lots of edge cases to think about involving redirections, etc. That probably merits a wider discussion than fits easily into a PR.
* Splitting with a delimiter would break if the delimiter was included in the params * Joining the array of params also inadvertently cast params to strings * Use JSON stringify/parse to avoid these problems * Catch JSON parse errors and continue, so that the troublesome cookie gets deleted * govuk-template provides a JSON shim for older browsers * Remove old spec helper regarding JSON.parse, all tests pass correctly with the latest PhantomJS it seems.