---
title: Session Two
slug: rtcdp-connections-lab/session-two
docTags: 
createdAt: 2026-06-26T23:10:39.417Z
---

In this session, we'll also need to use the AEP Debugger to replace the existing Tags (aka Launch) deployment on the Luma demo site with the Tags property we created in Session 1. Jump to the [instructions from Session 1](https://tvdocs.adobe.com/rtcdp-connections-lab/session-one#deploy-tags-code-via-adobe-experience-platform-deb) on how to do this if needed.

Last time we setup the WebSDK and began sending data to the Adobe Edge. We also migrated a third party tag from a client-side deployment to a server-side (via Event Forwarding) deployment. We used the Webhook.site tag for that exercise. In this session, we'll:

1. Simulate migrating another tag but instead of relying on the *Adobe Cloud Connector* extension to enable this we'll use a partner's own Event Forwarding extension.
2. Setup an enrichment use case where Event Forwarding receives a response from one end point with additional information before delivering the enriched data to the final end point.

# Create Meta rule in Event Forwarding

## Add data elements for Meta Conversion API

The Meta Conversion API ([Meta documentation](https://developers.facebook.com/docs/marketing-api/conversions-api)) needs certain data passed to effectively track clicks and events. Setup up the necessary data elements in Event Forwarding will enable us to fire events to Meta properly. Ultimately, several data elements are needed but to save time on redundant work we'll only setup a couple of the data element and then hard-code dummy values for the remaining items. In a production implementation all values will need to passed dynamically as data elements.

**eventTime**

1. Click to add a data element, name it ***eventTime***
2. Choose *Custom Code* for the data element type
3. Enter the following code: ***return Math.floor(Date.now() / 1000);***
   1. This will return the Unix timestamp in UTC as required by Meta

**eventSourceURL**

1. Click to add a data element, name it ***eventSourceURL***
2. Choose *Path* for the data element type
3. Enter the path value of ***arc.event.xdm*** and ***web.webPageDetails.URL***

**eventID**

1. Click to add a data element, name it ***eventID***
2. Choose *Path* for the data element type
3. Enter the path value of ***arc.event.xdm*** and ***\_id***

**userAgent**

1. Click to add a data element, name it ***userAgent***
2. Choose *Path* for the data element type
3. Enter the path value of ***arc.event.xdm*** and ***environment.browserDetails.userAgent***

There are other important fields for the Meta Conversions API such as *Browser ID* (stored in the cookie *\_fbp* with a value like *fb.1.1644871472023.1807854812*) and *Click ID* (stored in the cookie *\_fbc* with a value like *fb.1.1644877140422.l2k4ouf98s7e*...) that your existing client-side tags will be using. To ensure seamless migration of the Meta pixel/tag you'll want to make sure these ids are getting passed to the Experience Edge so you can capture them in data elements and pass them appropriately. We will just use static values for any remaining fields the lab. Though here are Meta [docs on all parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters) for reference.

## Setup the rule

1. Name it ***Meta CAPI call***
2. Click to add an action
3. Select *Meta Conversions API Extension* as the extension and *Send Conversions API Event* as the action type
4. In the *Action Source* field pick ***website*** from the drop-down
5. Add the other data elements to the appropriate fields
6. Finally, click to keep changes to the action and save the rule

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/RlV-XsrfuKkwqWv-RNOKC_fb-rule-action.jpg)

# Publish changes and validate

Now we've setup the Meta Conversion API in Event Forwarding let's publish changes and test them on our Luma demo site.

To publish changes we want to:

1. Navigate to *Publishing Flow*
2. Add a library named ***Lab EF Dev***
3. Set environment to development
4. Click to add all changed resources
5. Then click to save and build

## See it working

To see our changes lets load the [Luma site](https://luma.enablementadobe.com/). Our AEP Debugger should still be loading our lab tags property to the site. Since the Event Forwarding calls happen on the Edge we can't see them in the Network tab of the Developer Console like we could a client-side call. 

## Validate with AEP Debugger

You can validate the Event Forwarding requests when you are logged in to the AEP Debugger. To see these requests do this:

1. Open the AEP Debugger
2. Click to sign in (upper right corner), it should automatically detect your sign in if you are logged in on the browser.
3. Click *Logs* from the left nav under *Tools*
4. Click the Edge tab
5. Click connect to start monitoring the logs on the Edge

When logs appear if you scan for the blue hyperlink text you can quickly see when Event Forwarding made calls out to other destinations.

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/-zEpLuiQy9RUCDl-Z4ABH_validate-data-leaving-the-edge.png)

# Enrichment use case explainer

The use case we'll be focusing on is one where client-side we have a single piece of information about a visitor (e.g., a profile id), but we need additional information about that profile to go to our final end point (e.g., webhook.site, analytics system, partner). To get the additional information, we'll need to hit a another API. Event Forwarding allows us to do this from the Adobe Experience Edge rather than relying on the visitor's browser to handle the requests.

## Components to execute the use case

1. an ID for the visitor that is available client-side
2. an API that can provide the additional information for that ID
3. Event Forwarding to make the requests and capture the response of the API for other requests

# Client-side setup

## Data  elements

1. Navigate to Tags and open your ***Lab Tags*** property
2. Navigate to *Data Elements* and create a new element named ***userId***
3. Choose the *query parameter* as the type
4. Enter ***user*** as the query parameter

For demo purposes a query parameter makes it easy for us to demonstrate different visitors. In the real world, this could be populated from a cookie or local storage item - anything available on the page.

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/XsdvqbI0_8OaiCF6HfHgO_create-userid-data-element.png)

