Analytics — What Is the Problem and Why It Matters

Who should read this: Everyone on the team — engineers, interns, product, QA
Level: No prior analytics knowledge needed
Last updated: 2026-06-12

What is analytics and why do we have it?

When a user visits our website and clicks a button, loads a page, or buys something — we want to know about it.
We send that information to Adobe Analytics so our business can see things like:

This data helps us make decisions. If the data is wrong, the decisions are wrong.

How does it work right now?

Think of it like this:

  1. A user clicks a button on the page.
  2. Our code collects information about that click (what page, what button, what product).
  3. We put that information into a shared box called window.digitaldata.
  4. We then tell Adobe to go read that box and send the data.

Simple in theory. The problem is how we got here.

The story of how we got into this mess

Year 1 — Small and simple

We started with one app (Search), one country (US), one team.
We added analytics and it worked fine.

Year 2 — We grew fast

We added PDP, Home, Cart, Checkout.
We added Ford Protect plans for South Africa.
We added Lincoln brand support.
We added parts, chargers, merchandise.
Different teams worked on different parts.

The problem — Everyone solved it their own way

Every time a new app or feature needed analytics, the team added it in their own way.
Nobody stopped to say "let's make one unified system."
Now we have multiple approaches running at the same time, and they conflict with each other.

The 5 core problems — explained simply

Problem 1 — We have 5 different roads to the same destination

When a user clicks something, the analytics code can take 5 different paths depending on which app they are in:

All 5 paths write to the same shared box (window.digitaldata).

Imagine 5 people all trying to fill in the same form at the same time without talking to each other. That is what is happening.

Problem 2 — Even within NVC, there are two different ways

Inside the NVC apps, there is still a fork in the road:

Same user action. Same button. Different payload shapes depending on where in the world the user is.

This means our South Africa data and our US data are structured differently for the same event.

Problem 3 — The shared box can be accidentally wiped

The shared box (window.digitaldata) can be either:

If Team A writes page information, then Team B fires their event in replace mode, Team A's data disappears.
Adobe then receives incomplete data. Nobody gets an error. The data just quietly vanishes.

Problem 4 — Nobody validates the data before it is sent

Right now, the data is built, put in the box, and sent to Adobe.
There is no check that says "wait, is this correct?" before it leaves the browser.

The only real check we have is our Playwright E2E tests — which run at the very end of the development process.
By that point, the code has already been written, reviewed, merged, and tested. Finding a bug here is very expensive.

It is like proofreading a letter after it has already been mailed.

Problem 5 — PV documents are translated manually and errors happen

Our analytics team gives engineers a PV (specification document) that says which data fields to send and what values to use.
Engineers read this and write the code manually.

A tiny mistake like writing page.section instead of page.siteSection sends wrong data to Adobe.
TypeScript cannot catch this because the data object accepts any key name.
The wrong field arrives silently. Reports are wrong. Nobody knows why.

What happens when these problems combine?

A real week in our life:

Day What happened
Monday Analytics team delivers a new PV for a checkout event
Tuesday Two teams implement it slightly differently
Wednesday A shared analytics library change is deployed
Thursday PDP analytics for a different country stops working
Friday Incident raised — three teams needed to investigate
Next week A patch is added — system is now slightly more complex

This cycle repeats every few sprints. We spend more time fixing than building.

What do we want instead?

We want one system that:

  1. Has one contract per event — every event is defined in one place, every team uses the same definition
  2. Validates before sending — if the data is wrong, it does not get sent to Adobe
  3. Is safe to change — fixing one market does not break another
  4. Is config-driven for markets — adding a new country should not need a code change
  5. Is easy to understand — a new engineer or intern can add an analytics event without deep expertise

Simple before and after

Today What we want
5 different paths 1 unified path
Data can be accidentally deleted Data is always safely merged
No check before sending Every event validated before send
New country = code change + deployment New country = config change only
PV manually translated, errors happen Contract generated from PV automatically
Bug found in E2E or production Bug caught in developer's editor or CI

What should you do if you are working on analytics right now?

  1. Use the shared analytics hook (useAnalyticsClickEvents, useAnalyticsLoadEvents) — do not call _satellite directly
  2. Follow the existing pattern for your app — do not invent a new approach
  3. If you are unsure which event type or variant to use — ask the analytics platform team before implementing
  4. Write tests that actually verify the payload shape, not just that send was called

Who to talk to

Question Who to ask
What fields does this event need? Analytics / Product Analytics team
How do I wire the analytics hook? Your tech lead or senior engineer
Why is the data wrong in reporting? Analytics platform team
Can we add a new market or brand? Analytics platform team

Document maintained by: NVC Platform Architecture Team
Last updated: 2026-06-12