Happy (belated) New Year 2021! There is no denying the fact that the introduction of the Adobe Experience Platform Web SDK has revolutionized data collection. There are a lot of advantages of this approach but the main ones are reduced page latency, fewer cookies, a consolidated tracking library and the ability to directly stream data to Adobe Experience Cloud solutions to name a few. It's no surprise that Adobe is openly propagating this approach as the recommended path to implement all client-side solutions moving forward. I coauthored a post about the high level migration approach to the Web SDK on Adobe's official Medium blog site.
Assuming that we know the basics of the Adobe Experience Platform Web SDK, XDM and setting up the AEP schemas & datasets which will all apply in this case, this article will solely focus on Event forwarding which is a recently launched service by the Adobe data collection team. I'm working with one of my clients to evaluate the feasibility of this feature and have already set this up on my sandbox which I'll cover in this article.
Overview and Use Case
Event forwarding allows customers to federate or distribute data to a 3rd party platform such as Google Analytics or any system that has an API endpoint. The data is first collected from the page via the Adobe Web SDK client-side library and then sent over to a 3rd party endpoint from the Adobe Edge network. Even though it is called Event forwarding, data still needs to be collected at the source on the page.
The primary use case for leveraging this feature is to stream data in real-time to a Data Lake for on-site personalization, decisioning or simply for data collection to run offline queries, build dashboards or create ML models.
You can essentially leverage the implementation you have on your website to send data directly to your Data Lake which isn't very common for a lot of clients who usually send hourly or daily data feeds to their backend platform. With this, they can basically collect cherry picked data which is streamed in near real-time.
Architecture
I had originally created this simplified architecture diagram for a blog I wrote explaining the AEP Real-Time CDP which I've slightly tweaked to explain the concept of the how data is federated server-side to 3rd party platforms (explained in 3b). Basically, the AEP Edge Network is the system that federates data both to our own Adobe solutions and to 3rd party platforms.
Steps to Implement
In this section, I will cover how to implement this in Tags (formerly Launch) and also show how to collect data streamed from my sandbox using ngrok which is a localhost webhook development tool that allows me to make my endpoint URL public. Please note that I'll just cover the basic steps that will help you make a call to a 3rd party endpoint but a more exhaustive tutorial on this can be found here. So let's take a look.
The first step is to create a separate property under the Server Side section by clicking on the drop down as shown below. Please note that you will not have access to this by default so please contact your Adobe Customer Success Manager to request access and get details around licensing.
The next step is to create a new property (Rohan's Test in my case) in this section and add the extension called "Adobe Cloud Connector". Please note that there's another extension which allows you to federate data to Google Analytics as well.
Next, we need to create a new API endpoint. I'm using ngrok to map it to create a public facing URL tied to port 3000. The public facing domain ends with f3cc.ngrok.io.
I have a Node.js webhook (mapped to port 3000) which I ran while doing this test. I mapped the ngrok domain to my webhook/API endpoint and modified the URL to add '/ssftest' which is my final API endpoint URL.
The next step is to enable the toggle to enable Event forwarding and pick your newly created property ID and Environment.
Next, we need to a new rule tied to the Adobe Cloud Connector extension and pick the option called "Make Fetch Call". Please note that you can also need to create new data elements in this property in case you want to pass any additional data to your API endpoint.
Next, I mapped the API endpoint URL within the action. In this screen, we have the option to make different types of calls but in my case, I'm going to make a POST request. Note that I am also sending some test query string parameters as part of the JSON request. We can also add the XDM data and send it in the body of the request.
Finally, we need to go to the website and load the page with the Web SDK deployed which is the ideal scenario. In my case, my sandbox already has the AEP Web SDK deployed so as soon as I refresh the page, a call gets made both to Adobe Experience Platform and to my webhook (API endpoint).
What Else Would I Like to See
Below are a few additional things I'd like to see included in Launch Server Side:
- The ability to do the same thing on a mobile app client-side implementation. Adobe is working on a Mobile app equivalent of the Web SDK so hopefully we'll see it soon.
- It'll be great if the Launch Server Side team can collaborate with the Data/Bulk Ingestion API team and see if they can come up with shared learnings to standardize server side data collection within Adobe's own solutions as well.
- Being able to replicate the same data elements created in the client-side Launch property to avoid redundancy.
- Include more extensions in addition to Google Analytics to federate data server side which is collected by the Edge Server . This will hopefully allow clients to get rid of additional 3rd party scripts from the page such as Facebook and Google conversion pixels.
Even though this is a relatively new service, I'm confident it will become more and more popular as we get closer to the impending deprecation of 3rd party cookies and introduction of more stringent data sharing policies. Hope you found this post helpful and please don't hesitate to reach out with any questions!
