Legal Lead Attribution to Intake: Privacy-Safe Source Tracking

Legal lead attribution connects an approved source, campaign, and content identifier to a firm-controlled intake record through an internal attribution ID. Ad platforms receive only approved coarse events with no claimant identity or sensitive parameters. The secure intake system keeps answers, injury or exposure facts, diagnoses, narratives, and documents inside the firm's governed environment.

Set the boundary before selecting attribution fields

Legal lead attribution should answer a narrow operational question: which approved acquisition path produced an inquiry that reached a defined intake stage? It should not create a second copy of the claimant record inside an advertising tool.

That distinction matters before representation begins. ABA Model Rule 1.18 addresses information learned from a prospective client even when no client-lawyer relationship follows. ABA Model Rule 1.6 also addresses confidentiality and reasonable efforts to prevent unauthorized disclosure or access to information relating to a representation. Firm counsel must decide how applicable rules, notices, consent, contracts, and jurisdictional requirements apply to a particular implementation.

The technical design can enforce a conservative boundary. Meta and other acquisition systems remain on the public side. The firm's legal intake system owns the sensitive side. The handoff occurs before the firm asks about injury, diagnosis, treatment, exposure, medication, disability, financial loss, detailed legal facts, government identifiers, or documents.

Use a two-record attribution model

A useful implementation separates an acquisition touch record from the claimant intake record.

The acquisition touch record contains approved campaign metadata. It may store source_platform, campaign_id, content_id, landing_page_id, capture time, consent state, and a coarse funnel stage. It receives a random internal identifier such as attribution_id. It contains no claimant name, email address, phone number, intake answer, free-text narrative, diagnosis, injury, exposure detail, or document reference.

The secure intake record stores the person's identity, responses, permissions, source documents, corrections, review state, and provenance. It may store attribution_id as a foreign key. It should not expose its intake record ID to an ad platform.

This separation gives the firm a controlled join for internal reporting. The acquisition system can report that attribution record A7K4 reached a permitted stage. Only a restricted internal service can join A7K4 to the intake record when an authorized operational purpose requires it.

Capture source, campaign, and content IDs from an allowlist

Accept only documented fields. For example:

• source_platform identifies an approved channel such as Meta, referral, organic search, or direct traffic.
• campaign_id stores the platform campaign identifier or the firm's normalized campaign key.
• content_id stores an ad, creative, quiz, or landing-page variant identifier.
• landing_page_id stores an internal route or template identifier instead of a full URL.
• captured_at records when the first approved touch entered the attribution service.

Strip unapproved query parameters before the visitor enters secure intake. Never copy a full referrer URL, search term, form URL, or page title if it could contain a person's name or submitted facts. Map external values to an internal content registry so reporting uses stable labels even when platform names change.

Define events and data boundaries explicitly

The safest event catalog is small. Every event needs an owner, purpose, allowed destination, allowed parameters, consent requirement, and retention rule.

Event or record	Allowed data	Destination	Prohibited data
landing_view	Event ID, timestamp, source, campaign ID, internal content ID	Approved analytics and ad platform	Name, email, phone, device-derived identity, answers, medical or legal facts
quiz_started	Event ID, timestamp, internal content ID, coarse funnel stage	Approved analytics and ad platform	Question text, selected answers, free text, eligibility signals
handoff_to_secure_intake	Event ID, timestamp, internal content ID, destination class	Approved analytics and ad platform	Attribution ID, secure URL query string, claimant identity, matter type details, narrative
secure_intake_completed	Event ID, timestamp, coarse completion state	An approved ad-platform event after privacy review	Attribution ID, answers, injury, exposure, diagnosis, treatment, documents, qualification result
Internal stage record	Attribution ID, timestamp, coarse completion state	Restricted internal reporting	Any transfer of the attribution ID or joined intake values to an ad platform
Secure intake record	Identity, answers, consent history, documents, provenance, review state	Firm-controlled intake and case systems	Any transfer to an ad platform
Intake disposition	Firm-approved operational status and authorized review history	Restricted internal reporting	Legal reasoning or claimant facts in campaign reports

Meta describes the Conversions API as a connection for sending data from a server, website platform, app, or customer relationship system to Meta. That capability does not determine which legal intake data a firm should send. For this model, no claimant identity goes to the ad platform, including hashed names, email addresses, or phone numbers. Event parameters also exclude intake answers and inferred case facts.

If the firm uses a Meta instant form, review the official lead ads with forms overview, the Meta Lead Ad Terms, and the Meta Commercial Terms before configuration. Terms, product behavior, and available controls can change. Firm counsel and privacy staff own the final field set, notice, consent design, vendor assessment, and permitted downstream use.

Treat consent as a versioned operational record

