Med Spa Lead Forms: Which Fields Are Safe to Track

On a med spa lead form, the only fields safe to send to an ad platform are the contact identifiers those platforms use for matching (email, phone, first and last name, city, state, postal code, country) hashed before they leave your infrastructure, plus the click ID the platform issued itself, and Curve is the HIPAA-compliant tracking layer that enforces that boundary per destination. Everything else on a med spa form, including the treatment dropdown, the area of concern, the photo upload, and the free-text message, belongs in the CRM and nowhere near Meta or Google. Curve includes a signed BAA on every plan.

The reason med spa forms leak more than other healthcare forms is that they are designed to qualify. A good consultation form asks what the person wants done, where on the body, what they have tried, and what they can spend. Every one of those answers is exactly what makes the lead valuable to your intake team and exactly what you cannot disclose to an advertising vendor.

Three buckets, not two

Teams usually sort fields into safe and unsafe. Three buckets is the more useful model, because some fields are fine to collect and unsafe to forward, while others should not be on a marketing form at all.

• Bucket A: collect and forward, hashed. Matching identifiers the ad platform needs to connect a conversion to a click.
• Bucket B: collect, never forward. Operational and clinical detail that your intake team needs and that stops at the CRM boundary.
• Bucket C: do not collect here. Fields that belong in a clinical intake system behind a BAA, after the person is a patient, not on a public marketing form.

The bucket C category is the one people resist, because collecting it earlier feels efficient. It is not efficient. It moves the highest-sensitivity data onto the widest-exposure surface in your stack.

Bucket A: what may travel to an ad platform

A field belongs here only if all three are true: the platform uses it for matching, it is hashed where the platform's conversion API expects hashing, and it carries no clinical meaning on its own.

• Email address. Hashed. The primary matching key when a click ID is missing.
• Phone number. Normalized to E.164, then hashed.
• First and last name. Hashed. Lower match value than email, still useful.
• City, state, postal code, country. Hashed per the platform's requirement. Geography without treatment context is not health information.
• Click IDs captured at landing. The gclid, fbclid, msclkid, and li_fat_id values pass through unhashed, because the platform issued them and they mean nothing outside that platform.
• A neutral event name and timestamp. That a conversion happened, and roughly when.

That is the complete list. It is short on purpose, and it is enough. Attribution is a matching problem, not a content problem. The platform does not need to know why the lead is valuable in order to find more people like them.

Bucket B: collect it, stop it at the CRM

These fields earn their place on the form. They just never leave lane one.

Treatment or service of interest

The single most common leak on a med spa form. A dropdown listing your service menu turns every submission into a statement about a named person's interest in a specific medical procedure. It is legitimate to collect and route on. It must not appear in a conversion payload, in an event name, in a URL parameter, or in a hidden field that a tag reads.

Area of concern or treatment area

Body-area fields are more sensitive than treatment fields, not less, and they are frequently overlooked because they read as harmless UI. Keep them in the CRM.

Free-text message or notes

An unbounded field is a blank cheque written by the patient, and med spa prospects write remarkably specific things in them: medications, prior procedures, pregnancy status, conditions. There is no reliable way to sanitize free text at scale, so the correct handling is exclusion from the conversion lane entirely rather than an attempt to clean it.

Photo uploads

Med spa forms increasingly ask for a photo of the treatment area. Treat an uploaded image as the most sensitive object your marketing stack will ever handle. It should never touch a marketing automation tool without a BAA, it must never be referenced by a URL that a tag can read, and its storage needs the same controls as clinical records. If you can move this to a post-lead step inside a system built for it, do that instead.

Appointment preference, provider preference, and location

Preferred time is operational and low risk. Preferred provider is different: if a provider is associated with a specialty, the preference discloses the specialty. Location is usually fine unless a location is single-service.

Budget, financing interest, and membership questions

Financing interest relates to payment for care, which sits inside HIPAA's definition when tied to an identifiable person. Collect it if intake needs it. Do not forward it.

How did you hear about us

Harmless in itself and worth collecting for self-reported attribution. Just do not let it become the mechanism by which a treatment-specific campaign name rides along into a payload.

Bucket C: keep it off the marketing form

• Current medications. Necessary before treatment. Not necessary before a consultation booking.
• Pregnancy or breastfeeding status. Clinically required screening for several med spa treatments, and among the most sensitive categories in privacy law.
• Medical conditions, allergies, prior procedures, prior complications. All clinical intake.
• Date of birth. Age gating can be done with a yes or no confirmation rather than a full birth date, which is a direct HIPAA identifier.
• Insurance details or member numbers. Rarely relevant to a cash-pay med spa and high sensitivity when present.
• Any internal patient identifier. MRN-style values have no reason to exist on a public form.

The general principle: a marketing form's job is to produce a qualified conversation, not a chart. Move clinical screening to the intake system that sits behind your BAA, where it belongs anyway.

The fields you did not add

Some of the most damaging values on a med spa form submission are not fields at all. They are context the browser attaches automatically.

• Page URL and page title. A submission from a treatment-specific landing page carries the treatment in the URL even when the form asks nothing clinical. This is why "we do not collect health information on the form" is rarely a complete defense.
• Referrer. Same problem, one step back, and it frequently names the gallery or service page the visitor came from.
• UTM parameters and campaign names. If your campaign naming convention contains the service line, and it usually does, the service line is in the query string.
• Hidden form fields. Many form builders populate hidden fields with the page URL, the form name, and the source campaign, then pass the whole object to every connected integration.
• The event name itself. An event called botox_consult_request discloses the treatment in the event name and sits in the ad platform interface permanently.

