Sooner or later, someone auditing a system asks three plain questions. Who changed this setting? Who created that account? When did it happen? In a lot of analytics tools, those questions are hard to answer for the tool itself. The reports are polished. The record of who did what inside the tool is thin, scattered, or missing.
We think that is backwards. A tool that asks to be trusted with a website's data should be able to account for its own house first.
AGGREGATE now keeps an audit trail. It records what administrators do in the dashboard and on the command line: settings changes, user accounts and permission groups created, changed, or deleted, websites and groups added or removed, integrations connected, reporting API tokens created and revoked, updates installed, and jobs run by hand. Every finished background job run is recorded too. Sign-ins can be recorded as well; that area is off by default, and turning it on is a local decision.
Each entry says what kind of change it was, whether it succeeded, failed, or was denied, who made it, and when, in UTC. A change attempted by someone without the permission for it is recorded as denied, with who tried. That last part matters. An audit trail that only records successes tells half the story.
Two design choices are worth stating out loud. The first is that the trail protects the same privacy it exists to support. Entries never hold passwords, keys, submitted values, or visitor data. A settings change is recorded by the names of the settings that changed, not their values, so a secret cannot leak into the log that is supposed to keep everyone honest. An API token appears by its public ID, never by its secret.
The second is that turning auditing off leaves a trace. Areas of the trail can be switched off individually, because not every installation needs the same record. But a change to those switches is always recorded, even if the settings area is off. Nobody quietly disables the record and then acts unrecorded.
When auditors do come, the record is meant to be handed over, not admired. Administrators can filter it by date, area, action, outcome, and user, export the matching entries to CSV, or read it from the command line. An export is itself recorded, with the kinds of filters used. Retention is a local setting: background job entries are kept a year by default, administrator entries two years, and either period can be extended or set to keep entries indefinitely, so the schedule can match the institution's own audit and staff-data policies.
We will state the limits plainly, as we do. The audit trail records the actions the application knows about; it is not a recording of everything that happens on the server underneath it, and it does not replace an institution's own logging. Sign-in recording is off until an administrator turns it on. AGGREGATE is beta software and has not had an independent audit. We would rather describe the record accurately than oversell it.
But the principle is simple, and it is the same one behind the rest of the product. Count what happens, be able to show your work, and keep the record where the institution can reach it. Analytics that respects visitors should also respect the people who have to answer for the system. When the auditors ask who changed what, and when, there should be an answer.
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