Tenant Analytics
Fleet-wide operational analytics for the platform operator — not for individual tenants. A nightly cron sweeps every client company, computes seventeen metric groups for each, and stores dated snapshots plus a platform-wide aggregate in the main database.
Tenant Analytics answers a question only the platform operator can ask: "across our whole ERPat fleet, how many tenants are we running, how much payroll do they process, how many employees do they manage, and how healthy is each tenant's data?" Because ERPat keeps every tenant in its own separate database, that picture doesn't exist anywhere until something deliberately visits each tenant, measures it, and writes the numbers into one shared place. That is exactly what this module does.
What the module does
A nightly global-scope cron visits every client tenant — active and inactive — opening each tenant database in turn, measuring it, then restoring the main connection.
Per tenant, per date, per metric group, one JSON snapshot lands in the main database. Re-running a date replaces its rows — it never double-counts.
Snapshots roll up into a platform-wide total that carries no tenant identifiers. An optional, default-off public API serves that aggregate as read-only JSON.
Who this is for
- Platform operators / the ERPat business owner — the people who run the whole multi-tenant platform and need fleet-level visibility (tenant count, total payroll volume, fleet headcount, per-tenant data health).
- System administrators — who enable the module, grant permissions, tune the retention and sweep settings, and decide whether to switch on the public API.
- Support & operations staff — who read the Analytics tab, run a manual sweep when needed, and re-sweep a single tenant after fixing its data.
Where you'll find it
Tenant Analytics has no left-menu entry of its own. It appears as an Analytics tab on
the Tenants list page (Settings → Tenants), alongside the other tenant-management tabs.
The tab only renders on the platform's main database — open it while impersonating or
inside a tenant session and you are redirected away. The public JSON API (when enabled) lives at
/api/v1/analytics/….
The 60-second mental model
Every night at 03:00 the cron sweeps the fleet, measures each tenant across the seventeen metric groups, writes a dated snapshot per tenant, then rolls up those snapshots into an identifier-free platform aggregate and prunes anything past the retention window. The operator reads the result on the Analytics tab, and — if switched on — the aggregate is served as a keyless public API.
Explore the guide
Run the migration, enable the module, grant the three permissions, and load demo data.
Read the tab, run a manual sweep, re-sweep a tenant, and rebuild rollups.
Settings, permissions, the cron job, and the public API with its kill switch.
Controllers, routes, tables, the 17 metric groups, cron, and API endpoints.
Every file under the module and exactly what each one does.
Common problems, a glossary of terms, and where to escalate.
What ships in the box
The seventeen groups are overview (incl. live DB size), payslips, payrolls, employees,
attendance, leaves, establishments, schedules, departments, de minimis, loans, storage (files
& footprint), finance, assets, crm, projects and engagement. The three main-database
tables are tenant_analytics_snapshots (per tenant × date × group),
tenant_analytics_rollups (the identifier-free platform aggregate — the only
table the public API reads) and tenant_analytics_runs (the sweep audit ledger). The
cron job is tenant_analytics_snapshot. Full detail lives on
Reference.
php erpat db:seed TenantAnalyticsDemo — three sample tenants of snapshots,
a completed run, and matching rollups. Remove it any time with
php erpat db:seed TenantAnalyticsDemo --remove.
See Getting Started.