What Is a White-Label Client Reporting Portal?

A white-label client reporting portal is a BI environment where clients log in, view their dashboards, and interact with their data — and the entire experience carries your agency's brand, not the BI vendor's. Your logo, your domain, your colors. No "Powered by [Vendor]" badge. No vendor login page. No visible indicator that the software running the portal wasn't built in-house.

The term "white-label" comes from product manufacturing — a white-label product is one that's produced by one company and branded by another. In BI software, it means the vendor removes their brand from the interface so the agency or reseller can apply their own. What the client experiences is entirely the agency's product. What powers it behind the scenes is invisible to them.

What Clients Experience

From a client's perspective, the portal looks like something your agency built. They navigate to a URL like reports.youragency.com or analytics.clientname.com — a domain you control. The login page shows your logo and brand colors. Once authenticated, the interface reflects your brand throughout: navigation, headers, report headers, color scheme. The reports themselves are populated with their data.

Clients don't see a vendor name. They don't get redirected to a third-party login system. They don't receive emails from an unfamiliar sender domain. The experience is seamless — they're using your reporting product, full stop.

What the Agency Controls

Behind the scenes, the agency or MSP controls the entire environment. That includes the data connections (which databases or APIs feed the reports), the reports and dashboards themselves, which reports each client can access, the refresh schedule, and the branding applied to the interface. When a client logs in, they see the reports their account has been granted access to, populated with the rows their security policy allows — and nothing else.

A well-configured portal separates these concerns cleanly: branding is controlled at the policy level, data access is controlled at the security level, and report access is controlled at the permission level. Each client gets their own tailored experience without requiring a separate technical environment per client.

The Four Layers of a White-Label Portal

A complete white-label setup typically involves four distinct layers, each of which needs to be configured:

Custom domain. The portal lives at a URL you control — either a subdomain of your own domain (reports.youragency.com) or a client-specific domain (analytics.clientname.com). This requires DNS configuration and custom domain support in the BI tool.

Login page branding. The login page is the first screen clients see. It needs to carry your brand — logo, colors, favicon — with no reference to the underlying software. This is separate from the application branding that appears after login, because the login page is served before the user is authenticated and their branding policy can be applied.

Application branding. Once a client is logged in, the interface they interact with — navigation, headers, report chrome — should reflect your brand. In more sophisticated setups, different client groups can see different branding within the same instance: Client A sees branding that matches their co-branded agreement, Client B sees standard agency branding. This is controlled by branding policies assigned to user groups.

Email branding. Scheduled reports delivered by email should come from your domain — not from a generic BI vendor address. A custom SMTP configuration allows email delivery through your own mail server, so clients receive reports from an address they recognize as yours. Note that this is a single configuration per workspace — if you're running one shared environment for all clients, all emails originate from one sending domain.

What White-Label Is Not

It's worth being specific about what counts as white-label and what doesn't, because vendors use the term loosely.

Adding your logo to a vendor-hosted page is not white-label. If the URL still shows the vendor's domain and "Powered by [Vendor]" appears anywhere in the interface, that's co-branding at best. True white-label means your domain, your brand, no vendor attribution — not just a logo upload.

Tableau added a custom subdomain feature in August 2025. This allows a branded URL — but it's a subdomain of Tableau's domain, the Tableau interface and branding remain visible throughout, and there's no mechanism to remove Tableau's attribution from the experience. That's not white-label; it's a cosmetic URL change.

Looker Studio, even on the paid Pro tier, shows Google branding throughout the interface. There is no mechanism to remove it and no custom domain support. Agencies using Looker Studio for client reporting are delivering a Google-branded product to their clients, not a white-labeled one.

Single-Tenant vs. Multi-Tenant Branding Architecture

How you configure branding depends on whether you're running a single-tenant model (one environment per client) or a multi-tenant model (all clients in a shared environment).

In a single-tenant model — a separate BI instance for each client — white-label setup is straightforward. Each instance gets its own domain, its own branding, and there's no risk of data crossover because the environments are physically separate. The tradeoff is cost and operational overhead: you're managing N instances rather than one.

In a multi-tenant model — one shared environment serving all clients — branding becomes a policy management exercise. Each client group gets a branding policy applied to their user accounts, and custom domains route to the same environment but trigger different login branding based on which domain the user arrived from. Data isolation is handled by row-level security (covered in Chapter 3), not by separate infrastructure.

The multi-tenant model is almost always the right choice for agencies at scale. One environment to maintain, one set of reports to update, one security model to manage — with branding policies and data security handling the per-client differentiation. The specifics of how many clients you can differentiate in this model depend on your tier's branding policy and custom domain limits, which Chapter 4 covers in detail.