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 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 excersize. In this session, we'll:

The Meta Conversion API (Meta documentation) 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.

fbEventName

fbEventTime

fbEventSource

fbEventID

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 approriately. We will just use static values for any remaining fields the lab. Though here are Meta docs on all parameters for reference.

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:

To see our changes lets load the Luma site. 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.

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

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

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.

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

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.

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

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=1 to the URL. Then verify that is passed in the interact call to the Edge. It should show up within the data object.

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 reqres.in API (e.g., our enrichment end point).

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

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.

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

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=1 and load the this URL. If we check the interact call going out from our browser we should see userId = 1 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.

You might notice that we have to calls hitting our webhook.site page now when the user=# 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.

Congratulations you've done it!