Microsoft UET and Health Data: What to Configure

The Microsoft UET tag reports the page URL, page title, referrer, and a persistent visitor identifier on every page it loads, and none of those can be switched off in the tag's settings, so the configuration work for a healthcare advertiser is deciding what the tag is allowed to see rather than tuning what it sends. The settings that do exist and matter are consent mode, custom event names and parameters, the enhanced conversions identifier object, and the conversion goal counting rules. Curve is the HIPAA-compliant tracking platform that replaces the browser tag with a server-side feed to Microsoft, with per-destination field mapping and a signed BAA on every plan.

What UET sends when you configure nothing

Install the tag and it begins reporting immediately. On every page load it sends, at minimum:

• The full page URL, including path and query string
• The page title
• The referring URL
• The _uetsid and _uetvid cookie values, which identify the session and the visitor across sessions
• The Microsoft click ID, from the msclkid parameter appended to your landing page when auto-tagging is on
• The IP address and user agent, as with any browser request

For most advertisers that list is unremarkable. For a clinic it is the whole problem, because on a healthcare site the URL path and the page title routinely name a condition, a treatment, or a specialty. Combined with a persistent visitor identifier and a click ID that ties back to a specific ad click, that is an identifiable person associated with a health topic, disclosed to a platform whose advertising products are not covered by Microsoft's HIPAA Business Associate Agreement.

Everything below is written against that reality. Some of it is genuinely useful configuration. Some of it is a partial mitigation, and it is labeled as such.

The settings that exist, one at a time

Where the tag loads

This is the highest-impact lever available inside a browser-tag setup. UET does not have a "do not report this page" option, so the only way to keep it away from a treatment page is to not load it there.

Practically that means conditional loading through your tag manager, keyed to a page property rather than a URL match list. A URL allowlist rots. Someone publishes a new service page, it is not on the list, and the tag either loads where it should not or the loading rule was written as a blocklist and the new page was never excluded.

Both failure modes are common enough that a partial-coverage tag should be treated as a temporary state on the way to removing it, not as a design.

Auto-tagging and the click ID

Auto-tagging appends msclkid to your landing page URLs and is what makes click-level attribution possible, including offline conversion import later. Leave it on. The click ID is an opaque platform reference and it carries no patient information.

What matters is what happens to it afterward. It should be captured on landing and stored in your own systems so a conversion can be reported days later from your CRM. Curve captures it at landing and holds it through the session, including across a bridge to an external booking tool.

Consent mode

UET supports a consent signal, pushed as ad_storage with a value of granted or denied. Set the default to denied and update it when a visitor consents.

Understand what this does and does not do. Denied consent restricts cookie storage and limits how the visit can be used for advertising. It does not stop the tag from firing, and it is not a HIPAA control. Consent is a privacy-law mechanism; HIPAA turns on whether a valid authorization exists for a disclosure to a business associate, and an ad_storage flag is not that. Configure it because it is correct under other regimes, not because it solves this one.

Custom events and their parameters

Custom events are where you actually get to choose what Microsoft sees, and they are the part worth getting right.

A UET custom event carries an event category, action, label, and value, sent as ec, ea, el, and ev. All four are strings or numbers you supply, which means all four are yours to keep neutral.

The failure mode is treating the label as a free notes field. Teams populate el with the form name, the service, or the page title, all of which reintroduce the service line into the payload. Send a neutral identifier instead and keep the mapping in your own analytics. Microsoft already knows which campaign delivered the click, so campaign-level meaning is preserved without the event naming anything clinical.

Fire custom events on genuine actions rather than on page load. An event bound to a thank-you page URL fires again on every refresh and back-navigation, which inflates conversions and makes a reload look like a second patient.

The enhanced conversions identifier object

Microsoft's enhanced conversions feature accepts hashed contact identifiers alongside the conversion, pushed as a pid object containing hashed email and phone. It improves match rates when cookies are unavailable.

Two rules if you use it from a browser. The hashing must happen before the value enters the page context, not in the browser after the raw value has already been present in the DOM alongside the page URL. And the identifiers must be normalized exactly as Microsoft specifies, lowercased and trimmed, or the hashes will not match and you will have taken the risk for nothing.

This is one of the clearer arguments for doing the work server-side. A server can hash the identifier before it is ever adjacent to a condition-bearing page context.

Dynamic remarketing custom parameters

UET supports custom parameters for dynamic remarketing, including pagetype and prodid. These exist for retail catalogs and they are the wrong tool for a clinic.

A prodid holding a treatment code, or a pagetype distinguishing condition pages from general pages, is a health inference sent as a structured field. Leave these unset unless every value in them is genuinely non-clinical.

First-party storage and tag version

UET stores its identifiers in first-party cookies by default on modern versions. Keep the tag current if you run one, but do not read first-party storage as a privacy improvement. It changes where the identifier lives, not who receives it.

Conversion goal settings that change your numbers

Configuration on the goal side is less about disclosure and more about whether your reported conversions are true.

• Count. Choose one conversion per click for lead events. Counting all conversions turns a reloadable confirmation page into repeat conversions.
• Conversion window. Healthcare consideration cycles are long. A short window will attribute nothing to campaigns that genuinely work, and a very long one will credit clicks that had little to do with the booking. Set it against your real time-to-book, which your CRM already knows.
• Include in "Conversions". Only goals you want the bidding algorithm to optimize toward should be included. Engagement proxies should be tracked and excluded.
• Revenue. Assigning a value lets Microsoft weight a booked appointment above an enquiry. Use a modeled average value rather than a patient-specific amount, because a per-patient figure can itself be revealing on a specialty service.
• View-through. Reasonable for audience network campaigns and misleading for search. Keep it visible in reporting and think carefully before letting it drive bids.

