Document Type: Protocol
Status: Active
Version: v1.1
Authority: Affiliate Brain (Operational)
Applies To: Tracking infrastructure verification, signal hierarchy validation, attribution readiness, and measurement-environment discipline before testing
Parent: Affiliate Brain Canon
Linked Canon: Affiliate Brain Architecture v2.3
Last Reviewed: 2026-03-15
Purpose
The Tracking Governance Protocol defines the infrastructure verification rules required before any test may be approved inside Affiliate Brain.
This protocol exists to protect capital from false learning signals, weak attribution, and poor platform optimisation caused by bad tracking structure.
It governs:
• event reliability
• signal hierarchy
• attribution visibility
• server-side readiness
• first-party data resilience
• consent-aware measurement durability
This protocol does not approve campaigns.
It validates whether the measurement environment is strong enough to support disciplined testing.
Scope
This protocol applies to:
• pre-test tracking verification inside Affiliate Brain
• event and signal validation before Testing Definition
• attribution and revenue-path review
• server-side and first-party data readiness assessment
• consent-related interpretation risk review
• measurement-environment pass/fail discipline
This document governs whether the tracking environment is structurally fit for disciplined testing.
It does not govern:
• campaign profitability
• capital approval
• offer approval
• Velocity scoring
• Research Intelligence
• Structural Signal Audit
• direct campaign execution
Those remain governed by the Velocity Decision Engine, Finance Brain, Affiliate Brain evaluation layers, and related MWMS governance systems.
Definition / Rules
Core Principle
Bad tracking produces bad optimisation.
If ad platforms learn from weak or misleading signals, testing quality deteriorates and capital efficiency falls.
Tracking Governance therefore exists to ensure that the learning signals used by the platform are structurally sound.
Tracking Governance Checks
The following checks must be reviewed and logged.
Core Event Reliability
Evaluate:
• whether key conversion events fire correctly
• whether events are duplicated
• whether event names are stable
• whether triggers are deterministic
• whether critical actions are trackable
Output:
Event Reliability Status:
Fail / Partial / Pass
MWMS Signal Ladder Check
Every campaign must define:
• Tier 2 Intent Signal
• Tier 3 High-Intent Signal
• Tier 4 Revenue Signal
Tier 1 engagement signals remain optional.
Signal ladder structure:
• Tier 1 – Engagement
• Tier 2 – Intent
• Tier 3 – High Intent
• Tier 4 – Revenue
Output:
Signal Ladder Status:
Fail / Partial / Pass
Primary Optimisation Signal Declaration
A valid test must declare one primary optimisation signal.
Examples:
• CTA click
• VSL buy-button click
• order-page visit
Rules:
• only one primary signal may be declared
• primary signal must represent meaningful buyer intent
• engagement-only signals must not be primary
Output:
Primary Signal Declared:
Yes / No
Revenue Validation Path
Evaluate whether a final revenue-confirming event exists.
Examples:
• purchase thank-you page
• affiliate network postback
• subscription confirmation
Rule:
Revenue validation may be delayed or imperfect, but a declared revenue path must exist.
Output:
Revenue Validation Status:
Absent / Partial / Present
Affiliate Attribution Gap Review
Affiliate purchases often occur on third-party domains.
Example:
Landing Page → VSL → Affiliate Checkout → Purchase
This weakens direct platform attribution.
Evaluate:
• whether purchase occurs off-domain
• whether final purchase is visible to platform
• whether proxy signals are required for optimisation
• whether attribution gap is low, moderate, or high
Output:
Attribution Gap Status:
Low / Moderate / High
Server-Side Attribution Readiness
Purpose:
Assess whether the system can move beyond browser-only tracking.
Evaluate:
• whether browser-only tracking is currently in use
• whether a server-side GTM path exists
• whether a custom tracking subdomain is feasible
• whether a hosting path is identified
• whether server-side forwarding architecture is documented
Possible hosting paths include:
• direct cloud deployment
• managed hosting solution
Output:
Server-Side Status:
Not Assessed / Not Ready / Planned / Ready / Live
First-Party Data Resilience Review
Purpose:
Assess whether user-provided data can improve attribution quality.
Evaluate:
• whether email capture exists
• whether first-party identifiers exist
• whether enhanced conversion pathways are possible
• whether the funnel structure supports matching improvement
Output:
First-Party Data Status:
None / Limited / Usable / Strong
Consent & Attribution Durability Review
Purpose:
Assess whether privacy restrictions are likely to reduce data quality.
Evaluate:
• whether Consent Mode is absent, partial, or operational
• whether modeled conversions may influence reporting
• whether browser-side tracking loss risk is low, moderate, or high
• whether interpretation caution is required
Output:
Consent Status:
Unknown / Basic / Operational
Attribution Durability Status:
Low Risk / Moderate Risk / High Risk
Pass Conditions
Tracking Governance is considered complete only if:
• Event Reliability Status = Pass
• Signal Ladder Status = Pass
• Primary Signal Declared = Yes
• Revenue Validation Status is not Absent
All other statuses must still be logged, even when they do not block progression.
Fail Conditions
Tracking Governance must fail if:
• key events are not firing reliably
• signal ladder is undefined
• no primary optimisation signal exists
• no revenue validation path exists
A fail blocks progression to Testing Definition.
Non-Blocking Risk Conditions
The following do not automatically block testing, but must be logged for interpretation discipline:
• attribution gap is high
• server-side status is not ready
• first-party data is weak
• consent status is unknown
• attribution durability risk is high
These increase caution.
They do not override Velocity.
Prohibited Signals
The following must never be used as primary optimisation signals:
• page view
• session start
• ad click duplication
• low-intent micro interactions
• passive time-on-page only
These signals produce weak or misleading algorithm training.
Interpretation Rule
Tracking Governance validates infrastructure quality.
It does not:
• prove profitability
• approve capital
• replace Research Intelligence
• replace Structural Signal Audit
• replace Velocity
Architectural Role
This protocol operates inside:
Affiliate Brain Architecture
→ Infrastructure Governance – Tracking Layer
It supports:
• better platform learning
• cleaner testing logic
• better capital protection
Drift Protection
The system must prevent:
• weak or duplicate events being treated as valid learning signals
• undefined signal ladders entering live testing
• engagement-only signals being used as optimisation targets
• missing revenue paths being ignored because proxy signals look good
• attribution limitations being hidden or under-reported
• tracking weakness being mistaken for market weakness
Tracking Governance must remain a structural discipline layer, not a cosmetic checklist.
Architectural Intent
Tracking Governance Protocol exists to ensure MWMS tests are built on trustworthy measurement foundations before capital is exposed.
Its role is to verify that signals, attribution paths, and data-resilience layers are strong enough to support learning, optimisation, and later interpretation without contaminating results through broken infrastructure.
Final Rule
If the tracking environment is too weak to support reliable learning, the test is not ready.
Measurement quality comes before traffic.
Change Log
Version: v1.1
Date: 2026-03-15
Author: MWMS HeadOffice / Affiliate Brain
Change: Rebuilt and strengthened Tracking Governance Protocol to align with the MWMS document standard. Added Document Type, Purpose / Scope / Definition / Rules structure, clarified pass/fail and non-blocking conditions, formalised measurement checks, added Drift Protection, Architectural Intent, and Final Rule, and updated review metadata.
Version: v1.0
Date: 2026-03-07
Author: Affiliate Brain
Change: Initial creation. Established Tracking Governance Protocol with server-side, first-party, consent, and attribution durability checks.
END – TRACKING GOVERNANCE PROTOCOL v1.1