Self-hosted web analytics for universities and schools

Access is controlled by the analytics platform's own user and role model, combined with the school's identity provider, and the record of who viewed what lives in the platform's audit and access logs. FERPA requires institutions to use reasonable access controls so that school officials see only the education records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)), and to keep a record of disclosures of personally identifiable information (34 CFR 99.32). Confirm with your platform team which events the chosen tool logs, how long logs are kept, and whether reports for student portal sections can be restricted to named roles. Whether this evidence is sufficient is decided by your institution's auditor or the regulator, not by the vendor or implementer.

The arrangement is a contract or agreement that names the contractor as a school official, or as a processor where it applies, and records the controls on use, maintenance and redisclosure of records. Under FERPA, an outside party can receive education records only if it performs a service the institution would otherwise use employees for, stays under the institution's direct control for use and maintenance of the records, and follows the redisclosure limits in 99.33(a) (34 CFR 99.31(a)(1)(i)(B)). For EU campuses, the data processing terms required by GDPR (Regulation (EU) 2016/679) must also be in place. Ask your counsel which role applies and what the agreement must contain, and ask any implementation partner to name the people and access they will hold.

The retention and deletion schedule is a written policy, configured in the analytics platform, that states how long raw events, aggregated reports and visitor-level data are stored and how deletion is carried out. For any data relating to children under 13, the COPPA Rule requires a written data retention policy with a deletion timeframe, and operators may not keep that information indefinitely (16 CFR 312.10). Your evidence is the policy document, the data retention settings in the platform, and a record of purge jobs or backup expiry. Confirm whether backups follow the same schedule, because deleted data can persist in backups until they expire.

A written information security program (WISP) describes the controls, a named coordinator, and the review cycle for the analytics server, and the risk assessment records show the findings and decisions made. COPPA requires operators collecting personal information from children under 13 to keep a written information security program with a designated coordinator and at least annual risk assessments (16 CFR 312.8). Where the institution is subject to the GLBA Safeguards Rule through Title IV participation, it must also maintain a written program and multi-factor authentication for anyone accessing an information system (16 CFR 314.4). The program and assessments are owned by the institution, and the implementer can help prepare the evidence. Whether they meet the auditor's standard is for the auditor to decide.

Change and patch records are the dated log of upgrades, configuration changes, security patches and the approvals behind them, kept alongside the version of the analytics software in use. Auditors usually want to see that the platform runs a supported release and that security updates were applied on a known schedule. Matomo's changelog and the Plausible release history publish version dates that you can cite in your records, and Plausible notes that Community Edition gets security fixes only when the operator applies the release. Ask your team to keep a change ledger with the release applied, the date, the approver and any test evidence, and to confirm the support window of the release you run.

A tracking inventory is a maintained list of every site, subdomain, template and page that loads the analytics script or sends events, with the data each one collects and the reason it is in scope. It is produced by a crawl or tag scan, checked against the platform's site configuration, and reviewed whenever a page or plugin is added. Pages in authenticated student portals, course areas and admissions forms need a documented decision about whether tracking is excluded or limited. The inventory is the document that shows regulators and auditors what is measured, so keep it under version control and tie each entry to an owner. Confirm with the team that third-party embeds, such as video or form widgets, are included in the scan.

The biggest drivers are how many sites and faculties you measure, how much consent and privacy work the sites need, and how much identity integration the admin area requires. Each extra site adds tag placement, goal and report configuration, and testing. Consent work grows if you serve EU visitors and must decide whether a banner is needed. Identity integration adds single sign-on setup and access reviews. Infrastructure is a recurring cost that scales with pageviews. Ask any quote to itemize these components separately, state which sites and regions are in scope, and say who owns ongoing hosting. The cost of the software itself is not the main line item: Matomo's On-Premise Community edition is free, so most spend goes to people and infrastructure.

Often yes, if the team has Linux, web server, database and container skills and time to maintain them. Matomo On-Premise runs on PHP with MySQL or MariaDB behind a web server such as Apache or Nginx, and Matomo's requirements FAQ sizes a single server for up to 1 million pageviews a month. Plausible Community Edition requires Docker, Docker Compose and at least 2 GB of RAM, and its operators handle installation, upgrades, capacity, uptime, backups and security themselves. Confirm whether your team can take on that operating load and an on-call rota before deciding. A partner can take on the build, hardening and documentation while your staff keep ownership.

The project needs three kinds of input before engineering starts. First, a privacy and legal sign-off that defines the purposes of measurement, which student-facing pages are excluded, and how records are retained, since FERPA and COPPA limit what student data may be collected and kept. Second, a site inventory listing every domain, subdomain, student portal and course site, with its owner and whether it is public or authenticated. Third, named admin staff from web, IT and the registrar's or admissions office who can approve tag placement, user roles and reports. Without these, scope drifts and the admin area ends up with the wrong access rights. Ask any partner to show how it records these decisions in writing.

Upkeep is ongoing and it is the cost most often underestimated. Matomo publishes stable releases, and its changelog lists Matomo 5.14.1, released on October 4, 2026, as the latest stable version, with Matomo 6.0.0 in beta, which needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer. Plausible Community Edition is a long-term release published twice per year and gets security fixes only when the operator applies them, while Plausible Cloud ships updates multiple times per week. Plan a scheduled patch window, a test environment for each upgrade, and a backup before each change. Ask a partner whether upgrades, security monitoring and documentation are included in a retainer or a separate agreement.

Yes, both can import some history, but neither gives you a full copy of the original data. Matomo's Google Analytics Importer is free for On-Premise installations and imports aggregated report data into a new Matomo site, so Visitor Log, Ecommerce Log, Custom Reports, Segmentation and some reports such as Funnels do not work for imported data. Plausible's Google Analytics import brings in historical GA4 stats as daily aggregates up to the first native Plausible visitor, supports up to 5 GA properties per site, cannot import ecommerce revenue, and approximates unique visitors by summing daily uniques. Confirm with the owners which reports the faculties need to keep, and decide early whether to keep the old property running in read-only mode for comparison.

Fixed scope is the usual model for most DeployOpen engagements, because the scope, deliverables and timelines are agreed in writing before work starts. For a campus, a written scope typically lists the sites in scope, the platform and edition, the identity integration, the consent and retention settings, the documentation, and the handover to your staff. Ongoing support, upgrades and continuous testing are available as retainers, which suits institutions that want the platform kept current after go-live. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope in writing, the list of exclusions, and the terms for changes after the work starts.

Ask the partner to confirm the items that change effort most. Confirm the number of sites, faculties and subdomains, the traffic volume by site, and whether any student portal or course site needs authenticated tracking excluded. Confirm whether EU visitors are in scope and who decides on consent handling. Confirm the identity provider and the access model for admins. Confirm the hosting location, whether on campus or in the institution's cloud account, and how backups are stored. Confirm whether historical data will be imported and which reports must survive. Finally, confirm how the partner documents the setup, what evidence it provides for compliance reviews, and who holds administrative access after handover.