How to Embed Analytics Into Your App

Embedding analytics into your app usually comes down to four approaches: iframes, SDKs, Web Components, or a headless BI architecture. The right choice depends on your customization requirements, security model, existing architecture, and the level of control you want over the user experience.

This guide walks through the most common ways to embed analytics into an application, the trade-offs behind each approach, and the decisions that have the biggest impact on security, customization, and long-term maintenance.

How do you embed analytics into your app?

You embed analytics into your app by connecting your data to an analytics layer, controlling who can access what, and displaying dashboards or charts through an iframe, SDK, Web Component, or headless API.

While the implementation details vary, most teams are dealing with the same problem. They need to get the right data in front of the right users without creating a security, maintenance, or performance headache. The choices you make early on will influence everything from how easily dashboards can be customized to how much engineering effort is required to support them over time.

The typical embedded analytics architecture

Most embedded analytics implementations consist of three layers: the data layer, the query layer, and the presentation layer.

Data layer

The data layer is where your analytics data lives. This is often a data warehouse such as Snowflake, BigQuery, Redshift, or Databricks, although some applications work directly with operational databases. Many teams also use a semantic layer to create consistent definitions for metrics and KPIs across the product.

Query layer

The query layer sits between the data and the user. Its job is to fetch the right data, apply business rules, and make sure users only see information they're allowed to access. This is where concepts like row-level security and tenant isolation are commonly enforced.

Presentation layer

The presentation layer is what users see inside your application. It might be a complete dashboard, a collection of embedded charts, or a fully custom analytics experience built directly into your product.

Once these layers are in place, the next step is deciding how analytics should be delivered to users. That's where the choice between iframes, SDKs, Web Components, and headless BI comes in.

The 4 approaches to embedding analytics

Most teams embed analytics using one of four approaches: iframes, SDKs, Web Components, or a headless API. There isn't a universally “best” option. The right choice depends on how much control you need over the user experience, how much engineering effort you're willing to invest, and how closely analytics needs to integrate with the rest of your product.

The table below compares the four approaches at a high level before we look at each one in more detail.

iframe embedding

iframe embedding is usually the quickest way to get analytics into an application. Instead of building analytics directly into your product, you load a dashboard from another application inside an iframe.

That's exactly why many teams start here. You can get a dashboard in front of users quickly without spending weeks on integration work. If you're validating a new analytics feature, launching an MVP, or simply need to expose reporting to customers, an iframe can get the job done with relatively little effort.

The downside is that you're embedding someone else's application inside your own. Even if the dashboard looks good, it can be harder to make it feel like a natural part of the product. Custom styling, navigation, interactions, and responsive behavior are often constrained by what the analytics platform allows.

When iframe embedding works well

• You need to launch quickly
• Analytics is a supporting feature rather than a core part of the product
• A dashboard is enough and you don't need deeply customized experiences
• Keeping implementation effort low is a higher priority than complete control

When to avoid iframe embedding

• Analytics is a key part of your product experience
• You want dashboards and charts to feel completely native
• Different users need highly customized analytics experiences
• Your design system requires fine-grained control over how analytics components behave and look

There's a reason iframe embedding remains popular. It solves a real problem with very little engineering effort.

The trade-off is that flexibility tends to become more important as analytics adoption grows. What feels like a simple solution for a few dashboards can start to feel limiting once customers expect analytics to behave like the rest of the product.

SDK embedding

SDK embedding gives you more control over how analytics looks and behaves inside your application. Instead of embedding a complete dashboard through an iframe, you integrate analytics components directly into your product using a software development kit (SDK).

The biggest advantage is that analytics can feel like a natural part of the user experience. Navigation, styling, permissions, and interactions can all be integrated more closely with the rest of the application. Users often won't know where the product ends and the analytics experience begins.

However, that extra flexibility comes with more implementation work. Unlike iframe embedding, which can often be set up in a few days, SDK integrations typically take a few weeks. Engineering teams need to handle installation, configuration, authentication, testing, and ongoing updates as the SDK evolves.

Version management is another consideration. When a vendor releases new SDK versions, you'll need a process for testing and deploying updates. This usually isn't a major burden, but it's part of the long-term maintenance cost that teams should account for when evaluating different approaches.

When SDK embedding works well

• Analytics is an important part of the product experience
• You want dashboards and charts to feel native to the application
• Users need personalized analytics experiences
• Your team wants more flexibility without building analytics from scratch

