A tag sends an empty product value on some visits. Moving it from Page View to Window Loaded appears to help. But a slower API response brings the problem back. The trigger changed when the tag ran, without establishing when its data became available.
Choose a trigger by the condition the tag needs. That condition might be a constructed page, a consent default, or a completed application operation. These are different dependencies. A later page event cannot replace a missing signal from the application.
Know what each page event guarantees
Google lists five page-load trigger types in its page view trigger guide. Their order is Consent Initialization, Initialization, Page View, DOM Ready, then Window Loaded.
Consent Initialization is for consent management. Initialization is for other tags that must start before ordinary page triggers. Page View is suitable when the tag does not need to wait for the DOM. DOM Ready means the browser has constructed the document. Window Loaded is a later loading milestone that includes resources such as images.
These milestones describe the page, not the completion of every application task. As MDN explains, DOMContentLoaded waits for parsing and deferred scripts. It does not wait for images or asynchronous scripts. A request started by application code can finish later still.
If a tag reads an element from the initial HTML, DOM Ready is a reasonable starting point. If JavaScript creates that element later, DOM Ready alone does not establish that it exists. Identify who creates the value before choosing the trigger.
Keep consent initialization separate from data readiness
The starts tags that establish or update consent state. It is not a faster trigger for every analytics tag. Use a consent management platform’s supported integration and its documented setup.
