AEP-Commerce Integration
02 Jun 2024 » Platform
I am currently working on a project where my main activity is to support and guide the development teams in configuring a fairly new integration: Adobe Experience Platform (AEP) and Adobe Commerce (AC). The more I learn about this integration, the more interesting it becomes. In this post, I am going to introduce it and explain all its potential.
I came up with the idea of writing this post this week when I had to explain this integration to a coworker. I wanted to break it down into the smallest pieces, to make it easy to understand, and I then realized that this integration is actually quite comprehensive. I will follow the same explanation in this post. If you want the full details, here you have the link to the official documentation: Data Connection extension for Adobe Commerce.
One word of caution: I will use AC to refer to Adobe Commerce throughout this post, not Adobe Campaign.
Purpose
Before I continue, I want to explain the why of this integration or, better, how each side of the integration benefits from it.
- AEP will get commerce-related information, which can be used to create segments.
- AC will be able to use AEP segments in its promotion conditions.
The ultimate goal is to be able to show personalized messages to a consumer based on segmentation. By using AEP, these segment definitions can be based on a combination of AC and other data sources.
Architecture
Since I am an architect and an image is worth 1000 words, I will start with the architecture of this integration. It will also help the rest of the explanation.
I will not go into the details of the architecture. Just a few comments:
- The data flows that are created during this integration are in blue.
- Most of these data flows are funneled through AEP’s Edge Network.
- The promotions in orange are the promotions I mentioned in the purpose.
- I am not depicting the complexity of the connection between AEP Core and the Edge Network.
AC to AEP
This part of the integration sends two types of information: events and profile records.
Events
As you can probably guess from the name, these are occurrences related to a consumer. Obviously, we are only interested in commerce-related events in this context. We can further subdivide them into two categories.
Behavioral events
If you have implemented Adobe Analytics, these are the typical commerce events: scOpen, scAdd, scRemove, scView, scCheckout, and, most important of all, purchase. This means that, in the general case, you do not need to do anything special for this part of the integration: you have already done it during your Adobe Analytics implementation.
The only detail to keep in mind is that, when you configure the Edge datastream, you need to add the Adobe Experience Platform service and configure an Experience Event dataset to receive these events. This dataset will usually receive all behavioral events, not just commerce events, unless you have an implementation with multiple datastreams. I would not follow the documentation and I would use whatever design you have for the XDM schema.
These events are also known as storefront events. I like to use this nomenclature so that it is clear that I am referring to commerce events and this is what I will use in the rest of the post.
Back office events
As a consumer, once you place an order, you are done. However, behind the scenes, while the consumer is not interacting with your website, many other events can happen. A few examples:
- Order placed
- Order invoiced
- Items shipped
- Cancellations
- Refunds
You have the full list that AC supports here: Data Connection Back Office Events.
You will have noticed that the purchase event is duplicated between the storefront (s.events=purchase) and the back office (order placed). There is nothing wrong with it, you just need to be aware of it when you use the events in your AEP segment definitions. I will also add that this duplication only happens for orders placed online. If you have other means to place orders, like a call center or an agent, then you will only get the back office event.
The rest of the events are generally only back office events. The consumer does not usually do anything to trigger them. I can imagine some edge cases, though, like cancellations and refund requests, which could be done through the website.
On the AEP side, these events will require, you guessed it, an Experience Events dataset. While the documentation indicates that you use a single dataset for storefront and back office events, I strongly recommend that you use a separate dataset exclusively for the back office events. The documentation also suggests adding multiple field groups to the XDM schema, but the only required field groups for back office events are Commerce Details and Personal Contact Details.
Profile records
At the moment of writing, this feature is still in beta. The idea is very simple but useful. If you are using AC as your source of truth for some profile attributes, you will want to send any profile updates to AEP. For example, if you buy a subscription, you will likely want to have a profile attribute in AEP with this new subscription.
The idea is very similar to the back office events. You need to configure an XDM schema and the corresponding dataset to receive the updates. I still have to test it, so I cannot provide more details.
Identities
You will notice that, while reading the documentation, the current implementation of this integration uses pre-defined identities. However, if you use different identities, there are other ways to send them. It is beyond the scope of this post to show how to do it, but you can ask your Adobe representative for the instructions. Hopefully, in the near future, the integration will be expanded and this sub-section will become obsolete.
AEP to AC
Now that we have the AC data in AEP, we are going to focus on the opposite direction. What flows in this other direction is segmentation information: segment definition and audience qualification.
Segment definition
We first need to send the segment definition from AEP to AC, so that AC knows which AEP segments have been created to be used in AC.
On the AEP side, it all revolves around the Adobe Commerce connection, which is a destination. You enable it and map the desired segments to it.
On the AC side, the Real-Time CDP audiences dashboard shows the list of segments that have been mapped to the aforementioned destination. Now that AC knows of these segments, they can be used in the following personalization capabilities:
Audience membership
This is the last step of the integration, where this integration shows its value. Thanks to the Adobe Commerce destination in AEP, the audience membership is available in the WebSDK response. You can now pass this information to AC to request any of the personalization options described earlier (in orange). As with the storefront events, this part of the integration happens in the browser.
With this step, we have achieved our goal: we can personalize the storefront experience based on AEP segments, which, in turn, may use AC and other data.
Final remarks
I am very well aware that I have not explained how to implement the integration, I have just explained the what. I am not yet in a position to explain the process step by step. My goals with this post were to share the knowledge that I have recently acquired, to raise awareness of this new integration, and to explain the art of the possible.