Why does my Adobe Launch/DTM data element evaluate (or fire) twice on the same page load?

Why this happens

Data elements in Launch are lazily evaluated - a rule action that references one causes it to run at that moment, and nothing caches or dedupes that across rules. If two different rules both use the same data element and both fire on the same page load, the data element genuinely does run twice, which is expected and usually harmless. The problem worth fixing is when the same rule fires twice for what should be a single user action, and that has a short, specific list of causes:

• A duplicate rule condition - two rules (or the same rule published twice through a migration or a merge) matching the identical trigger, each firing independently.
• A native event listener bound more than once - common in single-page apps where a component re-mounts and re-attaches a listener without removing the previous one, or where both a native onclick attribute and a Launch Click rule target the same element.
• A Direct Call event dispatched from more than one place in the codebase - a legacy call left in place after a newer one was added elsewhere during a migration.
• Bubbling: a Click rule scoped broadly (e.g. matching a container) can match once for a click on the container and again for a nested interactive element inside it, if both independently satisfy the rule's selector logic.

Fix it

1. Confirm it's the rule, not the data element, by checking the AEP Debugger's rule log first. If the rule itself only logs once but a value still looks duplicated downstream, the duplication is happening after Launch - in a processing rule, or in how the report is aggregated - not in the tag.

2. Search the property for duplicate rule conditions. In Launch's rule list, sort or filter by event type and manually compare conditions for rules that look similar - a rule renamed or copied during a redesign is the most common source of an exact duplicate that's easy to miss by name alone.

3. Guard against duplicate listener binding in SPA components by cleaning up the previous listener before attaching a new one, or by using a bound-once flag:

if (!element.dataset.trackingBound) {
  element.addEventListener('click', handleClick);
  element.dataset.trackingBound = 'true';
}

4. For a Direct Call fired from your own code, grep the codebase for every call site. A migration that moves a tracking call to a new location and forgets to remove the old one is common enough to check explicitly rather than assume:

grep -rn "_satellite.track('formSubmitted'" src/

5. For bubbling-related duplicates, narrow the Click rule's selector to the exact interactive element (the button, not its containing card), or add a condition that checks event.target === event.currentTarget-equivalent logic in a Specificity/Advanced condition, so a click that bubbles from a child doesn't also satisfy a separate match on the parent.

How to verify it worked

• With the AEP Debugger open, perform the action once and count the rule-fired log entries - exactly one per action, not two.
• Filter the Network tab to your analytics or Edge Network domain and confirm exactly one beacon leaves the browser for the single action, with the variables you expect.
• In an SPA, repeat the test after navigating away and back to the same view (a re-mount scenario) to confirm the fix holds across component lifecycle, not just on first load.

Illustrative, not a measured result: a checkout page carrying both a legacy inline onclick handler and a newer Launch Click rule targeting the same button might see its purchase event count halve once the legacy handler is removed.