What Tableau embedded analytics actually is, what it really costs, and how to decide whether to build a custom solution or buy a purpose-built portal.
Tableau embedded analytics is the practice of taking Tableau dashboards and displaying them inside another application, website, or product - so that end users interact with the data without ever opening Tableau directly. Instead of sending someone a link to Tableau Server, you surface the dashboard inside your own interface: a client portal, a SaaS product, an internal tool, or a marketing site.
The appeal is obvious. Your team has already invested significant time building dashboards in Tableau. Embedded analytics lets you leverage that investment by putting those dashboards in front of audiences who would never log into Tableau on their own - external clients, partners, customers, or non-technical stakeholders.
At a technical level, Tableau provides several tools to make this possible:
A JavaScript library that lets you embed Tableau visualizations as web components in any HTML page. It gives you programmatic control over filters, parameters, and user interaction events - meaning your application can respond to what users do inside the dashboard and vice versa. This is the primary tool Tableau intends for production embedding, and it requires Tableau 2021.4 or later.
These establish a trust relationship between your application and Tableau, allowing your app to authenticate users without requiring each person to have a separate Tableau login. Your application issues a JSON Web Token (JWT) that Tableau validates, enabling seamless single sign-on. This is the mechanism that makes it possible to serve hundreds or thousands of external users without managing hundreds or thousands of Tableau accounts.
A programmatic interface for managing content, users, and permissions on Tableau Server or Tableau Cloud. You can use it to automate tasks like publishing workbooks, managing user groups, and querying metadata - useful for building admin functionality around your embedded deployment.
Together, these tools give developers the building blocks to create a custom application that surfaces Tableau dashboards inside any product or website. But "building blocks" is the operative phrase. Tableau gives you components; turning those components into a finished product is a separate, often underestimated, effort.
Tableau markets embedded analytics primarily to two audiences: software companies that want to add analytics capabilities to their own products (think a SaaS platform that offers built-in reporting to its customers), and organizations that want to deliver data to external audiences like clients, partners, or stakeholders without giving them direct Tableau access.
In practice, the second group is much larger and more diverse than Tableau's marketing suggests. It includes consulting firms sharing performance dashboards with clients, healthcare organizations distributing quality metrics to provider networks, financial services firms delivering portfolio analytics to advisors, and managed service providers reporting on SLA performance. These organizations are not building analytics products - they are trying to share the dashboards they have already built with people outside their firewall.
This is the question that brings most people to this topic, and the answer has more layers than Tableau's pricing page reveals.
User-based licensing is the traditional model: you purchase named Viewer, Explorer, or Creator seats for each person who needs access. Viewer licenses on Tableau Cloud start around $15 per user per month. This model is straightforward - you know what you are paying for - but costs scale linearly with your audience size. One hundred external viewers means 100 Viewer licenses, regardless of whether all 100 actually use the dashboards.
Usage-based licensing charges based on the number of dashboard interactions (impressions) rather than named users. This can be significantly more economical for large audiences with infrequent usage. If you have 500 external contacts but most of them only check a dashboard once or twice a month, usage-based pricing avoids paying for 500 seats that sit idle most of the time.
The right choice depends entirely on your audience's size and behavior patterns. A useful rule of thumb: if your average user views dashboards more than 15-20 times per month, user-based licensing is typically cheaper. If average usage is well below that threshold, usage-based pricing often wins. But these thresholds shift based on Tableau's specific pricing tiers and your negotiated rates, so modeling the numbers with real (or projected) usage data is essential before committing.
Getting this decision wrong in either direction can mean significant overspend. We have seen organizations paying $30,000/year more than necessary because they chose the wrong licensing model for their usage profile - and the mistake was not obvious until someone actually modeled the numbers.
The licensing fee gets you access to Tableau's platform and APIs. It does not get you a finished product. To actually deliver embedded analytics to your external audience, you need to build (or buy) everything else: the user interface, the authentication system, the security layer, the branding, the user management, and the ongoing maintenance. For most teams, these costs dwarf the Tableau licensing fee - often by a factor of 3-5x in the first year alone.
This is the part that catches teams off guard. The conversation starts with "how much does Tableau licensing cost?" when the real question should be "what is the total cost of delivering embedded analytics to our audience?"
When teams first explore the Tableau Embedding API, the initial scope estimate usually sounds reasonable: a developer or two for six to eight weeks. The API documentation is solid. The sample code works. A proof-of-concept dashboard appears on a webpage within a day or two. Progress feels fast.
Then reality sets in. The scope was never just "embed a dashboard." It was always "build a secure, branded, user-managed application that happens to use Tableau as its visualization engine." Here is what that actually entails:
Your external users need to log in. That means building or integrating an authentication system: SSO via SAML or OIDC, session management, token refresh logic, password reset flows, and potentially multi-factor authentication. If your clients use different identity providers - one client uses Okta, another uses Azure AD, a third uses Google Workspace - you may need to support multiple protocols.
Connected Apps and JWT authentication handle the Tableau side of the trust relationship, but your application still needs to issue those JWTs correctly, manage their lifecycle (expiration, refresh, revocation), and map authenticated user identities to the right Tableau user attributes. A bug in this flow does not just break the user experience - it can expose one client's data to another.
Ensuring each client sees only their data is the most critical requirement for any external-facing deployment, and it is more complex than it appears on the surface. You need logic in your application that maps each authenticated user to their data permissions, passes the correct filters or user attributes to Tableau, and verifies the result.
This is not a one-time configuration. Every new client, every new dashboard, and every change to your data model requires RLS to be reviewed and tested. For regulated industries - healthcare (HIPAA), financial services (SOC 2), government (FedRAMP) - this also means audit logging: recording who accessed what data, when, and verifying that no unauthorized access occurred. Building and maintaining audit infrastructure is a project in itself.
A proof-of-concept that shows a dashboard on a page is not a product. Users need to navigate between multiple dashboards, see appropriate loading states (Tableau views can take several seconds to render, and a blank white screen during that time feels broken), receive meaningful error messages when something goes wrong, and have an experience that works across desktop, tablet, and mobile.
They also need the experience to feel cohesive. If the login page looks like your brand but the dashboard area looks like Tableau, users notice the seam. Hiding or customizing the Tableau toolbar, managing the interaction between your application's navigation and Tableau's built-in navigation, and handling edge cases (what happens when a filter returns no data? when a dashboard fails to load? when the user's session expires mid-interaction?) — this is front-end development work that has nothing to do with Tableau's API and everything to do with building a polished application.
Someone needs to add new clients, remove former ones, modify access permissions, and troubleshoot login issues. If that "someone" is a developer running database queries, your system does not scale. You need an admin interface - a way for non-technical team members to manage users, view activity, and configure access. Building admin tools is rarely glamorous work, but without them, every user management task becomes a developer ticket.
A custom-built embedded analytics application is software your team now owns and must maintain indefinitely. Tableau updates its API (the Embedding API v3 replaced the older JavaScript API, and future changes are inevitable). Browsers change their security models (third-party cookie restrictions have already affected some embedding patterns). Dependencies need patching for security vulnerabilities. Identity providers update their protocols. And users request features: "Can we add a new dashboard?" "Can we change the navigation?" "Can we add email notifications when data refreshes?"
Each of these is manageable individually. Collectively, they represent an ongoing commitment of engineering time that competes with your team's primary work - which, for most organizations exploring embedded analytics, is building great dashboards and delivering analytical value, not maintaining a web application.
Custom building is the right call in specific situations. If your product IS an analytics platform (i.e. you are a software company whose core offering includes data visualization), embedding Tableau into your product is a core engineering investment, not a side project. If you need deeply custom interactivity that goes beyond standard dashboard interactions - programmatically driving complex multi-step workflows based on user selections, for example - the Embedding API's flexibility may be necessary. And if you have a dedicated development team with long-term capacity to maintain the application through API changes, security updates, and feature requests, the ongoing maintenance burden is absorbable.
The common thread: building makes sense when the embedded analytics application IS your product or a core differentiator of your product, and you have the engineering team to treat it as such.
Required resources: front-end and back-end developers, security review, UI/UX design, DevOps for hosting and monitoring. Typical timeline: 3-6 months to reach a production-ready launch, plus ongoing maintenance capacity. Realistic first-year cost: $50,000-$200,000+ depending on team location, scope, and whether you use contractors or in-house staff. This estimate includes developer time, infrastructure, security audit, and the opportunity cost of pulling those developers away from other work.
A portal product is the better fit when your core competency is analytics and data - not web application development. This describes the majority of organizations exploring Tableau embedded analytics. You have a team that is excellent at building dashboards and generating insights. You need to get those dashboards in front of external audiences. But building and maintaining a custom web application to do so is a distraction from the work that actually creates value for your clients.
Buying also makes sense when speed matters. If a client is waiting for a branded reporting portal and the alternative is a 3-6 month development project, the portal product gets you live in days. When predictable costs matter - you can budget a subscription fee more easily than an open-ended development project. And when you want to avoid the accumulating maintenance burden of owning a custom application that needs ongoing attention from scarce engineering resources.
Required resources: your existing Tableau Server or Cloud instance, an admin to configure settings, your logo and brand assets. Typical timeline: days to a working deployment, weeks to full production rollout. Cost: a predictable subscription that typically runs a fraction of the custom build cost. Your analytics team stays focused on dashboards and data - not on maintaining authentication systems, patching security vulnerabilities, and building admin interfaces.
Portal Panda gives you everything the Embedding API lets you build - authentication, row-level security, custom branding, and a polished client-facing interface - without the development work. You connect it to your existing Tableau instance, configure your branding and security settings, and invite your clients. The entire setup takes days, not months.
Because the Portal Panda team has helped dozens of organizations navigate Tableau's licensing options, you also get expert guidance on the user-based vs. usage-based decision before you commit - guidance that can save tens of thousands of dollars in licensing costs by matching the right model to your actual audience behavior.
If you are weighing whether to build a custom embedding solution or evaluating portal products, book a demo at portalpanda.com to see how the build-vs-buy math works for your specific deployment.
Portal Panda gives your external clients a secure, white-labeled interface to access Tableau dashboards — with zero custom code.
Book a Demo