When to avoid SDK embedding

• You need the fastest possible implementation
• Analytics requirements are relatively simple
• Your team has limited engineering resources available
• A standard dashboard experience is sufficient for your users

Web Component embedding

Web Component embedding allows you to add analytics to an application using reusable browser-native components. Unlike many SDKs, Web Components aren't tied to a specific front-end framework, which makes them a flexible option for teams working across different technologies.

One way to think about Web Components is as self-contained building blocks. Instead of embedding an entire dashboard, you can place analytics components exactly where they make sense within the product. A chart can live on a customer account page, a KPI widget can appear inside a workflow, etc.

This gives you more flexibility than an iframe while avoiding some of the complexity of a fully headless implementation. Because the components are part of the application itself, it's often easier to match the surrounding user experience.

Another advantage is portability. The same analytics components can typically be reused across applications, pages, and front-end frameworks. That's particularly valuable for larger organizations where different teams may be using React, Angular, Vue, or other technologies.

When Web Component embedding works well

• You want analytics to feel like a natural part of the product
• Analytics needs to appear in multiple places across the application
• Different teams work with different front-end frameworks
• You want more flexibility than an iframe without taking on the complexity of a headless approach

When to avoid Web Component embedding

• You need the fastest possible implementation
• A standard dashboard experience meets your requirements
• Your team has limited front-end development resources
• You need complete control over every aspect of the analytics experience

Web Components offer a practical middle ground. You get more flexibility than with iframes and greater portability than framework-specific SDKs, while avoiding much of the engineering effort required to build analytics experiences entirely from scratch.

JS API and headless BI

Headless BI gives you complete control over how analytics is presented inside your application. Instead of embedding dashboards or pre-built components, you access analytics functionality through APIs and use that data to build your own experience.

This approach gives product and engineering teams a blank canvas. Charts, dashboards, filters, navigation, and workflows can all be designed around the needs of the application rather than around the capabilities of an embedded dashboard. For products where analytics is a core part of the user experience, that level of control can be valuable.

The trade-off is ownership. The more control you have, the more responsibility you take on. Your team becomes responsible for building and maintaining much of the analytics experience, including front-end components, interactions, testing, and ongoing improvements.

That's why headless BI is often less about embedding dashboards and more about building analytics directly into the product. Users may never realize they're interacting with an analytics platform at all. They simply experience analytics as another feature of the app.

When headless BI works well

• Analytics is a core part of the product experience
• You need complete control over the user interface
• Standard dashboards don't fit your use case
• Your team wants analytics embedded directly into existing workflows and screens
• You have the engineering resources to build and maintain a custom experience

When to avoid headless BI

• You need to launch quickly
• Your analytics requirements are relatively straightforward
• Your team wants pre-built dashboards and visualizations
• Engineering resources are limited
• Time-to-value is more important than complete customization

The most important question to answer here is whether that additional flexibility justifies the extra complexity and ownership that comes with it.

What's the best way to add user-facing analytics dashboards to a SaaS application?

Different embedded analytics use cases require different implementation approaches. The best way to add user-facing analytics depends on what role analytics plays in your product. Building a simple reporting feature is not the same as designing a customer-facing analytics experience that users rely on every day.

When evaluating different approaches, it's worth thinking about five areas: user experience, customization, white-labeling, multi-tenancy, and scale.

User experience

If analytics is a supporting feature, an iframe may be all you need. Users get access to dashboards and reports without requiring a significant engineering investment.

If analytics plays a more central role in the product, SDKs, Web Components, and headless BI often become more attractive. They provide greater control over how analytics fits into the application and make it easier to create experiences that feel native rather than separate from the rest of the product.

Customization requirements

A basic dashboard is often enough in the early stages. As requirements grow, teams typically evaluate additional embedded analytics features such as drill-downs, alerts, exports, and personalized dashboards.

The more customization you need, the more important flexibility becomes. SDKs and Web Components generally offer a good balance between control and implementation effort. Headless BI is often the next step when analytics needs to be woven directly into the product experience rather than presented as a standalone destination.

White-labeling and branding

Customers may expect dashboards to match the rest of the application, support custom branding, or behave differently depending on the account. While most embedded analytics solutions provide some branding options, SDKs, Web Components, and headless approaches typically allow for much deeper customization than iframe-based implementations.

