Event Filters

Why filter events per destination

Not every event belongs on every platform. You might want only purchases and sign-ups going to Meta for attribution, while a richer set (page views, scroll depth, engagement events) flows to GA4 or your data warehouse for analytics. Event Filters give you per-destination control without requiring separate SDK calls or different tag configurations.

The default behavior is wide-open. When no event names are listed, every event from the source reaches the destination. That's the right default for simple setups where you want all server-side data going everywhere. For more selective routing, list specific event names.

Adding events to the filter

Navigate to Echo > Destinations and open the destination you want to filter. The Event Filter panel has a chip input where you can type event names. Type a name, press Enter, and a chip appears. Repeat for each event you want to include.

Below the input are two preset rows: Echo canonical (snake_case) with events like page_view, add_to_cart, purchase, and Meta native (PascalCase) with PageView, AddToCart, Purchase. Click any preset to add it instantly. These exist because different teams naturally think in different conventions.

You can also type completely custom event names like GetStartedClick or VideoWatched50. The input accepts letters, digits, underscores, dots, hyphens, and colons, matching the Echo Collector's validation. Save when done.

How case handling works

Matching is case-insensitive on the server. If your SDK fires Purchase and your filter lists purchase, they match and the event flows. If your SDK fires purchase and your filter lists Purchase, they also match. The case you type into the chip input is preserved visually, so filters look exactly how you typed them, but the actual match doesn't care about case.

This matters because the Echo SDK has a normalizeEventNames flag. By default it's true, and the SDK lowercases event names to Echo canonical before posting. If you set it to false (useful if your team prefers Meta's vocabulary), event names pass through exactly as written in the track() call. Either way, the Event Filter handles it.

Two layers of filtering

Events can be filtered at two levels: the destination's Event Filter (documented here) and the Connection's event filter. A Connection links a Source to one or more Destinations, and each Connection can narrow which events flow through that particular link. The effective filter is the intersection of both.

For most setups, filtering at the destination level is enough. Use connection-level filtering only when you need different subsets of events for the same destination across different sources (rare) or when you want to distribute events among destinations by category without editing each destination individually.

Tips

• Leave the filter empty to forward every event. That's the right default for most setups.
• Case doesn't matter for matching, but the chip preserves what you typed. Type what reads naturally for your team.
• If you set SDK normalizeEventNames: false, think about using PascalCase filter names for clarity.
• Custom event names (like MyBrandSpecialEvent) pass through fine. Add them to the filter if you're narrowing.
• Preset rows cover 80% of common events. Use them as a starting point and add your own names as needed.

Troubleshooting

Events not reaching destination despite being in filter

Confirm the destination is enabled (the toggle at the bottom of the edit page). Confirm the Source is producing those events by checking the Echo dashboard's received counts. If received is positive but destination sent is zero, the destination credentials might be wrong rather than the filter.

Events flowing that shouldn't be

Empty filter means all events flow. If you didn't intend that, add specific event names. Also check the Connection between source and destination since it has its own filter layer.

Case mismatch suspected

Matching is case-insensitive. If you're sure your SDK fires CustomEvent but the filter has customevent and events aren't flowing, the problem is elsewhere (destination disabled, credentials wrong, source not emitting). The case itself won't cause misses.