What is msclkid?

Auto-tagging is already on

This is the first thing that catches people moving over from Google Ads. Microsoft states plainly that auto-tagging of MSCLKID is enabled by default. With gclid you have to switch auto-tagging on before the parameter exists at all; with msclkid it's already running unless somebody deliberately turned it off.

That inverts the usual failure mode. On Google, "no click ID" usually means you forgot to enable something. On Microsoft, it almost always means something in your funnel is removing a parameter that was there all along — a redirect, a link shortener, an affiliate hop.

You can disable it under Campaigns → Settings → Account level options by clearing the "Add Microsoft Click ID (MSCLKID) to URLs to allow conversion tracking" checkbox. Microsoft's own argument against doing that is worth quoting: the UET tag reports the Microsoft cookie, but "in some cases, the Microsoft cookie can't be returned due to browser settings (for example, third-party cookie blocking) or browser type. If you don't have auto-tagging of Microsoft Click ID enabled, these conversions aren't tracked."

It's a last-click ID — overwrite it

Microsoft's event schema labels msclkid the "last click ID", and the Conversions API guidance is unambiguous about what that means for storage: you only need to retain the most recent value for each user, and you should always overwrite the existing click ID when a new one is captured.

That's the opposite instinct from first-touch attribution, and it's a real trap if you've built a generic click-ID store that preserves the earliest value it sees. A returning visitor who clicks a second ad should overwrite, not append. Microsoft's own dos-and-don'ts put it bluntly — always include the most recent msclkid for each user, and don't omit it from conversion events, because the visitor ID alone isn't sufficient.

Microsoft suggests a 90-day retention on the stored value, in a first-party cookie or local storage — a server-side store is fine too. The UET tag handles this for you when it's installed, writing the value to a first-party _uetmsclkid cookie; you only need to do it yourself when you're running the Conversions API without Microsoft's JavaScript.

The two 90-day gates on offline conversions

This is where most "I uploaded it and nothing happened" reports come from. Importing an offline conversion against an msclkid has to clear two independent checks, and only one of them tells you when it fails.

1. The upload gate — 90 days. Microsoft's spec: "The date and time must be within the last 90 days, otherwise the operation will fail when you attempt to send Microsoft Advertising the offline conversion data." This one errors loudly.
2. The conversion window — your setting. The conversion must also land inside the goal's ConversionWindowInMinutes. Miss this and the upload succeeds — the row is accepted and then simply never counted. No error.

Microsoft's own worked example makes it concrete. Three clicks recorded April 30, a conversion window of 30 days, uploading on July 31:

• Conversion on April 30 — rejected at upload; more than 90 days old.
• Conversion on May 15 — counted. Inside both gates.
• Conversion on June 15 — uploaded fine, never counted. It falls outside the April 30–May 29 conversion window.

One more rule that bites: the conversion time must be later than the recorded click time. Timezone bugs that push a conversion a few hours behind its click will fail, and the cause is rarely obvious. Microsoft expects UTC in the API, which differs from the timezone options in the web UI.

Two Microsoft paths, two different windows

Worth keeping straight, because the numbers aren't the same and neither is the mechanism:

• Offline conversion import — keyed on msclkid, conversion time within the last 90 days.
• Conversions API (UET server-to-server) — eventTime must be within the last 7 days. Send a timestamp older than that and validation rejects it.

So the CAPI is for events you report promptly and offline import is for the long tail — a lead that closes weeks later. Reaching for the wrong one is a common cause of silently missing conversions.

In both paths, msclkid is required only if you're not sending hashed email or phone instead — Microsoft's enhanced-conversions route accepts a SHA-256 hashed email or an E.164-normalised, SHA-256 hashed phone number as the match key.

Capturing msclkid

1. On landing. Read msclkid from the query string and store it first-party. Overwrite any existing value.
2. Through the flow. Carry it into a hidden form field and on into your CRM alongside the record, so the conversion can be uploaded later against the click it belongs to.
3. At conversion. Include the most recent msclkid in the offline import or the UET event. Track the age of the click, not just the conversion — that's what the 90-day gate measures.

Common msclkid failure modes

• A redirect stripping it. The dominant cause on Microsoft, precisely because auto-tagging was never the problem — the parameter was there and something dropped it.
• Keeping the first value. It's a last-click ID. Overwrite on every new click.
• Passing the conversion-window check mentally, not actually. The silent failure. An upload that returns success is not an upload that counted.
• Conversion timestamped before the click. Usually a timezone bug; Microsoft's API expects UTC.
• Using the CAPI for an old conversion. Seven days, not ninety. Use offline import for the long tail.
• Brave. Strips msclkid by default for every user — see the Click ID Survival Matrix.

For how msclkid sits beside the other platforms' identifiers, see the click ID explainer; for the full build, the tracking-setup playbook.