Route server-side events to third-party analytics and ad platforms
Extend a server-side forwarding property to deliver filtered event data from the edge network to multiple external destinations such as analytics services, cloud functions, and advertising platforms.
Routing server-side events to third-party platforms produces a live, multi-destination forwarding configuration that delivers enriched, field-selected event data to analytics services, advertising platforms, and cloud infrastructure without client-side overhead. The primary outputs are the destination-specific rule actions within the forwarding property and the confirmation of received payloads at each target system (visible in GCF logs, Kinesis monitoring tabs, or S3 bucket file creation).
The key design decisions are: which fields from the edge payload are relevant to each destination (different platforms need different subsets), whether to use field-level extraction via data elements or full-payload forwarding, and how to handle authentication to each target (public endpoints, signed AWS requests, OAuth tokens). Teams should also consider the fan-out cost implications — each additional forwarding action increases edge processing latency marginally and may incur per-event billing at the destination side.
This task has medium-to-high parallelism across architectures. The AEP Event Forwarding approach is edge-native and operates in sub-100ms latency from the browser interaction. Composable equivalents use stream processors (Kafka with consumers, Kinesis Firehose, Pub/Sub subscriptions) where each consumer handles one destination. The functional result is identical — filtered event data reaching multiple third-party endpoints — but the latency, operational burden, and cost model differ significantly. Teams choosing a composable approach gain full control over field mapping and transformation logic at the cost of managing consumer infrastructure.
Side-by-side implementations
In AEP Data Collection Event Forwarding, extend an existing property by adding destination-specific data elements and additional rule actions. For a Google Cloud Function, create path-based data elements for customerECID (arc.event.xdm.<tenantId>.identification.core.ecid), eventTimestamp (arc.event.xdm.timestamp), and pageName (arc.event.xdm.web.webPageDetails.name), then add a rule action targeting the GCF HTTP trigger URL with a JSON body composed from those elements. For an AWS Kinesis destination, create a custom-code data element that serializes the full XDM event as a JSON string with a dynamic partitioning key, then add a rule action targeting the AWS API Gateway endpoint with the Kinesis PutRecord payload structure (StreamName, PartitionKey, Data). Each new destination gets its own rule action, allowing fan-out to multiple platforms from a single edge event. After configuring each action, publish via Publishing Flow → Save & Build for Development.
Capability: Audience Segmentation
Fan-out to multiple third-party destinations from a Kafka event stream is implemented by configuring one Kafka Sink Connector per target (Google Cloud Function URL, AWS Kinesis via API Gateway, Pub/Sub topic). Each connector applies its own field extraction transforms using Kafka Connect SMTs (Single Message Transforms): ExtractField, ValueToKey, ReplaceField. For Google Cloud Function, the HTTP Sink Connector POSTs filtered JSON to the GCF trigger URL with configurable headers. For AWS Kinesis via API Gateway, the connector serializes the payload as {"StreamName":"...","PartitionKey":"...","Data":"<base64>"} and POSTs to the API Gateway endpoint. Testing uses Kafka consumer CLI and target-platform monitoring consoles — identical to AEP's GCF logs and Kinesis Monitoring tab approach.
Capability: Reverse-ETL (CDW-to-Destination Sync)
Hightouch Event Streaming supports fan-out to multiple third-party destinations from a single source event stream: Google Analytics 4 (via Measurement Protocol), Facebook Conversions API, AWS Kinesis, Azure Event Hubs, custom HTTP endpoints, and others. Each destination is configured as a separate Hightouch Event Streaming destination with its own field mapping and authentication credentials stored in Hightouch's connection settings. The fan-out pattern mirrors AEP's per-rule-action model: each destination gets its own configuration object, and all receive payloads from the same source event trigger. Authentication to advertising platforms (GA4 Measurement Protocol API secret, Facebook CAPI access token) uses API keys configured in Hightouch's destination connection panel. The primary operational difference from AEP is latency: Hightouch Event Streaming reads from the warehouse (Snowflake event table), so there is a 1–30 second delay from browser interaction to forwarding, depending on Snowpipe ingestion speed — compared to AEP's sub-100ms edge-native forwarding.
Capability: Audience Segmentation
Task-level sources
- technical-training/module14/index.md
- technical-training/module14/ex4.md
- technical-training/module14/ex5.md
How is this implementation?
Sign-in-gated. Tomorrow morning's curriculum-ingestor consumes your feedback: "Inaccurate" queues the task for re-review, "needs update" queues it for a refresh, and "one vendor panel is wrong" re-drafts just that panel.