Feature request: The new Update Variable action in the AEP Web SDK Launch extension would be a lot more helpful if you could start with an existing XDM data element and update that

[#1]

The new Update Variable action in the AEP Web SDK extension would be a lot more helpful if you could start with an existing XDM data element and update that, rather than having to start with an empty XDM object every time.

In the scenario where you’ve got a lot of fields that you want to set on every event (e.g. domain, customer id, whatever), I’d want to start with an XDM object that’s already got all those fields populated, and then update that. Likewise, if I've got a lot of ecommerce events, I would want to start with an XDM object where the basic productListItems array is already defined, and then just update that with the relevant additional fields for the particular event (product view, basket add, etc)

Currently, you have to start with an empty object in every rule, so you end up repeating a lot of work if you have rules that share a lot of fields.

Another, perhaps better, option would be if you could just do the equivalent of the Merge Objects data element in rules. For example, if I've got some default 'global' fields that I want to set in every event, and I've got some standard ecommerce fields that are set on all ecommerce events, a simpler workflow would be:

1. Create an XDM data element that contains all my global dimensions.
2. Create an XDM data element that contains all my standard ecommerce fields.
3. In my 'cart add' rule:
   1. Start with the 'global' XDM data element
   2. Merge it with the 'ecommerce' data element
   3. Update it with a few fields that are specific to the cart add (e.g. carts adds metric)

Then I could just duplicate this rule for all my ecommerce events, and just tweak the final 'update' action depending on if its a product view, cart remove, etc. This would be much cleaner than the current situation where you either

• Have one XDM data element per rule, where you're repeatedly setting the same 'global' and 'ecommerce' XDM fields.
• Have layers of 'merge object' data elements, where you build up the object before putting it in the rule (e.g. global + ecommerce + cart add)
• Use the Update Variable action where, again, you're repeatedly setting the same XDM fields over different rules.

[#2]

XDM has access to the database so he can change the basic product list items to update as per requirement.

@makrandzare

[#3]

Thanks for your detailed feedback! This is an area where we continue to make changes. I read your blog post, and here's an approach that you could use that may be better:

1. Create an XDM object data element that contains all the data that is the same for every event.

2. In a rule create two update variable actions. On the first one click on the root level of the XDM tree and specify your base XDM object data element. This will copy the entire base element to the variable.

3. On the second update variable action set only the fields that you want to change for that event.

Now the variable data element will have all the fields from the base and the ones you have changed.

[#4]

Oh that is a good idea! I hadn't noticed that you could just provide an entire XDM object at the root of the Update Variable action. That makes a lot of sense.

Thanks for the response, I've added a note on the blog