The Update Variable action in the Web SDK Tags extension

When you need this

Any rule that needs to send more than the Web SDK's automatic page-view fields - a product ID, an order total, a custom XDM field group your schema defines - needs Update Variable actions ahead of the Send Event action to populate that data. It's the practical alternative to writing custom code that manually constructs an XDM object, and it keeps the mapping visible in the rule editor instead of buried in a code block.

It also matters when migrating from AppMeasurement-style eVar/prop setting to the Web SDK: where the old pattern set s.eVar1 = value directly, the Web SDK pattern is an Update Variable action writing to the corresponding XDM field path, ahead of the send.

How to work with it correctly

1. Target the exact XDM path your schema defines. Update Variable writes to a dot-notation path inside the event's XDM object - it has to match your schema's field group structure exactly, or the value lands somewhere your data view or dataset never reads from.

Action 1: Adobe Experience Platform Web SDK > Update Variable
  XDM Data:
    productListItems[0].SKU  = %product.sku%
    productListItems[0].name = %product.name%
    commerce.order.priceTotal = %order.total%

Action 2: Adobe Experience Platform Web SDK > Send Event
  (uses the XDM object built by Action 1)

2. Order matters - Update Variable actions must run before the Send Event they're meant to affect. An Update Variable action placed after Send Event in the same rule has no effect on that already-sent event; it would only apply to a later send in the same rule, if one exists.

3. Use multiple Update Variable actions to build one payload incrementally, rather than one giant custom-code block. Splitting page data, commerce data, and custom fields into separate, clearly labeled actions makes the rule easier to audit later - each action's name in the rule editor should say what it sets.

4. Reference data elements, not hardcoded literals, for anything that varies by page. Update Variable fields accept the same %data-element% syntax as other Tags settings - hardcoding a literal here reintroduces exactly the fragility a data-layer-driven implementation is meant to avoid.

How to verify it worked

• The AEP Debugger's decoded request panel shows the field at the exact XDM path you set, with the expected value - not just that the rule ran without an error.
• The Network tab request to the Edge Network endpoint carries the field in its raw JSON payload - confirming the value survived from rule to browser send, not just to the Debugger's interpretation.
• The corresponding dataset or CJA data view shows the field populated after normal processing - confirming the schema mapping is correct end to end, not only that the browser sent it.

Illustrative, not a measured result: a team migrating a product-detail page from AppMeasurement eVars to the Web SDK might replace a dozen s.eVarN = lines with a single Update Variable action mapped to the productListItems field group, cutting the rule down to something a non-engineer can review.

Field group paths depend entirely on your own XDM schema design - verify the exact field names against your schema in the Experience Platform UI, not a generic example.

FAQ

Does Update Variable overwrite the whole XDM object or just the fields you set?

Just the fields you set - it merges into the event's XDM object rather than replacing it wholesale, so multiple Update Variable actions (and the Web SDK's own automatic fields) can coexist and combine into one payload before the Send Event action fires.

Can Update Variable set an array field, like multiple products?

Yes, using indexed path notation such as productListItems[0].SKU and productListItems[1].SKU for multiple entries - for a variable number of items built dynamically, a Custom Code data element that returns the full array structure, referenced by a single Update Variable field, is usually cleaner than a fixed number of indexed actions.