Server-to-Server Pixels Are Still Pixels: Google S2S and TikTok S2S in the FTC Complaint

When the FTC listed the tracking technologies allegedly deployed across Hims & Hers properties, it did not sort them into browser-based and server-based categories. Paragraph 77 of the complaint puts the "Google Ads S2S Pixel" and "TikTok (s2s)" in the same inventory as the Bing Pixel, the Pinterest tag, and every other browser tag on the list. The agency treated a server-to-server integration as one more disclosure channel, because from a consumer-protection standpoint that is exactly what it is.

The takeaway is short. Moving a tag from the browser to your server changes who makes the request. It does not change whether health information reaches a third party, and the FTC's pleading is written as though everyone already understands that. Curve is a HIPAA-compliant conversion tracking platform for healthcare advertisers that runs server-side by design and, critically, sanitizes events before they leave your infrastructure, so protected health information never reaches the ad platform on either transport.

These are allegations in an active case. FTC; The People of the State of California, acting by and through Los Angeles County Counsel Dawyn R. Harrison; and Utah Division of Consumer Protection v. Hims & Hers Health, Inc., Case No. 3:26-cv-7871 in the Northern District of California, is being litigated, not settled. Hims has denied the allegations, says its privacy policy makes clear that users may choose how their data is used, and intends to defend the case.

The Short Version

• Complaint paragraph 77 names server-to-server integrations, specifically the Google Ads S2S Pixel and TikTok s2s, alongside conventional browser pixels with no distinction drawn between them.
• Paragraph 70 does the same with Meta, describing the Conversions API accurately as a direct server-to-server connection and pleading it as a disclosure vector regardless.
• The regulatory question is whether identifiable health information was disclosed to a third party. Transport is an implementation detail in that analysis.
• A Google Tag Manager server container is a relay by default. It receives the full client payload and forwards it onward unless someone builds the filtering, and most implementations never do.
• What makes a server-side setup defensible is what happens at the egress boundary: field allowlists rather than blocklists, identifier policy, per-destination configuration, and a BAA covering the processor.
• If your compliance story is "we moved to server-side," you do not yet have a compliance story.

What Paragraph 77 Actually Says

The complaint alleges that, in addition to the Meta technologies discussed at paragraph 70, Hims placed a substantial roster of other advertising trackers on its platforms. As pled, the list includes Microsoft's Bing Pixel and Bing Image Pixel, Google's Google Ads Pixel and Google Ads S2S Pixel, Criteo, MediaBids.com, PartnerCentric, PebblePost.com, Pinterest, Podsights (now Spotify Ad Analytics, listed as Podsights_iHeartMedia), Reddit, StackAdapt, TikTok (s2s), The Trade Desk, and X, formerly Twitter.

Two entries on that list are server-side integrations, and they are not flagged as exceptional. They appear in the middle of the inventory, in the same sentence structure, described the same way. The pleading treats a conversion sent from a Hims server to Google's API and a tag firing in a visitor's browser as members of one category: technologies through which, the FTC alleges, information about consumers reached advertising platforms.

Paragraph 70 makes the point explicit rather than implicit. There the complaint names both the Meta Pixel and the Conversions API, and it 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." The agency understood the architecture, wrote it down correctly, and pled it as a violation vector anyway. We work through that specific finding and what it means for Meta implementations in our analysis of whether the Meta Pixel or Conversions API is HIPAA safe. This article is about the rest of the ecosystem, where the same logic applies with less attention paid to it.

Why Transport Was Never the Defense

The confusion has an understandable origin. Server-side tracking genuinely solves several real problems. It survives browser tracking prevention. It is not blocked by extensions. It gives you a chokepoint where you can inspect and modify data, which is a legitimate and important compliance capability. Vendors sold those benefits hard, and somewhere in the retelling "server-side gives you control over what you send" became "server-side means you are compliant."

