Can a standard analytics tool like Google Analytics collect consumer health data under WMHMDA?

It can, depending on what events and page paths you send it. If a page URL, event name, or custom parameter reveals a health condition, symptom, or treatment (for example, a URL path like /condition/anxiety or an event named 'viewed_pregnancy_test_results'), that data can qualify as consumer health data even inside a general-purpose analytics tool.

Does sending data to an advertising SDK count as a 'sale' under WMHMDA?

It can. WMHMDA defines 'sale' broadly, covering exchanges of data for monetary or other valuable consideration, which can include some ad-attribution and audience-building SDK integrations depending on how they're configured and what value flows back to you.

For analytics, SDK & tracking review · Updated 2026

WMHMDA and Analytics SDKs: The Hidden Compliance Gap

Q: How do we check whether our SDKs are creating WMHMDA exposure?

Audit every third-party SDK and pixel for what data it receives from your app (not just what you intend to send), check each vendor's default data-sharing settings, and confirm whether any receive information that could reveal a consumer's health status.

Q: Am I a 'data broker' under WMHMDA if I sell health data to advertisers through an SDK?

WMHMDA does not use the term 'data broker' as a separate defined category the way some other state privacy laws do — instead it regulates the act of 'selling' consumer health data directly, defined broadly as any exchange of consumer health data for money or other valuable consideration. If your SDK or ad-attribution integration exchanges consumer health data for value with an advertiser or analytics vendor, that can qualify as a sale under RCW 19.373 regardless of whether the recipient calls itself a data broker, requiring the same signed, revocable authorization as any other sale.

The riskiest data collection often isn't in your product code — it's in a vendor SDK you added in ten minutes

Most WMHMDA conversations focus on the privacy policy and the consent form. Fewer focus on the third-party SDKs already running in production: crash reporters, analytics platforms, ad-attribution kits, and session-replay tools. Each one is a data pipe out of your app, and several default configurations can turn an innocuous integration into a "sale" or "sharing" of consumer health data — without a single line of your own code doing anything unusual.

In short: Analytics, crash-reporting, and ad-attribution SDKs can leak health-revealing event names, screen paths, or session recordings to vendors — potentially counting as a "sale" or "sharing" of consumer health data. Audit every SDK's actual data flow, not just what you intended to send. Run the free scope check below.

Read the full SDK audit guide

How an SDK can end up collecting consumer health data

Event names and parameters — an event like viewed_condition_page with a parameter condition=anxiety sent to a general analytics SDK carries health information into that vendor's systems.
Page/screen paths — a URL or in-app screen name like /symptom/migraine automatically logged by a session-replay or crash tool reveals health context even without an explicit health field.
Session-replay recordings — tools that record on-screen interactions can capture typed symptoms, diagnoses, or medication names verbatim if fields aren't explicitly masked.
Ad-attribution SDKs — install and in-app event attribution tied to a health-related conversion event (e.g., "completed symptom quiz") can constitute sharing health-linked data with an ad network.

Example: a fitness app's default analytics setup

A fitness app installs a popular analytics SDK using its default settings and sends events like workout_completed with parameters including heart_rate_avg and calories_burned. Heart rate and calorie data tied to an identifiable user is consumer health data. Because the SDK vendor may use aggregated event data for its own product-improvement or advertising purposes under its standard terms, this default setup can plausibly constitute "sharing" or even "selling" health data — triggering the need for a specific WMHMDA authorization separate from ordinary "necessary to provide the service" consent, and separate from the general privacy policy disclosure.

A practical SDK audit checklist

List every third-party SDK and pixel currently integrated (including ones added by ad networks or app-store requirements).
For each one, list every event name and parameter your app actually sends it — not just what you intended to send.
Flag any event/parameter that could reveal a health condition, symptom, treatment, diagnosis, or biometric health signal.
Check each vendor's data-use terms for whether they can use, aggregate, or resell the data you send them.
For anything flagged, decide: strip the health-revealing data before sending, or obtain the specific consent WMHMDA requires for that sharing/sale.

Note on terminology: WMHMDA doesn't create a separate "data broker" category the way some other state laws do — it regulates the underlying act of selling consumer health data for money or other value, whoever the recipient is and whatever they call themselves.

Not sure if your setup is in scope?

Run the free scope check first, then generate a privacy policy and sale/sharing authorization that reflects what your SDKs actually do — not just what your product code intends.

Run the Scope Check — Free

Legal limitations

Whether a specific SDK integration constitutes a "sale" or "sharing" of consumer health data depends on that vendor's exact data-use terms and your specific configuration — this page describes common patterns, not a determination for your stack. A technical and legal review of your actual SDK configurations is recommended before relying on any generated authorization language.

FAQ

Can a standard analytics tool collect consumer health data under WMHMDA?

Yes, depending on the event names, parameters, or page paths you send it — these can reveal health information even in a general-purpose tool.

Does sending data to an advertising SDK count as a 'sale'?

It can, depending on configuration and what value flows back to you — WMHMDA's definition of "sale" is broad.

How do we check whether our SDKs are creating WMHMDA exposure?

Audit every SDK for what data it actually receives, check default sharing settings, and flag anything that could reveal health status.

Does wmhmda or mhmda apply to session-replay and crash-reporting tools?

Yes, if what they record or capture includes information revealing a consumer's health status.

Am I a "data broker" under WMHMDA if I sell health data to advertisers?

WMHMDA doesn't use a separate "data broker" category — it regulates the act of selling consumer health data directly, defined broadly as any exchange for money or other value. An SDK or ad-attribution integration that exchanges health data for value can count as a sale under RCW 19.373, triggering the same signed authorization requirement no matter what the recipient calls itself.

WMHMDA and Analytics SDKs: The Hidden Compliance Gap

How an SDK can end up collecting consumer health data

Example: a fitness app's default analytics setup

A practical SDK audit checklist

Not sure if your setup is in scope?

Legal limitations

FAQ

Your SDKs might already be creating exposure — check for free