The White-Label Branding Gap

Ask any embedded analytics vendor if they support white-labeling and the answer is yes. What that yes actually means is where the challenge lives — because white-label is used to describe everything from "your logo is visible somewhere on the page" to "the vendor is completely invisible to your customers." For ISVs, the gap between those two definitions is significant.

The branding challenge in embedded reporting isn't just cosmetic. When your customers see a third-party vendor's interface inside your product, it undermines the perception that analytics is a native part of what you've built. It raises questions about your data handling. And in enterprise sales cycles, it can surface as a procurement concern — some customer security policies restrict third-party software embedded in vendor products without disclosure.

What "White-Label" Actually Means in Practice

There are roughly four levels of white-label support in the embedded analytics market:

Logo replacement only. Your logo appears instead of the vendor's in the header. The rest of the UI — colors, typography, component styling, layout patterns — remains the vendor's default. Customers who use the product regularly will recognize it as a third-party tool. This is branding, not white-labeling.

Theme-level customization. You can configure a primary color and upload a logo. The resulting UI looks approximately like your brand at a glance. A developer inspecting the DOM or examining network requests can identify the underlying platform, but most end users won't. This is adequate for many B2B ISV use cases where customers aren't actively auditing your tech stack.

Full CSS customization. The platform exposes its stylesheet for complete override. Your design system can be applied fully — typography, spacing, component styling, color system. The embedded analytics UI is visually indistinguishable from the rest of your application. This is genuine white-labeling at the visual layer.

Per-tenant branding. Each of your customers gets their own branding configuration — their logo, their colors, their experience. This is the ISV-specific requirement that most platforms handle poorly, because it requires a configuration layer that maps tenant identity to a branding policy at render time. It's different from a single global white-label configuration, and it's what an ISV actually needs when customers have distinct brand identities.

The Scheduled Export Branding Gap

This is the white-label failure point teams discover after go-live, not during evaluation — because it's not visible in a demo environment.

Many platforms white-label the in-product analytics UI completely but send scheduled report emails from a vendor-branded address with a vendor-branded template. Your customer's finance team gets their Monday morning revenue summary delivered from noreply@analyticsvendor.com with the vendor's logo in the email header. Every scheduled delivery is a reminder that the analytics in your product isn't really yours.

For an ISV trying to present a seamless, native analytics experience, this is a significant gap. Customers who never think about the underlying platform while using the in-product UI are reminded of it every time a scheduled report lands in their inbox.

Before completing any evaluation, confirm explicitly: can scheduled report emails be sent from your domain, with your email template, with no vendor branding present? The honest answer from platforms that support it is a straightforward yes with configuration documentation. Platforms that deflect this question or describe it as a professional services engagement are telling you it's not a supported capability.

What Customers Can Still Detect

Even with complete CSS customization and per-tenant branding, there are signals a technically curious customer could use to identify the underlying platform — JavaScript bundle names, API endpoint patterns visible in network requests, specific DOM structures that match known analytics platforms. In practice, enterprise B2B customers rarely inspect your product at this level. But it's worth understanding what "invisible" means in a realistic sense versus a theoretical one.

What customers reliably cannot detect with a proper white-label implementation: the vendor's name, the vendor's logo, any visible vendor branding in the UI, and the vendor's name in scheduled report email headers. What a developer could potentially detect: the vendor platform identity via network inspection. For most ISV deployments, the former matters and the latter doesn't.

OEM Licensing — The Legal Layer of White-Labeling

White-labeling is a technical capability. OEM licensing is the legal permission to use it — specifically, the right to embed the platform in a product you sell to customers without disclosing the underlying vendor to end users.

Some embedded analytics platforms require a separate OEM agreement on top of the base license. That agreement may restrict which products you can embed in, require disclosure in certain circumstances, or limit the number of deployments covered. Confirm OEM licensing terms before you assume white-labeling is fully permitted under your base contract.

Yurbi's OEM license is included in every plan — no separate agreement, no restrictions on embedding in the products you sell. The license covers one ISV product per plan; additional products get a meaningful discount.