What a Public College Actually Needs from Analytics (and Why GA4 Is Not It)

What a Public College Actually Needs from Analytics (and Why GA4 Was Not It)

Public institutions are built on trust and transparency. They answer to students, to taxpayers, and to the public that funds them. Their website analytics should be held to the same standard, and that is where the usual tools start to fall short.

Start with ownership. When analytics are supplied through an advertising company, the data lives in that company's system, under that company's rules. Retention is set by the vendor. Definitions change when the vendor changes them. If the relationship ends, the history is hard to take with you. For a private business that may be an acceptable tradeoff. For a public institution, holding records it cannot fully control is a problem in principle, not just in practice.

Then consider what an institution actually needs to know. The honest questions are simple ones. Which programs are people looking at? Are prospective students finding the application and the deadlines? Is the information the public is required to get actually being reached? None of those questions requires knowing who a visitor is. They require counts, trends, and definitions that stay the same from one semester to the next, so a number reported this year means the same thing next year.

Privacy follows from the same obligation. Students do not choose whether to use a public college's website the way a shopper chooses a store. They come because they have to. Collecting more about them than the institution needs, and keeping it longer than it needs to, is not diligence. It is exposure, for them and for the institution.

There is also a practical matter. Public institutions run lean. There is no analytics team to babysit a complex setup, rebuild reports when the tool changes, or explain to leadership why last year's figures cannot be compared with this year's. A small staff needs a system that is boring in the right ways: self-hosted, documented, and stable, with views that a reporting tool, or an AI assistant, can read directly and get the same answer everyone else gets.

That is why Subschema was driven to build AGGREGATE. It counts events, not visitors. It stores no IP addresses and no visitor IDs, and small counts are withheld by the database itself. Additional details are only collected if visitors consent to enhanced analytics. AGGREGATE's metrics are published as documented views, so the definition of a number lives with the institution, not with a vendor. It runs on the institution's own server, where retention is a local decision.

We will state the tradeoffs plainly. Self-hosted means the maintenance is yours. Anonymous aggregation means there is no visitor journey to replay. AGGREGATE is beta software and has not had an independent audit (yet). A college that needs advertising attribution or real-time campaign dashboards will need something else, and we would rather say so than oversell it.

But if the need is the one public institutions actually have: own the data, respect the visitor, keep the definitions stable, and let a small team answer simple questions with confidence, then the free tool from an advertising company is not the bargain it looks like. The cost is paid in control, and control is the thing a public institution is not free to give up.

AGGREGATE is open source under AGPL-3.0. Run it, read the code, or take a starter issue and help build it.
GitHub: https://github.com/Subschema-LLC/aggregate
Start here: https://github.com/Subschema-LLC/aggregate/issues/212

Back to Blog