If a Google Ads cookie ignores your cookie_expires setting, identify which tag actually writes it before changing the number. Google's current documentation says Ads and Floodlight cookies created by Conversion Linker do not support cookie_expires or cookie_update. That is a configuration-support limit, not evidence that a WordPress cache needs another purge.
Start With the Cookie Writer
The Google cookie configuration guide documents the unsupported Conversion Linker parameters and points to gtag.js when those controls are required. Review the installed measurement architecture before considering a change. Do not paste a second Google tag into the theme just to gain an expiry field.
Write down the container ID, destination ID, tag type, cookie name, domain and path. Check both the published container and any preview workspace. A saved workspace value that was never deployed is a different failure from a deployed parameter the tag does not support.
On WordPress, identify every installation point: a tag-manager plugin, a theme header, a consent plugin integration and any ecommerce extension. Use this inventory to find ownership, not as a reason to disable everything. Record which component is responsible for the cookie in the browser you are actually testing.
Distinguish Three Different Questions
| Question |
Evidence needed |
Misleading shortcut |
| Does this tag support the setting? |
Current documentation for the actual tag type |
A similarly named field in another product |
| Did this configuration reach the page? |
Published version and resolved tag settings |
A screenshot of an unpublished workspace |
| What did this browser retain? |
Cookie attributes before and after a controlled visit |
One expiry value with no timestamp |
An advertising cookie's expiry is also not the same setting as the conversion window in an advertising report. Document which problem you are trying to solve. A reporting-window question should not become an unreviewed storage-lifetime change.
Separate the requested lifetime, the tag that writes the cookie, and the browser observation. A configuration field alone is not proof of support. Explanatory diagram, not a customer test.
Build a Small Expiry Observation Sheet
Use a protected test environment and a browser profile whose consent choices you can document. Record times in UTC so another operator can compare the observations without guessing your timezone. Retain cookie metadata, not full identifier values, in the shared worksheet.
- Record the time, hostname, cookie name, path, displayed expiry and consent state before navigation.
- Open the intended page once. Confirm the tag and destination expected for that page, not a different container from another environment.
- Record the same attributes after loading. Note whether the cookie already existed or appeared during this visit.
- Visit a second page with the same destination configuration and repeat the observation.
- Keep a separate clean-profile test. Do not clear the returning profile halfway through the sequence and label it a continuity test.
- Repeat the approved rejected-consent case without forcing storage on. A missing cookie can be the correct result for that configuration.
For a supported configuration, compare the elapsed time between observations with the change in expiry. If both move together, investigate refresh behavior before concluding that your original duration was ignored. If no writer is identified, stop interpreting the expiry and finish the installation inventory first.
Choose a Repair Based on the Evidence
For an unsupported parameter, remove misleading assumptions from the implementation plan. Have the measurement owner choose a supported configuration and test its consent behavior, destinations and conversion path together. Changing the storage implementation without checking the event path can introduce a duplicate conversion problem while appearing to fix a cookie problem.
For an unpublished setting, review and publish the intended container version through the normal approval process. For mismatched settings, compare the actual resolved values on each relevant page before changing defaults globally. Preserve a copy of the previous configuration so a failed test can return to a known state.
Do not promise that a requested lifetime guarantees browser retention. The useful acceptance criterion is narrower: the selected tag supports the intended configuration, the approved configuration reaches the page, and observed behavior is consistent with it in the tested browser and consent states.
Finish at the Measurement Outcome
After the storage check, follow one permitted synthetic lead through the form and its test destination. Keep synthetic identifiers out of real advertising conversion uploads. Verify that the storage change did not create another tag, another event, or a blank mapping.
Use the cookie-versus-click-ID diagnostic when the question is whether a form captured GCLID. Use the cookie prefix continuity guide when returning visitors suddenly look new. For an implementation that spans plugins and containers, request a scoped tracking repair with the tag inventory and redacted observation sheet.
References checked October 24, 2026. Diagnostic recipes are not claims of a test on your installation.