A measurement capability from zero

the problem

The relaunch shipped five interactive tools with no way to tell whether anyone used them. A product configurator, a comparison tool, a lighting layout tool, a rebate finder, and a redesigned distributor portal. Some carry subscription costs. None emitted a measurable signal.

Around that: no view of which documents drove demand, no way to compare the new site against the old, no visibility into who was logging into the portal. A relaunch also destroys the historical baseline unless the migration is planned first, and that window closes on launch day.

every event answered a live question

The fifth row is the one worth pausing on. Login volume tells you the portal is busy. Login volume by user type tells you whether it's reaching distributors or just being used internally.

the audit, and what it found

• The container was under the wrong account. Provisioned under IT's account rather than Marketing's. I created a replacement under the right account, coordinated access with IT, briefed the agency to swap the snippet, and confirmed the old one was removed rather than left firing in parallel.
• The legacy containers were empty. Both held no tags, so the live site ran on hard-coded on-page tracking — which explained why nothing had ever been changeable without a developer.
• Advertising tags were about to be orphaned. Ad platform and social tags hadn't been carried across to the new build. Flagged pre-launch with a remediation path.

relaunch readiness

• Three properties configured in parallel — new site, legacy site, distributor portal — so post-launch performance had a baseline to compare against.
• Tracking built and verified on staging before go-live. Tags confirmed firing via preview mode and hit-level inspection, screenshotted and confirmed back to the agency.
• Live on day one, including a cross-property migration comparison.

the tags, built by hand

No auto-events, no plugins. Each one specified, built, tested in preview, verified in hit detail, published, and paired with a registered custom dimension — a parameter that isn't registered never appears in a report.

• File downloads. Document type resolved through a RegEx table mapping seven categories, product code extracted via custom JavaScript, so downloads report by what and by which product.
• Product configurator. Event on the request button, element variables reading the generated SKU and a validity attribute — capturing failed configurations too, because failure is a UX signal.
• Comparison tool. Element visibility trigger on the results container, custom JavaScript extracting every compared product plus a count. This feeds the renewal decision directly.
• Interactive tools. Click tags scoped by destination URL, with one form tag scoped to the form's unique identifier rather than the page, so it doesn't misfire where the form is embedded in several places.
• Portal logins. Custom JavaScript variable reading user role from a body class, firing a login event with a user-type parameter. An untracked authenticated area became a segmentable audience with no backend work.

two judgment calls

• The tracking I chose not to build. A third-party rebate widget turned out to be a component library embed generating non-deterministic element IDs on every render. DOM-based tracking against it would have appeared to work and broken silently on the vendor's next release. I used the vendor's own reporting and shipped a page-view metric as an honest interim measure.
• The discovery that avoided a backend project. Portal login tracking was scoped as API work with an external development partner. Inspecting the post-login page showed the user role was already in the markup, which collapsed it into one variable.

the dashboard

An access-controlled web dashboard querying the Analytics Data API directly. Eleven named report queries — totals, daily active users, top events, top pages, traffic by source and medium, downloads by filename, product page performance, portal logins by user type and daily, portal section usage, and form starts versus submissions. A twelfth produces the migration comparison. Date range selector and PDF export.

• Service account authentication hand-rolled, not lifted from an SDK: constructing and RSA-signing a JWT assertion, exchanging it for an access token, caching that token just under its expiry.
• Two-tier caching — a token cache and a per-date-range payload cache — to stay inside API quota.
• Queries batched in groups of five per request rather than fired individually.
• Least privilege. The service account holds read-only viewer access and nothing else, documented at the top of the file.
• Graceful degradation. Missing configuration returns a clear disabled state with the reason, not an error.

Why custom. Commercial reporting tools were used first. They hit real limits: filters silently dropping between report views, and interface changes that removed controls the team relied on.

architecture

no vendor past the analytics platform · nothing in it needs a developer to change