How do I read a clicked element's (or its parent's) data attributes in an Adobe Launch rule?

Why this happens

A Launch Click rule's condition matches on a CSS selector, but the element the user actually clicks is often a child of the element carrying the data you want - an icon or span inside a button, a link's text node inside an anchor with the real product ID on a wrapping <div>. event.target is always the innermost element that received the click, which is frequently not the element your selector matched (that one is event.currentTarget in a native listener, though Launch's own rule-matching logic handles selector matching separately from either).

The fix is a DOM-traversal problem, not an Adobe-specific one: find the right node relative to whichever one the click actually landed on, then read its attributes.

Fix it

1. Reading an attribute directly off the clicked element. Inside a Custom Code data element (or a rule's custom code action), event.target is in scope:

return event.target.getAttribute('data-product-id') || '';

2. Reading an attribute off a parent, when the click lands on a child element inside it. Use .closest(), which walks up from the clicked node through its ancestors and returns the nearest match, or null if none exists - always check for null before reading an attribute off the result:

var card = event.target.closest('.product-card');
return card ? card.getAttribute('data-product-id') : '';

3. Reading a data attribute with the standard data-* convention via the DOM's built-in dataset API, which is generally cleaner than getAttribute for anything named data-something:

var card = event.target.closest('[data-sku]');
return card ? card.dataset.sku : '';

4. If the Launch Click condition's own selector already scopes to the right container, confirm which node Launch treats as the matched element for that rule type versus which node is event.target - they can differ when the selector matches a container and the click lands on a nested child. When in doubt, .closest() from event.target against the same selector used in the rule condition guarantees you're reading the element the rule actually meant to match.

How to verify it worked

• Click the element from a few different spots - the icon inside a button, the label text, the padding around it - and confirm the data element resolves the same value every time in the AEP Debugger's data-element inspector.
• Test on a card or row that legitimately has no matching attribute (a malformed or third-party-injected element) and confirm your code returns an empty string or a safe default instead of throwing - a null-check gap here is the most common way this "works" in testing and breaks in production.
• Confirm the value lands correctly in the resulting Adobe Analytics variable or XDM field by checking the outgoing beacon in the Network tab, not just the Debugger's rule log.

Illustrative, not a measured result: a product-listing page where clicks on the product image versus the title text previously produced two different (or empty) tracking values might see both converge on the correct SKU once the data element switches from a direct attribute read to a .closest() traversal.