Document Type: Framework
Status: Active
Authority: Data Brain
Parent: Data Brain Architecture
Applies To: All MWMS environments where behavioural, conversion, interaction, or tracking events are used for measurement, optimisation, or decision-making
Version: v1.0
Last Reviewed: 2026-04-23
Purpose
The Data Brain Event Reliability Framework defines how MWMS evaluates whether tracked events can be trusted as dependable representations of real user behaviour.
An event being present does not automatically mean it is reliable.
Event reliability depends on:
• whether the event fired correctly
• whether it fired at the right time
• whether it captured the correct data
• whether it was able to fire under real-world technical conditions
• whether it remained stable across environments and changes
Weak event reliability produces false measurement confidence.
False measurement confidence creates false optimisation decisions.
This framework ensures MWMS treats event collection as a reliability problem, not just an implementation problem.
Scope
This framework governs:
• event firing reliability
• event timing reliability
• event dependency chains
• trigger sequencing reliability
• asynchronous event risk
• race condition risk
• navigation-loss risk
• third-party event reliability
• iframe event reliability
• cross-system event continuity
This framework applies across:
• analytics environments
• advertising environments
• funnel environments
• click tracking environments
• external tool environments
• embedded component environments
• event-based conversion systems
• behavioural signal systems
This framework does not govern:
• event naming conventions
• dashboard design
• reporting UI structure
• capital allocation decisions
• media buying strategy
Those remain governed by related MWMS systems.
Core Principle
An event is only trustworthy if it is reliably collectible under real-world conditions.
An event may fail even when:
• the implementation appears correct
• the tag exists
• the trigger exists
• the reporting interface shows some data
Therefore:
event presence is not proof of event reliability.
MWMS must distinguish between:
• event implemented
• event firing
• event firing correctly
• event firing consistently
• event surviving technical constraints
Reliable event collection requires more than correct setup.
Reliable event collection requires dependable execution conditions.
Event Reliability Definition
Event reliability is the probability that an event:
• fires when the real behaviour occurs
• does not fire when the behaviour did not occur
• captures the intended values
• survives platform, browser, navigation, and timing constraints
• remains stable across deployments and environments
Event reliability therefore includes both:
• logical correctness
• technical survivability
Event Reliability Components
Firing Accuracy
The event must fire when the intended behaviour occurs.
Examples:
• click event fires when the intended CTA is clicked
• lead event fires when the valid lead action completes
• checkout event fires when checkout actually begins
If the intended behaviour occurs but the event does not fire, reliability is weakened.
If the event fires when the intended behaviour did not occur, reliability is also weakened.
Timing Reliability
The event must fire in time to be captured.
Examples of timing risk:
• click occurs and navigation starts before tracking completes
• page unload interrupts event processing
• asynchronous systems delay value availability until after the event is sent
Timing reliability is one of the most common hidden weaknesses in event collection.
An event may be logically correct but technically too late.
Dependency Reliability
Some events depend on other events, tags, variables, or configuration objects being available first.
Examples:
• configuration tag must fire before event tag
• user ID must be available before login event is sent
• page context must be set before a click event is emitted
• external tool state must exist before event can be interpreted
If a dependency fails, event reliability falls even if the final event tag itself appears correct.
Data Completeness Reliability
The event must include the data needed for interpretation.
Examples:
• click event includes URL and context
• purchase event includes value and item information
• lead event includes correct step or source metadata
An event without required parameters may still fire, but not be decision-safe.
Stability Reliability
The event must behave consistently across time, environments, and changes.
Examples:
• same event works across templates or site sections
• same event survives deployments and front-end updates
• same event behaves the same in live and embedded environments
An event that works only in some situations is not fully reliable.
Event Reliability Failure Types
Silent Failure
The event does not fire, but no obvious error is visible.
Examples:
• event blocked by timing
• event lost on navigation
• event never triggered because selector changed
• dependency value unavailable
Silent failure is highly dangerous because it weakens trust without producing obvious alerts.
False Positive Failure
The event fires when it should not.
Examples:
• duplicate click events
• repeated conversion events
• event triggered by the wrong element
• form interaction counted as full form completion
False positive failure inflates signal strength and distorts optimisation.
False Negative Failure
The user behaviour occurred, but the event was not captured.
Examples:
• click lost before navigation
• iframe interaction not visible to parent container
• external vendor component does not expose tracking hooks
• non-anchor interaction not included in link tracking logic
False negative failure hides real behaviour and weakens measurement completeness.
Context Failure
The event fires, but its meaning is incomplete.
Examples:
• click recorded without knowing region or component
• interaction recorded without destination context
• event captured without knowing user state or funnel stage
Context failure reduces interpretability even when the event technically exists.
Drift Failure
The event was once reliable, but no longer behaves consistently.
Examples:
• site redesign changes selectors
• component markup changes
• vendor widget changes behaviour
• tag sequencing changes during implementation updates
Drift failure is especially dangerous because legacy trust may continue after reliability has weakened.
Timing Risk Rule
Events that depend on a short execution window must be treated as high-risk.
Examples:
• link clicks before navigation
• file download clicks
• outbound click events
• button-triggered redirects
• JavaScript-triggered navigation events
These events require special scrutiny because event loss may occur before tracking completes.
High timing risk events must never be assumed reliable by default.
Configuration Dependency Rule
Events relying on configuration tags or upstream value-setting must be evaluated for sequencing reliability.
Examples:
• user ID set in configuration tag after login action begins
• page context set too late for downstream event use
• event sent before configuration values are refreshed
If the required configuration object was not fired or refreshed before the event, the event may fire with stale or missing values.
Reliable sequencing is part of event reliability.
Asynchronous State Rule
Events depending on asynchronously loaded information must be treated as reliability-sensitive.
Examples:
• authentication state loads after page view
• external tool data arrives after interaction
• consent state updates after initial page actions
• component data becomes available after render
If an event depends on asynchronous state, the implementation must verify that the state is available before event firing.
Otherwise:
the event may fire with incomplete or outdated information.
Race Condition Rule
Where two or more processes compete in time, event reliability must be explicitly validated.
Examples:
• event firing vs page navigation
• configuration update vs event emission
• iframe postMessage vs parent listener readiness
• external vendor render vs DOM scraping logic
A race condition does not need to occur every time to weaken reliability.
Intermittent loss is still loss.
Embedded and External Environment Rule
Events inside embedded or external systems must be treated as reduced-visibility environments unless proven otherwise.
Examples:
• third-party forms
• video embeds
• chat widgets
• payment processors
• external authentication flows
• iframes
In these environments, reliability depends on whether MWMS can:
• add a tracking container
• access the DOM
• receive callbacks or postMessages
• capture meaningful state
If none of these are available, event reliability may be low or unknowable.
Event Reliability Tiers
High Reliability Event
Conditions:
• fires consistently
• survives technical conditions
• includes required data
• no known timing or dependency instability
• validated across real scenarios
Use:
safe for decision-making
Moderate Reliability Event
Conditions:
• generally works
• some edge-case loss or dependency risk
• context may be partial
• minor environment variability exists
Use:
acceptable with caution and supporting evidence
Low Reliability Event
Conditions:
• inconsistent firing
• timing-sensitive loss
• dependency instability
• poor visibility in some environments
• incomplete parameter coverage
Use:
not safe as a primary decision signal
Unknown Reliability Event
Conditions:
• not yet validated
• embedded in restricted environment
• external vendor logic opaque
• cross-frame behaviour not confirmed
Use:
must not be treated as trusted until evaluated
Validation Requirements
Event reliability must be evaluated using:
• real user journey testing
• GTM preview mode
• GA4 debug inspection
• dependency sequencing review
• environment comparison
• change regression checks
Where relevant, validation should also include:
• iframe interaction testing
• external vendor interaction testing
• navigation timing checks
• parameter completeness review
Reliability Questions
For any important event, MWMS should ask:
• Does the event always fire when expected?
• Can it fire when it should not?
• Does navigation interrupt it?
• Does it depend on another tag or state being present first?
• Does it survive asynchronous loading?
• Does it work inside third-party or embedded systems?
• Does it include enough context to remain interpretable?
• Has it been validated recently?
If these questions cannot be answered clearly, reliability is not yet proven.
Relationship to Other Frameworks
Supports:
• Data Brain Measurement Integrity Framework
• Data Brain Data Trust Framework
• Data Brain Analytics Audit Framework
• Data Brain Measurement Validation Protocol
• Data Brain Signal Flow Framework
• Data Brain Visibility Gap Framework
Event reliability is a foundational layer beneath:
• signal trust
• attribution confidence
• experiment confidence
• decision safety
Failure Modes Prevented
This framework helps prevent:
• trusting events that fail silently
• undercounting real user behaviour
• overcounting actions through duplication
• assuming embedded systems are trackable
• relying on stale configuration values
• making decisions from incomplete interaction signals
• losing trust through unrecognized event drift
Drift Protection
The system must prevent:
• event reliability assumptions surviving after deployments
• timing-sensitive events being treated as stable without validation
• configuration dependency problems remaining invisible
• asynchronous state issues weakening event quality unnoticed
• external vendor changes silently degrading signal capture
Event reliability must remain observable, reviewable, and testable.
Architectural Intent
The Data Brain Event Reliability Framework ensures MWMS understands that event collection is not binary.
Events are not simply:
tracked
or
not tracked
Instead, events exist on a reliability spectrum.
By making event reliability explicit, MWMS improves:
• signal quality
• interpretation quality
• optimisation safety
• system truthfulness
Reliable events strengthen every downstream Brain that depends on behavioural measurement.
Final Rule
If event reliability is weak or unknown, the signal must not be treated as decision-safe.
Event implementation is not enough.
Event reliability must be proven.
Change Log
Version: v1.0
Date: 2026-04-23
Author: Data Brain
Change:
Initial creation of Data Brain Event Reliability Framework defining how MWMS evaluates whether tracked events can be trusted under real-world technical conditions.
Change Impact Declaration
Pages Created:
Data Brain Event Reliability Framework
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes