app/assets/docs/analytics.md in govuk_frontend_toolkit-7.4.2 vs app/assets/docs/analytics.md in govuk_frontend_toolkit-7.5.0
- old
+ new
@@ -5,11 +5,11 @@
* a Google Analytics universal tracker wrapper
* code to asynchronously load universal analytics
* a generic Analytics wrapper that allows multiple trackers to be configured
* sensible defaults such as anonymising IPs
* data coercion into the format required by Google Analytics (eg a custom dimension’s value must be a string)
-* stripping of PII from data sent to the tracker (strips email by default, can be configured to also strip UK postcodes)
+* stripping of PII from data sent to the tracker (strips email by default, can be configured to also strip dates and UK postcodes)
## Create an analytics tracker
The minimum you need to use the analytics function is:
@@ -221,46 +221,48 @@
### Stripping Personally Identifiable Information (PII)
The tracker will strip any PII it detects from all arguments sent to the
tracker. If a PII is detected in the arguments it is replaced with a
placeholder value of `[<type of PII removed>]`; for example: `[email]` if an
-email address was removed, or `[postcode]` if a postcode was removed.
+email address was removed, `[date]` if a date was removed, or `[postcode]`
+if a postcode was removed.
We have to parse all arguments which means that if you don't pass a path to
`trackPageView` to track the current page we have to extract the current page
and parse it, turning all `trackPageView` calls into ones with a path argument.
We use `window.location.href.split('#')[0]` as the default path when one is
not provided. The original behaviour would have been to ignore the anchor
part of the URL anyway so this doesn't change the behaviour other than to make
the path explicit.
By default we strip email addresses, but it can also be configured to strip
-postcodes too. Postcodes are off by default because they're more likely to
-cause false positives. If you know you are likely to include postcodes in
-the data you send to the tracker you can configure to strip postcodes at
-initialize time as follows:
+dates and postcodes too. Dates and postcodes are off by default because
+they're more likely to cause false positives. If you know you are likely to
+include dates or postcodes in the data you send to the tracker you can configure
+to strip postcodes at initialize time as follows:
```js
GOVUK.analytics = new GOVUK.Analytics({
universalId: 'UA-XXXXXXXX-X',
cookieDomain: cookieDomain,
+ stripDatePII: true,
stripPostcodePII: true
});
````
-Any value other than the JS literal `true` for `stripPostcodePII` will leave
-the analytics module configured not to strip postcodes.
+Any value other than the JS literal `true` will leave the analytics module
+configured not to strip.
#### Avoding false positives
Sometimes you will have data you want to send to analytics that looks like PII
and would be stripped out. For example on GOV.UK the content_ids that belong
to every document can sometimes contain a string of characters that look like a
UK postcode: in `eed5b92e-8279-4ca9-a141-5c35ed22fcf1` the substring `c35ed` in
the final portion looks like a postcode, `C3 5ED`, and will be transformed into
`eed5b92e-8279-4ca9-a141-5[postcode]22fcf1` which breaks the `content_id`. To
-send data that you know is not PII, but it looks like an email address or a UK
-postcode you can provide your arguments wrapped in a `GOVUK.Analytics.PIISafe`
+send data that you know is not PII, but it looks like an email address, a date,
+or a UK postcode you can provide your arguments wrapped in a `GOVUK.Analytics.PIISafe`
object. If any argument to an analytics function is an instance of one of these
objects the value contained within will be extracted and sent directly to the
analytics tracker without attempting to strip PII from it. For example:
```js