Google Ads Pixel and Google Ads S2S Pixel in the FTC's Hims and Hers Complaint

When the FTC listed the trackers allegedly placed on Hims & Hers platforms, it named two Google entries, not one. Paragraph 77 of the July 2026 complaint identifies the Google Ads Pixel and, separately, the Google Ads S2S Pixel. S2S means server to server. The agency called out the server-side variant by name, as its own item, in a complaint about health data disclosure.

That single listing does more damage to a widely held industry belief than any regulatory guidance document has managed. Healthcare marketers have spent three years being told that routing conversions server-side resolves the compliance problem. The FTC just enumerated a server-side integration alongside a browser tag as though the distinction were unremarkable. Curve is a HIPAA-compliant conversion tracking platform that lets healthcare advertisers send Google Ads the conversion signal it needs while protected health information never leaves the covered entity, on either the client path or the server path.

The case is Case No. 3:26-cv-7871 in the Northern District of California, brought by the FTC with the People of the State of California, acting through Los Angeles County Counsel, and the Utah Division of Consumer Protection. These are allegations and nothing is proven. Hims has denied the allegations, has said its privacy policy makes clear that users may choose how their data is used, and has said it intends to defend the case.

The Short Version

• Paragraph 77 names both the Google Ads Pixel and the Google Ads S2S Pixel, and separately names TikTok in its server-to-server form.
• Paragraph 70 shows the FTC understands server-side architecture, describing the Meta Conversions API as creating a direct connection between the advertiser's server and the platform, and pleading it anyway.
• Server-side is a control point, not a control. It only helps if sanitization actually happens there and is verified against real payloads.
• In a Google setup, conversion action names, enhanced conversions, offline imports, and Customer Match are four distinct places health data can ride along.
• A conversion action named after a condition is a disclosure at the account level, before any event fires.
• Automated campaign types amplify whatever signal you feed them, including signal you did not intend to send.

Why the S2S Listing Is the Story

Take paragraph 77 and paragraph 70 together. Paragraph 77 lists Google Ads S2S and TikTok s2s among the trackers allegedly placed on Hims platforms. Paragraph 70 addresses Meta and describes the Conversions API as operating differently "to the extent it creates a direct connection between the advertiser's server, website, app or other internal software and Meta's systems."

That description is technically correct. The FTC is not confused about what server-side tracking is. It characterized the architecture accurately and then treated it as a vector for the same alleged disclosure as the browser tag. There is no passage where server-side transmission is credited as a mitigation.

The reason is straightforward once you drop the engineering frame. Consumer protection law asks what was represented to consumers and what was actually done. HIPAA asks whether protected health information was used or disclosed, and to whom. Neither question has a field for transport mechanism. If identified health data reached an advertising platform, it reached the platform. The route is a detail for the technical appendix.

This is the same conclusion reached the long way in why server-side tracking alone is not HIPAA compliance. The value of a server-side architecture is real but narrow: it creates one place you control where every outbound payload can be inspected and modified. That is a prerequisite for compliance, not an instance of it. A server container that faithfully forwards a full URL containing a medication name has changed nothing except who is holding the pen.

What the Browser-Side Google Ads Tag Sends

The Google Ads conversion tag is delivered through the global site tag. On each page load it reports a page view against a conversion linker and any configured conversion actions, and it carries the page location, the referrer, the user agent, and the request IP address. It also reads and writes first-party cookies that persist the click identifier appended to landing page URLs by auto-tagging.

That click identifier is the spine of the whole system. It ties a session to a specific ad click in a specific account, which means any data joined to it is joined to an advertising identity. It is also the join key for the offline paths discussed below, so it deserves more attention than it usually gets.

Conversion events add their own parameters: a conversion action identifier, a value, a currency, a transaction identifier, and whatever custom parameters someone configured. In healthcare builds those custom parameters routinely carry product or service names populated from the same catalog that generates the page, which is how a treatment name ends up in an ad platform without anyone deciding to send it.

Remarketing is a separate concern on the same tag. If the remarketing tag runs on authenticated pages, patient portals, or intake flows, it is building audience membership from clinical context by construction.

The Four Server-Side Paths That Matter

Server-side in a Google context is not one thing. There are at least four distinct integrations that move data from your systems to Google without a browser, and healthcare teams routinely have two or three running while believing they have none.

Click conversion uploads

The classic server-to-server integration sends a conversion record keyed on the click identifier: the identifier, the conversion action, a timestamp, and a value. Nothing about that payload looks sensitive at first glance. The exposure lives in the conversion action, which is a named object in the account. If the action is called something like "Consult Booked, Dermatology" or worse, then every upload against it is an assertion about an identified click, and by extension about a person.

Enhanced conversions

Enhanced conversions improve match rates by attaching hashed customer identifiers to conversion data, either collected in the browser and hashed there or supplied in a server-side upload. The accepted fields include email, phone, and name and address components. Hashing here is deterministic with published normalization, which is exactly what makes matching work across organizations, so a hashed email should be treated as an identifier rather than as de-identified data. The lead variant extends the same idea to conversions that complete offline, uploading hashed identifiers captured on a lead form and matched later. Doing this without leaking is possible but requires deliberate work, laid out in the server-side enhanced conversions setup that avoids PHI leakage.

Offline conversion imports

Offline imports exist to close the loop between an ad click and something that happened later in a CRM or practice management system. That is a genuinely useful capability and a genuinely dangerous one, because the source system is the clinical system. A CRM connector configured by someone optimizing for attribution completeness will happily map fields that should never leave. The risk is not that the connector is malicious. It is that the field mapping screen offers every column you have.

Customer Match uploads