Now we want to make sure the date element userId is available on the Experience Edge. This can be done by including it into the data layer which gets passed to the Edge by the AEP Web SDK send event.

1. Edit the datalayer data element
2. Open the editor
3. Add the line `dl.userId = _satellite.getVar('userId');`
   1. This should go before the last line of code

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/6KbWNlrghSv3yp5_aCAuR_datalayer-edit-element.jpg)

Save changes, then add all changes to the library and save and build to publish the updates.

## Validate changes

Once the data element changes have been saved and published we can validate them. Open the Luma site (ensure the AEP Debugger is replacing the on page tag with your ***Lab Tags*** property development tag). On one of the pages add ***?user=u01*** to the URL. Then verify that is passed in the interact call to the Edge. It should show up within the data object.

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/NeVWQwd-1d5PgRTA860JK_client-side-user-parameter-validate.jpg)

# Event Forwarding setup

We also need to capture the user id in a data element on the event forwarding side so that we can make a call to the *53rd.in Demo Enrichment API* (e.g., our enrichment end point).

## Capture userId

1. Navigate to *Event Forwarding* and select the ***Lab EF*** property we created previously
2. Navigate to Data Elements and create a new element named ***userId***
3. Leave extension to Core
4. Choose *Path* as the element type
5. Select *arc.event.data* in the top field
6. Enter ***userId*** as the path field
   1. You can confirm this path by checking the body of the interact call from the Luma site
7. Save the data element

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/cN5k6ZXc8uptFP5Ss0rhH_create-data-element-userid-in-ef.png)

## Create new rule

We will use our existing *Webhook 3rd party call* rule to save a few steps when creating are new rule. Then add some modifications to handle our profile enrichment use case.

1. Navigate to Rules
2. Select the check box next to *Webhook 3rd party call* rule
3. Click the *copy* action/button above the rules
4. Keep the destination property as *Lab EF* and click copy
5. Click the new copied rule name *Webhook 3rd party call copy* to edit it
6. Rename it ***Webhook 3rd party enriched call***
7. Click to add a condition
   1. We only want to execute this rule when a ***userId*** is present, otherwise we unnecessarily hit the enrichment end point
   2. Select *Value Comparison* as the condition type
   3. Use the data element icon to pick *userId* as the left operand
   4. Change the operator to *Is Truthy*
      1. This means the userId is present
   5. Optionally name the condition ***userId exists***
   6. Keep changes
