Helping Nightingale Connect reach the NDIS participants who need nurse-led care
- Lifted Meta's Health & Wellness restriction
- Every enquiry sent to Meta as a clean Lead, tied to its ad
- One setup the agency now runs across its NDIS clients
- Industry:
- NDIS provider
- Website:
- WordPress
- Restriction:
- Health & Wellness
- Product:
- Unrestrict by Zappush
- Agency:
- Agency partner
Nightingale Connect is a registered, nurse-led NDIS provider in Brisbane. An enquiry on its site says the person, or someone they care for, lives with a disability, and Meta's Health & Wellness restriction followed. Through the agency that runs its marketing, Zappush lifted the restriction and sends every enquiry to Meta as a Lead with nothing in it that describes a condition, so the campaigns can find the participants who need the care.
The story
Nurse-led support for people with complex needs, funded by the NDIS
Nightingale Connect is a registered NDIS provider in Brisbane delivering nurse-led support: supported independent living, specialist disability accommodation, high-intensity care such as tracheostomy, PEG feeding and catheter management, community nursing, palliative care and group programmes. Participants and their families enquire through the website, and the team builds a personalised care plan. The site runs on WordPress and its Meta campaigns are run by an agency that manages several NDIS providers.
The work
Two problems. Two fixes.
An enquiry form with a dropdown for High Intensity Support or Palliative Care tells Meta what the person needs. Meta classifies nightingaleconnect.com.au as Health & Wellness and blocks the Lead events campaigns learn from. And the agency behind it had the same problem on every NDIS provider it managed.
The category restriction
Meta had classified nightingaleconnect.com.au as Health & Wellness and was blocking Lead and the events under it. Zappush lifted the restriction in Events Manager and now delivers every event through the Conversions API with the page path, service and anything that implies a disability removed. The WordPress site did not change.
ID
Data sharing restrictions applied
One or more websites or apps are in categories with data sharing restrictions. Specifically, certain standard events are blocked, and your data source(s) are in a core setup. If you think the categories haven't been applied appropriately, you can request a review. About the restrictions
See other tasks
The enquiry is the conversion, and the enquiry is the diagnosis
There is no checkout. The conversion is a form with a name, a phone number and the service the person needs. Every field but the identifiers is health information. Zappush sends the Lead to Meta with the hashed name, email and phone that let Meta match it, and drops the service, the message and the page it came from. Meta gets a lead it can optimise for, never what the person asked for.
What Meta receives
Restricted context removed. Match keys kept.
Our impact
What Zappush made possible
Nightingale Connect now runs unrestricted on Meta, with every enquiry attributed to its ad and nothing in any event that names a disability or a service. Campaigns learn from real enquiries again, and the agency applies the same setup to every NDIS provider it manages.
Health fields in any event sent to Meta
Of each enquiry still reaching the care team
Changes to the WordPress site
The technical detail
The category restriction
- What it looked like
- Meta had restricted nightingaleconnect.com.au under Health & Wellness. Lower-funnel events were blocked before campaigns could optimise on them.
- Why the usual fixes fail
- Renaming events, switching to CAPI or opening a new Pixel does not change the classification. It is attached to the domain and to what each event contains. A Lead that carries a path like /services/high-intensity-care or a form value naming a service stays restricted, whatever it is called.
- What Zappush built
- Every event passes through the Zappush container before delivery. Page paths, form values, query parameters and referrers are removed on the server. Permitted identifiers are hashed. Event IDs are kept. The clean event goes to Meta through the Conversions API, and acceptance is verified.
- What it restored
- Meta accepts Lead again and optimises on it. No pixel violations. No account warnings. The site and its enquiry form did not change.
The enquiry is the conversion, and the enquiry is the diagnosis
- What it looked like
- Every enquiry carried the service selected and the page it was sent from. The Pixel sent all of it with the Lead event.
- Why the usual fixes fail
- A browser Pixel sends what the form and page contain. The only browser-side fix is to strip the service from the form, which is the one thing the team needs to route the enquiry.
- What Zappush built
- Form submissions go to Zappush server-side. Name, email and phone are hashed for matching. Service, message, page URL and referrer are removed. The Lead goes to Meta through the Conversions API with a shared event ID, and the full enquiry still reaches the team unchanged.
- What it restored
- Matched Lead events with nothing in them that names a disability or a service. The team sees every enquiry in full.
Selling in a restricted category?
See what the same setup would restore for you. Free audit, 30 seconds, no signup.