Customer Match takes the same shape as the Snap customer list uploads described at paragraph 76 of this complaint. You upload hashed identifiers, Google matches them to accounts, and the resulting audience becomes a targeting or exclusion asset. The list membership criteria are the disclosure. If the list was built by querying a table of patients on a given therapy, the audience encodes that fact regardless of which columns you uploaded.

What a Curve-Style Setup Does Differently for Google

Curve sits between your systems and Google rather than beside them. Events are captured first-party and sanitized on Curve's servers before egress, so identifiers, clinical URL paths, and catalog-derived parameters are removed at the boundary instead of being trusted to a tag configuration or a connector's field mapping. Because both the browser path and the server-side upload path run through the same sanitization layer, there is no second integration that quietly skips the rules, which is the failure mode a partial server-side migration creates. Destinations are configured per platform, so what Google receives is an explicit decision with an explicit payload. Curve offers a Business Associate Agreement, which places the vendor handling the data inside the covered entity's compliance perimeter rather than outside it. Google still gets a conversion, a time, and a click to attribute it to, which is what the bidding models actually consume. The general architecture question is covered in how server-side tracking improves HIPAA compliance when it is audited properly.

Where Health Data Actually Rides in a Google Account

If you are auditing a Google Ads setup for a healthcare advertiser, these are the places to look, roughly in order of how often they turn up something.

• Conversion action names. Open the conversion actions table and read every name as an outsider would. Names are visible to anyone with account access, including agencies and Google representatives, and they persist in reporting indefinitely. This is the cheapest finding available and the one most often missed.
• Page location on the conversion tag. If your URLs carry condition, medication, or intake-step identifiers, the tag is transmitting them on every fire, and a server container will forward them just as faithfully unless something rewrites them.
• Enhanced conversions status and its source. Determine whether it is enabled, whether it collects from the page or from an upload, and which fields are mapped. Automatic collection from page form fields is the setting worth checking first.
• Every offline import pipeline. Inventory the connectors, scheduled uploads, and integration partners writing conversions into the account, and read the field mapping for each.
• Customer Match audiences and their names. Same analysis as any list upload: the query that built the list is the real exposure, and the audience name is a standing label on it.
• Analytics linkage. If a GA4 property is linked and conversions are imported from it, the analytics configuration becomes part of your ad platform exposure. That inheritance is examined in whether GA4 can be used in healthcare and what the alternatives are.
• Remarketing tag placement. Confirm whether it fires on authenticated, portal, or intake pages, and what audience rules were built from those pages.

Automation Amplifies Whatever You Send

Automated campaign types make this worse in a way that is easy to underestimate. When you hand an automated system a conversion signal, you are not just measuring. You are instructing an optimization engine to find more people who resemble the people who generated that signal, across search, display, video, and shopping inventory simultaneously.

If the signal carries clinical specificity, the targeting inherits it. That is the mechanism paragraph 74 of the complaint describes when it alleges Hims "was only able to create audiences with such specificity because it flouted the promises it made to its users about treating their medical conditions 'privately' or keeping their health information private." The audience precision is the visible symptom. The data intake is the cause. A structured way to review this exposure is in the audit framework for PHI risk in automated Google campaign types.

There is a second-order effect worth naming. Automated systems reward richer signal with better performance, which creates continuous internal pressure to send more. Every quarter someone will propose adding a parameter, enabling a match feature, or connecting one more system, and each proposal will be supported by a performance argument. The controls have to be architectural, because they will not survive as a policy that depends on individual restraint.

Frequently Asked Questions

Does the FTC complaint say server-side tracking is not allowed?

It does not say that. It lists a Google server-to-server integration and a TikTok server-to-server integration among the trackers allegedly placed on Hims platforms, and at paragraph 70 it describes Meta's server-side API accurately while treating it as a sharing vector. The takeaway is that server-side deployment is not itself a defense, not that server-side architecture is prohibited.

We moved our Google conversions server-side last year. Does that fix our exposure?

Only if you also changed the payload. Most server-side migrations forward the same URL, the same parameters, and the same identifiers through a container that does not modify them. Pull the actual outbound request bodies your server sends to Google and read every field. If they match what the browser tag used to send, you changed the route and nothing else.

Are enhanced conversions safe for healthcare advertisers?

The hashed identifiers enhanced conversions relies on are identifiers by design, because deterministic hashing is what makes cross-organization matching work. Whether the feature is workable depends on whether an identified person is being linked to a conversion action that implies a clinical fact. When the conversion action is generic and no clinical context travels with it, the risk profile changes substantially.

Is a conversion action name really a compliance problem?

It can be. The name is stored in the ad platform, visible to every user with account access, and attached to reporting for as long as the account exists. A conversion action named for a condition tells anyone who opens the interface what the associated clicks represent, without a single event parameter being examined.

What about offline conversion imports from our CRM?

Treat that pipeline as the highest-risk integration in the account, because it originates in the system that holds clinical records. Review the field mapping directly rather than the vendor's description of it, confirm what the connector sends on each run, and restrict it to a click identifier, a conversion action, a timestamp, and a value.

Does Google sign a BAA for Google Ads?

Google does not offer a Business Associate Agreement covering Google Ads. Some Google Cloud services are covered under a Cloud BAA, which is a separate matter and does not extend to the advertising products. The workable structure is a BAA with the vendor handling data before it reaches Google, plus an architecture where Google never receives protected health information.

This article reflects the record as of July 2026 and is based on the redacted complaint e-filed on ftc.gov. The allegations are unproven, and Hims has denied them, stated that its privacy policy makes clear that users may choose how their data is used, and said it will defend the case.

If your compliance answer for Google Ads is currently "we run it server-side," paragraph 77 is a reasonable prompt to go read the payloads that assertion is resting on. Curve was built so that healthcare advertisers can keep Google Ads measurable and well-optimized without protected health information crossing the line. See how it works at curvecompliance.com.