Multi-tenant architecture

Security should be part of the conversation from the beginning. If different customers, teams, or user roles need access to different data, you'll need a strategy for authentication, authorization, and tenant isolation. These requirements often influence the implementation approach as much as front-end considerations do.

Scalability

Current requirements matter, but you need to think about what you’ll need in the future too.

A dashboard that works well for a few hundred users may need a very different architecture once analytics becomes a key product feature. It's worth considering how requirements might change over time. Will customers eventually need personalized dashboards? Will analytics become a competitive differentiator? Will different user roles need different views of the same data?

The answers don't necessarily point to a single implementation approach, but they do help clarify how much flexibility you'll need as the product grows.

In practice, many teams start with an iframe, move to SDKs or Web Components as requirements grow, and only consider headless BI when analytics becomes a core part of the product experience.

How to customize embedded analytics for different users

To customize embedded analytics for different users, maintain a small number of dashboard definitions and adjust what each user sees based on role, permissions, customer tier, region, or account attributes.

Many teams make the mistake of creating separate dashboards for every customer or use case. That approach works when you have ten customers, but it becomes difficult to manage when you have hundreds or thousands.

Treat dashboards as templates instead of one-off experiences

A more sustainable approach is to treat dashboards as templates. The dashboard itself stays the same, while the data, filters, metrics, and available functionality change depending on who is viewing it.

Instead of creating separate dashboards for every scenario, teams can personalize analytics using:

• User roles
• Permissions
• Customer tiers
• Regions
• Account attributes

For example, a product manager might see adoption and engagement metrics, while an executive sees high-level business outcomes. Both users access the same underlying dashboard, but the experience is tailored to their needs through permissions, filters, and user context rather than separate dashboard builds.

Personalization can happen at multiple levels

Let’s deepen the value of the template-first approach a bit. Think about a SaaS platform that both executives and individual contributors use. An executive may need a high-level overview of company performance, while an individual contributor only needs information related to their own work. The underlying dashboard structure can remain largely unchanged, even though each user sees a different experience.

The same principle applies to:

• Customer tiers (Enterprise vs SMB)
• Geographic regions
• Departments or teams
• Product plans
• Internal vs external users

Beyond reducing maintenance, this approach helps keep analytics consistent across your product. Teams can update dashboards in one place and roll out new metrics, visualizations, or features without rebuilding the experience for every user group.

Users get analytics that feels relevant to them, while product and engineering teams have far less to manage.

Centralize the rules

This type of personalization becomes much easier when access controls, user attributes, and business rules are handled centrally rather than embedded directly into dashboards.

Instead of maintaining dozens of nearly identical dashboards, you manage a smaller set of reusable analytics experiences that adapt automatically based on the user viewing them.

Multi-tenant analytics architecture patterns

Multi-tenant analytics architecture is the practice of serving multiple customers from the same analytics system while ensuring each customer can only access their own data.

This is one of the most important considerations when building customer-facing analytics. A dashboard that works perfectly for a single customer becomes much more complicated when hundreds or thousands of customers are accessing the same platform.

The good news is that most SaaS companies don't need a completely separate analytics environment for every customer. In many cases, customers can share the same infrastructure while remaining isolated through permissions, filtering rules, and row-level security.

Shared vs dedicated environments

Most multi-tenant analytics implementations fall into one of two categories:

• Shared environments use a common analytics infrastructure for all customers. Data is separated through tenant identifiers, permissions, and access controls. This is generally more cost-effective and easier to scale.
  
  
• Dedicated environments give each customer their own analytics infrastructure. This can provide stronger isolation and support strict compliance requirements, but it also introduces additional operational complexity and cost.

For many SaaS products, a shared environment with strong tenant isolation provides the best balance between security and scalability.

Tenant isolation

Regardless of the architecture, tenant isolation is non-negotiable. Every request should be associated with a customer, tenant, or account identifier that determines which data can be accessed. These controls should be enforced at the data and query layers rather than relying solely on front-end logic.

A useful rule of thumb is that users should never be able to request data that doesn't belong to them, even if they manipulate filters, URLs, or browser requests.

Scaling considerations

Multi-tenant analytics requirements tend to become more complex as customer adoption grows. That's one reason why you should consider dynamic filtering, dashboard templates, and centralized access controls instead of maintaining separate dashboards for every customer.

