GLP-1 Subscription Billing: Tracking Leak Points

GLP-1 subscription billing leaks protected health information at six predictable points: the checkout page, item-level ecommerce parameters carrying the program name, the receipt or thank-you page, recurring charge and renewal events, the billing portal, and the cancellation or refund flow where patients type clinical reasons into a text box. Curve is the HIPAA-compliant tracking layer that lets a clinic measure all six without any of that reaching Meta, Google, or an analytics vendor. Billing is where most clinics leak, because it is the part of the funnel marketing does not own. Curve includes a signed Business Associate Agreement on every plan.

The pattern is consistent. A clinic cleans up its landing pages, neutralizes its event names, and moves conversion tracking server-side, then leaves an ecommerce plugin running on checkout that sends the product name with every purchase event. The product name is the medication. The purchase event is tied to a browser identifier the ad platform issued. That is a disclosure, and it fires on every successful order.

Why billing is the part that gets missed

Three reasons, and all of them are organizational rather than technical.

Billing surfaces are usually owned by engineering or finance, not marketing, so they are outside the scope of a marketing compliance review. They are frequently built on a commerce platform or subscription tool with tracking integrations enabled by default, which means events fire without anyone configuring them. And they are the highest-value events in the funnel, so nobody wants to disturb them once revenue reporting depends on what they send.

The result is that the most sensitive events in a GLP-1 funnel, the ones tied to actual payment for actual treatment, are also the least reviewed. Payment for care is explicitly part of the definition of protected health information, so a billing event that identifies a person is squarely in scope. We covered a specific version of this in our piece on how one complaint exposed subscription telehealth billing tracking.

The six leak points

Leak point one: the checkout page

Checkout pages accumulate scripts. Payment processor scripts, fraud tools, chat widgets, session tools, analytics, and whatever the ad platform tag manager container is loading this month. Each one loads in the patient's browser with access to the page, and the page names the treatment.

Even a checkout that collects nothing clinical carries the health context in its URL, its title, its heading, and the plan description sitting next to the payment fields. A visitor at checkout on a GLP-1 program page is a person about to pay for treatment, and any third-party script on that page can see enough to know it. Our note on Stripe and HIPAA for patient payments covers the processor-side contractual questions that sit alongside this.

Leak point two: item-level ecommerce parameters

This is the most common and most overlooked. Standard ecommerce tracking sends structured item data with purchase events: item name, item ID, item category, item variant, quantity, price. In a GLP-1 program those fields contain the medication name, the dose tier, the program length, or a SKU that maps to all three.

The event is a purchase event. It carries a click identifier or a browser identifier. It contains the item name. Nothing about that payload requires interpretation to be a disclosure. It arrives at the ad platform already saying that this identifiable person purchased this specific treatment.

Dose tier variants deserve a specific mention. Clinics often structure plans by dose, so the item variant field ends up carrying clinical information more granular than the diagnosis. That field is usually populated automatically by the commerce platform, and almost nobody has looked at it.

Leak point three: the receipt or thank-you page

Post-purchase pages leak in several ways at once. The URL often contains an order ID or an invoice reference, which functions as an identifier. The page title frequently names the program. The confirmation body describes what was purchased and when the next shipment arrives. And this is the page where clinics most reliably fire their conversion pixel, because it is the page that proves the sale.

If your conversion event fires from a page whose URL and title describe a medication, the page URL and title travel with it unless something is stopping them. Referrer data does the same job one hop later, carrying the receipt page URL into whatever loads next.

Leak point four: renewals and recurring charges

The first purchase is the one everyone tracks. Renewals are where the money actually is in a subscription model, and they happen server to server without a browser involved, which creates a specific temptation: teams wire the subscription platform's webhooks directly into an ad platform's conversion API to get renewal revenue into their reporting.

Those webhook payloads are built for billing systems, not for advertising. They carry the subscription plan name, the product description, the amount, the billing interval, and customer identifiers, and they get forwarded wholesale because filtering them was not part of the integration. A renewal event forwarded raw is a monthly recurring disclosure that this person is still on this treatment.

Leak point five: the billing portal

Self-service portals where patients update payment methods, change plans, pause, or view invoices are logged-in surfaces about an active treatment relationship. Analytics and session tools running there capture plan names, invoice detail, and sometimes the full billing history. Because the portal is a product surface rather than a marketing surface, it usually inherits whatever site-wide tag configuration exists without anyone reviewing it against health-context rules.

Leak point six: cancellation, pause, and refund flows

The worst of the six, and the one that surprises teams. Cancellation flows almost always ask why. The reason options in a GLP-1 program are clinical by nature: side effects, nausea, cost, plateau, switched to another provider, no longer eligible. Many flows include a free-text box, and patients write remarkably specific things in them.

When that survey fires an analytics event with the selected reason as a parameter, you have transmitted a clinical outcome attached to an identifiable person. Free text makes it worse, because it is unbounded and cannot be reliably sanitized at scale. The correct handling is to keep cancellation reasons entirely out of the tracking layer, in a system covered by a BAA, and to send no more than a neutral churn signal onward if you need one at all.

Refund and chargeback events have the same problem in a smaller package: reason codes that describe clinical dissatisfaction, attached to a person the platform can identify.

What ad platforms actually need from a billing event

The reason all six leaks are fixable is that none of that content is required for the platform to do its job. Meta, Google, Microsoft, and TikTok need to know that a conversion occurred, roughly when, which click it belongs to, and optionally its value. Attribution is a matching problem, not a content problem.