Offline conversion import: the fields that matter

Offline import is the most privacy-friendly conversion path Microsoft offers, because the conversion is reported from your systems rather than from the patient's browser.

A row needs the Microsoft click ID, the conversion goal name, the conversion time, and optionally value and currency. That is the whole payload. Nothing about the appointment, the service, or the patient is required or wanted.

Two configuration notes. The goal must be created as an offline conversion goal before you upload against it, and the click ID must be one your site captured at landing, which is why auto-tagging and click-ID capture are prerequisites rather than optional extras. Get those in place and the conversion that actually matters, an attended appointment rather than a form submission, becomes reportable without a browser event ever touching a treatment page.

What no configuration will fix

It is worth being direct about the ceiling here, because a great deal of effort gets spent on settings that cannot reach the underlying issue.

You cannot tell UET to omit the page URL. You cannot tell it to omit the referrer. You cannot inspect a payload before it leaves the browser and decide not to send it. The tag is code running on the patient's device, and once it fires, the request has been made. Consent mode limits downstream use, it does not prevent the request. Restricting where the tag loads works exactly as well as your loading rules do on the day someone publishes a new page.

That is the argument for moving the decision off the device. When events go to infrastructure you control first, the question changes from "what did the tag report" to "what did we choose to forward", and that second question has an auditable answer. Our piece on client-side pixels and HIPAA exposure works through the same reasoning for Meta and Google.

How Curve configures the Microsoft destination

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and Microsoft UET is one of its server-side destinations.

The Curve script installs in place of the UET tag. Events go to Curve's US-hosted infrastructure, and the Microsoft destination is configured explicitly:

• Per-destination field mapping. Only fields you map are forwarded to Microsoft. The default is that nothing goes, so a new page or a changed form cannot silently start sending something new.
• Neutral event aliases. The event Microsoft records carries a neutral name, so no conversion goal in your account names a treatment.
• Identifier hashing. Contact identifiers are SHA-256 hashed server-side, per the receiving platform's requirements, before anything is forwarded.
• Click ID capture and bridge tokens. The msclkid is captured at landing and preserved, including when the patient clicks out to a separate booking or intake tool such as IntakeQ, Calendly, or Jane App.
• Incoming webhooks. Your CRM posts outcomes back and Curve matches them by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields.
• Offline conversion uploads. Bulk CRM or EHR uploads with click-ID matching, up to 10,000 rows or 5MB per file.
• PHI-pattern detection. Payloads are flagged when they contain PHI-shaped values such as SSNs, MRN-style identifiers, dates, or long numeric sequences. It is a monitoring layer that tells you when something upstream changed; the protection is the field mapping and the hashing.

A signed BAA is included on every plan, and the same event stream feeds Google Ads and Meta CAPI, so you configure the rules once rather than per platform. See our cross-platform conversion tracking setup guide and the technical conversion API architecture overview.

Frequently asked questions

Can I stop UET from sending the page URL?

No. The tag reports the page it fired on and there is no setting to suppress that. Your options are to prevent it from loading on that page or to stop using the browser tag and forward conversions from a server instead.

Does consent mode make UET HIPAA compliant?

No. Consent mode adjusts cookie storage and downstream advertising use based on a visitor signal. HIPAA governs disclosure of protected health information to a vendor, which requires a Business Associate Agreement, and Microsoft's BAA does not cover Microsoft Advertising. Configure consent mode because other privacy regimes require it.

Is it safe to put a hashed email in the UET tag?

Safer than a raw one, and still not the same as server-side. Hash before the value reaches the page, normalize exactly as Microsoft specifies, and be aware the hash is being sent from a page whose URL may itself be the disclosure.

What should I use for the event label?

A neutral identifier that means something inside your systems and nothing outside them. Keep the mapping between that identifier and the real service in your own analytics rather than in the value you send.

Do I still need UET if I use offline conversion import?

Microsoft's offline import matches on the click ID, which needs to be captured on your site at landing. Curve captures and stores it without a UET tag on the page, so you get click-ID matching and offline conversions with no browser tag reporting page data.

How do I check what my tag is currently sending?

Open your browser network tools on a treatment page and inspect the UET request. You will see the page URL and title in the payload. Doing this once, on your own site, is usually the moment the abstract concern becomes concrete.

Where to start

Load a treatment page on your own site with network tools open and read what the UET request actually contains. Then check the practical items: is auto-tagging on, are custom event labels neutral, are dynamic remarketing parameters unset, are goals counting one per click, and is an offline conversion goal set up for real appointment outcomes.

Once you have seen the payload, the useful question is whether a browser tag belongs on a clinic site at all. Curve replaces it with server-side collection, per-destination field mapping, neutral event aliases, hashed identifiers, click-ID and bridge-token attribution, and offline uploads, with a signed BAA on every plan. Run the free compliance scanner to see every tag your site loads today, read our take on whether platform pixels and conversion APIs are HIPAA safe, or visit curvecompliance.com to review your Microsoft configuration with us.

Reviewed August 2026. Microsoft UET parameters, consent mode behavior, and conversion goal options change periodically. Verify against current Microsoft Advertising documentation before implementation.