Document Type: Standard
Status: Canon
Authority: HeadOffice
Parent: Governance
Applies To: All MWMS tracking systems, websites, funnels, advertising environments, analytics implementations, and measurement infrastructure
Version: v1.0
Last Reviewed: 2026-04-23

Purpose

The MWMS Tracking Architecture Standard defines how all future tracking systems within MWMS must be structured, implemented, and governed.

Tracking architecture determines:

• how behavioural signals are captured
• how data is transported
• how measurement systems receive information
• how attribution is preserved
• how decisions are supported

Without a defined architecture:

• tracking becomes inconsistent
• data becomes unreliable
• attribution becomes distorted
• decision quality degrades

This standard ensures all MWMS tracking systems are:

→ structured
→ consistent
→ scalable
→ decision-safe

Core Principle

Tracking is not data collection.

Tracking is:

→ signal architecture for decision systems

Every tracking system must be designed to support:

• accurate interpretation
• reliable attribution
• behavioural visibility
• controlled data flow

Scope

This standard governs:

• tracking architecture design
• event capture structure
• signal transport logic
• attribution preservation
• data integrity enforcement
• measurement system integration
• cross-system signal consistency

This standard applies to:

• websites
• landing pages
• funnels
• advertising traffic systems
• analytics platforms
• tag management systems
• data pipelines

Tracking Architecture Overview

All MWMS tracking systems must follow a structured signal flow:

Signal Flow Model

User Behaviour
→ Event Capture Layer
→ Signal Transport Layer
→ Measurement Control Layer
→ Analytics / Storage Layer
→ Interpretation Layer
→ Decision Systems

Each layer must be defined and controlled.

Layer 1 — Event Capture Layer

Captures user interactions.

Includes:

• page interactions
• button clicks
• form interactions
• behavioural signals
• system events

Requirements

Events must:

• represent meaningful behaviour
• follow MWMS event design standards
• capture pre-conversion signals
• include contextual data

Prohibited

• arbitrary event creation
• inconsistent naming
• duplicate event logic
• meaningless interaction tracking

Layer 2 — Signal Transport Layer

Moves signals from capture to measurement systems.

Primary mechanism:

→ structured data layer or equivalent signal transport system

Requirements

Signals must:

• be transported consistently
• preserve event structure
• remain traceable
• support downstream systems

Core Rule

All signals must pass through a structured transport layer.

Direct, uncontrolled transmission is not permitted.

Layer 3 — Measurement Control Layer

Controls data before dispatch to analytics systems.

Includes:

• data validation
• data cleaning
• data enrichment
• duplication control
• compliance enforcement

Requirements

Data must be:

• validated before dispatch
• enriched with required context
• free from duplication
• compliant with privacy rules

Core Rule

No data is considered trustworthy unless controlled before dispatch.

Layer 4 — Analytics and Storage Layer

Receives structured signals.

Includes:

• analytics platforms
• data warehouses
• event storage systems

Requirements

Systems must:

• receive structured data
• support consistent querying
• preserve event integrity

Core Rule

Analytics platforms are consumers of data, not sources of truth.

Layer 5 — Interpretation Layer

Transforms data into usable insight.

Includes:

• dashboards
• reporting systems
• analysis frameworks

Requirements

Interpretation must:

• account for data limitations
• respect measurement integrity rules
• reflect attribution constraints

Layer 6 — Decision Layer

Uses interpreted data to make decisions.

Includes:

• campaign optimisation
• funnel improvements
• budget allocation
• experiment decisions

Core Rule

Decisions must not be made from unvalidated or incomplete data.

🔴 Attribution Preservation Requirement

All tracking systems must preserve:

• original landing page
• traffic source
• campaign parameters
• session continuity

Required Data

• gclid (or equivalent click ID)
• utm parameters
• initial page URL
• timestamp of entry

Core Rule

Original source data must never be overwritten.

🔴 Pre Conversion Signal Requirement

Tracking systems must capture behaviour before conversion.

Required signals include:

• CTA interaction
• engagement signals
• form interaction
• abandonment behaviour
• funnel progression

Core Rule

Tracking must not be limited to final conversion events.

🔴 Event Standardisation Requirement

All events must follow a consistent structure.

This includes:

• naming conventions
• parameter structure
• event categorisation

Core Rule

Inconsistent event structures are not permitted.

🔴 Measurement Integrity Requirement

Tracking systems must ensure:

• accurate event capture
• correct sequencing
• no duplication
• complete data coverage

Core Rule

Tracking must reflect real behaviour, not assumed behaviour.

🔴 Data Trust Requirement

Tracking must support:

• reliable signals
• consistent data
• validated measurement

Core Rule

Data must be trusted before it is used.

🔴 Signal Flow Integrity Requirement

Signals must move reliably across systems.

Tracking systems must prevent:

• signal loss
• signal fragmentation
• inconsistent routing

Core Rule

Signal flow must remain consistent across environments.

🔴 Visibility Awareness Requirement

Tracking systems must acknowledge:

• unobservable behaviour
• external system limitations
• tracking gaps

Core Rule

Absence of data must not be treated as absence of behaviour.

🔴 Automation Requirement

Tracking systems should support:

• automated reporting
• automated validation
• monitoring systems
• reusable tracking modules

Core Rule

Manual-only tracking systems are not scalable.

Relationship to MWMS Systems

This standard supports:

• Data Brain → signal integrity and trust
• Experimentation Brain → test measurement
• Ads Brain → performance tracking
• Affiliate Brain → offer evaluation
• HeadOffice → decision control

Failure Modes Prevented

inconsistent tracking
incorrect attribution
duplicate data
missing signals
unreliable measurement
poor decision quality

Drift Protection

The system must prevent:

• uncontrolled tracking changes
• inconsistent implementation across pages
• degradation of signal quality
• loss of attribution integrity
• fragmentation of measurement systems

Architectural Intent

The MWMS Tracking Architecture Standard ensures all future systems are built with:

→ structured, controlled, and decision-ready measurement systems

It transforms tracking from:

ad-hoc implementation → governed architecture

Final Rule

If tracking is not structured:

→ data cannot be trusted

If data cannot be trusted:

→ decisions must not be made

Change Log

Version: v1.0
Date: 2026-04-23
Author: HeadOffice

Change:
Initial creation of MWMS Tracking Architecture Standard defining the structure and rules for all MWMS tracking systems.

Change Impact Declaration

Pages Created:
MWMS Tracking Architecture Standard

Pages Updated:
None

Pages Deprecated:
None

Registries Requiring Update:
MWMS Architecture Registry

Canon Version Update Required:
Yes

Change Log Entry Required:
Yes