Recommended data collection approach for AEP event types

[Harveer_SinghGi1]

Hi Team,

I wanted to understand what would be the recommended approach while tracking multiple AEP event types through a single AEP event.

For example if I have three events happening on a page load: page_load, product_impression, alert_pop_up and I want to use a single tracking call to send this information to AEP, how should these be tracked,

• With a string type XDM field that concatenates all three event types like page_load|product_impression|alert_pop_up
• With three different integer type XDM fields for each of the event types populated with value 1

Please suggest what should be the preferred approach with it's pros and cons in terms of the usage of these fields in EP and it's app services.

Thanks,

[bjoern__koth · Accepted solution]

Hi @Harveer_SinghGi1 

as such, you cannot have multiple AEP event types sent at the same type, but you can include different events in the same overarching request.

In your case, I'd say the page_load is the page view, so it's likely a "Web Webpagedetails Page Views" event type you are sending as main event.

For product_impression, the Commerce XDM field group already contains Product Views events (the classic prodView event you may know from Adobe Analytics), that works in combination with the data contained in the productListItems section. This is transformed into the classic s.products string.

alert_pop_up seems to be the only non-standard event that you may have to create in your own XDM fieldgroup (maybe call it events?) and let it be of the Type "Measure" (same as the Analytics and Commerce events are of) which basically can hold an id and a value that should be set to 1 or which ever value shall be set.

https://experienceleague.adobe.com/en/docs/experience-platform/xdm/data-types/commerce

So, in a single page view request you can squeeze any other sub-event that shall more or less just increase a counter.

At least this would be my starting point. Let me know if this helps.

[brekrut]

Hello @Harveer_SinghGi1 ,

I would recommend using each event as it own sentEvent action into the Adobe Experience Platform.  This will make things easier for both segmentation and evaluation in CJA.

Is the main reason to reduce the number of sendEvent calls which is being performed?

[Harveer_SinghGi1]

Hi @brekrut ,

The idea is to reduce the sendEvent calls exactly. So if there are multiple events happening simultaneously, they should be tracked using a single sendEvent call instead of sending individual sendEvent calls. While doing that we also want to make sure all the events are accounted for and get used properly in AEP and its app services as needed.

With the above example I shared, if we track them as a concatenated string, we can use them with contains clause in segmentation, split them on delimiter in tools like CJA to report on them separately. If we track them as individual integer fields then off-course they can be used straight forward.

What I want to understand is which of these methods will be better in terms of data storage and usage? I know database querying work faster with integers as compared to string type data. Are there any other such considerations to take like which method provides lighter for storage etc.?

Cheers!

[brekrut]

If you bring in all three events into a single string field then you can only perform the operations of contains or equals.  

Segments ideally are using event Types to create event patterns to create an audience.  

Another option is the data is written into the Adobe data lake and data distiller is used to separate out the calls.

This is a can be a tough consideration with multiple events in a single payload.  What is the upper limit you are considering of concat to bring multiple event types together.  

[brekrut]

Another item to consider is have a primary event type and then use metadata attributes to track the product impression with a value of 1 and an alert popup with a value of 1 if all three items are happening at the same time of a page load.

[Harveer_SinghGi1]

Hi @brekrut ,

Maximum number of actions that we might end up tracking together is 4. I'm also inclined towards keeping the different actions as separate fields and use xdm.eventType limited to available enums like "web.webpagedetails.pageViews", "web.webinteraction.linkClicks" or commerce event type values wherever relevant, so basically some sample payload like below,

{
	"xdm": {
		"eventType": "web.webpagedetails.pageViews"
		"pageView": 1
		"productImpression": 1
		"modalPopUp": 1
	}
}

providing the needed information alongwith a quantitative field for each action that works as a metric in connected app services.

Thanks for your inputs @brekrut @bjoern__koth 

Cheers!

[TylerKrause]

This is similiar to the integration we did

[TylerKrause]

Can you deserialize the event within the schema itself? 

Use the OOO function for eventType and set it to something akin to WebInteraction, and then have a custom Object indicated somewhere else on the schema in which you can call all of the other events or details that you're looking for. This would allow you to be able to use it for segmentation and analysis, while not requiring you to have each of those be a distinct event that fires off for profile (which I can totally appreciate).