The _uetsid cookie is associated with Microsoft Advertising Universal Event Tracking, or UET. Microsoft's FAQ describes it as containing a session identifier and additional UET-related parameters. On WordPress, it may originate from a marketing plugin, a tag manager or code added to the theme. The cookie name alone does not tell you which installation created it.
Use this guide to identify the source and test its behavior. It is a technical audit, not a legal determination that a site's consent implementation is compliant.
Identify the tag that creates the cookie
Open a fresh browser profile or a clean test session on a site you are authorized to inspect. Record the page, browser and whether a consent choice already exists. In browser storage tools, inspect the cookie's domain, path and expiration without copying its full identifier into a public support ticket.
Reload with Network recording enabled and locate Microsoft UET requests. Inspect the initiating script and tag ID. Compare those with the WordPress marketing plugins, active tag-manager container and any theme-level snippet the site owner has configured.
If the same tag is installed through both a plugin and GTM, document both paths before disabling either. Two loaders can produce duplicate events even when storage shows one cookie name. Conversely, several cookie names do not necessarily mean the same conversion fired twice.
Distinguish related identifiers
Microsoft's documentation distinguishes the session-related _uetsid, visitor-related _uetvid and click-attribution _uetmsclkid. A missing click identifier is not the same problem as a missing session cookie, especially for a visit that did not originate from an ad click.
Do not fabricate a click identifier to make an attribution test pass. Use the platform's supported tag testing and a controlled journey. The immediate objective is to prove what the page loads and sends under each choice, not to inflate advertising conversions.
Define the expected consent behavior first
Confirm whether the approved implementation blocks the tag until consent or loads it with a denied consent state. Microsoft's UET Consent Mode documentation, localized help page describes these as different approaches. An event before consent must be evaluated against the actual configuration, not automatically labeled correct or incorrect from timing alone.
The same documentation identifies ad_storage as the consent setting and asc as an event-level diagnostic. It also warns that an integrated Clarity setup needs its own consent configuration. Do not assume a Google consent update automatically proves the Microsoft path received the visitor's current choice.
A four-state diagnostic checks actual tag behavior rather than inferring it from a cookie banner or one stored value. Synthetic explanatory visual.
Run a four-state journey
Start with no saved choice, then test rejection, permission for the relevant category and withdrawal. Use a fresh starting state when required, and keep the page sequence the same. After each choice, navigate to a second page and submit only a synthetic form if a conversion event is part of the test.
For each step, record the visible choice, UET tag ID, whether a request occurred, its observed consent state and whether storage changed. Do not record real form values or raw cookie identifiers. A small table of observations is more useful than a screenshot of the banner alone.
After withdrawal, check the next event rather than assuming the previous granted state was cleared everywhere. Inspect delayed scripts and duplicate integrations if one loader continues using an old choice. Keep Google and Microsoft results in separate columns using the form consent timing guide.
Interpret surprising results cautiously
A placeholder-looking value is not proof of legal compliance, and a missing cookie is not proof that no request left the browser. Inspect the payload and initiator, then compare with current vendor documentation. Do not rely on an old forum answer as a blanket privacy assurance.
Escalate unexplained identifiers or mismatched consent states to the tag owner and your privacy adviser. For an implementation problem, request a WordPress tracking audit with the redacted four-state worksheet. Acceptance means the observed behavior matches the approved configuration across page transitions, without duplicate conversion events or sensitive form data in advertising requests.
Reference and review date
Primary technical reference. Sources checked October 29, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.