Document Type: Standard
Status: Canon
Authority: HeadOffice
Parent: Governance
Applies To: All MWMS tracking systems, Data Brain signals, event capture systems, analytics pipelines, and measurement implementations
Version: v1.0
Last Reviewed: 2026-04-23
Purpose
The MWMS Custom Event Payload Standard defines the required structure, naming conventions, and parameter rules for all custom events generated within MWMS.
Custom events are the primary mechanism through which behavioural data becomes system signals.
Without standardisation:
• signals become inconsistent
• data becomes fragmented
• analysis becomes unreliable
• system intelligence degrades
This standard ensures all events follow a consistent structure that supports:
→ signal comparability
→ cross-system compatibility
→ reliable analysis
→ scalable data processing
Core Principle
All events must speak the same language.
If event structures differ:
→ signals cannot be compared
→ analysis becomes unreliable
Scope
This standard governs:
• event naming conventions
• parameter naming and structure
• event payload design
• required and optional parameters
• data typing and formatting
• cross-system compatibility
This standard applies to:
• custom events
• behavioural signals
• system events
• conversion events
• experiment events
Standard Event Payload Structure
All events must follow the structure below:
event: custom_eventevent_type: string
event_category: string
event_label: string
event_value: number (optional)element_id: string (optional)
element_text: string (optional)page_type: string
page_context: string
funnel_step: stringtraffic_source: string (if available)
campaign_id: string (if available)experiment_id: string (optional)
variant_id: string (optional)timestamp: numeric or ISO string
Parameter Definitions
event
Defines the event trigger.
Value:
→ must be "custom_event" for all MWMS custom events
Purpose:
→ standardizes event detection
event_type
Defines the specific interaction type.
Examples:
• click
• focus
• blur
• submit
• abandon
• scroll
• view
• start
• complete
event_category
Defines the interaction category.
Examples:
• form
• button
• navigation
• video
• content
• system
event_label
Defines the specific interaction target.
Examples:
• hero_cta
• signup_form
• pricing_section
• faq_toggle
event_value
Optional numeric value.
Examples:
• scroll percentage
• time spent
• value score
element_id
Optional identifier for the interacted element.
element_text
Optional visible text of the element.
page_type
Defines page classification.
Examples:
• landing_page
• presell_page
• checkout_page
• thank_you_page
page_context
Defines specific page or funnel context.
Examples:
• campaign_lp_1
• bridge_page_variant_a
• checkout_step_2
funnel_step
Defines stage in funnel.
Examples:
• entry
• engagement
• consideration
• conversion
traffic_source
Captures origin source where available.
Examples:
• google_ads
• organic
• direct
campaign_id
Captures campaign reference where available.
experiment_id
Optional experiment reference.
variant_id
Optional variant reference.
timestamp
Captures event time.
🔴 Required Parameters
The following must always be present:
• event
• event_type
• event_category
• event_label
• page_type
• page_context
• funnel_step
• timestamp
🔴 Optional Parameters
Optional parameters must only be included when:
• data is available
• data is accurate
Optional parameters must not be populated with:
→ placeholder values
🔴 Naming Convention Rules
All parameters must:
• use lowercase
• use underscores
• be descriptive
• be consistent across environments
Examples:
correct:
hero_cta_click
form_start
incorrect:
Click1
CTAbutton
eventA
🔴 Event Type Discipline
event_type must represent:
→ how the interaction occurred
event_category must represent:
→ what was interacted with
event_label must represent:
→ which specific element or instance
🔴 Consistency Rule
The same interaction must produce:
→ identical event structure across all environments
Inconsistent event definitions are not permitted.
🔴 Context Completeness Rule
Events must include enough context to be interpretable.
Events missing:
• page context
• funnel step
• interaction target
are considered incomplete.
🔴 Data Type Rule
All parameters must use consistent data types:
• strings for labels and categories
• numbers for values
• timestamps for time
Mixed data types are not permitted.
🔴 Payload Size Discipline
Event payloads must balance:
• completeness
• efficiency
Excessive parameters create:
• noise
• processing overhead
🔴 Transport Compatibility Rule
All payloads must be compatible with:
• data layer systems
• tag management systems
• analytics platforms
• data warehouses
Payloads must not rely on platform-specific structures.
🔴 Enrichment Compatibility Rule
Payloads must support future enrichment.
Events must allow:
• additional parameters
• extended context
• system-level augmentation
🔴 Duplication Rule
Events must not be duplicated unintentionally.
Duplicate payloads must be:
• prevented
• detected
• corrected
🔴 Version Control Rule
Changes to payload structure must:
• be documented
• be version-controlled
• maintain backward compatibility where possible
Relationship to Other Standards
Supports:
• MWMS Tracking Architecture Standard
• MWMS Pre Conversion Signal Tracking Standard
• MWMS Attribution Preservation Standard
• Data Brain Custom Event Design Framework
• Data Brain Signal Flow Framework
Failure Modes Prevented
inconsistent event naming
fragmented data
incompatible systems
incorrect analysis
loss of signal meaning
Drift Protection
The system must prevent:
• uncontrolled parameter changes
• inconsistent payload evolution
• undocumented structure changes
Architectural Intent
The MWMS Custom Event Payload Standard ensures all MWMS systems communicate using:
→ a unified behavioural signal language
This enables:
• scalable analytics
• reliable experimentation
• consistent interpretation
• cross-system intelligence
Final Rule
If an event does not follow the standard:
→ it is not valid
Change Log
Version: v1.0
Date: 2026-04-23
Author: HeadOffice
Change:
Initial creation of Custom Event Payload Standard defining the universal structure for all MWMS event data.
Change Impact Declaration
Pages Created:
MWMS Custom Event Payload Standard
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
Canon Version Update Required:
Yes
Change Log Entry Required:
Yes