Meta pixel and Conversions API: a privacy-safe setup for service businesses

The short answer: send fewer, better events

The Meta pixel is code in your website that tells Meta when someone does something on your site, such as viewing a page or sending an enquiry. The Conversions API does a similar job from your server or your CRM instead of the visitor's browser. Meta recommends running both together and calls this a "redundant setup", as long as you stop the same event being counted twice.

For most service businesses, the useful version of this is small. Send one clean event when an enquiry is genuinely received, add a booked appointment or a won job later if your systems can, and leave out anything that reveals more about the person than Meta needs to know. That gives your campaigns better signals without turning your website into a data feed.

The privacy side has also moved. The OAIC published tracking pixel guidance in November 2024, and in June 2026 the Privacy Commissioner found that two health providers had interfered with people's privacy through their pixels. The OAIC says the business that deploys the tracking is responsible for configuring it lawfully, and that the platform has its own obligations too. You can't hand that responsibility to your developer.

What the pixel and the Conversions API each do

Both send events to the same place in Meta, a dataset, which should sit in a business portfolio you own. Meta says server events are "processed like events sent using the Meta Pixel", so they can be used for measurement, reporting and ad optimisation in the same way. The difference is where the event comes from and what it can know.

If you already have a pixel, Meta says you can set up the Conversions API for website events "in one click from Meta Events Manager, with no code, configuration, or setup fees." A custom integration from your own server or CRM takes more work, and it's only worth it if it sends something the one-click version can't.

In short:

• The pixel runs in the visitor's browser and reports what happens on the page, such as a page view or a form submission.
• The Conversions API sends events from a system you control, such as your website server, booking tool or CRM.
• Because it comes from your systems, a server event can report things the browser never sees, such as whether an enquiry became a booked job.

Keep readingMake sure your business owns the Meta dataset

Choose events that match real enquiries

Start with the decision you want Meta to optimise for. For a service business that's usually a completed enquiry, not a click on the Contact button and not a visit to the thank-you page by someone who bookmarked it. Fire the Lead event when your website has actually accepted the form, so that failed or spam submissions don't train your campaigns.

Keep the event and its details plain. Meta's Business Tools Terms say the names and criteria you choose for your events, conversions and custom audiences "must not reflect, imply or be based on" sensitive categories, which include health and financial information. An event called Lead is fine. An event called Anxiety counselling enquiry, or one carrying a loan amount or a medical condition, isn't.

Watch the address bar as well as the form. Some forms put what people typed into the web address of the next page, and a pixel can pass full page addresses to Meta. If your thank-you page shows a name, phone number or service detail in its URL, fix the form before you add more tracking.

If you send both, give every event one ID

When the pixel and the Conversions API both report the same enquiry, Meta needs a way to know it's one enquiry, not two. Its recommended method is to send the same event name and the same event ID from both. In the pixel, the ID goes in the fourth part of the tracking call, for example fbq('track', 'Lead', {}, {eventID: 'EVENT_ID'}). The Conversions API then sends the matching event_id.

Meta says that if it receives the same event name and ID within 48 hours, "we discard the subsequent events." Without that ID, your reports can show more leads than you really received, and your campaigns optimise against inflated numbers.

You don't need deduplication for events you only send one way. Meta says advertisers who don't send the same event twice through both channels "do not need to set up deduplication for those events." If you add a booked-job event from your CRM that the pixel never sees, it simply needs its own name.

Send outcomes from your CRM, if you have the volume

The biggest gain from the Conversions API often comes from your CRM rather than your website. Meta's CRM integration lets you send later lead stages back to Meta, such as contacted, quoted or won, so it can look for people more likely to become customers rather than people who simply fill in forms. Meta says it is a separate integration from your website setup, and that its Conversion Leads performance goal "is currently only compatible with Facebook/Instagram's Lead Ads (Instant Forms)."

Check the fit before you commission the work. Meta's guidelines for a good fit include generating at least 200 leads per month, uploading data at least once per day, the stage you want to optimise for happening within 28 days, and that stage having a conversion rate between 1% and 40%. Meta estimates a developer build at 3 to 4 weeks, or less than a day through Zapier or another partner, followed by a learning period of 2 to 4 weeks.

Many small service businesses won't reach 200 leads a month. If yours doesn't, the useful step is still to record clear lead stages in your CRM now, so you can judge campaigns on outcomes yourself and are ready if volume grows.

Keep readingDefine which enquiries count as qualified

Keep readingCompare Meta instant forms with landing pages

What Australian privacy rules expect from tracking tools

First, check whether the Privacy Act covers your business. The OAIC says most small businesses, those with annual turnover of $3 million or less, aren't covered. Some are regardless of turnover, including health service providers and businesses that trade in personal information, which the OAIC describes as disclosing personal information for a benefit, service or advantage. Whether sharing customer data with an ad platform falls into that is a question for your lawyer, not your developer.

