The Right Way to Approach User-Facing Analyics

Once you deliver on your core product promise, the next thing your customers will undoubtedly want is better visibility and reporting around the business process your software enables. They want to track metrics, trends, and patterns around the “thing” your software helps them manage. At its core, almost every product we use helps us manage something we care about, whether it’s calls, schedules, shipments, meetings, jobs, interviews, people, or [pick your domain].

If you deliver software-as-service, infusing insights right into your product isn't just an enhancement—it’s a key differentiator. It can set you apart from the competition and even unlock new revenue streams that you may not have considered. This need for insight is universally true for both internal and customer-facing apps. Sometimes it’s overtly expressed; other times it lies beneath the surface, waiting to be uncovered. But launching customer-facing analytics can lead you to costly false starts and wasted effort if you underestimate the following:

1) The Analytics Scope Snowballs

What starts as a simple feature request often evolves into a substantial project — sometimes even larger than the core product itself. For startups and mid-sized companies, this can be a real problem. Every time a customer asks for a new visual or a tweak to a dashboard, it turns into a new product feature request (PFR) for your engineering team and requires a full code build, test, release cycle.

2) Analytics isn’t One Size Fits All

Speaking to hundreds of organizations, we have learned that every client wants a slightly different view of the same data. And they’re not wrong — users have their own goals to meet and have preferences on how they want to see their data, or narrow down to only what’s relevant to them. A read-only canned dashboard is hardly ever useful.

3) Security and Performance: Non-Negotiables

When you externalize analytics, i.e., make your data accessible to users outside of your organization, you need to think about how to best isolate the data between clients. With multiple users — and potentially multiple organizations — using your app, you’ll need to build a multi-tenant architecture that spans different analytical stores. If you present data from object stores like S3, you also need to have on-demand caching to maintain acceptable performance.

Many companies think they can handle this scope in-house. After all, how hard can it be to add a few charts, right? But here’s the thing: when you give users a chart, they’ll want a dashboard. Give them a dashboard, and they’ll ask for filters. Before you know it, they’ll be asking for custom views, and now AI. Suddenly, you’re spending more engineering time and resources on analytics than on your actual product.

One of our customers summed it up well:

Analytics is a must-have for our product, but it shouldn’t come at the expense of slowing down our core roadmap.

The Common Approach (And Why It Doesn’t Work)

So, what do most companies do? They turn to their old-guard BI tools. The legacy BI vendors are more than happy to shrink-wrap their whole product into an iframe and tell you to just drop it into your app. This approach might suffice if you want a dashboard embedded in wikis or small internal apps. But if you’re building a professional-grade customer-facing app, this approach can lead to some serious issues.

• Bloated Apps: Those iframes come with a lot of unnecessary code, which can bloat your app. Why? Because all those legacy BI tools were NEVER built to live inside of your apps. They were built as standalone apps for internal BI needs.
• A Frankenstein Experience: Your app can end up looking like a disjointed mess, with limited styling options and a user experience that doesn’t respond well to different screen sizes. Every small customization seems like a band-aid fix, piling on more inconsistencies and leaving your app feeling more fragmented with each change.
• Opaque and Restrictive: These tools often hold your data hostage, requiring proprietary tech to view analytics. You might not even be able to view the underlying business logic of the chart, let alone modify it. You will be forced to do things the BI way, and not the way your application expects. Plus, managing users in both the BI tool and your app can become a nightmare. So the next time you hear the term “Unified BI,” think “Bloated BI.”

The Right Approach

Decouple Analytics from Product Code

This decoupling allows you to 2X your shipping velocity. When you separate your product codebase from analytics, you can move faster. Your product team can focus on the core features, while your customer success team can rapidly prototype and launch new experiences without touching the product code.

Go for Open Standards

Choose technologies where you can see and control the code behind your analytics. This transparency gives you the flexibility to fine-tune the business logic and deliver exactly what your customers need.

Use Framework-Specific Components

Choose a tool that’s designed from the ground up to live inside of your app as a first-class citizen. Use native components such as React, Vue, or Web Components. This approach lets you create a responsive, cohesive experience for your users.

Stick to Modern Web Standards

HTML, JavaScript, and CSS aren’t going anywhere. While nifty Python-based wrappers like Streamlit are great for quick prototypes, when it’s time to ship, native web technologies perform better and are easier to maintain and customize. Do it the right way the first time.

Keep It Simple and Flexible

Most BI tools are overly complex, requiring too many steps to do something simple. Less is sometimes more when it comes to customer-facing analytics. The analytics experience you enable should be intuitive and shouldn’t require training.

At Semaphor (opens in a new tab), we are taking this approach. Semaphor is an embedded analytics solution for delivering user-facing analytics in your apps.

We take our inspiration from Stripe. For instance, when you need to integrate payments in your software, you don't waste time building a comprehensive payment system from the ground up. You turn to a solution like Stripe. With just a few lines of code, you can start collecting payments. This way you can focus on the core of what makes your product unique instead of worrying about payments.

We do the same for analytics. If you want to launch fully-responsive, AI-powered, interactive analytics in your app, you can use Semaphor. With just a few lines of code, you can deliver branded analytics in your app. You can style almost everything to precisely match the look and feel of your app.

Semaphor offers a canvas experience where users can view a set of visuals and engage with a dashboard conversationally. As they discover new insights, they can easily add them to the existing dashboard and personalize the experience. This is fundamentally different from the read-only dashboards provided by legacy BI vendors.

Here’s how Semaphor is unique:

• Open Standards: We are built with open standards. We understand natural language, SQL, and Python, giving you full transparency and control over how every insight is generated. No lock-in, just flexible, powerful analytics.
• Plug and Play: Use framework-specific components like React, Vue, or Web Components to render insights directly into your product — no clunky iframes!
• Deep Customization: Tailor every aspect of your dashboard — styles, fonts, colors — to match your brand. Bring your own visuals if you like and create layouts that look great on any device.
• Real-Time Insights: Deliver insights at the speed of your business — as fast as your data comes in, and wherever it comes from, whether it is databases, APIs, or other sources.
• Dashboard-as-Code: Manage your dashboards as code — version control and automate deployments just like any other software. Your dashboards always remain secure, version-controlled, and consistently backed up.

Curious to learn more? Set up a demo here (opens in a new tab).