Meta and Google do not sign BAAs for their advertising products, so there is no contractual cover for any of this. Healthcare pixel litigation settlements have cumulatively crossed $100 million. Med spas that provide or bill for medical services can be covered entities, and state consumer health privacy laws such as Washington's My Health My Data Act reach consumer health data beyond HIPAA's boundary regardless.

How Curve enforces the boundary

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. The tracking script installs in place of the Meta Pixel or Google tag, and events go to Curve's US-hosted infrastructure rather than straight to an ad platform. That is the structural change everything else depends on: there is now a place where a decision can be made before data leaves.

Per-destination field mapping. Only fields you explicitly map forward to a given destination, and mapping is configured per destination. The default is that nothing goes. A field you forgot about is a field that stays put, which is the correct behavior for an unreviewed change.

Identifier hashing. Bucket A identifiers are SHA-256 hashed to each platform's conversion API requirements before forwarding.

Neutral event aliases. The ad platform sees a neutral event name. Your team keeps the descriptive name internally, so reporting stays readable without the service line traveling.

PHI-pattern detection. Curve inspects payloads for PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences, and flags them. This is a monitoring layer rather than redaction. The protection is the field mapping and the hashing. Detection is how you learn that someone added a medications field to your consultation form three weeks ago.

Bridge tokens and incoming webhooks. When the prospect clicks out to a separate booking or intake tool, bridge tokens preserve attribution across the handoff. When the CRM knows the person actually booked and attended, an incoming webhook matches that outcome back by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields, so a misconfigured upstream tool cannot corrupt the record.

For the surrounding architecture, see how lead routing works from ad click to CRM without PHI. If your form vendor or automation middleware is the open question, we have looked at HubSpot for clinic marketing and where Zapier sits in a healthcare automation chain separately.

An audit you can run this week

1. Inventory every form on every property. Include the ones nobody remembers owning, the chat widget, and the pop-up offer.
2. Label every field A, B, or C. Do it on paper before touching a tool.
3. Delete the bucket C fields and move that screening into intake.
4. List every integration each form posts to. Form builder, CRM, automation middleware, email tool, notification inbox. Each needs a signed BAA.
5. Open the network tab and submit a test lead. Filter to your ad platform domains and read what actually goes out, including page URL and hidden fields.
6. Rename events to neutral aliases before launch, because renaming after the fact loses history in the ad platforms.
7. Re-run step five whenever anyone edits a form. This is the step that catches real problems, and it is the step teams skip.

Frequently asked questions

Is a treatment dropdown really PHI?

Tied to an identifiable person and submitted to a practice that provides medical services, yes, it relates to that person's care. The dropdown label alone is not PHI. The dropdown label plus a name and email address is information about a named person's interest in a medical procedure, which is the thing HIPAA's marketing disclosure rules exist to govern.

Does hashing the email make it safe to send the treatment too?

No. Hashing protects the identifier in transit. It does not change what the disclosure communicates. Meta can match a hashed email to a known user, so an event that says this hash enquired about a specific procedure is still a disclosure about an identifiable person.

Can I send the treatment as a custom parameter if I use a code instead of the name?

Coding the value does not remove the meaning, it only obscures it from a casual reader. The mapping exists, the platform holds a stable per-person signal about a procedure category, and you have taken on the burden of arguing that a code is not information. Send a neutral event and keep the detail in the CRM.

What about a photo upload field?

Treat it as the highest-sensitivity object in the stack. Keep it out of any tool without a BAA, make sure no URL referencing it is readable by a tag, and prefer moving the upload to a post-lead step in a system designed for clinical images.

Will stripping these fields hurt ad performance?

The removed fields were never used for optimization. Match rate and outcome quality drive performance, and both usually improve when you move to server-side collection with click-ID matching and start sending real downstream outcomes such as booked and attended instead of raw form fills.

Do I need this if my forms are on a third-party booking platform?

Yes, and the handoff is the part that breaks. When the prospect leaves your site for a separate booking tool, the click ID is usually lost, which is why bridge tokens exist. Check what tags the booking platform loads on its own pages too, because that is outside your site and inside your exposure.

How do I know whether my current forms are leaking right now?

Submit a test lead with the browser network tab open, filtered to ad platform domains, and read the outbound payloads field by field. Our free compliance scanner will also flag risky tracking on any healthcare site as a starting point.

Where to start

Label your fields A, B, and C this week. That exercise alone usually removes two or three bucket C fields and reveals a hidden field nobody knew was carrying the page URL into three integrations.

Then make the boundary structural rather than remembered. Curve collects events server-side, forwards only explicitly mapped fields per destination, hashes identifiers to each conversion API's requirements, sends neutral event names instead of treatment names, monitors payloads for PHI-shaped values, and matches CRM outcomes back by email, click ID, or bridge token. A signed BAA comes with every plan. Read the med spa guide to Facebook Lead Ads consultation requests, or visit curvecompliance.com to walk through your forms with someone who has audited a few hundred of them.

Reviewed August 2026. Ad platform conversion API field requirements and healthcare advertising policies change frequently. Verify field-level requirements against current platform documentation, and confirm your own covered entity status with counsel.