The more personalization requirements you introduce, the more important it becomes to have a scalable approach to permissions and tenant isolation.

Row-level security for embedded analytics

Row-level security (RLS) ensures users only see the data they're allowed to access. It's one of the most important parts of embedded analytics because it helps prevent customers, teams, or users from seeing data that doesn't belong to them.

Let’s say a SaaS platform is serving hundreds of customers. Without proper row-level security, a customer could potentially see another customer's data. Even if dashboards look identical, the data shown to each user should be filtered based on who they are and what they're allowed to access.

You solve this by enforcing row-level security at multiple layers rather than relying on a single control. This approach aligns with widely accepted OWASP guidance on multi-tenant security and defense-in-depth practices.

Data-layer row-level security

The safest place to enforce row-level security is as close to the data as possible.

At the data layer, filters are applied directly in the data warehouse or database before any information reaches the analytics layer. This creates a strong foundation for tenant isolation because unauthorized data never leaves the source system in the first place.

For example, if a user belongs to Company A, the warehouse only returns records associated with Company A. Any data belonging to Company B is excluded before a dashboard is even generated. Because these controls sit closest to the data, they're often considered the most reliable layer of protection.

Query-layer row-level security

Query-layer security applies filters when analytics requests are made. A common approach is to pass user information, such as customer ID, role, region, or account type, through JWT claims or other authentication mechanisms. The analytics platform then uses that information to dynamically filter queries before returning results.

This makes it possible to use a single dashboard template while showing different data to different users.

For example, an executive might see company-wide performance metrics, while a regional manager sees data only for their territory. Both users access the same dashboard, but the underlying queries return different results based on their permissions.

UI-layer permissions

The user interface can also be used to control what users see. This includes hiding dashboards, restricting access to specific charts, or limiting certain actions based on permissions. For example, an administrator may have access to advanced reporting features that are not available to standard users.

However, UI controls should never be your only security layer. Hiding a chart does not prevent someone from accessing the underlying data if security isn't enforced elsewhere.

UI permissions work best as an additional layer on top of data-layer and query-layer controls. This helps you tailor the experience while keeping data protected.

Authenticating users for embedded dashboards

Authentication is how an analytics platform confirms a user's identity before giving them access to dashboards and data. Even the best permissions and security controls only work if the system knows who the user is.

It's also important to distinguish authentication from authorization. Authentication answers the question, "Who is this user?" Authorization answers, "What is this user allowed to see and do?" Both are needed to deliver secure, personalized analytics experiences.

Most embedded analytics platforms support several authentication methods, with JWT authentication, single sign-on (SSO), and signed embed URLs being among the most common.

JWT authentication

JWT (JSON Web Token) authentication allows applications to pass user information directly to the analytics platform in a secure, standardized format.

When a user logs into your application, a JWT can include information such as their user ID, role, customer account, region, or subscription tier. The analytics platform then uses that information to determine which dashboards, data, and functionality the user should have access to.

This works particularly well for SaaS products because it supports personalized analytics without requiring separate dashboards for every user group. The same dashboard can serve multiple audiences, with the experience adapting based on the user context included in the token.

SSO integration

Single sign-on (SSO) allows users to access analytics without logging in separately. Instead of creating and managing another set of credentials, users authenticate through an identity provider such as Okta, Azure Active Directory, or Google Workspace. Once signed in, they can move between applications and dashboards without being prompted to log in again.

SSO is especially common in enterprise environments where security, compliance, and user management are important requirements. It simplifies the user experience while giving IT teams centralized control over access and permissions.

Signed embed URLs

Signed embed URLs provide a secure way to grant access to embedded dashboards. Rather than exposing a dashboard directly, the application generates a URL that contains encrypted or signed information about the user and their permissions. The analytics platform validates the signature before displaying the dashboard.

This helps prevent unauthorized access and ensures users only see content they're allowed to view. Signed URLs are often used alongside other authentication methods and can be a good fit when dashboards need to be embedded quickly without implementing a more complex authentication flow.

How to embed analytics without iframes

iframes are often the fastest way to embed analytics into an application, but they're not the only option. As your product becomes more sophisticated, you might want to look for ways to embed analytics without iframes. There are other approaches that offer greater control over the user experience and functionality.

Today, alternatives such as SDKs, Web Components, and headless BI architectures make it possible to embed analytics more deeply into a product. They typically require more implementation effort than an iframe, but they can deliver a more seamless and customizable experience.