8. Click to add an action (note there is already one action will be adding a second)
   1. Change the extension to *Adobe Cloud Connector*
   2. Set action type to *Make Fetch Call*
   3. Leave method to GET
   4. Enter the URL: [https://53rd.in/demo-api/users/u01](https://53rd.in/demo-api/users/u01)
      1. This can be found at [Demo API Docs](https://53rd.in/demo-api/docs)
      2. The  dynamically populates the userId in the request
9. Under Advanced check the box to save the response
10. Set ***userProfile*** as the response key
11. Change the name to ***enrichment call***
12. Keep changes to the action
13. Drag the enrichment call action to be the left-most action
14. Save the rule

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/16AL11edAD2-ALpOaqvXJ_enrichment-call-action-config.jpg)

## Setup enrichment data elements

Now we will create data elements based on the response key *userProfile* to parse additional information about the user received in the response. We'll create and use two different versions. The first will capture the entire response key object. The second will grab a specific part of the object. Either method can be useful so we wanted to show both.

### Capture the whole object

1. Navigate to date element and click to create a new Data Element
2. Name it ***enrich userProfile***
   - Adding the *enrich* prefix will help us remember the context for this data element later on
3. Change the type to *Path*
4. Enter the path:
   - ***arc.ruleStash.adobe-cloud-connector.responses.userProfile***
   - *userProfile* is the name we gave the response key, this dot-notation is how we reference that response key in a data element path
5. Save the data element

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/hy5bnSePTxITeKFD-FJI7_create-data-element-for-userprofile-in-ef.png)

### Capture just the email

1. Create another data element
2. Name it ***enrich userEmail***
3. Set the type to custom code
   1. Open editor and add the following code snippet:
      `return(JSON.parse(arc.ruleStash['adobe-cloud-connector'].responses.userProfile).data.email);`
   2. This code parses the response key object and returns the *data.email* part

## Modify the enriched call rule

With our data elements handling the response from our enrichment call or profile look up to the demo API, we can now utilized that information and send it to another end point or destination.

1. Navigate to rules and open the enriched call rule
2. Click the webhook call action to edit it
3. Add a query parameter of ***user\_id*** and set the value to the ***userId*** data element
   - This is from the client-side data layer
4. Add a query parameter of ***email*** and set the value to the ***enrich userEmail*** data element
   - This is from the response key from the Demo Enrichment API
5. Change the method to ***POST***
6. Navigate to the *Body* tab (instead of the *Query Params* tab)
7. Choose *Raw* as the body format and set the value to the ***enrich userProfile***
8. Keep changes to the action and save your rule

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/lNsMEJSnCKBx9nIIGlQ9v_webhook-action-enriched-a.jpg)

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/eFSI2XxCa0QlLacw3e7G4_webhook-action-enriched-b.jpg)

## Publish/build and validate changes

Now lets see this working. First we need to navigate to the publishing flow, add all changed resources, and then save and build those to our library.

To see the use case in action load the Luma site. Then in the URL add ***?user=u01*** and load the this URL. If we check the interact call going out from our browser we should see *userId = u01* within the data object, like we did before. If we open our webhook.site page we should see a new request that is the POST type. It should include values for userid, email and the body.

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/gmGDBGJh4pVbDMB5G79cj_webhook-validation-enriched-call.jpg)

You might notice that we have to calls hitting our webhook.site page now when the user=u## parameter is in the URL of our Luma site. This is because we copied the original webhook call rule. If we only want to fire one per page load we can modify the condition of the original rule. The enriched rule only fires if the userId data element is present. So we could add an inverse rule to the original webhook call so only one or the other fires depending on if the userId is present.

### Modify the original webhook call rule

1. Navigate to rules in Event Forwarding
2. Open the original ***webhook 3rd party call***
3. Click to add a condition
4. Choose value comparison as the condition type
5. Select the data element ***userId*** as the Left Operand
6. Set the operator to *is Falsey*
   - Meaning that the userId is not present or doesn't exist
   - This is the exact opposite of the enrichment call rule
7. Name it ***userId doesn't exist***
   - Naming conditions helps later on when you are debugging rules
8. Keep changes to the condition, save the rule
9. Publish and build the changes and reload the Luma page to verify

![](https://api.archbee.com/api/optimize/1Jp0iolWv35Z_mkI7oUiT/WJoC7EH1T-UNFWjQIN9yt_webhook-condition-orig-rule.jpg)

Congratulations you've done it!