On 24 June 2026 the Privacy Commissioner published two determinations and an inspection report that should change how every Australian business thinks about the analytics on its website. Medmate Australia and Monash IVF were found to have interfered with privacy by collecting sensitive information through third-party tracking pixels. The accompanying scan of 50 health-service websites found that 96% used tracking technologies, 52% used a third-party tracking pixel, and of those, 77% did not mention the pixel in their privacy policy (VERIFIED, OAIC blog, 24 June 2026).
The lesson is not “stop measuring your website”. It is narrower and more useful: the risk was never in counting visitors. It was in handing the count, and everything riding with it, to a third party nobody had disclosed.
This article sets out what the Privacy Act actually asks of a business website, and the three design choices that answer it. We practise what it describes, and the last section says exactly what this site runs.
This site runs the kind of setup this article recommends, on an analytics instance operated by Skaffold, a business related to this site's publisher. We have no affiliation with Matomo or any other analytics vendor named here, receive no payment or referral fee from any of them, and name products only as examples of an architecture. Nothing in this article is an endorsement of a product, and the same design choices are available with other tools.
What the Privacy Act asks of a website
The Privacy Act 1988 does not regulate cookies, pixels or analytics tools by name. It regulates personal information, and the Australian Privacy Principles (APPs) attach to any website that collects it. Four of them do most of the work:
- APP 1 — a clearly expressed, up-to-date privacy policy. The policy must say what kinds of personal information you collect, how you collect and hold it, and why (VERIFIED, APP 1 guidelines v2.0, paras 1.2 and 1.15). The guidelines also say entities are better placed to comply when they “embed privacy protections in the design of their information handling practices” (VERIFIED, para 1.3). That phrase is the whole argument of this article.
- APP 5 — tell people at or before the point of collection. The guidelines specifically say individuals should be told about a collection method they may not know about, giving “software (such as cookies)” as the example (VERIFIED, APP 5 guidelines, para 5.11).
- APP 3 — collect only what is reasonably necessary, and fairly. The OAIC’s pixel guidance states that “collecting personal information covertly without the knowledge of the individual is likely to be an unfair means” of collection, and tells organisations to “adopt a data minimisation approach” (VERIFIED, OAIC tracking-pixel guidance, 4 November 2024).
- APP 8 — overseas disclosure. If a third-party provider sends the data offshore, you must take reasonable steps to ensure the recipient does not breach the APPs (VERIFIED, same guidance).
One more piece matters. The OAIC’s own key-concepts guidance says analytical information collected from cookies, such as the number of times a page was visited, “will not be personal information under the Privacy Act unless an individual is reasonably identifiable” (VERIFIED, APP guidelines Chapter B, footnote 14). Whether someone is reasonably identifiable is an objective test that turns on what other information is held or available, and where it is unclear the OAIC says to treat the data as personal information.
Put those together and the question a website owner should ask is not “do I need a cookie banner?” It is: does my analytics make a visitor reasonably identifiable, who receives the data, and have I said so?
A note on banners. Australia has no equivalent of the EU’s ePrivacy consent rule for cookies; the banner you see on most sites is a European artefact. The Privacy Act’s test is about identifiability and disclosure, not about whether a cookie was set (INFERRED: the Act and the OAIC’s pixel guidance never mention cookie consent; the guidance does not refer to cookies at all). A banner is not a substitute for a privacy policy that tells the truth, and it is not required where the data is not personal information.
Three design choices that take most of the risk off the table
1. First-party: your analytics talks only to you
The determinations above were all about third-party pixels: scripts that send browsing data to a platform that also knows who the visitor is on its own service. That is what turned “page views” into sensitive information about someone’s fertility treatment.
A first-party setup means the tracking script is served from your own domain and the data lands on infrastructure you control, or a provider that processes it only for you. No advertising platform receives it. No cross-site profile is enriched. The APP 8 overseas question becomes answerable, because you know where the server is.
This is the single biggest change, and it is available with self-hosted or privacy-first analytics tools. Matomo (what this site runs), Plausible, Fathom and Umami all support it; the point is the architecture, not the brand.
2. Cookieless: nothing is stored on the visitor’s device
Most analytics tools set a first-party cookie to recognise the same browser on its next visit. Matomo’s documentation describes a setting that disables those cookies entirely and counts visits from the request itself instead (Matomo FAQ, “How do I go cookieless”). Other tools in this class are cookieless by default.
What you give up is honest to state: returning-visitor counts and some multi-session attribution become less accurate, because the browser is not being remembered between days (Matomo FAQ on report accuracy). What you keep is everything a content or lead-generation site actually decides on: which pages are read, where visitors arrive from, which downloads are taken, which searches return nothing.
What you gain is that the analytics now sits inside footnote 14: aggregate counts, no persistent identifier, no reasonable path back to a person. There is nothing to opt out of, so there is nothing to ask consent for.
3. A tag-manager container: one inventory of everything that runs on your site
The 77% figure above is the number to remember. Those organisations did not set out to hide a pixel. Someone in marketing added it, and the people who wrote the privacy policy never knew. That is a governance failure, and it is the failure APP 1.2 is aimed at: “practices, procedures and systems that will ensure the entity complies with the APPs” (VERIFIED, APP 1 guidelines, para 1.4).
A tag-manager container is the website version of that system. Every script that runs on the site is declared as a tag, with a trigger that says when it fires and a version history that says who changed it and when. Matomo’s Tag Manager guide describes the model: tags, triggers and variables held in a container, edited as drafts, tested in a preview mode, then published as a numbered version that can be rolled back (Matomo Tag Manager guide). Google’s tag manager works the same way.
Why that matters for privacy rather than just for tidiness:
- The container is the inventory. When you update the privacy policy, you open the container and read the list. There is no “we didn’t know it was there.”
- Publish is a review gate. A new tag sits in draft until someone with the authority to publish checks it against the policy. The rule is simple: nothing is published that the privacy policy does not already describe.
- Pause beats delete. A tag can be switched off instantly when a provider changes its terms, without a code deployment.
Two warnings. First, a container only helps if the container itself is first-party. A tag manager loaded from a third party’s domain is, by definition, a third-party script with permission to add more. Self-hosted tag managers, Matomo’s included, serve the container from your own domain. Second, a tag manager makes it easy to add scripts, which is exactly how the 77% happened. The control is the publish step, not the tool. Give publish rights to someone who has read the privacy policy.
What to write in your privacy policy
APP 1.4 lists what a privacy policy must cover. For analytics, that comes down to four plain sentences:
- What you collect. “We collect aggregate analytics about how this site is used: pages viewed, referring site, approximate region, browser type, searches and downloads.”
- How. “This is collected by a first-party analytics script served from our own domain. It sets no cookies and stores no identifier on your device.”
- Who receives it. Name the tool and who operates the server. If the data leaves Australia, say so and where.
- What you don’t do. “We do not share browsing data with advertising or social-media platforms, and we do not use tracking pixels.”
If any of those sentences would be untrue for your site today, that is your to-do list, not a drafting problem.
What this site does
In the spirit of APP 1, here is our own disclosure. SecurityPolicy.com.au runs Matomo, self-hosted, served first-party from this domain, with cookies disabled. It records page views, the referring site, site-search terms and their result counts, which starter-pack downloads are taken, and whether the download form was submitted. Requests made by AI assistants fetching a page on someone’s behalf are counted on the server, since those agents run no scripts. It sets no cookies and stores nothing on your device beyond your light-or-dark theme preference. Nothing is sent to an advertising or social platform, and there are no tracking pixels. Cloudflare, which hosts the site, processes standard request logs for security the way any host does.
We do not currently use a tag-manager container, because the site runs exactly one script and it is wired by hand. A container earns its keep the day a second tag appears, and that is the day we would add one.
The full statement is on our cookie policy and privacy policy pages, which were updated to match this article.
The checklist
- List every script on your site. View source, or open your tag container. If you cannot produce the list in ten minutes, that is finding number one.
- Classify each one as first-party or third-party, and note where its data goes.
- Remove any third-party pixel your privacy policy does not name, or name it. The OAIC’s June 2026 findings make “we didn’t mention it” the worst of the available positions.
- Move analytics to a first-party, cookieless setup if your decisions do not depend on recognising returning browsers. For most content and lead-generation sites they do not.
- Put the remaining scripts in a container served from your own domain, and give publish rights to one person who owns the privacy policy.
- Rewrite the analytics paragraph of your privacy policy using the four sentences above, and diarise a re-read of the container every time the policy is reviewed.
What this article is not
This is education, not legal advice, and following it is not a guarantee of compliance with the Privacy Act or any other law. Whether the Act applies to your business at all, and what it requires of your website, depends on your turnover, your sector, the data you handle and the contracts you hold. A first-party, cookieless setup reduces what you collect; it does not change your obligations for whatever you still collect, including the details people type into your forms. If your website collects health, financial or other sensitive information, or your business is inside a regulated sector, have a qualified adviser check the policy wording.
Statements about how analytics and tag-manager tools behave are drawn from the vendors’ own documentation as at the article date; products change, and the documentation linked in the sources is the authoritative description. The OAIC findings cited here concern specific entities and facts, and the Commissioner’s determinations are the authoritative record of what was decided.
Our Privacy Act reforms guide tracks the broader changes, including the automated decision-making disclosure that lands in privacy policies on 10 December 2026.
Sources
- OAIC — Privacy Commissioner finds privacy breaches in third-party tracking pixel investigation (24 June 2026)
- OAIC — Your life, pixelated: how tracking pixels watch your every click (24 June 2026)
- OAIC — Tracking pixels and privacy obligations (4 November 2024)
- OAIC — APP guidelines, Chapter 1: APP 1 open and transparent management of personal information (v2.0, 30 September 2026)
- OAIC — APP guidelines, Chapter 5: APP 5 notification of the collection of personal information
- OAIC — APP guidelines, Chapter B: Key concepts (what is personal information)
- Privacy Act 1988 (legislation.gov.au)
- Matomo — Tag Manager user guide
- Matomo — How do I go cookieless (disable Matomo cookies) for a visitor?
- Matomo — When cookies are disabled, how does it impact report accuracy?
This article is education, not legal advice. Dates and obligations are cited to the official sources above — the linked source is the authoritative wording. See how we verify.