Skip to main content

Mapping

Mapping transforms your events - either as they come from sources or before they go to destinations. Use the same mapping syntax in both places.

Why mapping?

For Sources: Clean up messy input data, filter unwanted events, normalize formats

For Destinations: Transform events to match what each tool expects (GA4, Meta, etc.)

Source
Collector
Destination
12
1Source mapping: Clean, filter, normalize incoming data2Destination mapping: Transform to tool-specific formats

When to use

Source Mapping:

  • Filter test/debug events before they reach your collector
  • Rename inconsistent event names from different sources
  • Validate or normalize data before processing

Destination Mapping:

  • Transform event names to match destination requirements (e.g., product viewview_item for GA4)
  • Reshape data to fit destination APIs
  • Add required fields like currency codes

How it works

Map events by their entity-action structure:

Loading...

Both mappings are independent - the same event can be transformed differently at each stage.

What you can do

  • Rename events to match your needs or destination requirements
  • Filter events by ignoring unwanted ones
  • Reshape data to match destination formats
  • Add static values like currency codes
  • Validate data before sending
  • Require consent to respect user privacy
  • Apply policies to modify events at config or event level

Event mapping with getMappingEvent

getMappingEvent(event: WalkerOS.PartialEvent, mapping?: Mapping.Rules): Promise<Mapping.Result>

This function finds the appropriate mapping configuration for an event based on its entity and action.

Basic event mapping

Map specific entity-action combinations to custom event names:

Configuration
Loading...
Result
Loading...

Wildcard mappings

Use wildcards (*) to match multiple entities or actions:

Configuration
Loading...
Result
Loading...

Conditional mappings

Use conditions to apply different mappings based on event properties:

Configuration
Loading...
Result
Loading...

Ignoring events

Skip processing certain events by setting ignore: true:

Configuration
Loading...
Result
Loading...

Skip vs Ignore

Two related but distinct rule flags control destination behavior:

  • ignore: true: the rule matched but nothing happens. No data transformation, no destination call, no side effects. Use for suppression.
  • skip: true: the rule matched and the destination's push() is called. settings.identify, settings.revenue, settings.group, etc. still run. Only the destination's default forwarding call (e.g. track(), capture(), event()) is suppressed. Use for "identify without an event" style flows.

If both flags are set on the same rule, ignore wins.

{
user: {
login: {
skip: true,
settings: { identify: { map: { user: 'data.id' } } },
},
},
}

The example above runs the destination's identify() side effect on user login events but skips the destination's default forwarding call.

Value mapping with getMappingValue

getMappingValue(value: unknown, mapping: Mapping.Data, options?: Mapping.Options): Promise<WalkerOS.Property | undefined>

This function transforms values using various mapping strategies.

String key mapping

Use a string to extract a value by its property path:

Configuration
Loading...
Result
Loading...

Array access

Access array elements using dot notation:

Configuration
Loading...
Result
Loading...

Static values

Return static values using the value property:

Configuration
Loading...
Result
Loading...

Custom functions

Transform values using custom functions:

Configuration
Loading...
Result
Loading...

Object mapping

Create new objects by mapping properties:

Configuration
Loading...
Result
Loading...

Array processing with loop

Process arrays and transform each item:

Configuration
Loading...
Result
Loading...

Validation

Validate values and return undefined if validation fails:

Configuration
Loading...
Result
Loading...

Only return values when required consent is granted:

Configuration
Loading...
Result
Loading...

Policy

Policies modify events before processing. Apply them at config-level (all events) or event-level (specific entity-action combinations).

Processing order: Config policy → Event matching → Event policy → Data transformation

Config-level policy

Global transformations applied to all events:

Loading...

Event-level policy

Transformations for specific events:

Loading...

Policies work with wildcards and conditions, and both levels can be combined - config policy runs first, then event policy for the matched rule.

Usage examples

Source mapping

Normalize events before they reach the collector:

Loading...

Destination mapping

Transform for specific destination APIs:

Loading...

Combined flow

Event processed twice with different configs:

Loading...

Best practices

  1. Source mapping: Normalize, filter, validate incoming events
  2. Destination mapping: Transform to destination-specific formats
  3. Use specific mappings over wildcards for better performance
  4. Validate critical data before sending to destinations
  5. Respect consent by using consent-based mappings
  6. Keep transformations simple - complex logic in custom functions
💡 Need help mapping your events?
Getting GA4, Meta, or custom destination mappings right for complex e-commerce setups is exactly what our consulting calls are for. Start with a free scoping call.