The problem Custom Attributes solves
Echo ships with built-in mappings for the standard fields each ad platform cares about. For Meta that's value, currency, content_name, content_category, content_type, order_id, num_items, search_string, and a few others. For GA4 it's the standard params list. For Snap, Pinterest, TikTok, and Reddit, similar sets. These standard fields flow automatically from your SDK call into the right slot of each destination's payload.
But your business often needs to forward extra context that isn't in any platform's standard list. Things like which funnel step the user is on, which promotional campaign they arrived from internally, which visitor segment they belong to, or which content tier they viewed. These are useful for custom conversions, audience building, and reporting, but platforms don't know about them by default.
Custom Attributes bridge this gap. You list the attribute names you want forwarded to each destination, and Echo pulls matching ep.* parameters from your events and places them in the destination's custom data section alongside the standard fields.
Adding Custom Attributes
Navigate to Echo > Destinations and open the destination you want to configure. Below the Event Filter panel, you'll see the Custom Attributes panel. It only appears for destinations that have a custom data container: Meta, Snap, Reddit, TikTok, Pinterest, and GA4. LinkedIn, Google Ads, Microsoft Ads, and Floodlight use fixed schemas without a custom data slot, so the panel is hidden.
Type an attribute name into the input field and hit Enter. A chip appears with the name. Repeat for each attribute you want to forward. The chip input accepts letters, digits, underscores, and dots, and preserves case exactly as you typed. You can type with or without the ep. prefix, either works (Echo strips it automatically if present).
Once you've listed the attributes, click Save. The EventBridge rule for the property refreshes with the new list, and the next event that fires will include matching attributes in the destination's payload.
How Custom Attributes flow
When an event reaches the Echo Processor, it first runs through the standard mapping for that destination. This is where ep.value becomes custom_data.value for Meta, and so on. After the standard mapping completes, the Custom Attributes passthrough step runs. It iterates your configured list, looks up each name in the event (checking both ep.{"{"}name{"}"} and the raw {"{"}name{"}"}), and copies any matches to the destination's custom data path.
Each destination has its own destination path. Meta, Snap, and Pinterest write to custom_data.{"{"}name{"}"}. Reddit writes to event_metadata.{"{"}name{"}"} since Reddit uses a different payload shape. TikTok writes to properties.{"{"}name{"}"}. GA4 writes to params.{"{"}name{"}"}. The Processor handles the correct path per destination type.
An attribute added to one destination does not leak to another. If you add funnel_step to Meta only, GA4 will not receive it unless you also add it to GA4's destination. This is intentional: you have full control over which platforms see which data, which matters for privacy compliance and for reducing noise in your advertising reports.
A concrete example
Imagine your site tracks a custom event WatchedVideo50 when a user watches 50% of a video. Your developer fires it like this:
tph.echo.track('WatchedVideo50', {"{"} video_id: 'vid_abc', funnel_step: 'awareness', campaign_stage: 'launch', value: 0 {"}"})
By default with no custom attributes configured, Meta would receive the WatchedVideo50 event (as a custom event) with custom_data.value: 0 and nothing else. The video_id, funnel_step, and campaign_stage values would be dropped before reaching Meta.
If you add video_id, funnel_step, and campaign_stage to the Custom Attributes list on the Meta destination, Meta will now receive all three fields inside custom_data. You can use them to build Custom Audiences (like "people who watched 50% of videos in the launch campaign") or Custom Conversions.
Never put personal data (email, phone, names) in Custom Attributes. Those fields are not hashed. Personally identifying data belongs in the standard user_data fields (em, ph, fn, ln, etc.), which Echo automatically SHA256-hashes before sending to ad platforms. Custom Attributes are meant for non-PII business context.
Case preservation and prefix handling
The chip input preserves whatever case you type. If you enter FunnelStep, the chip displays FunnelStep. If you enter funnel_step, the chip displays funnel_step. Echo uses the exact string you typed to look up the attribute on the source event, so the casing must match what your SDK sends.
If you accidentally type the ep. prefix (e.g., ep.funnel_step), Echo strips it automatically. The stored name is funnel_step, and the lookup will try both ep.funnel_step and raw funnel_step in the source event. This tolerance makes the input forgiving for users who think in terms of the Echo internal field naming.
Tips
- Each destination has its own independent Custom Attributes list. Add the same attribute to multiple destinations if you want it everywhere.
- Standard fields are handled automatically. You only need Custom Attributes for fields Echo doesn't already know about.
- Attribute values can be strings, numbers, or booleans. Arrays and objects are passed through as-is, which may or may not be accepted by the destination.
- For Meta specifically, Custom Attributes appear under
custom_datain Events Manager. You can use them as filters when building Custom Audiences or Custom Conversions. - Custom Events (event names Echo doesn't know) already pass through to destinations automatically, provided they're allowed by the Event Filter. You don't need Custom Attributes configured for Custom Events; only for Custom Parameters on those events.
Troubleshooting
Custom Attribute doesn't appear in destination
First check that the attribute name you configured exactly matches what your SDK sends. If the SDK sends funnelStep (camelCase) and you configured funnel_step (snake_case), they won't match because matching is case-sensitive on the attribute name. Update the chip to match.
Second, verify the event actually contains the attribute. Look in CloudWatch logs for the Processor Lambda, which logs the source event on debug mode. If the attribute isn't in the raw event, the SDK didn't send it. If it's in the raw event but not the destination, check that you saved the destination after adding the chip.
Custom Attribute appears in wrong section of destination payload
Each destination has a fixed destination path for custom attributes. For Meta that's custom_data. If your attribute is appearing outside custom_data, check whether the name collides with a standard mapped field. If you configure value as a custom attribute when ep.value is already a standard field, the custom attribute runs second and overwrites the standard value. Rename the attribute if you need both.