The legal analysis does not work that way. HIPAA asks whether protected health information was disclosed to someone without permission or a business associate agreement. Section 5(a) of the FTC Act asks whether a practice was deceptive or unfair to consumers. Neither test contains a field for which network topology the disclosure used. If a request carries an identifier and a fact about a person's health to a company that is not your business associate, the origin IP address of that request is irrelevant to the analysis. We laid the general version of this argument out in why server-side tracking alone is not HIPAA compliance, and the Hims complaint reads like a regulator making the same point in a caption.

There is a second, more practical reason transport is not protective. Server-side integrations usually carry more information than their browser counterparts, not less. Conversion APIs were built to improve match rates, and match rates improve when you send more identifiers. The standard integration guides for these endpoints encourage sending hashed email, phone number, first and last name, city, state, zip, external ID, IP address, and user agent, together with event parameters describing what the person did. A browser pixel gets a cookie and whatever the page hands it. A server integration gets whatever your CRM knows.

How a Curve-Style Server-Side Setup Differs

The distinction that matters is not browser versus server. It is whether anything filters the payload before it leaves your control. Curve runs as a first-party collection and egress layer: events are collected on your own domain, processed server-side, and stripped of protected health information before any outbound request is made to a destination. Filtering is allowlist-based, so a new field added by a developer or a form vendor does not silently start flowing to Meta, Google, or TikTok next Tuesday. Each destination is configured separately, because the fields Google Ads accepts, the fields the TikTok Events API accepts, and the fields Microsoft UET accepts are not the same set, and a single generic mapping tends to over-send to at least one of them. A BAA is available for the layer that touches the data, which is the piece a raw server container cannot give you.

The measurable outcome is that campaigns keep optimizing. Platforms need conversion signal, timing, and value. They do not need the treatment category, the page path, or a raw email address to do that. If you want the implementation-level version, our setup guide for Google, Meta, and Microsoft covers destination-by-destination configuration, and the Enhanced Conversions walkthrough covers the Google-specific case that most often goes wrong.

The Server-Side Integrations Healthcare Advertisers Actually Run

Each of these behaves differently enough that a single policy statement will not cover them. Treat the list as an audit inventory.

Google Ads server-side conversion imports

The entry pled as "Google Ads S2S Pixel" corresponds to the family of integrations where conversions are sent from your systems to Google rather than from a browser tag. In current practice that includes offline conversion imports keyed on GCLID or WBRAID, Enhanced Conversions for leads keyed on hashed customer data, and server container forwarding to the Google endpoint. The compliance-relevant part is the conversion action name and any user-provided data attached. A conversion action named after a treatment category communicates a diagnosis on every upload, forever, no matter how clean the identifiers are.

TikTok Events API

TikTok's server integration accepts hashed identifiers plus event names and properties, and it accepts custom events with names the advertiser chooses. The named risk is the same as with Google: the event taxonomy is free text written by a marketer. Healthcare advertisers on the platform have additional policy constraints layered on top of the privacy analysis, which we cover in running TikTok healthcare ads without breaking HIPAA.

Microsoft and Bing

Microsoft supports offline conversion imports and server-side event submission alongside the UET tag. Advertisers frequently run both, which produces two independent egress paths that need separate review. Deduplication settings are also a compliance surface, because the identifiers used to deduplicate are themselves identifiers.

Snap customer list matching

Paragraph 76 alleges that Hims uploaded customer lists to Snap in order to match users to Snapchat accounts. List matching is a server-to-server disclosure in every meaningful sense, and it is the one most often handled outside the analytics team entirely, by someone exporting a CSV from a CRM.

Reddit, Pinterest, and the programmatic layer

Reddit and Pinterest both offer conversions APIs with the same shape as the others. The Trade Desk, StackAdapt, and Criteo sit further out in the demand-side stack, where data often arrives through an agency rather than directly from you, which means your review has to extend to what your agency is uploading on your behalf. Audio and podcast measurement, listed in the complaint as Podsights_iHeartMedia, works through a mix of pixel drops and postbacks that most healthcare marketers have never inspected.

The Google Tag Manager Server Container Misconception

Server-side GTM deserves its own section because it is the single most common source of false confidence in healthcare marketing stacks.