Consent cannot be represented by a campaign label alone. Store the notice identifier, notice version, action, timestamp, collection surface, permitted channel, and withdrawal or change history. Keep consent to receive contact separate from consent for measurement, document collection, electronic signature, or any other distinct purpose.

The public acquisition layer should stop when the next question would reveal a sensitive fact. Redirect the person to a firm-controlled domain or approved subdomain. Remove campaign query strings from the secure destination after the attribution service resolves them to attribution_id.

The NIST Privacy Framework presents privacy as an enterprise risk-management concern. Applied here, that means defining the processing purpose, mapping data flows, restricting access, reviewing vendors, setting retention, and testing the boundary as one governed system. A consent banner by itself does not provide those controls.

Use first touch and last touch as views, not facts

First-touch attribution records the earliest approved source observed for an attribution record. Last-touch attribution records the latest approved source before a defined handoff. Each view answers a different question and both depend on what the firm could observe.

A person may see an ad on one device, return directly on another, speak with a referral partner, and call the firm later. Cookie restrictions, consent choices, browser changes, shared devices, offline contacts, and duplicate records can all break the path. Reports should label first touch and last touch as attribution methods. They should not present either as proof that one source caused the inquiry or the firm's decision.

Store the rule version used to choose each touch. Define whether direct visits can overwrite a prior source, how long an attribution window remains open, and how referral or offline contacts enter the sequence. When the rule changes, preserve prior results or record the recomputation date.

Deduplicate events without joining claimant identity to ad data

Generate an event_id for each coarse event and send the same ID through approved browser and server paths when the implementation uses both. The receiving system can use that ID to recognize two deliveries of the same event. Keep event deduplication separate from person deduplication.

The secure intake system may compare names, contact details, dates, and other firm-approved identity fields to find potential duplicate claimant records. That work stays inside the firm-controlled environment. The attribution service receives only the resulting internal relationship needed for reporting, such as one retained attribution_id and a reason code showing that two acquisition records were linked. It does not receive the identity fields used to make the decision.

A possible match should enter an authorized review queue. Shared phone numbers, email addresses, devices, or households do not prove that two inquiries belong to one person. Preserve the original source touches and the merge history so reporting does not erase legitimate inquiries.

Design the offline handoff as a controlled interface

Calls, referrals, mailed responses, and event lists need the same attribution discipline as web traffic. Staff should select an approved source, campaign, and content value from a registry. Free text belongs in a restricted intake note, not in an attribution field.

An offline import should validate the identifier format, reject unknown campaigns, record the importer and timestamp, and create an exception when the source is uncertain. Use an explicit unknown value rather than guessing. Unknown means the team attempted to identify the source and could not. Unanswered means the source question was never completed.

When the record enters the client intake process, the attribution ID travels with it. The intake record then accumulates consent, structured answers, documents, provenance, and review history. If the inquiry becomes a matter, that history should continue into the case record. The ad platform does not receive the later file content or disposition reasoning.

Restrict access, retention, and reporting

Give acquisition staff access to aggregate campaign metadata and coarse stages. Give intake staff the source context needed to work the inquiry. Limit the crosswalk between attribution IDs and claimant records to roles with an approved operational purpose. Log exports, joins, field changes, and bulk access.

Set retention by data class. Raw touch events, platform identifiers, consent evidence, internal attribution IDs, and aggregate reports may require different periods. A vendor default should not become the firm's policy by accident. Document deletion behavior across the attribution service, intake system, analytics warehouse, backups, and exported reports.

Reports should group by approved source, campaign, content ID, time period, and coarse funnel stage. Suppress small groups when they could expose a person. Do not include claimant names, contact details, narratives, injury or exposure categories, diagnoses, document status, legal analysis, or disposition reasons in ad-platform reports.

Operational reviewers can use a restricted internal report to examine handoff volume, duplicate exceptions, missing consent, intake completion, and time between approved stages. The mass tort intake data model should define the record states and provenance needed for that report. Lawyers and authorized firm staff remain responsible for conflict, legal merit, engagement, and other legal decisions.

Book a demo →

Test the boundary before launch

Use fictional records to test each route. Inspect browser requests, server logs, tag-manager variables, webhook payloads, redirect URLs, analytics exports, and Conversions API calls. Confirm that only approved event names and parameters cross the public boundary.

Test a sensitive answer, uploaded document, free-text narrative, duplicate merge, consent withdrawal, offline import, and completed secure intake. None of their values should appear in an ad-platform request, event name, URL, parameter, custom dimension, or user-data field. Confirm that staff can still trace an internal report row to its governed source through authorized tools.

Repeat the review when a form field, campaign template, vendor, tag, event, or attribution rule changes. This guide describes a technical operating model and does not provide legal advice. Firm counsel and privacy staff should approve the implementation and review current platform terms before release.