Send Offline Conversions to Facebook: Contractor Guide
To send offline conversions to Facebook, connect eligible business outcomes to Meta through a supported integration such as Conversions API. Your CRM, booking, call, or payment system supplies the actual outcome. The integration maps and delivers the event; Meta’s diagnostics help you check what arrived.
For contractors, offline often means the decision happened after the website visit: a dispatcher qualified an inquiry, a homeowner booked an estimate, or a completed job was paid. A web Pixel alone does not know those things occurred.
On this page
- Choose the outcome you can record reliably
- Map the record before connecting the platform
- Preserve the link to the original inquiry
- Choose and test the delivery path
- Send mapped outcomes through the free open-source software
- Handle duplicate records and revenue carefully
- Verify four different results
- What should the contractor review each week?
Choose the outcome you can record reliably
Start with one stage your team maintains consistently. If salespeople update won jobs once a month but dispatchers record appointments immediately, those stages have different timeliness and operational value.
| Outcome | Good source record | Required business definition |
|---|---|---|
| Qualified call | Call or CRM record with a reviewed status | Serviceable customer requesting eligible work |
| Booked estimate | Confirmed booking record | Appointment accepted, not merely proposed |
| Won job | Accepted job or deal record | A defined sale milestone |
| Payment | Completed payment record | Collected amount and treatment of adjustments |
Use the actual source record and timestamp. Do not turn every old contact in a database into a new conversion. The first-party data guide explains how to preserve origin, identifiers, and permissions.
Map the record before connecting the platform
Your implementation specification should identify the source system, contact identifier, event-specific ID, event time, status, and value if applicable. It should also define how to distinguish a new action from a correction or repeated delivery.
Map business stages to event names supported by your chosen integration and campaign use case. Do not invent a standard Meta event name because it sounds like a CRM stage. Have the implementation owner confirm accepted names and action sources in the current documentation.
Keep sensitive notes, unnecessary job details, and unrelated fields out of the payload. Pass only information appropriate to the intended purpose and destination. A server connection changes how data travels; it does not establish permission to send every field in the CRM.
Preserve the link to the original inquiry
An illustrative HVAC journey might start with a Facebook visit on Monday, an estimate booking on Wednesday, and a payment three weeks later. Retain the relevant visit, inquiry, customer, appointment, job, and payment IDs so each link can be inspected.
Matching two records on an email or phone number can support a customer link, but it does not establish that two different jobs are the same sale. Shared household details, repeat business, and corrected contact information require explicit handling.
Keep unknown links visible. If a payment cannot be connected to an eligible inquiry, do not fill the source field with the campaign you expected to receive credit.
Choose and test the delivery path
A CRM-native connection, a managed provider, or a direct server integration may fit. Meta’s CRM lead-quality training describes using CRM data with Meta advertising. Verify your specific CRM, plan, stage mapping, and destination access before treating the path as complete.
Use authorized test records and the destination’s test tools. Inspect the accepted source outcome, the queued event, the outbound payload, the response, and the corresponding destination diagnostics. Fix errors at the layer where they occur.
For the broader setup, follow Meta CAPI for home services. If a vendor is providing the integration, use the software evaluation scorecard to assign ownership for monitoring and repairs.
Send mapped outcomes through the free open-source software
PipelineOn open source accepts normalized outcomes through an authenticated API and can explicitly queue eligible ones for Meta. A backend, CRM HTTP action or trusted automation relay supplies the connection. This is a generic mapped integration, not a bundled native login for every CRM.
Carry stable source and activity IDs, original occurrence time, authoritative revision time and the accepted visitor session reference where available. For Meta, include permissioned customer-provided matching fields and the actual conversion context. The software’s supported mappings include payments, bookings, forms and explicitly qualified calls; unsupported or incomplete records receive visible stopped reasons.
The open-source software is free to self-host. Infrastructure and operating effort remain separate, and PipelineOn-hosted is planned at around $20/month; final pricing, included usage and availability are still being finalized. Use the cost guide and server-side shortlist to compare ownership.
After any outbound attempt, a changed conversion requires review. Retained accepted receipts do not mean a later refund, correction or deletion was applied in Meta; handle the required downstream change separately.
Handle duplicate records and revenue carefully
The same webhook can arrive more than once. A customer can also make several legitimate payments. Those situations need different treatment: repeated delivery of one action retains its stable identifier, while a new action receives a new one.
For an illustrative $12,000 job with a $3,000 deposit, decide whether the conversion value represents the signed job or collected payments. Reporting a $3,000 deposit and then the full $12,000 as additional collected revenue would overstate receipts. Document how cancellations, refunds, and changes are handled by your chosen connection.
If the browser already reports the same action, coordinate the name and ID for deduplication. A later offline outcome is not automatically a duplicate of the original lead. The Pixel versus CAPI guide covers that distinction.
Verify four different results
First, verify delivery: did the correct event arrive without a rejected payload? Second, inspect matching diagnostics: did it carry usable identifiers? Third, inspect reporting and campaign settings: is the event eligible and being used as intended? Fourth, measure the business result: did qualified appointments or profitable jobs improve?
These are separate checks. A successful API response does not guarantee ad attribution or performance lift. Missing identifiers should lead to a match-quality investigation, not fabricated data.
What should the contractor review each week?
Review the count of eligible outcomes in the source system, excluded records, delivered events, failures, and delays. Sample a few records from each category. Compare job and payment totals with the system your business considers authoritative.
Then evaluate qualified-lead rate, estimate attendance, cost per won job, and a consistent revenue measure. Keep the Pixel improvement checklist nearby for problems that begin on the website. Talk with PipelineOn about how homeowner visitor evidence fits into your overall tracking workflow.
View the open source and compare the self-hosted and PipelineOn-hosted options.
Written by
PipelineOn Research Team