A server container is infrastructure you control, usually running in your own cloud project on a subdomain you own. That is genuinely useful. It is also, out of the box, a forwarding proxy. The default configuration collects data in the browser through a client-side tag, transmits the full payload to your container, and then relays it to vendor endpoints. The vendor still receives the data. The container did not remove anything, because nobody told it to.

Three specific failure patterns show up repeatedly.

• The client forwards everything by default. The GA4 client in a server container passes through the parameters it receives. If your page pushes a form payload into the data layer, and something maps that payload into an event, the container will happily relay every field.
• Blocklists rot. Teams that do build redaction usually write it as a list of fields to strip. Six months later a developer adds a new parameter, or a form vendor renames one, and the new field is not on the list, so it flows. Allowlists fail closed. Blocklists fail open.
• Page context travels with the request. Page location, page path, and referrer are transmitted by default. In healthcare those three fields are frequently the entire disclosure, because the URL names the condition. Redacting a query parameter while sending the path is the most common half-fix in the category.

None of this means server containers are bad. It means a server container is a place to build a control, not a control in itself. If you are evaluating an existing implementation, the technical review sequence in our server-side tracking audit is the right order to check things in: capture what the container receives, capture what it sends, and compare the two field by field.

A Diligence Checklist for Every S2S Integration You Run

1. Enumerate every server-side destination, including ones configured by an agency, a CRM automation, or a marketing ops contractor. Dormant integrations still hold credentials.
2. For each one, capture an actual outbound request payload from production. Documentation describes what the endpoint accepts, not what your system sends.
3. Read every field. Identifiers, event names, custom properties, page context, and conversion action names all count.
4. Confirm the filter is an allowlist and that adding a new field to the site requires a deliberate change to make it egress.
5. Check who holds a BAA. The ad platform does not. Whoever operates the layer that processes the data before egress should.
6. Verify the same rules apply on mobile app SDKs and offline uploads, which are usually maintained by different people than the web stack.
7. Log egress. If you cannot answer "what did we send to TikTok on the 14th," you cannot answer a regulator either.

Frequently Asked Questions

Is server-side tracking HIPAA compliant?

Not on its own. Server-side tracking is a transport choice that gives you the ability to inspect and modify data before it leaves, which is a prerequisite for compliance rather than compliance itself. Whether an implementation is defensible depends on what the outbound payload contains and whether a business associate agreement covers the party handling it.

Does the FTC complaint say server-to-server tracking is illegal?

No. The complaint alleges that specific integrations, including the Google Ads S2S Pixel and TikTok s2s at paragraph 77 and the Meta Conversions API at paragraph 70, were channels through which consumer health information reached advertising platforms contrary to privacy promises. The allegation targets the disclosure, not the technology. Nothing has been proven, and Hims has denied the allegations and intends to defend the case.

If my GTM server container runs in my own cloud account, is the data still going to a third party?

Yes, if the container forwards to vendor endpoints, which is what it exists to do. The hop through your infrastructure gives you an opportunity to intervene. Absent an intervention that actually removes protected health information, the vendor receives the same data it would have received from a browser tag.

Do hashed identifiers make a server-side payload safe?

Hashing protects the identifier in transit and at rest to a degree, but the receiving platform hashes its own user records the same way in order to match them, so a match is still a re-identification. And hashing does nothing about the other half of the payload, which is the event or conversion name describing what the person did.

Which is better for healthcare, browser pixels or server-side?

Server-side, but only because it gives you a place to enforce a policy. A server-side setup with no sanitization is not better than a browser pixel with careful URL hygiene, and it is often worse because it carries CRM fields the browser never had.

What should I check first if I inherited someone else's implementation?

Capture one real outbound request to each destination and read it end to end. Every other document, including vendor contracts and internal architecture diagrams, describes intent. The payload describes what is actually happening.

This article reflects the record as of July 2026 and is based on the redacted complaint as e-filed, available at ftc.gov. It is general operational guidance, not legal advice.

If you are running server-side integrations and cannot say precisely which fields reach each platform, that is the gap worth closing this quarter. Curve provides healthcare advertisers with server-side conversion tracking where events are sanitized before egress, destinations are configured individually per platform, and a BAA covers the processing layer. See how it works at curvecompliance.com.