Exploring Adobe Launch Server Side (aka Adobe Experience Platform Data Collection Event Forwarding)

In digital analytics, there has been a trend lately to move data collection away from the client towards a server side implementation. In most cases, companies try to circumvent technical restrictions like Apple’s “Intelligent” Tracking Protection, make collected data more consistent across analytics tools and marketing platforms, or hide their non-GDPR-compliant setups from their users. This trend also brings some (but not all) elements of tag management to the server side, as Jim Gordon described well.

In most scenarios, data and events are collected from the client (like a website or app) using a tag manager. Instead of sending events directly to, for example, Adobe Analytics, Google Ads, Facebook, etc., from the browser, they are first sent to a common endpoint that collects, enriches, and forwards data to the desired tools. This common endpoint is usually referred to as a server side tag manager and is implemented in a first-party context, usually to circumvent technical limitations like third-party cookies being rejected. While the first-party context can also be created using a proxy (as I demonstrated for Adobe Analytics in this post), doing so for all tools on a typical website is complex, if doable at all.

The most popular server side tag manager is certainly Google’s server-side version of its popular Google Tag Manager. But recently, Adobe extended their Experience Platform offering with Adobe Launch Server Side, which was quickly renamed to the (much more intuitive) Adobe Experience Platform Data Collection Event Forwarding. With this new tool, Adobe Experience Platform has gained the ability to forward events to other vendors like Google or Facebook in real time.

This post is taking you along my personal journey of exploring the tool while taking a look at how it could be used for analytics use cases, and if it could be an alternative or replacement for Adobe Analytics’ Processing Rules in Experience Platform.

Adobe Event Forwarding Architecture

Before we start sending events to Adobe Launch Server Side, let’s first take a look at how it fits into the larger Adobe Experience Platform architecture. One of the great things about Experience Platform is the Edge Network, which acts as a new endpoint for all data that we want to use in any Adobe solution. The overall flow, from left to right, looks something like this:

Whenever the new Adobe SDKs are implemented in an app or website, they send data to the Edge Network (1) and receive a single response. The Edge Network then takes care of pushing the event to the desired Adobe solutions (2) and hand their response back to the client, as can be seen with the double-sided arrow for Adobe Target. The red path after the Edge Network is what we are taking a look at today, as this brings events to Event Forwarding, which forwards events to any destination you want (3).

This architecture already shows an important detail: Event Forwarding can be used to push data to third-party solutions (or even your data warehouse), but it can’t influence the data that is pushed to other Adobe solutions like Adobe Analytics or Experience Platform. This makes it very different from, for example, Processing Rules in Adobe Analytics, as those can actually change the data after it has been collected. You also can’t enrich data for Adobe’s own tools when it is collected, so you would need to find other ways to do that.

Now that we know how the overall architecture looks like and what the product should be able to do, let’s go into the interface!

Adobe Event Forwarding Interface

Adobe Experience Platform Data Collection Event Forwarding (still love the name) is a separate product that you need to buy to get access. Once you have done that, it will show up in Launch as a new menu entry:

When you create a new Event Forwarding property, you will find a very familiar interface to what you would expect in a client side property. As we can see, we still have Extensions, Data Elements, Rules, Libraries, and other things that we are used to:

Talking about Extensions: Those still take care of handling connections to the tools that should receive data. Right now, there are just very few Extension available in the Catalog. This number will likely go up in the future, but there is not a lot to choose from right now:

One thing you will also notice once you start creating rules, is that there is no Event section anymore. This makes sense, because Launch Server Side doesn’t need to listen for events, as it will get everything that is collected through the Edge Network. What is left is only Conditions and Actions:

Now that we know how the interface looks like, let’s send some data through it!

Processing data with Adobe Launch Server Side

As with all Adobe Web SDK implementations (which is what we are going to use for this experiment), we need to configure a Data Stream to instruct the Edge Network where we want our data to go. In this case, I need to enable Event Forwarding and provide the Property I configured before:

With this setup, all events that we send to this Datastream will also end up in Event Forwarding. That was super easy! Now let’s create a rule in our Event Forwarding Property. With the two Extensions I have installed (Adobe Cloud Connector and the Core Extension), I’m only able to either execute Custom Code or use the Make Fetch Call Action to invoke an HTTP endpoint. The interface for the latter looks like this:

To inspect how those Experience Edge Network events actually look like, I’m using the amazing https://beeceptor.com as an endpoint, as that will print all the content in readable way. Using just the GET configuration shown above, I only get a call to the endpoint (within a fraction of a second, the speed is impressive!) whenever I load the page with Web SDK on it. It works, neat!

Now that we successfully sent our first event to Event Forwarding’s destination, let’s take a look at the actual event payload. To do this, I quickly created a Custom Code Data Element that returns the arc variable, which seems to contain some event data according to the comment (if you’re wondering, I didn’t look at the docs at all up to this point). This is how this Data Element looks like:

Now I can use this Data Element in the Rule I used before. In my case, I switch the method to Post and add the Data Element as element to the body like this:

This will now include the arc data in the events that Event Forwarding pushes towards the destination. In Beeceptor, I can now view what is in the event super easily:

Nice, that was again super easy! What shows up is the payload of our XDM object as well as some internal variables and headers. With a config like this, we could already forward our events to, for example, our company’s data warehouse or any other API endpoint.

Now I want to try to enrich the event data. Let’s see what happens if we enable this little checkbox in the Fetch Call Action:

To view how the event is changed by this, I just add the same Action again to view the changed event, like this:

This makes two events show up in my little API mock:

Inspecting the second event now shows a new object in the payload, which indeed contains the response that Event Forwarding receives from my mocked endpoint:

Success! Now we could enrich our events with backend data if we, for example, have an API that would translate a user id into a membership status, which we could then push to Facebook or Google. Pretty neat!

If we only want to hand over parts of our collected event data, doing that is also super easy with Data Elements. For example, if I want to capture the Web SDK eventType, I could just create a Data Element like this:

Now I can use this Data Element in the existing rule as a new key in the payload body:

As expected, this will now pull the data from our event into the Data Element and attach it to the payload we send to the API mock:

So, we now successfully sent data from the Edge Network to a custom API endpoint through Event Forwarding and even enriched it through Data Elements and capturing the response. How cool is that?! If we were really adventurous, we could even send events back to the Edge Network to ingest them into Experience Platform! But that is a topic for another post. For now, it’s time for the…

Wrap up

This was surprisingly easy and a lot of fun! Once I understood how Event Forwarding is intended to be used, it was actually super fast to send out the first event. The old name (“Launch Server Side”) was indeed a bit misleading, because it is really only sensible to send data to non-Adobe products, also considering the additional cost of usage.

Unfortunately, using this neat tool for something similar to Adobe Analytics’ Processing Rules is still not feasible. For that, we would need a lot more comfort features (like an integration with Experience Platform’s Schemas, similar to what we have in Launch for the Web SDK) and a pre-built connection back to the Experience Edge Network. That, or a direct Extension for Platform, would be really useful.

Talking about useful: I hope you found this post useful! As always, let me know what your thoughts on this are and have a great rest of your day.

Frederik Werner

German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.

2021&2022 Adobe Analytics Champion

EMEA Adobe Analytics User Group Lead

www.frederikwerner.de/