What the load order actually governs
Extensions and load rules run in scopes - broadly, pre-loader logic that runs before anything else, then extensions scoped to all tags, then extensions scoped to specific tags. Within a scope, sequence matters. The order of operations decides which of several matching rules or extensions executes first, and whether one can block or override another.
When this actually matters in practice
- Two extensions touch the same data layer key and the result depends on which ran last
- A tag isn't firing, and the real cause is an upstream load rule silently excluding it
- Someone wants to add a "kill switch" extension meant to override everything else on the page
How to work with it properly
Audit existing extension scopes and their sequence before adding a new one - a new extension is not being added into an empty system, it is being inserted into an existing resolution order. Document each extension's intended position, not just its logic, since the next person who touches the profile cannot infer sequence from the configuration screen alone. Use the "all tags" pre-loader scope sparingly - it runs before per-tag logic, which makes it powerful and easy to forget about at the same time.
How to verify it worked
Configuration screens describe intended order; they do not prove actual execution order. Use profile preview or trace tooling to watch the literal sequence for a real test page load, and confirm the value your extension depends on already exists at the point your extension runs - not just that both extensions are enabled.
Named failure mode: the unowned load rule - one nobody remembers writing, that nobody is confident is still needed, and that nobody wants to be the one to delete. Sequencing debt accumulates from exactly this pattern.