Tracking pixels on health sites: what the June determinations mean for your agency

If you build or manage websites for health providers, June 2026 changed the conversation you'll be having with your clients. Here's what happened, why it lands on your desk as much as theirs, and what to do about it.

What happened

On 11 June 2026 the Privacy Commissioner handed down two determinations, against Monash IVF and telehealth provider Medmate. Both involved third-party tracking pixels on their websites, and both found an interference with privacy under APP 3, APP 5 and APP 7.

Two weeks later the OAIC published Your life, pixelated, a report on an inspection of 50 health service provider websites. Nearly all used tracking technologies, and about half ran third-party pixels.

This is no longer guidance you can debate with a client. It's a regulator applying the law to sites that look a lot like the ones you build.

The three findings that matter for agencies

1. Visiting a health website can itself be sensitive information. Tracking people who visit health-related pages, then targeting them with ads, is a collection of sensitive information. Under APP 3 that needs consent. For a physio, a fertility clinic or an NDIS provider, that covers most of the site.

2. A cookie banner doesn't fix pixels. The determinations drew a clear line. A visitor can clear or block cookies themselves. A pixel fires the moment the page loads, before anyone can touch a banner. A cookie consent pop-up doesn't give valid consent for pixel collection, and it isn't sufficient notice either. Many agencies have been treating "we added a banner" as the answer. That no longer holds.

3. Nobody knew what was running. Monash IVF had pixels in place since 2012. It couldn't say when Meta Advanced Matching had been switched on, or for how long. Advanced Matching sends hashed names, emails and phone numbers from form submissions. Most agencies will recognise the pattern: a tag added for one campaign, never reviewed, still firing years later.

The Commissioner was explicit that this isn't a ban on pixels. The issue is that consent has to be properly obtained, and the deploying organisation is responsible for how its tools are configured.

Why this is your problem too

Your client carries the primary obligation, because they're the one collecting the information. But you built the thing that collects it.

If a patient complains, the first question will be what was running on the site and who put it there. If the answer is a GTM container your team manages, a pixel your team installed for a Google or Meta campaign, or a form your team built, that becomes your commercial and reputational problem, wherever the legal liability lands.

A few other points often catch agencies out:

• Health providers don't get the small business exemption. If a business provides a health service, the Privacy Act applies regardless of turnover. The OAIC's health privacy guide names gyms and weight loss clinics as health service providers too.

• Hashing isn't anonymising. A hashed email is designed to be matched against accounts the platform already holds. That's the mechanism, not a side effect.

• Meta's own terms prohibit sending it sensitive data. So a pixel on a condition page can also be a problem under your client's contract with Meta, not just the Privacy Act.

• Individuals can sue. A statutory tort for serious invasions of privacy has been in place since June 2025.

What to check across your client book

Start with the health clients where you run ads or manage the tag container. For each site:

• List what loads before consent. Open the homepage and one condition or service page with dev tools open. Note every third-party request that fires before anyone clicks anything.

• Find out where the pixels sit. Site-wide pixels send condition page views to the platform by default. The OAIC's pixel guidance suggests deploying on selected pages only. Almost nobody does.

• Check Advanced Matching and similar features. Meta Advanced Matching, Google enhanced conversions and Google Signals all change what's being sent. Know whether they're on, and since when.

• Test the banner, don't trust it. If there's a consent tool, check whether it actually holds tags back or just displays a banner over tags that are already firing.

• Write down what you advised. If a client insists on keeping something you've flagged, put your advice in writing. Agencies that get burned are usually the ones with no record of having said anything.

Turning this into a better client conversation

For a health client, "we checked what your site sends before consent, and here's the evidence" is a stronger position than "we added a cookie banner". It protects the client, and it protects the retainer.

It also gives you a reason to call every health client this quarter that isn't a sales pitch. Most of them haven't read the determinations. Being the agency that raised it first is worth a lot in a sector that talks.

How Savira helps

Savira works with agencies to put this in place across their client sites: a banner that actually holds things back, a record of who agreed to what and when, and an evidence pack showing exactly what fires before and after consent.

We work alongside your developers to design, implement and validate the setup in each client's actual environment. The validation is the part most vendors skip, and it's the part your health clients will want on file.

If you manage several health sites, talk to us about partnering. We'll run your first client site through our scanner so you can see what's firing before consent.

This is general information, not legal advice. Every business handles information a bit differently, so if you're not sure how this applies to yours, it's worth checking with a lawyer or privacy adviser.