Which Lead Fields Can Reach Your Ad Platforms

Only a short list of non-clinical identifiers may reach an ad platform from a patient lead: hashed email, hashed phone, hashed name and coarse location, plus the click identifiers the platform issued itself, event time, and a neutral event name. Everything describing why the person contacted you stays behind. Curve is the HIPAA-compliant tracking layer that enforces this per destination, forwarding only explicitly mapped fields, SHA-256 hashed to each platform's conversion API requirements, with a signed BAA on every plan.

This article is the field-level reference. The reasoning behind each entry matters more than the entry itself, because new fields appear constantly and you need a rule that decides them, not a list to memorize.

The rule that generates every entry below

A field may travel to an ad platform only if it passes all three tests:

1. It is a matching key. The platform uses it to connect a conversion to a click or a user. If a field is not used for matching, sending it adds risk and adds nothing.
2. It is hashed where the platform's API expects hashing. Contact identifiers are hashed before they leave your infrastructure. Click IDs are not, because the platform issued them and needs them raw.
3. It carries no clinical meaning on its own or in combination. Not the field alone, and not the field alongside the event name, the campaign name, or the page URL travelling with it.

Test three is where healthcare advertisers fail, and it fails in combination rather than in isolation. An email address is not health information. An email address attached to an event called bariatric_consult is. The field passed; the payload did not.

The underlying insight is that attribution is a matching problem, not a content problem. Meta, Google, Microsoft, and TikTok do not need to know why a lead was valuable. They need to know that a conversion happened, roughly when, and which click it belongs to. The routing architecture around these fields is covered separately in our guide to connecting lead forms to your CRM without PHI.

Allowed: click identifiers, passed through unhashed

These are issued by the platform, captured on your landing page, and returned unchanged. They are the highest-quality matching keys available and they carry no personal meaning outside the platform that minted them.

• gclid, and gbraid or wbraid for iOS app and web-to-app journeys, for Google Ads
• fbclid, and the derived _fbc and _fbp browser cookies, for Meta
• msclkid for Microsoft Advertising
• ttclid for TikTok
• li_fat_id for LinkedIn

Capture these at first landing and store them with the session. They cannot be reconstructed afterwards, and a conversion without a click ID falls back to weaker identity matching, which is exactly the situation where teams start reaching for extra fields they should not send.

Allowed: contact identifiers, hashed before they leave

These are the fallback matching keys, used when the click ID is missing or expired. Every one of them is hashed with SHA-256 after normalization.

• Email address. The strongest hashed key. Lowercase and trim before hashing.
• Phone number. Normalize to E.164 digits with country code, strip punctuation and leading symbols, then hash.
• First name and last name. Lowercase, strip punctuation and accents per the platform's stated normalization.
• City. Lowercase, no spaces or punctuation.
• State or region. Two-letter code, lowercase, for United States addresses.
• Postal code. First five digits for United States addresses.
• Country. Two-letter ISO code, lowercase.

A caution on location. Coarse geography is a legitimate matching key. Location becomes a disclosure the moment it is precise enough to identify a facility. A postal code covering a single specialty clinic communicates that specialty. Street address is never a matching requirement and should not be sent.

Allowed: technical and event fields

• Event name, provided it is a neutral alias rather than a description of the service line.
• Event time, as a timestamp.
• Event ID, a stable identifier used for deduplication between browser and server events and across webhook retries.
• Action source, the platform's field for whether the conversion happened on the web, by phone, or in person.
• Client IP address and user agent, which several conversion APIs require unhashed for match quality. These are personal data and deserve care, but they carry no clinical meaning and are required by the API.

Never send: the list, with the reason for each

These fail test three. None of them is a matching key, so nothing is lost by excluding them.

• Reason for visit, symptom, or condition. This is health information about an identifiable person disclosed to a vendor with no BAA. It is the plain case.
• Diagnosis or procedure codes. ICD and CPT values are clinical by definition and trivially decoded.
• Medications, dosage, or treatment history. Drug names frequently identify a single condition.
• Insurance carrier, plan, member number, or coverage status. Payment for care is explicitly in scope under HIPAA, and plan type often implies condition or eligibility category.
• Medical record numbers and internal patient identifiers. These are enumerated identifiers, and they let anyone holding a second dataset rejoin the record.
• Social Security number. Never required, never a matching key, never appropriate.
• Date of birth. Some platforms accept a hashed birth date as a matching key. In healthcare, decline it. Date of birth combined with postal code and gender is one of the classic re-identification triples, and the marginal match rate gain is not worth it.
• Free-text message, note, or comment fields. Unbounded and uncontrollable. Patients volunteer clinical detail without being asked, and free text cannot be reliably sanitized at scale.
• Appointment type, service line, department, or provider name. Each names the condition indirectly. A provider list where each clinician holds one specialty is a diagnosis lookup table.
• Pipeline stage or CRM status that encodes clinical progress. A stage called "pre-surgical consult booked" discloses as much as a diagnosis field.
• Full page URL or referrer naming a condition or treatment. The most common leak of all, because it travels automatically unless something stops it.
• Descriptive event names. An event called fertility_consult_request sits in the platform's interface permanently and appears in every report exported from it.
• Campaign, ad set, and ad names carrying the service line. These flow into CRM source fields and back out through conversion payloads and reporting integrations.
• Uploaded files, images, or document links. Intake attachments and clinical photographs have no place in a conversion payload.
• Call recordings, transcripts, or links to either. Recordings stay in systems covered by a BAA.

The middle ground: fields that depend on context

Four fields sit between the lists, and they are where careful teams still make mistakes.

