Deploying a White-Labelled Analytics Platform for a Government Intranet

The Scenario

A large Canadian federal government department — responsible for managing the country's fisheries, waterways, and aquatic resources — needed a web analytics solution that could serve both its public-facing internet properties and its internal intranet. The department selected Piwik as its analytics platform of choice, but off-the-shelf Piwik wasn't sufficient on its own. Two critical gaps had to be addressed: the platform's visual identity needed to align with internal branding standards, and it needed to integrate with the department's existing single sign-on (SSO) infrastructure rather than managing a separate set of credentials.

For a government agency operating under strict security and privacy mandates, both requirements were non-negotiable.

The Approach

White Labelling Piwik

The standard Piwik interface carries its own visual language — logos, colour schemes, and UI chrome — that can feel disconnected from an organization's internal tooling. For government deployments in particular, a unified look and feel isn't merely cosmetic; it signals legitimacy and reduces user confusion when the tool sits alongside other enterprise systems.

The solution involved a comprehensive white labelling effort developed in close collaboration with the Piwik core team. This included:

• Overriding CSS across all core and plugin views to apply the department's visual standards
• Replacing images and templates throughout the interface, including plugin-level views that are often overlooked in partial customizations
• Developing custom charts to match the department's reporting style and branding requirements

The key technical consideration here is scope: a true white label needs to account for every surface in the application, not just the main dashboard. Plugin views, report pages, and embedded components all need consistent treatment, which requires a systematic audit of the full template tree.

Custom SSO Authentication Plugin

Requiring government employees to maintain a separate set of Piwik credentials would create both a usability problem and a security risk. The standard approach in enterprise environments is to integrate analytics access directly into the existing identity management infrastructure.

A custom authentication plugin was built to bridge Piwik's internal user model with the department's SSO system. The plugin handled:

• Authentication delegation — users authenticate via the existing SSO system rather than Piwik-native credentials
• Role population — upon successful authentication, user roles are populated automatically from the SSO system's directory
• Group-level privilege management — access controls can be managed at the group level, meaning administrators don't need to configure permissions for individual users

This last point is particularly valuable in large organizations where staff turnover and role changes are frequent. Group-based access management means that when someone changes roles, their analytics permissions update as part of the existing HR/IT workflow rather than requiring a separate action in Piwik.

Implementation Considerations

The deployment covered both intranet and internet analytics, providing the department with unified visibility across its internal and external web properties from a single Piwik instance. The security and privacy requirements typical of a federal government environment shaped several decisions:

• Data residency and access controls needed to satisfy government IT compliance standards
• The SSO integration reduced the attack surface by eliminating a secondary credential store
• Role-based access control ensured that sensitive intranet analytics were only accessible to users with appropriate clearance

The white labelling work was done in a way that remains maintainable across Piwik updates — by working at the CSS, image, and template layer rather than forking core functionality, customizations can be reapplied or updated without requiring a full redevelopment cycle.

Outcomes and Tradeoffs

The result of this kind of implementation is a Piwik deployment that behaves like a native internal tool: employees log in with their existing credentials, see a familiar interface, and access only the data their role permits. For the department, this meant a complete intranet and internet analytics capability that met government security and privacy standards without requiring users to adopt new credentials or adapt to a foreign-looking interface.

The main tradeoff in this pattern is maintenance overhead. White labelling and custom authentication plugins both introduce a delta from the upstream open-source codebase. Organizations adopting this approach should plan for a review cycle whenever Piwik (now Matomo) releases significant updates, particularly to templating systems or authentication APIs. That cost is generally well justified when government compliance or strong branding requirements are in play.