Document Type: Protocol
Status: Active
Version: v1.2
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-07-19
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, broken conversion routing and poor platform optimisation caused by bad tracking structure.
It governs:
• event reliability
• signal hierarchy
• attribution visibility
• postback reliability
• conversion-path reconciliation
• 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
• affiliate-network postback validation
• conversion-value and identifier preservation
• 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 And Rules
Core Principle
Bad tracking produces bad optimisation.
If ad platforms learn from weak, duplicated, delayed 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
• whether event values remain consistent
• whether test events can be distinguished from live events
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
• qualified lead submission
• confirmed application event
Rules:
• only one primary signal may be declared
• primary signal must represent meaningful buyer intent
• engagement-only signals must not be primary
• the signal must be consistently observable
• the signal must not be duplicated through multiple tracking routes
Output:
Primary Signal Declared:
Yes / No
Revenue Validation Path
Evaluate whether a final revenue-confirming or commercially meaningful conversion event exists.
Examples:
• purchase thank-you page
• affiliate-network postback
• accepted lead event
• subscription confirmation
• qualifying phone-call completion
• advertiser-confirmed conversion
Rule:
Revenue validation may be delayed or imperfect, but a declared revenue path must exist.
Output:
Revenue Validation Status:
Absent / Partial / Present
Affiliate Conversion Path Definition
The complete affiliate conversion path must be documented.
Example:
Traffic Platform
→ Landing Page
→ Affiliate Link
→ Advertiser Page
→ Conversion
→ Affiliate Network
→ Tracker
→ Traffic Platform
Evaluate:
• where the conversion occurs
• which system first records the conversion
• which identifier links the conversion to the original click
• whether payout value is transmitted
• whether conversion status can later change
• whether rejected, scrubbed or reversed conversions are visible
• whether every handoff is documented
Output:
Conversion Path Status:
Undefined / Partial / Defined / Verified
Postback Coverage And Redundancy
Where affiliate-network postbacks are supported, the tracking design should use layered coverage.
Preferred structure:
• global network-level postback as a fallback
• offer-level or campaign-level postback for precision
• tracker-side conversion capture
• traffic-platform conversion feedback where permitted
The global postback acts as a safety net.
The offer-level or campaign-level postback provides more specific attribution and control.
Layered postbacks must not create duplicate conversions.
Evaluate:
• whether a global postback exists
• whether offer-level or campaign-level postbacks are available
• whether both routes preserve the same click identifier
• whether duplicate-event controls exist
• whether payout values are passed correctly
• whether unsupported networks require custom configuration
• whether fallback behaviour is documented
Output:
Postback Coverage Status:
Absent / Single Route / Layered Unverified / Layered Verified
Identifier Preservation
The system must preserve the identifiers required to connect:
• traffic click
• landing-page visit
• affiliate click
• network conversion
• tracker record
• platform conversion
Possible identifiers include:
• click ID
• sub ID
• transaction ID
• conversion ID
• campaign ID
• ad group ID
• keyword or search-term identifier
Rules:
• identifiers must remain stable across the conversion path
• identifiers must not be overwritten without documentation
• missing identifiers must be logged
• sensitive personal data must not be placed in tracking parameters
Output:
Identifier Preservation Status:
Fail / Partial / Pass
Conversion And Payout Value Transmission
Where supported, conversion records should include:
• conversion type
• conversion timestamp
• payout value
• currency
• offer or campaign reference
• transaction or conversion ID
• status
Evaluate:
• whether payout value is passed from the network
• whether currency is preserved correctly
• whether delayed payout changes can be reconciled
• whether reversals or rejected leads are visible
• whether revenue reporting uses gross or accepted value
Output:
Conversion Value Status:
Absent / Partial / Complete
Test Conversion Requirement
Before paid traffic begins, a controlled test conversion must be attempted where technically and contractually possible.
The test should verify:
• landing-page tracking
• affiliate-link parameter passing
• network conversion capture
• tracker conversion receipt
• payout-value transmission
• traffic-platform feedback
• duplicate-event prevention
Where a genuine test conversion is not permitted, the limitation must be recorded and the strongest available alternative verification used.
Output:
Test Conversion Status:
Not Possible / Not Run / Failed / Partial / Passed
Network Tracker And Platform Reconciliation
Conversion counts must be reconcilable across:
• affiliate network
• tracking platform
• advertising platform
• internal reporting layer
Evaluate:
• total clicks
• tracked affiliate clicks
• network conversions
• tracker conversions
• platform conversions
• payout totals
• timing delays
• reversals or scrubs
• duplicate or missing events
Small differences may occur because of timing, attribution windows or platform modelling.
Material differences require investigation.
Output:
Reconciliation Status:
Not Assessed / Misaligned / Partially Aligned / Aligned
Affiliate Attribution Gap Review
Affiliate purchases and leads often occur on third-party domains.
Example:
Landing Page → Advertiser Page → Affiliate Checkout Or Form → Conversion
This weakens direct platform attribution.
Evaluate:
• whether conversion occurs off-domain
• whether final conversion is visible to the platform
• whether proxy signals are required for optimisation
• whether the affiliate network returns a reliable conversion event
• whether conversion delay affects 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
• whether network postbacks can be received server-side
• whether server-side routing preserves required identifiers
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
• whether consent and disclosure requirements are satisfied
Output:
First-Party Data Status:
None / Limited / Usable / Strong
Consent And Attribution Durability Review
Purpose
Assess whether privacy restrictions are likely to reduce data quality.
Evaluate:
• whether Consent Mode is absent, partial or operational
• whether modelled conversions may influence reporting
• whether browser-side tracking loss risk is low, moderate or high
• whether interpretation caution is required
• whether affiliate-network reporting is independent of browser consent loss
• whether first-party and server-side methods remain compliant
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
• Conversion Path Status is Defined or Verified
• Identifier Preservation Status is not Fail
For affiliate-network campaigns where postbacks are supported:
• Postback Coverage Status must not be Absent
• Test Conversion Status must not be Failed
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
• the conversion path is undefined
• required click or conversion identifiers are not preserved
• postback testing fails and no reliable alternative conversion path exists
• duplicated conversion events cannot be controlled
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
• reconciliation is only partially aligned
• test conversion is not technically possible
• payout values are delayed
• the network reports accepted conversions later than the traffic platform
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
• duplicate tracker and platform events representing the same action
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
• guarantee that network reporting is accurate
• eliminate attribution delay
Architectural Role
This protocol operates inside:
Affiliate Brain Architecture
→ Infrastructure Governance
→ Tracking Layer
It supports:
• better platform learning
• cleaner testing logic
• more reliable affiliate attribution
• better capital protection
• faster identification of tracking failure
• stronger conversion reconciliation
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
• network conversions being disconnected from original traffic clicks
• global and offer-level postbacks creating duplicate conversions
• payout-value changes being ignored
• unexplained differences between network, tracker and platform reporting
• tool-specific setup instructions becoming permanent Canon rules
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, postback routing 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.
Course Absorption Note
Version v1.2 incorporates selective operational intelligence from:
Aidan Booth — 3 Click Commissions
Accepted contributions:
• global network-level postback as fallback coverage
• offer-level or campaign-level postback for attribution precision
• layered postback duplicate-event control
• click and conversion identifier preservation
• payout-value transmission
• controlled test conversion before traffic
• network-to-tracker-to-platform reconciliation
• explicit affiliate conversion-path documentation
Rejected as duplicate, tool-specific or insufficiently durable:
• TrackBeam-specific setup instructions
• Launchpad Pro folder installation steps
• browser-console debugging commands
• software-specific interface walkthroughs
• treating one tracking product as mandatory
Change Log
Version: v1.2
Date: 2026-07-19
Author: MWMS HeadOffice / Affiliate Brain
Change:
Added affiliate conversion-path documentation, layered postback coverage, global fallback and offer-level precision controls, identifier preservation, conversion-value transmission, test-conversion validation, duplicate-event prevention and network-to-tracker-to-platform reconciliation. Added selective course absorption record from Aidan Booth — 3 Click Commissions.
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 and 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.
Change Impact Declaration
Pages Created:
None
Pages Updated:
Tracking Governance Protocol
Pages Deprecated:
None
Registries Requiring Update:
Affiliate Brain Page Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
END — TRACKING GOVERNANCE PROTOCOL v1.2