TL;DR
- Sending a form-fill event to Meta trains its algorithm to find more form-fillers, not more signed pedestrian accident cases.
- Three events are worth firing: the lead, the signed retainer, and the case value passed as a conversion value.
- All three must be tied to the original
fbclid(Facebook click ID) so Meta can close the loop from ad to retainer. - The signed-retainer event is the one that actually moves the algorithm toward the cases you want.
- CAPI (Meta's Conversions API) is the delivery mechanism for offline events like a retainer signed days or weeks after the click.
- If you fire only one event, fire the retained event, not the form fill.
Send Retained-Case Value, Not Just Lead Status
When a pedestrian accident case is signed, the most important thing that can happen for your Meta campaign is not the retainer itself. It is sending that retainer signal back to Meta, attached to the exact ad click that produced it.
Sending only a form-fill event to Meta trains its algorithm to find people who fill out forms, not people who sign pedestrian accident retainers.
Most firms fire a "Lead" event when someone submits a form. That is where the signal stops. Meta sees the form fill. Meta optimizes toward more form fills. Over a few weeks, the ad set drifts toward whoever is most likely to tap "submit," which may or may not be the person who has a viable pedestrian accident case and is ready to retain counsel.
The fix is not complicated in concept: send the signed-retainer event back to Meta, with the case value attached, within days of signing. Meta's algorithm uses that signal as evidence of what a qualified outcome looks like, and it adjusts targeting accordingly.
Why Lead-Volume Optimization Quietly Fills Your Pipeline With Junk
A pedestrian accident case has a long qualification path. Someone clicks your ad. They fill out a form. An intake specialist calls. A case manager evaluates liability and injuries. An attorney reviews. The client signs. That path can take days.
A form fill happens at step two. A signed retainer happens at step seven. If your optimization event is step two, Meta is watching step two. Every subsequent step that filters out unqualified leads is invisible to the platform.
The result is a campaign that looks healthy on the surface. Lead volume is up. Cost per lead looks reasonable. But the intake team is spending most of its time on calls that do not convert, and the firm's cost per signed case is climbing in the background.
This is not a targeting problem. It is a signal problem. The platform is doing exactly what it was told to do. It just was not told the right thing.
The Three Events Worth Firing
The three events worth sending back to Meta for a pedestrian accident campaign are the initial lead, the signed retainer, and the associated case value.
Event 1: Lead
Fire this when the form is submitted or the intake call is completed and a record is created in your CRM. Use the standard Meta Lead event. This event is fine to keep. It gives the algorithm a fast signal that the click resulted in an inquiry. The problem is when it is the only event.
Event 2: Retained
Fire this when the client signs the retainer agreement. Use a custom conversion event, labeled clearly in Events Manager (something like PedestrianCaseRetained). This is the event that matters most for algorithm training. It tells Meta: this specific person, who came from this specific ad, became a signed case.
Event 3: Case Value
Attach a value parameter to the Retained event. For pedestrian accident cases, firms typically work on contingency, so the actual fee is not known at signing. A reasonable approach is to pass a consistent placeholder value that reflects how the firm internally weights a pedestrian case relative to other case types. The purpose is not accounting. The purpose is giving Meta a signal that distinguishes a signed pedestrian accident case from a signed fender-bender case if your firm runs campaigns for both.
Do not pass a specific dollar amount that represents a settlement estimate or case outcome prediction. Pass a value your firm assigns internally for campaign prioritization purposes. And never state case values to prospective clients or in your ads.
Mapping CRM Stages to Meta Events Without Double-Counting
The risk with firing multiple events is counting the same conversion twice and inflating your reported numbers. Here is how to prevent that.
Your CRM should have discrete pipeline stages that map one-to-one with your Meta events:
- Inquiry created maps to
Lead - Retainer signed maps to your custom
Retainedevent
Each stage should trigger the corresponding event exactly once. The safest implementation fires the Meta event from the CRM, not from the website. When a staff member moves a contact to "Retainer Signed" in your CRM, that action triggers a CAPI call. The CRM is the source of truth, not a pixel on a thank-you page.
If you also have a pixel firing a Lead event on your form submission page, you now have two systems that can fire the same event. Deduplicate by passing the same event_id from both the pixel and the CAPI call. Meta uses the event_id to identify and suppress duplicate events, per the deduplication logic described in Meta's CAPI documentation.
Handling the Lag Between Ad Click and Signed Retainer
Meta's Conversions API lets law firms send offline events, including a signed retainer recorded weeks after the original ad click, back to the platform.
A pedestrian accident case does not sign the same day the ad runs. There is intake, evaluation, sometimes a meeting, sometimes a waiting period while the potential client considers their options. The gap between click and signed retainer can be a few days or several weeks.
Meta's CAPI accepts events after they occur, even if they happen well after the click. The key requirement is that the event includes enough matching parameters for Meta to connect it to the original user. The most reliable of those parameters is the fbclid, the click ID that Meta appends to your landing page URL when someone clicks your ad.
Every lead must carry the same click ID from the moment the ad is clicked through every CRM stage, so Meta can match the signed-case event back to the original ad.
Your intake system must capture the fbclid at the moment the form is submitted and store it in the CRM record. When the retainer is signed and you fire the Retained event via CAPI, that fbclid travels with it. Meta matches the click to the signed case.
If your intake form does not capture hidden fields including fbclid, the matching rate for your offline events will be low, and the algorithm improvement you are trying to create will be limited. That is a form configuration issue, and it is worth fixing before anything else.
Meta also uses personal information parameters (email, phone, first name, last name) for event matching when the fbclid is not available. These must be hashed using SHA-256 before they are sent, per Meta's requirements. A properly configured CAPI integration handles hashing automatically.
What Changes in Meta's Algorithm Once It Sees Real Case Value
Meta's ad delivery system uses the optimization event you choose as its primary signal for who to show your ad to next. When you switch from optimizing for Lead to optimizing for your custom Retained event, the system recalibrates.
This recalibration takes time. Meta's ad delivery requires a sufficient volume of optimization events within a given period for an ad set to exit the learning phase and stabilize. For a pedestrian accident firm running one or two campaigns, signed retainers arrive more slowly than form fills. That means it may take longer to accumulate the events needed for stable delivery, compared with a high-volume consumer product campaign. Per Meta's documentation on the learning phase, each ad set needs enough optimization events to exit learning, and the count applies at the ad set level, not the campaign level.
One practical implication: if your pedestrian accident campaign runs at low volume, you may need to consolidate ad sets rather than fragment them by audience or creative. Fewer ad sets, each accumulating retainer events faster, will stabilize more quickly than many ad sets each starving for signal.
The other change is in the value-based signals. If you are passing case value as a parameter on the Retained event, you can eventually test value-based bidding, which tells Meta to seek not just signed cases but higher-value signed cases. For pedestrian accident cases specifically, this is useful if your firm handles a range of case types and you want Meta to prioritize traffic that looks like your higher-value pedestrian clients.
Audit Checklist Before You Trust the New Signal
Before you shift your campaign optimization from Lead to Retained, confirm the following.
1. fbclid is captured and stored.
Pull five recent CRM records for signed pedestrian accident cases. Check whether each record has an fbclid value. If it is missing, your form is not capturing the hidden field and the CAPI matching rate will be low.
2. Events are firing from the CRM, not the thank-you page.
A thank-you page pixel fires when the form is submitted, not when the retainer is signed. The Retained event must come from the CRM at the moment the stage changes.
3. Deduplication is in place.
If you have both a pixel and a CAPI call that could fire the Lead event, confirm that both carry the same event_id for the same submission. Check Events Manager for duplicate event counts.
4. The event name is consistent.
A custom event named PedestrianCaseRetained in one ad account and RetainedCase in another cannot be compared or consolidated. Name events consistently across every campaign in the account.
5. Attribution window settings are understood.
Meta Events Manager lets you configure the attribution window for reporting. Check your current setting and understand that any change you make applies to conversions going forward. [SPEAKABLE] Attribution-window changes in Meta Events Manager apply to future conversions, not to conversions already recorded. Historical reporting reflects the window that was active when those conversions were processed.
6. Value parameters match your internal case-weighting logic.
If you are passing a value on the Retained event, confirm that your team has agreed on what value to pass and that it is consistent across every signed case of the same type. Inconsistent values will confuse the algorithm and produce unreliable value-based delivery.
How This Connects to the Full Acquisition System
The conversion signal is one layer of a larger system. The ad produces the click. The qualifying page screens the inquiry. Intake qualifies the case. The CRM records the retainer. CAPI sends the retainer event back to Meta. The algorithm uses that event to find more people who sign retainers, not just people who fill out forms.
Each layer depends on the one before it. A strong signal sent back via CAPI cannot fix an intake process that never closes. An intake team that closes every call cannot fix an ad that reaches people with no pedestrian accident case. And a well-targeted ad cannot fix a qualifying page that lets every inquiry through without screening.
If you want to see how this system maps to your specific pedestrian accident campaigns, the RGDM Meta Ads service page walks through the full structure. The conversion tracking service page covers the CAPI implementation in detail, including the CRM automation layer that fires the offline events automatically. You can also see how this was applied for a real firm at the Nordanyan Law case study.
If you fire only one event, fire the retained event, not the form fill.
Frequently Asked Questions
What is a conversion signal in Meta ads?
A conversion signal is an event you send to Meta that tells the platform what happened after someone clicked your ad. It can be a form submission, a phone call, a scheduled appointment, or, in the case of a law firm, a signed retainer. Meta uses these signals to train its delivery algorithm to find more people who take the same action.
How do law firms report case outcomes to Facebook?
Law firms use Meta's Conversions API (CAPI) to send offline events, such as a signed retainer, back to the platform. The event includes matching parameters (the click ID captured at form submission, along with hashed personal information) so Meta can connect the signed case to the original ad click. The event is typically triggered automatically when a CRM stage changes to "Retained."
Why does Meta need offline conversion data?
Meta's pixel only captures events that happen in the browser, meaning it can record a form submission but not a retainer signing that happens days later in your office or over the phone. CAPI fills that gap by letting you send server-side events from your CRM after they occur, giving the algorithm a complete picture of which clicks resulted in actual signed cases.
What happens if you only optimize for form fills?
If your campaign optimization event is a form submission, Meta's algorithm trains toward the type of person most likely to submit a form. For a pedestrian accident firm, that population includes many people whose cases will not qualify, who will not be reachable by intake, or who will not sign. The algorithm has no way to distinguish those form fills from the ones that become retained cases because you have not given it that data.
How long can the gap be between an ad click and the conversion event I send?
Meta's CAPI accepts events that occur after the click, including events that arrive days or weeks later. The practical limit is Meta's attribution window setting in Events Manager. As long as the retainer is signed within the active attribution window, the event can be matched to the click. Check your current window setting in Events Manager and confirm it covers the typical lag between ad click and retainer signing for your pedestrian accident intake process.
Do I need to send the actual settlement value of the case?
No. For a contingency case, the final fee is not known at signing. The value parameter you pass with the Retained event is for campaign optimization purposes, not accounting. It should reflect how your firm internally weights this case type relative to others. Never pass a figure that represents a settlement estimate or a prediction of case outcome, and never communicate case values to prospective clients through your ads or intake process.
What is deduplication and why does it matter for CAPI?
Deduplication prevents Meta from counting the same conversion twice when both a browser pixel and a CAPI server call fire for the same event. Both calls should carry an identical event_id value for the same submission. Meta's system uses that shared ID to recognize the duplicate and count the event only once. Without deduplication, your reported conversion counts will be inflated, and the algorithm will receive a distorted signal.
Can I run this setup myself or does it require a developer?
Configuring CAPI with CRM-triggered events, hidden field capture for fbclid, SHA-256 hashing, and deduplication across pixel and server calls does require technical implementation. Many CRM platforms have native CAPI integrations or supported connectors that reduce the custom development needed. But the mapping of CRM stages to event names, the case-value logic, and the audit process described above still require someone who understands both the campaign structure and the intake workflow. That combination, campaign plus CRM plus signal, is the full system, and it is what RGDM builds and manages for pedestrian accident firms. Book a free Case Acquisition Review to see what the setup looks like for your specific account.