How Facebook ads tracking works for a repair shop

When you launch a campaign, Meta doesn’t know who your customers are. It starts by showing your ad to broad slices of people in the area you target and watches what happens. Every conversion you report back, a quote request for a brake job or a booked oil change, is a training signal: this kind of person, in this context, took the action you care about.

Report nothing and it keeps optimizing for cheap clicks and video views, the things it can see on its own. Report real conversions (who visited, who asked for a quote, who booked) and the model shifts from broad categories to finding people who actually book. The quality of that feedback is the biggest lever you control.

Everything else in this guide is about making that feedback accurate: getting the booking to Meta reliably, tying it to the right person, and making sure your ad gets the credit.

A conversion event can reach Meta by two paths. The browser path fires the Meta Pixel: JavaScript on your shop’s website sends the event straight from the visitor’s browser. It’s easy to set up, but it’s the fragile path. Ad blockers, tracking prevention (ITP), and people leaving before the script loads all quietly drop events.

The server path uses the Conversions API (CAPI). Your own server sends the event to Meta directly, so browser blockers never see it, and it fires even when the visit was too short for a pixel to load. It’s more work to build, but it’s the reliable path, and it’s where a booking the browser missed can still get through.

The strongest setups send both and deduplicate: the same event goes out from the browser and the server with a shared event ID, Meta keeps one copy, and you get the browser’s detail plus the server’s reliability.

A booking is only useful to Meta if it can tie it to a person. It does that by matching the identifiers you send against its own graph of users, a process it scores as Event Match Quality. The more (and stronger) the identifiers, the higher the score, and the more conversions get attributed instead of thrown away.

You don’t send raw personal data: strong identifiers like email and phone are hashed before they leave your server. But when a customer books a diagnostic and leaves a phone number and email, the difference between sending just an IP address and sending a hashed email, phone and name is the difference between a coin-flip match and a near-certain one.

When someone taps your ad, Meta adds a click ID (fbclid) to the address of the page it opens. Your pixel reads it and stores it as the fbc cookie; a separate fbp cookie identifies the browser itself. When the booking comes in, sending that click ID back is what tells Meta “this job came from that ad.” It’s how your ad earns the credit.

The catch is that the tap and the booking often don’t happen at the same moment. A driver taps your ad on their phone at lunch, thinks about the grinding noise their brakes are making, and books from a laptop three days later. If the click ID wasn’t captured and stored server-side at the moment of the tap, there’s nothing to send back later, and the booking looks organic even though your ad paid for it.