Integration

Overview

The following document outlines the integration of Analytics into the everyday building of websites and web-based applications.

This document is organized into the following sections:

• Roles & Responsibilities
• Base-Level Analytics
• Trigger Patterns
• Proposed Future State

For the purposes of this document, the following definitions should be understood:

• GTM (Google Tag Manager)
  Google Tag Manager, at a high level, provides the ability to add and update tags for conversion tracking, site analytics, remarketing, and more. It allows for scripts and policy to be pushed to one or more sites.
• GA (Google Analytics)
  Google Analytics is used to track the website activity—such as session duration, pages per session, bounce rate, etc.—of individuals using the site, along with the information on the source of the traffic. Can be added as part of GTM or as a stand-along snippet.

Base-Level Analytics

Each project being developed by ID will include a base level of analytics. This base level will consist of one or more of the following:

• analytics and other tools provided as part of BU Core functionality
• integration of client-provided GTM package
• integration of client-provided GA package
• Integration of other third-party analytics package

Roles & Responsibilities

Analytics Managers

• oversee day-to-day operations and functionality of analytics platforms and services
• provide reporting as needed to external vendors, clients, and internal stakeholders
• work directly with external vendors, clients, and internal stakeholders to determine needs
• create detailed project scope and requirements, as well as identify what, if any, involvement will be required from either (or both) front-end and back-end developers
• provide guidance on running reports to clients and how to gain insights from results
• review and test custom trigger classes implemented by either front-end or back-end developers during implementation phase of project
• review and test custom trigger classes immediately following launch of project

Front-End Developers/Designers/Producers

• implement site-wide GTM or GA packages as provided
• provide primary-level integrations of custom trigger classes on elements as needed on specific projects
• provide guidance on DOM navigation, accessing specific trigger elements, and best practices for how and where to create trigger elements
• integrate trigger classes on elements as part of product roadmaps
• escalate requests to include back-end developers as needed

Back-End Developers

• integrate custom trigger classes on elements generated in PHP or other back-end technologies, as needed, which cannot be addressed in any other manner
• integrate trigger classes on elements generated in PHP or other back-end technologies as part of product roadmaps

Please note: It should be generally understood that neither front-end developers nor back-end developers will be provided access to any analytics package owned or managed by the University nor owned or managed by a client or partner, unless specifically requested by the analytics managers. Testing requests after implementation of triggers or other changes should be made to the analytics managers directly.

Trigger Patterns

In order to maintain the proper separation of stylistic classes from trigger classes related to analytics, the following class pattern must be utilized either alone or alongside other classes when a custom solution is required:

STANDARD PATTERN: alyt__[gtm]–[trigger]-[optional]

Example patterns for classes:

Google Tag Manager trigger pattern for a single submit button

alyt__gtm–submitbutton

Google Tag Manager trigger pattern to differentiate multiple submit buttons on the same page

alyt__gtm–submitbutton-newsletterreg

alyt__gtm–submitbutton-contactus

Log Rocket trigger pattern for a single submit button

alyt__lrkt–submitbutton