Configure server-side event forwarding rules
Create a server-side data collection property with data elements and rules that intercept edge network traffic and forward selected XDM event fields to external endpoints without client-side code execution.
Configuring server-side event forwarding rules produces a deployed property on the edge network that intercepts inbound event data and selectively forwards it to external systems — without requiring any additional JavaScript to execute in the visitor's browser. The primary output is a versioned, published library of data elements and rules running at the edge that transforms and routes XDM payloads in real time.
The critical design decisions are: which fields from the XDM payload to extract (full event body vs. selective fields for privacy or payload-size reasons), which external endpoints to target, and what trigger conditions (if any) should gate forwarding. The arc.event.xdm path model allows precise field selection by referencing nested XDM schema paths. Teams must also decide whether to forward to a single endpoint or fan out to multiple destinations in parallel — each forwarding rule action is evaluated independently, so multiple actions on one rule is a common pattern.
This task has medium parallelism across CDP architectures. Native edge-network event forwarding is specific to platforms that operate an edge node between the browser and the data warehouse. Composable alternatives achieve equivalent outcomes through server-side stream processors (Apache Kafka, AWS Kinesis, Google Pub/Sub) with consumer workers that apply field filtering and POST to target endpoints. Hightouch and similar reverse ETL tools do not provide a native event-forwarding layer; the composable equivalent is a Kafka consumer with a connector to the target system.
Side-by-side implementations
In AEP Data Collection, create an Event Forwarding property (distinct from a Client property) at experience.adobe.com/#/data-collection and install the Adobe Cloud Connector extension. Define data elements using the Core extension with Path type, referencing the Adobe Resource Context object (arc.event.xdm) to extract specific fields from the edge payload — for example "arc.event.xdm" for the full XDM body, or narrower paths like "arc.event.xdm.timestamp" for individual fields. Create a forwarding rule (e.g., "All Pages") with an action of type "Make Fetch Call" from the Adobe Cloud Connector, configured as a POST request to the target endpoint URL with the desired data element in the body. Publish changes via the Publishing Flow by adding all changed resources to the development library and building. The Datastream must be updated separately (ex 14.2) to connect the Client property to the Event Forwarding property so that edge-collected data flows into the server-side pipeline.
Capability: Audience Segmentation
The Snowflake + Kafka Connect composable equivalent of server-side event forwarding is a Kafka Consumer application that subscribes to a topic receiving XDM-structured events, applies field filtering rules (e.g., extract ECID, page name, timestamp from the JSON payload), and forwards filtered payloads via HTTP POST to the target URL. In Kafka Connect, this is implemented as a custom Kafka Connect Sink connector (e.g., the HTTP Sink Connector) with a transforms configuration for field filtering and renaming. The All Pages rule equivalent is a Kafka topic subscription with no topic-level filter; publishing the rule is deploying the connector configuration via the Kafka Connect REST API. Note: this pattern has medium parallelism — native edge-network forwarding is specific to platforms operating an edge node, so the composable path requires managing Kafka consumer infrastructure.
Capability: Reverse-ETL (CDW-to-Destination Sync)
Hightouch Event Streaming is a warehouse-native server-side event forwarding product. Unlike AEP's edge-network model where forwarding intercepts real-time browser events before they reach the warehouse, Hightouch Event Streaming reads events from a Snowflake event table (populated via Snowpipe or streaming inserts) and routes them as HTTP POST payloads to configured destination endpoints. Rules are expressed as SQL WHERE clauses and SELECT field lists in the Hightouch Event Streaming configuration — the logical equivalent of AEP's data elements and rule actions, but written in SQL against the warehouse rather than as GUI-defined path extractors. The trigger is a new row in the source table: sub-second detection with Snowpipe Streaming; seconds to minutes with standard Snowpipe batch loads. Authentication to external endpoints uses stored credentials in Hightouch's connection settings. Functional output is identical to AEP event forwarding: a filtered, field-selected JSON payload arrives at the target URL when a qualifying event row appears in the source table.
Capability: Audience Segmentation
Task-level sources
- technical-training/module14/index.md
- technical-training/module14/ex1.md
- technical-training/module14/ex3.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.