When avoiding iframes makes sense

Moving away from iframes isn't always necessary. For many teams, they're still the fastest and most practical option. However, alternatives become more attractive when analytics needs to feel like a fully integrated part of the product experience.

For example, teams often move beyond iframes when they need:

• Consistent styling that matches the rest of the application
• Greater control over interactions and user workflows
• Advanced customization of dashboards and visualizations
• More flexibility in how analytics components are displayed
• Tighter integration with existing front-end architecture

The trade-off is that these approaches typically require more implementation work. The right choice depends on how much control, customization, and ownership your team needs over the analytics experience.

Headless BI vs embedded analytics

Headless BI and embedded analytics both help bring data and reporting directly into a product, but they take very different approaches:

• Traditional embedded analytics provides pre-built dashboards, charts, and reporting experiences that can be integrated into an application
• Headless BI focuses on the underlying analytics capabilities, such as querying, metrics, and data access, while leaving the user interface entirely up to the development team

The right choice depends on how much control your team wants over the analytics experience, how quickly you need to launch, and how much engineering effort you're willing to invest.

When headless BI is the better choice

Headless BI is often the right fit when analytics is a core part of the product experience and the team wants complete control over how it looks and behaves.

Rather than embedding a pre-built dashboard, developers can use APIs and analytics services to create custom reporting experiences using their own design system and front-end components.

This approach offers maximum flexibility. Teams can create highly customized workflows, unique visualizations, and experiences that feel completely native to the product.

The trade-off is complexity. Building and maintaining the analytics layer becomes a larger engineering responsibility, which can increase development time and ongoing maintenance requirements.

When traditional embedded analytics is the better choice

Traditional embedded analytics is often the better option when speed, simplicity, and ease of maintenance are priorities.

Instead of building dashboards from scratch, teams can embed pre-built analytics components and focus on delivering value to users faster. Many platforms also include features such as dashboard management, permissions, filtering, and security controls out of the box.

This typically gives you a shorter implementation timeline and lower long-term maintenance overhead.

The trade-off here is that customization may be more limited than with a fully headless approach. While modern embedded analytics platforms offer significant flexibility, they still operate within the capabilities of the platform.

How to decide between headless BI and embedded analytics

The right choice depends on how much control you need over the analytics experience and how much engineering effort you're willing to invest.

As a general rule, embedded analytics is often the better choice when analytics supports the product and speed to market is important. Headless BI becomes more attractive when analytics is a core part of the product experience and the team wants full control over how users interact with data.

Neither option is universally better. The right decision depends on your product requirements and available engineering resources.

Build vs buy embedded analytics for a SaaS app

One of the biggest decisions SaaS teams face is whether to build embedded analytics internally or use an existing platform.

Again, there isn't a universal right answer here. The best choice depends on your product requirements, engineering resources, timeline, and how important analytics is to your overall product strategy.

Building gives you complete control over the experience, but it also means taking ownership of everything that comes with it. Buying can help you launch faster and reduce maintenance, but it requires working within the capabilities of a platform.

The table below highlights some of the most important trade-offs.

Building embedded analytics internally

Building your own analytics experience gives you complete control over how dashboards, reports, and workflows look and behave.

This can make sense when analytics is a core part of the product and your team needs capabilities that aren't available through existing platforms. It also allows you to create experiences that align perfectly with your design system and product vision.

The challenge is that building analytics involves much more than creating charts and dashboards. Teams are also responsible for permissions, security, performance, scalability, filtering, dashboard management, and ongoing feature development.

For many companies, the biggest cost is the long-term maintenance required to keep the analytics experience secure, reliable, and up to date.

Buying an embedded analytics platform

Using an embedded analytics platform allows teams to deliver analytics much faster without building every component from scratch.

Many platforms provide dashboards, filtering, permissions, authentication, security controls, and reporting capabilities out of the box. This can significantly reduce development time and allow engineering teams to focus on core product functionality.

The trade-off is that every platform has limitations. Some offer more flexibility than others, but there will always be decisions about customization, integrations, pricing, and long-term vendor fit.

When evaluating embedded analytics platforms, it's worth considering:

• How much customization is required
• Whether the platform supports your security and authentication needs
• How well it integrates with your existing data stack
• The level of control you need over the user experience
• Long-term pricing and scalability