If you are covered, the OAIC's tracking pixel guidance sets out what it expects. It says the Privacy Act doesn't prohibit tracking pixels, but it's "the responsibility of the organisation" deploying one to make sure it's configured and used lawfully. The OAIC also says that where it's unclear whether pixel data is personal information, organisations should "err on the side of caution" and comply. Even if you aren't covered, Meta's terms still require you to have a lawful basis for the data you send and prohibit sending health and financial information.

The main expectations:

• Collect the minimum. Configure the pixel to share only what you need, and consider running it only on certain pages rather than the whole site.
• Tell people at the time. A privacy policy alone doesn't meet the APP 5 notification duty; the OAIC gives a banner or pop-up on the first visit as an example.
• Let people opt out of retargeting. Using pixel data to target people with ads is direct marketing under APP 7, which needs a simple way to opt out.
• Know where the data goes. If the platform sends it overseas, APP 8 requires reasonable steps to make sure the overseas recipient doesn't breach the APPs.
• Keep sensitive information out. The OAIC expects sensitive information to be shared through pixels only in limited circumstances and with express consent.
• Review it regularly. The OAIC says due diligence shouldn't be a "set and forget" approach.

Keep readingCheck the privacy basics for your enquiry forms

What the June 2026 decisions changed

On 24 June 2026, the OAIC announced two determinations finding that Medmate, a telehealth provider, and Monash IVF had interfered with the privacy of people whose sensitive information was collected through third-party tracking pixels. The Commissioner found that tracking visitors to health-related websites and then targeting them with social media ads amounts to a collection of sensitive information, for which the website provider must obtain consent.

Law firm Allens' summary of the decisions describes how ordinary features caused the problem. Page addresses sent through the pixels sometimes included health conditions or medication sought, and an advanced matching feature that links visitors to platform profiles was active on one site. Allens also reports that the Commissioner treated people as identifiable if they could be singled out and treated differently, even when the business didn't know who they were, and that a generic cookie banner was not enough where sensitive information was collected.

These decisions concerned health providers, and Allens notes the Commissioner has acknowledged they're likely to go to appeal or review. The practical lesson travels further: what your pages are called, what your forms ask and which matching features are switched on can say more about a person than you intended.

Hashing helps, but it isn't anonymity

When you send names, emails or phone numbers through the Conversions API, Meta requires them to be hashed with SHA-256 first, and says its systems are designed not to accept unhashed contact information. Hashing turns an email address into a long string of characters, so the raw address isn't sent. Meta's terms say its JavaScript pixel hashes contact information before sending it.

That protects the raw details in transit, but it doesn't make the data anonymous. The point of hashing here is matching: Meta compares the string with the hashed details of its own users. The OAIC gives a hashed email address as an example of information that can make someone reasonably identifiable once it is matched with other information the platform holds. Treat hashed data as personal information, and send only the identifiers you've told people about.

Worked example: a plumber's tracking clean-up

Here's a made-up example. A plumbing business in Ballarat runs Meta ads to its website. Its pixel is on every page, and its quote form sends people to a thank-you page whose address includes their name and suburb. Reports show about 40 leads a month, but the office counts closer to 25 real enquiries.

The fixes are modest. The form is changed so nothing the customer typed appears in the web address. The Lead event now fires only after the website accepts the enquiry, and the server sends the same Lead with a matching event ID and a hashed email and phone number, so each enquiry counts once. The privacy policy names Meta and explains the tracking, a short notice appears on the first visit with a way to opt out of ad tracking, and the owner checks the setup every quarter.

At 25 enquiries a month, the business is well short of Meta's 200-lead guideline for CRM optimisation, so it records quoted and won jobs in its CRM and compares campaigns on those itself. If the same business were a counselling practice, the OAIC's advice points the other way: where visiting a site could reveal sensitive information, it may be preferable to avoid third-party pixels altogether.

A tracking setup checklist

Work through this with whoever manages your website and ads before adding new events:

• Confirm your business owns the Meta dataset and who can change it.
• Fire the Lead event only when an enquiry is actually accepted.
• Give each event that's sent from both browser and server the same name and event ID.
• Keep names, phone numbers and service details out of page addresses.
• Name events plainly, with nothing that implies health, financial or other sensitive details.
• Hash contact information before it's sent, and send only identifiers you've disclosed.
• Check whether the Privacy Act covers your business, and get advice if you're unsure.
• Show a notice on the first visit and update your privacy policy to name the tracking tools.
• Give people a simple way to opt out of ad tracking.
• Review the setup every quarter and whenever the site or forms change.