Set Up a Pipeline

How Echo works

Echo moves event data from the browser to advertising platforms entirely server-side. The browser SDK posts events to the Echo Collector, which validates them and writes them to a Kinesis Firehose stream. From there, events land in S3 and trigger the Echo Processor Lambda, which transforms each event per destination and forwards it to the right API. End-to-end latency is typically under two minutes.

This server-side approach is immune to ad blockers that strip browser-side pixel calls, and it gives you precise control over what personal data leaves your infrastructure. Events are first-party, so they benefit from longer cookie lifetimes and better match quality on ad platforms.

Every Echo pipeline has three moving parts: a Source that collects events from your website, one or more Destinations that know how to talk to specific ad platforms, and Connections that decide which events flow where. Set up each piece in order and you'll have events flowing within minutes.

Create a source

Navigate to Echo > Sources and click Add Source. A source represents a website or app that produces events. You can have multiple sources per property if you need to distinguish between domains or subdomains, or stick with a single source for simpler setups.

Give the source a descriptive title so you'll recognize it later. The default SDK version setting works for most installations. After saving, you'll see the source's unique ID, which is what the Echo SDK references when posting events.

Create destinations

Navigate to Echo > Destinations and add each advertising platform you want to send events to. Supported destinations are Meta (Facebook), Instagram, TikTok, Pinterest, Snapchat, Reddit, Google Analytics 4, Google Ads, LinkedIn, Microsoft Ads, Floodlight, the Lens data warehouse for analytics, and a Custom destination for any HTTP endpoint, for thirteen types in total.

Each destination requires platform-specific credentials. Meta needs a Pixel ID and Access Token from your Business Manager. Snapchat needs a Snap Pixel ID and OAuth bearer token. Reddit needs an Ad Account ID (starting with a2_) and an access token from a Reddit app. The help panel on the right side of the edit page tells you exactly where to find each credential on the platform side.

You can create multiple destinations of the same type. A common pattern is one production destination plus a separate test destination with a test event code, so you can verify new events before flipping them live.

Create connections

Navigate to Echo > Connections and link your source to one or more destinations. Each connection defines which events from the source reach which destination. You might connect a single source to five destinations if you want the same events routed everywhere, or create separate connections with different event filters if you want to send specific events to specific platforms.

A connection's event filter is in addition to the filter on the destination itself. Between the two, you have flexible control over what flows where. If both filters are empty, every event from the source reaches the destination. If either has events listed, only those events flow.

Deploy the SDK

Add the Echo client SDK to your website. The SDK exposes a tph.echo.track(name, params) function that captures an event and posts it to the Echo Collector. The SDK handles authentication, retry on the client side, and consent integration automatically.

The SDK has a normalizeEventNames option. By default it normalizes event names to Echo canonical (snake_case like page_view, add_to_cart). Setting it to false preserves whatever case your developers used, useful if you want to match Meta's PascalCase vocabulary exactly. Either way, Echo handles the translation per destination.

Every call to track() returns an object containing a unique event_id. Pass that ID to the corresponding browser pixel call so server-side and client-side events deduplicate properly: fbq('track', 'Purchase', params, {'{'} eventID: result.event_id {'}'}). This prevents double-counting when both paths succeed.

Verify events are flowing

Fire a test event from a page on your site. Within about 30 seconds, the event should appear in the Events Manager of your destination platform. If you configured a Test Event Code on Meta, the event shows up in the Test Events tab specifically. The Echo dashboard inside TagPipes also shows per-destination metrics updating in near-real-time.

If events aren't flowing, check the Echo dashboard first. If the source's received count is zero, the SDK isn't posting successfully, which usually means a CORS or authentication issue in the browser. If received is positive but destination sent is zero, the destination credentials are probably wrong. CloudWatch logs on the tagpipes-echo-processor Lambda have the exact error.

Tips

• Start with one destination at a time. Verify events flow correctly before adding another destination.
• Use a Test Event Code on Meta during setup so you can see events in the Test Events tab without affecting live numbers.
• The Echo SDK returns an event_id synchronously. Pass it to your browser pixel for proper deduplication.
• Event names flow through destinations per their own translation maps. You don't need to send Meta-PascalCase event names if you don't want to, but you can if the normalizeEventNames: false flag is set.
• Aggregate metrics on the dashboard update within minutes, not instantly. If something looks off, wait a minute and refresh before deep-diving.

Troubleshooting

Events show up in source but not destination

Check the destination is enabled and the Event Filter isn't excluding your event name. If both are correct, check the destination credentials. The CloudWatch logs for tagpipes-echo-processor contain the exact failure reason.

Events duplicated in ad platform

This usually means the browser pixel is firing without the event_id from the Echo SDK. Meta, Snap, TikTok, Pinterest, and Reddit all deduplicate using event_id. Pass the ID from result.event_id in your pixel tag so dedup takes effect.

Browser posts but server doesn't see events

Open the network tab in your browser and fire an event. You should see a POST to the Echo Collector URL returning 200. If it returns 4xx, check the SDK configuration. If the POST succeeds but no events appear in the dashboard, CloudWatch logs on the Collector Lambda reveal validation failures.