• Implementation record

---

• Data
• Events
• Attributes
• Data schemas

---

• Documentation
• Development approach
• Consent handling
• Personally identifiable information
• Trackers
• Further reading

---

• Implementation progress

Development approach

This is our high-level approach to implementing tracking across our applications.

• For elements that are consistent from page to page (such as the header, footer and breadcrumbs) tracking should be enabled by default.
• For elements within the content of a page, tracking should be controllable. Specifically, tracking should be enabled on components by default but disabled with a ‘disable_ga4’ option. This provides the flexibility to disable tracking in the unforeseen event of some kind of tracking collision or duplication.
• For elements that are inside content coming from a publishing interface, such as govspeak elements, tracking should be decided on a case by case basis. The most likely approach would be to enable tracking by default. This removes the need to provide publishers with an option to enable tracking on their content, which could get much more complex.

Enabling tracking should be as simple as possible. For this reason, tracking should be handled internally by components unless external data is required, that is, unless something unique must be passed from the application to the component to track it correctly.

During the development phase of the GA4 migration our approach with components was not to enable tracking by default, but to have a ‘ga4_tracking’ option that allowed tracking to be enabled. This allowed us greater control during testing and deployment.