What a destination is
A destination in Echo represents a single connection to an advertising platform. When you fire an event from your website through the Echo SDK, every enabled destination receives its own copy, translated into that platform's native format. A single property might have three destinations: one for Meta, one for Google Ads, and one for your internal data warehouse.
Each destination holds the credentials needed to authenticate with that platform, the event filter that controls which events it receives, and any custom attributes you've chosen to forward. Destinations are scoped to a single property, so different properties under the same company can have completely different destination configurations.
Echo supports server-side delivery to Meta (Facebook), Instagram, TikTok, Pinterest, Snapchat, Reddit, Google Analytics 4, Google Ads, LinkedIn, Microsoft Ads, and Floodlight. It also supports the Lens data warehouse for analytics and a Custom destination for any HTTP endpoint, for thirteen destination types in total.
Adding a destination
Navigate to Echo > Destinations within your property. Click Add Destination to open the configuration page. The first section lets you give the destination a friendly name and description, then pick the platform from a grid of cards.
Selecting a platform reveals the configuration fields specific to that platform. Meta requires a Pixel ID and Access Token. Snapchat needs a Snap Pixel ID and a bearer token from your Business Manager. Reddit needs your Ad Account ID (the one starting with a2_) and an access token from a Reddit app you've created. Each platform's configuration help panel on the right side explains where to generate the required credentials.
The platform cards are deliberately clear and recognizable. Pick Meta if you want Facebook or Instagram tracking, since Meta now covers both. Pick GA4 if you want server-side Measurement Protocol. Pick Lens if you want to send raw events to your own warehouse for analytics.
Choosing which events to forward
The Event Filter panel controls which events reach this destination. Leave it empty and every event from the source flows through. Add specific event names (like purchase or add_to_cart) and only those events flow, with everything else skipped.
Matching is case-insensitive. An event named Purchase in your SDK matches a filter of purchase and vice versa. The UI preserves exactly the case you typed, so if you prefer to work in Meta's PascalCase vocabulary (with the SDK's normalizeEventNames: false flag) you can enter Purchase and it'll display as Purchase in the chip.
Two quick-add rows appear below the input: Echo canonical (snake_case) and Meta native (PascalCase). Click any preset to add it instantly. You can also type freeform event names including custom ones like GetStartedClick that aren't in either convention.
Forwarding custom attributes
Standard fields flow automatically based on the platform mapping. For Meta, these include value, currency, content_name, content_category, and order_id. Each is pulled from the corresponding ep.* parameter on your event and placed in the right slot of Meta's CAPI payload.
If you want to forward extra parameters beyond the standard set, use the Custom Attributes panel. Type the attribute name (like funnel_step or campaign_stage) and hit Enter. Any ep.* parameter matching one of these names will be added to the destination's custom data section alongside the standard fields.
Each destination has its own independent custom attributes list. Adding funnel_step to Meta does not cause it to flow to GA4 unless you also add it there. This prevents attributes meant for one platform from accidentally polluting another. Only destinations with a custom_data-like container (Meta, Snap, Reddit, TikTok, Pinterest, GA4) show the Custom Attributes panel.
Verifying events flow correctly
After saving a destination, fire an event from your website and check the platform's Events Manager. If you entered a test event code on Meta, the event appears in the Test Events tab within about 30 seconds. Without a test event code, live events flow directly to the main Events Manager stream.
The Echo dashboard inside TagPipes shows per-destination metrics: events received, events sent successfully, processing errors, and DLQ writes. These metrics update in near-real-time after each Lambda invocation. If Events Delivered is climbing and errors stay near zero, the destination is healthy.
Every event Echo sends includes an event_id. If the same event also fires via the browser pixel (via fbq('track', 'Purchase', {}, { eventID }) in Meta's case), the platform deduplicates them so you never double-count. This makes retries safe and free.
Multiple destinations of the same type
You can create multiple destinations of the same platform type. A common use case is one production Meta destination and one test destination with a test event code. Each destination is independent, so they can have different event filters, different custom attributes, and different credentials.
All enabled destinations for a property are aggregated into a single EventBridge rule. When you save or delete a destination, the rule refreshes automatically so the Processor sees the updated configuration on the next event.
Tips
- Personal data like email and phone is automatically SHA256 hashed before reaching the ad platform. Never put PII in custom attributes since those are not hashed.
- Use the Test Event Code field during rollout to verify events in the platform's Test Events tab before switching to live.
- Create multiple destinations of the same type if you need to send events to different ad accounts or to different environments.
- Batches up to 500 events per request are sent for most destinations. Failed batches are retried on transient errors and written to DLQ on permanent failures.
- The destination you see in the UI is what the Processor Lambda uses, but there's a short delay (usually seconds) between save and the new configuration taking effect.
Troubleshooting
Events not reaching the destination
First check that the destination is enabled and the property's source is firing events. On the Echo dashboard, look at the destination's received count. If it's zero, events aren't reaching the Processor at all. If received is positive but sent success is zero, credentials are probably wrong. Check CloudWatch logs on the tagpipes-echo-processor Lambda for the exact error.
Authentication errors
Access tokens expire for some platforms. Meta's System User tokens are long-lived, but short-lived tokens expire in 60 days. Reddit and Snapchat OAuth tokens also have expiry. Regenerate the token in the platform's business manager and update the destination config.
Events showing up but missing fields
If events appear in the platform but custom_data or user_data is incomplete, check that your SDK is passing the right parameters. Standard fields like value need to be sent as ep.value in the event payload. Custom fields need to be added to the destination's Custom Attributes list.