What the JS extension API is
iQ's JavaScript extension runs custom code inside the load sequence, with access to the documented extension surface - the data layer object, load rule results, and the sequencing context of where the extension sits. It is the escape hatch for logic that no declarative (point-and-click) extension covers.
When you actually need custom code instead of a declarative extension
Reach for it deliberately, not by default -
- Normalizing inconsistent values arriving from a third-party plugin you don't control
- Computing a derived attribute (a bucketed cart value, a composite score) that no built-in extension expresses
- Bridging legacy page code written before a clean data layer specification existed
- A vendor-specific requirement with no pre-built extension and no time to wait for one
How to implement it properly
Scope every JS extension as narrowly as the use case allows - a specific tag or load rule, not "all tags," unless the logic genuinely belongs everywhere. Write against the documented extension API surface rather than reaching into global page objects, which breaks the moment the page changes. Respect load order deliberately: if one extension's output feeds another, the sequence has to be verified, not assumed from the order they appear in the list, since scope type affects execution order as much as list position.
How to verify it worked
Use profile preview or trace tooling to confirm the extension actually executes in the position you intended, then confirm the transformed value appears in a captured tag payload downstream - not just in a console.log during testing. A value that looks right in preview but never reaches the tag it was written for is not a working extension.
The audit signal we look for: if most of an implementation's logic lives in ad hoc JavaScript extensions rather than in the data layer specification itself, that is model drift - the JS extension has become the data layer by accident, and nobody wrote it down that way.