Config command out of order
Tag Diagnostics reports that event commands run before the Google tag's config command, so events can be routed unexpectedly. Open the page source and find the first gtag call. If an event call comes first, move the config code so it sits right after the opening head tag, then publish the change and check the diagnostic again.
At a glance
- Where it shows
- The Diagnostics tab in the Google tag settings.
- What stops
- No ad stops. Events that run first can land in the wrong place, so the numbers look right and are not.
- How serious
- A diagnostic, not a penalty. The cost is measurement you cannot trust until the order is fixed.
What it means
The config command gives the Google tag its account and its settings. Event commands ask it to record something, such as a page view or a conversion. When an event runs first, the tag has no settings yet to apply to it, which is what Google means by unexpected event routing.
The message describes the order of calls in the page, not whether the tag is installed. The Tag Manager workspace can look correct while a second script on the page runs an event ahead of the config call, so the check is the page source.
What actually triggers it
A second script that sends an event first
A conversion script, a form plugin or a builder's own code placed higher in the page than the Google tag runs its event before the config call. Find the first gtag call in the page source. If it is an event, the order is the problem.
A builder's own gtag function on the same data layer
Not on Google's help page
In one real site, a website builder shipped its own gtag() function on the page's data layer and sent its own page view and click events. A builder script like that can send events before the site's own config call runs, so read the builder's code in the page source as well as the Google tag.
The config code moved lower in a template edit
The config code belongs right after the opening head tag on every page. A template change that moves it below the first event call puts the events ahead of it, and only the edited pages show the message.
Fix it in this order
- Open the page in a browser, view the page source, and find every gtag call. Note which one comes first.
- If an event call comes before the config call, move the config code so it sits immediately after the opening head tag. Move the event call below it only if the config code cannot move.
- Make the same change in the site template or the container, so every page gets it, not only the page you checked.
- Create a version of the container and publish it, or deploy the site change, then check the status again in Tag Diagnostics.
Load the same page in Tag Assistant to confirm the config call now runs before any event on a fresh page load.
Often confused with
Missing gtag config command
The config code is not on the page at all, so automatic events may not be measured. This message means the code is there but runs after an event. The fix for a missing config is to add it, not to move it.
Missing Google tags
Event tags in the container have no matching Google tag. That is a container problem, so check the container's tags before the page source.