If you're exploring platform options, our guide to the top embedded analytics platforms compares some of the most common approaches and trade-offs to help narrow your shortlist.

Make the right long-term decision

Choosing how to embed analytics is never just a front-end decision. You’ll need to think about where you are at the moment and how much you’ll grow. Is an iframe enough, or will you outgrow it in six months? How do you show different customers different dashboards without creating a maintenance headache? Where should permissions and row-level security live? Is this something your team should build from scratch at all?

The answers to these questions will influence much more than implementation effort. They affect how easily analytics can scale, how secure customer data remains, how much flexibility you have to personalize the experience, and how much maintenance your team takes on over time.

The good news is that there are more options than ever before. Here is a list of useful resources if you want to continue your research:

• Explore Power BI Embedded alternatives
• Evaluate Looker Embedded alternatives
• Review Tableau alternatives for embedded analytics
• Compare Metabase alternatives

And if you’re interested in native customer-facing analytics, we invite you to explore Embeddable. You can give your customers native dashboards and conversational self-serve they can trust, while Embeddable handles the security, permissions, performance, and scale underneath.

‍

Frequently asked questions

‍

How do I embed analytics charts in external apps?

‍

The most common ways to embed analytics charts in external apps are through iframes, SDKs, Web Components, or APIs. The right approach depends on how much customization and control you need. iframes are typically the fastest option, while SDKs, Web Components, and headless approaches provide greater flexibility and a more integrated user experience.

‍

What's the best way to add user-facing analytics dashboards to my SaaS application?

‍

The best approach depends on your product requirements, timeline, the level of customization you need, and available engineering resources. Many SaaS teams start with embedded analytics because it provides dashboards, permissions, and security controls out of the box. If analytics is a core part of your product experience and requires extensive customization, a headless approach may be a better fit.

‍

How can I give each customer a different analytics view without hardcoding every dashboard?

‍

The most scalable approach is to use dashboard templates combined with user context, permissions, and row-level security. Instead of creating separate dashboards for every customer, a single dashboard can dynamically adjust what data, metrics, and functionality are available based on factors such as customer ID, role, region, or subscription tier.

‍

Can I embed analytics without using an iframe?

‍

Yes. Analytics can also be embedded using SDKs, Web Components, or headless BI architectures. These approaches provide more control over styling, interactions, and user experience than iframes, although they generally require more implementation effort.

‍

Is iframe or SDK better for embedded analytics?

‍

Neither is universally better. iframes are usually faster to implement and require less development work, making them a good choice when speed is the priority. SDKs offer greater customization and allow analytics to feel more integrated with the rest of the product, but they typically require more engineering effort to implement and maintain.

‍

What is row-level security in embedded analytics?

‍

Row-level security (RLS) is a security mechanism that ensures users only see the data they're authorized to access. For example, in a multi-tenant SaaS application, row-level security can prevent customers from viewing data belonging to other customers. RLS is often enforced through a combination of data-layer controls, query filtering, and user permissions.

‍

Do I need a full BI stack to embed analytics in my app?

‍

Not necessarily. Many embedded analytics platforms provide dashboards, reporting, permissions, and security features without requiring teams to build and maintain a complete BI stack themselves. However, organizations with highly complex reporting requirements or custom analytics experiences may choose to invest in additional BI infrastructure.

‍

What is headless BI and how is it different from embedded analytics?

‍

Headless BI provides the analytics capabilities behind the scenes while leaving the user interface entirely up to the development team. Traditional embedded analytics typically includes pre-built dashboards, charts, and reporting components that can be integrated into an application. Headless BI offers more flexibility and control, but it also requires more engineering effort to build and maintain the user experience.

‍

How long does it take to embed analytics in a SaaS app?

‍

The timeline depends on the approach you choose. iframe-based implementations can often be completed in days, while SDK-based integrations may take several weeks depending on customization requirements. Fully custom or headless BI implementations can take significantly longer because teams are responsible for building more of the analytics experience themselves. Factors such as authentication, security, data modeling, and customization also affect implementation time.

‍

How do I authenticate users for embedded dashboards?

‍

Users are typically authenticated through JWT tokens, single sign-on (SSO), signed embed URLs, or a combination of these methods. The goal is to securely identify the user before granting access to dashboards and data. Once authenticated, user information such as role, customer ID, region, or subscription tier can be used to control permissions and personalize the analytics experience.

‍