Document Type: Business and Stakeholder Communication
Scope: Full Digital Commerce Platform — all applications and markets
Audience: Business stakeholders, product leadership, vendor partners, analytics leadership
Status: Current-state assessment and investment proposal
We run a digital vehicle commerce platform that covers the complete purchase journey — from browsing vehicles and accessories to configuring, financing, and completing a purchase online.
As our platform grew, so did our analytics implementation. But our analytics did not grow as a unified platform. It grew as a collection of team-by-team, ticket-by-ticket additions.
Today we are operating with multiple analytics approaches running at the same time across our products. This creates inconsistency in our data, risk in our reporting, and a growing drag on our engineering delivery.
We are investing in a unified analytics platform to fix this. This document describes the problem clearly, the business impact we are seeing, and what we need from a solution.
We launched NVC with a small set of applications.
At that point, analytics was manageable:
We now operate:
Each time we added a new application, market, or team, analytics was extended locally rather than built from a shared foundation.
When our analytics team provides a PV (specification document) to an engineering team, each team interprets and implements it slightly differently. Over time this creates events that have the same name but different structures. Business reports can show inconsistent numbers because the data feeding them is not uniform.
We currently implement analytics requirements ticket by ticket. Each fix works in isolation but does not improve the system as a whole. In fact, each local fix can create a new side effect somewhere else.
Because our analytics logic is shared across many applications, a change made to fix one journey can silently break another. A team working on checkout analytics can accidentally change how search analytics behaves.
When we want to launch in a new market or enable a new brand, we need engineering teams to make code changes. This takes sprint cycles and increases risk of regression. It should be a configuration change only.
When two teams implement the same business event with slightly different field names or values, our reporting tools receive conflicting signals. Analysts see inconsistent funnel numbers, and leadership loses confidence in the data.
Every sprint, teams are debugging analytics regressions instead of building new features. This is a measurable tax on our delivery capacity.
| Impact Area | What We Are Seeing |
|---|---|
| Reporting confidence | Inconsistent event data across journeys reduces trust in funnel and conversion metrics |
| Decision quality | Leadership decisions based on incomplete or inconsistent data carry higher risk |
| Delivery velocity | Engineering teams spend significant time on analytics rework and regression fixes |
| Market expansion | New country or brand launches require code changes, adding lead time and risk |
| Onboarding cost | New teams take longer to implement analytics correctly because standards are unclear |
| Vendor/partner relationships | Analytics vendor implementations are harder to validate against inconsistent contracts |
The following sequence illustrates what actually happens when we add a new analytics requirement today.
Analytics team delivers a new PV document covering a checkout flow event.
It includes field names, values, and when to fire.
Two engineering teams implement the same event from the same PV.
Team A works in the cart. Team B works in checkout confirmation.
Each interprets one field name slightly differently.
A shared analytics library change is deployed to improve an unrelated search event.
Unknown to the team, the change alters how payload merging works.
PDP analytics for a specific country stops reporting correctly.
The data goes silent in the reporting dashboard.
Analytics team raises a data quality incident.
Engineering investigation begins. Three teams need to coordinate to find the root cause.
No one team owns the problem end to end.
A patch is applied to fix the specific regression.
The patch adds another layer of special-case logic.
The underlying system is now slightly more complex than before.
This cycle repeats every few sprints.
What this diagram shows:
Multiple teams and modules all write to the same shared object.
There is no coordination mechanism.
The shared library is a high-risk dependency for everyone.
This shows the path a single user interaction takes to become a data point in our reports.
The problem highlighted:
There are three separate entry points to the same global data layer.
There is no single point of validation, governance, or contract enforcement.
We did not make analytics a platform.
We made it a shared library with multiple entry points.
The difference matters:
| Library Model (What We Built) | Platform Model (What We Need) |
|---|---|
| Teams import and call shared functions | Teams express intent, platform handles execution |
| Each team shapes the payload | Platform enforces the contract |
| Global object is shared and mutable | Data layer is managed with strict lifecycle |
| Market variation is in code branches | Market variation is in configuration |
| No validation before data is sent | Validation is mandatory before send |
| Ownership is distributed and unclear | Ownership is explicit with clear RACI |
| Testing is per team, no contract coverage | Contract validation is centralized and automated |
Every business event should have one canonical definition.
That definition should specify exactly what fields are required, what defaults apply, and what the satellite track name is.
All teams use the same definition. No local interpretation.
Instead of every team handcrafting a payload, they call one function and pass their business context.
The platform builds the correct payload automatically from the contract.
Adding a new country, brand, or locale should require only a configuration change.
No code changes. No engineering sprints. No regression risk from branching.
Every event should be validated against its contract before it reaches Adobe.
If the payload is invalid, we log the error and stop the send.
We never silently send bad data to our reporting systems.
We cannot stop our production platform and rewrite everything.
We need to migrate gradually, running old and new paths in parallel, comparing their outputs, and switching markets one by one with rollback capability.
Every analytics event should carry metadata: which contract version was used, which tenant, which schema version.
When something goes wrong, we should be able to diagnose it within hours, not days.
Every analytics event should have an accountable owner.
Every change to a contract should go through a defined approval process.
We need a RACI so teams know their role and we stop having incidents that no single team owns.
We are looking for a partner who can help us implement one or more of the following capabilities:
| Capability | Description |
|---|---|
| Analytics Contract Registry | A versioned registry of event definitions that all teams consume as their source of truth |
| Event Builder Runtime | A TypeScript SDK that accepts typed business intent and produces validated transport payloads |
| Tenant Overlay Engine | A configuration-driven system for brand, country, locale, and commodity variation |
| PV Compiler | A tool or workflow that converts business PV definitions into machine-readable contracts |
| Migration Framework | Dual-run capability with parity logging and market-by-market rollout controls |
| Observability Platform | Dashboards and alerting for event quality, duplicate rate, schema violations, and parity metrics |
| Governance Workflow | Tooling and process for contract review, approval, and versioning |
We are open to building some of these internally, procuring tools, or engaging a partner for implementation services.
What is non-negotiable is that our current fragmented model is replaced with a unified, governed, scalable platform.
| Value Driver | Conservative Estimate |
|---|---|
| Engineering time saved on analytics rework | 1–2 sprints per team per quarter |
| Reduced regression investigation cycles | 3–5 incidents per quarter across teams |
| Faster market onboarding | 2–4 weeks per new market reduced |
| Improved data quality for business decisions | Difficult to quantify but material for conversion optimization |
| Reduced onboarding time for new teams | 1–2 weeks per new engineer |
We are not making this investment to add capability.
We are making it to stop losing capacity to a problem that grows larger every sprint.
We will know this investment is working when:
| Criteria | Measurement |
|---|---|
| Event contract consistency | Over 95% of high-priority events conform to canonical schema |
| Regression incidents | Less than 1 analytics regression incident per quarter |
| Duplicate event rate | Below 0.1% of fired events |
| Market onboarding lead time | New country or locale enabled via config only, no engineering sprint required |
| Reporting parity | Old and new paths produce equivalent reporting output during migration |
| Incident diagnosis time | Analytics incidents diagnosed within 4 hours, not 2 days |
| Ownership clarity | Every event has a named owner and approved contract version |
| Capability | Product Analytics | Feature Engineering Teams | Analytics Platform Team | Data Engineering | QA and E2E |
|---|---|---|---|---|---|
| Define event intent and business meaning | Accountable | Consulted | Consulted | Consulted | Informed |
| Define technical event schema and contract | Consulted | Consulted | Accountable | Consulted | Informed |
| Implement event trigger in UI feature flow | Consulted | Accountable | Consulted | Informed | Consulted |
| Implement contract builder and runtime changes | Informed | Consulted | Accountable | Informed | Consulted |
| Define tenant and market overlay configuration | Consulted | Consulted | Accountable | Consulted | Informed |
| Pre-merge contract validation gates | Informed | Consulted | Accountable | Informed | Consulted |
| E2E analytics test coverage | Informed | Consulted | Consulted | Informed | Accountable |
| Reporting mapping and downstream data quality | Consulted | Informed | Consulted | Accountable | Informed |
| Incident triage and root cause analysis | Consulted | Consulted | Accountable | Consulted | Consulted |
| Migration planning and rollout approvals | Consulted | Consulted | Accountable | Consulted | Informed |
| Governance and contract change approval | Consulted | Informed | Accountable | Informed | Informed |
A = Accountable — one person or team who owns the outcome
C = Consulted — input required before decision
I = Informed — notified of decision or outcome
We did not arrive at this situation because our teams made poor decisions.
We arrived here because we were moving fast and solving real business problems as they came.
Analytics was never the primary concern when features were being shipped.
What we are asking for now is the investment to correct the architectural foundation under our analytics platform.
We are confident that this investment will:
We are ready to move forward.
Document maintained by: NVC Platform Architecture Team
Last updated: 2026-06-12
Distribution: Product Leadership, Analytics Leadership, Vendor Partners, Engineering Leadership