Event source URL

Several conversion APIs accept a page URL, and match quality does not depend on it. In healthcare it is conditionally allowed at best. If your URLs are structured as /treatments/hormone-therapy, the URL is a clinical field. Either strip it from the payload entirely or send a generic path. Never rely on truncating query strings alone, because the path itself is usually the problem.

External ID

A hashed internal identifier can be a legitimate matching key and is useful for stitching across sessions and devices. It is acceptable only when the underlying value is a randomly generated marketing identifier. If it is a medical record number, an EHR patient ID, or anything else that resolves to a chart, it fails regardless of hashing, because hashing a value from a small enumerated space does not protect it.

Conversion value and currency

Revenue is normally fine and genuinely useful for value-based bidding. It becomes a disclosure when the amounts are distinctive enough to identify the procedure. If one service line is the only thing you sell at a particular price point, that number names it. Consider sending banded or standardized values where the price list is that revealing.

Lead source and location code

Operational metadata is fine when it is genuinely operational. It is not fine when the taxonomy is organized by condition, which happens more often than teams expect because the taxonomy was designed by the marketing team to be useful, not to be neutral.

Normalization rules that decide whether hashing works at all

A hash of an unnormalized value is a hash that never matches. These rules are why match rates disappoint.

• Trim leading and trailing whitespace from every value before hashing.
• Lowercase everything. Hashing is case sensitive and users type inconsistently.
• Hash the normalized string, not the display value the user typed.
• Produce lowercase hexadecimal output, not base64, unless the platform states otherwise.
• Never hash an empty string. Omit the field instead, because a hash of an empty value is a constant that matches every other empty value.
• Never send a field both hashed and in the clear as a fallback. This appears in real implementations and defeats the entire exercise.
• Normalize per destination. Platforms differ on phone formatting and name handling, so one canonical hash for all destinations will underperform on at least one of them.

How Curve enforces the field boundary

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, built so that this list is enforced by configuration rather than by memory.

• Server-side collection. Events go to Curve's US-hosted infrastructure instead of directly to an ad platform, which creates a decision point before anything leaves.
• Per-destination field mapping. Only explicitly mapped fields forward to a given destination, and the default is that nothing goes. A field added to a form next month does not start travelling on its own, which inverts the usual failure mode where new fields leak until somebody notices.
• Identifier hashing. SHA-256, applied per each platform's conversion API requirements and normalization rules.
• Neutral event aliases. The ad platform records a neutral name while your internal reporting keeps the descriptive one.
• PHI-pattern detection. Values shaped like SSNs, MRN-style identifiers, dates, and long numeric sequences are flagged. This is monitoring rather than redaction. Protection comes from the mapping and the hashing; detection tells you when an upstream form or automation changed.
• Incoming webhooks and offline uploads. Outcomes from a CRM or EHR match by email, click ID, or bridge token, and incoming data cannot override protected core attribution and contact fields.

A signed BAA is included on every plan.

Frequently asked questions

Does hashing make a field safe to send?

No. Hashing protects the identifier in transit and at rest. It does not change what the disclosure communicates. If the event tells Meta that this identified person enquired about a specific treatment, hashing the email changes nothing about that, because Meta can match the hash to a known user. Hashing is a transport control, not a compliance argument.

Which single field leaks most often?

The page URL. It travels automatically with browser tags and with many server-side implementations that pass through whatever the client sent. Healthcare URLs are usually organized by condition, so the leak is built into the site structure rather than into any form field.

Can I send hashed date of birth if the platform accepts it?

You can, technically, and in healthcare you should not. It is a strong re-identification vector in combination with postal code and gender, it is rarely necessary at the lead stage, and its contribution to match rate is small next to email and phone.

Will sending fewer fields hurt performance?

Match rate depends on click IDs and on email and phone quality, not on volume of fields. Server-side conversions with click ID matching typically measure better than browser pixels, because they are unaffected by ad blockers, tracking prevention, and cookie expiry. The clinical fields you remove were never used for optimization in the first place.

What about custom parameters my team already built reports around?

Move the reporting rather than the data. Keep the descriptive dimension in your own analytics, where it belongs, and send the ad platform the neutral alias. Ad platform reporting is not the right home for clinical segmentation, and once a value is in there it is effectively permanent.

Do these rules change for LinkedIn, TikTok, or Microsoft?

The field names and normalization details change. The rule does not. Every one of them wants matching keys, none of them signs a BAA for advertising products, and none of them needs to know the clinical reason behind a conversion.

How do I check what is actually leaving right now?

Inspect the outbound payload rather than the configuration screen. Submit a test lead, capture what your stack sends to each destination, and read every field including the ones nobody documented. Our free compliance scanner will also flag risky client-side tracking across a healthcare site.

Where to start

Take one destination and write down every field currently forwarded to it. Run each through the three tests: is it a matching key, is it hashed where required, does it carry clinical meaning alone or in combination. Anything that fails comes out, and almost nothing you remove was contributing to performance.

Then close the loop so it stays closed, because these leaks arrive through form edits and new CRM automations rather than through deliberate decisions. Curve makes the safe state the default: per-destination mapping where nothing forwards unless mapped, SHA-256 hashing to each platform's requirements, neutral event aliases, PHI-pattern monitoring, and a signed BAA on every plan. See the surrounding setup in our guide to HIPAA-compliant conversion tracking for Google, Meta, and Microsoft, or visit curvecompliance.com.

Reviewed August 2026. Conversion API field specifications, accepted matching keys, and normalization rules change frequently. Verify field-level requirements against current platform documentation before implementation.