A renewal event containing a neutral event name, a timestamp, a click ID captured at landing, a hashed contact identifier, and a currency amount is fully useful for optimization and contains nothing clinical. The item name, the dose variant, the plan description, and the cancellation reason are all things you want in your own reporting and none of them are things the optimizer uses.

How Curve handles subscription billing events

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. The tracking script installs in place of the Meta Pixel or a raw Google tag, events go to Curve's US-hosted infrastructure rather than directly to ad platforms, and decisions about what continues onward happen there.

Per-destination field mapping with a deny-by-default posture. Only fields you explicitly map forward to a given destination. Item name, item variant, plan description, invoice reference, page URL, and page title stay behind unless you deliberately map them. On billing surfaces this default is doing most of the work, because the leak is almost always a field nobody intended to send.

Neutral event aliases. The ad platform sees a neutral event name instead of one naming the program or the medication. Internally the event keeps its descriptive name, so subscription reporting, cohort analysis, and revenue attribution are unaffected.

Incoming webhooks with attribution matching. Your billing system posts renewal, refund, and churn events to Curve rather than to an ad platform. Curve matches them to the original session by email, click ID, or bridge token, then forwards only what is mapped. Incoming webhook data cannot override protected core attribution and contact fields, so a misconfigured billing integration cannot corrupt the attribution record.

Bridge tokens across the intake handoff. GLP-1 funnels usually route through a separate intake or booking tool before payment. Bridge tokens preserve attribution across that handoff, which is what makes it possible to connect a renewal months later back to the original click.

Offline conversion uploads. For reconciliation and backfill, bulk upload from the billing system or CRM with click-ID matching, up to 10,000 rows and 5MB per file.

PHI-pattern detection. Curve inspects payloads for PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences and flags them. It is a monitoring layer, not redaction. The protection is the field mapping and hashing. Detection is how you learn that a commerce plugin update started populating a field it did not populate before, which on billing surfaces happens more often than anywhere else.

Identifiers are SHA-256 hashed per each platform's conversion API requirements, and Curve forwards clean conversions server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, LinkedIn, and others. A signed BAA comes with every plan.

Remediation order

1. Read the actual payloads first. Open checkout, receipt, and portal pages with the network tab filtered to ad platform and analytics domains. Complete a test purchase. Read every outbound request field by field.
2. Kill item-level ecommerce parameters on treatment products, or replace product names with neutral identifiers before the event is constructed.
3. Strip page URL, title, and referrer from anything leaving billing surfaces.
4. Cut cancellation and refund reasons out of tracking entirely. Keep them in a BAA-covered system.
5. Reroute billing webhooks through your own infrastructure rather than pointing them at an ad platform's conversion API directly.
6. Review the billing portal's tag configuration separately from the marketing site. It usually inherited settings nobody chose.
7. Re-test after every commerce platform or plugin update. Billing stacks change underneath you.

Step one is not optional and it is not replaceable by reading a configuration screen. A configuration is a statement of intent. The outbound request is the fact.

Frequently asked questions

Can I send purchase value to an ad platform for a GLP-1 subscription?

Yes. A currency amount attached to a neutral event name is not clinical information, and value-based optimization is one of the more useful things you can give the platform. The problem is never the number, it is the item name and description that standard ecommerce tracking sends alongside it.

Is a receipt page conversion event safe if the URL has no medication name in it?

Better, but check the page title, the referrer, and any structured ecommerce data on the page as well. Clinics frequently clean the URL and leave the title naming the program, which travels with the event just as reliably.

What should I do with cancellation reason data?

Keep it. It is valuable and you should analyze it. Keep it inside systems covered by a BAA, exclude it from the tracking layer completely, and send at most a neutral churn signal onward. Free-text boxes in particular should never be part of an event payload.

Can I connect my subscription platform directly to Meta's Conversions API?

Technically yes, and that is why it happens. The payload those platforms emit is built for billing and carries plan names, product descriptions, and customer detail, so a direct connection forwards clinical content by default. Route it through infrastructure that lets you decide field by field what continues.

Do renewals need to be tracked at all for advertising?

They are worth sending as neutral value events, because optimizing toward first purchase alone teaches the platform to find people who start and do not stay. Renewal signals are how the optimizer learns the difference, and none of that requires disclosing what the renewal was for.

Does using a payment processor with a BAA solve this?

It addresses the processor, not the ad platform. A BAA covers only the party that signed it, and no ad platform signs one for its advertising products. The processor relationship and the tracking configuration are separate problems that both need solving.

How often should billing tracking be re-audited?

After every commerce platform update, plugin change, subscription tool migration, or checkout redesign, and on a fixed schedule regardless. Billing stacks accumulate integrations, and integrations enable tracking by default.

Where to start

Complete a test purchase on your own site with the network tab open, then complete a test cancellation. Most clinics find at least two of the six leak points live within ten minutes, and the item name in the purchase payload is usually the first one.

Curve is built to make billing surfaces safe without giving up the reporting: server-side collection, per-destination field mapping that defaults to sending nothing, neutral event aliases, incoming webhooks with attribution matching for renewals and churn, bridge tokens across intake handoffs, offline uploads for reconciliation, and a signed BAA on every plan. Run the free compliance scanner against your checkout, read our analysis of what changed for direct-to-consumer telehealth after the FTC action against Hims and Hers, or visit curvecompliance.com to review your billing stack with us.

Reviewed August 2026. Commerce platforms, subscription tools, and conversion API requirements change frequently. Re-verify outbound payloads after any change to your billing stack.