Once you deliver on your core product promise, the next thing your customers will undoubtedly ask 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, [pick your domain].

This need for insight is universally true for both internal and customer-facing apps. If you’re providing Saas, offering robust analytics right into your product can set you apart from the competition and even open up new revenue streams. But launching customer-facing analytics can lead you to 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

From my consulting days, I’ve learned that every organization, team, or 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. 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 are presenting data from object stores like S3, you need to have on-demand caching to maintain acceptable performance.

A lot of companies think they can handle this 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 then AaaayEyee (AI). Suddenly, you’re spending more time on analytics than on your actual product.

One of our customers summed it up well:

“Analytics is a necessary part of 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 works if you are embedding a dashboard in wikis or small internal apps. But if you’re building a 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 stand alone 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 engineering 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 deliver exactly what your customers need.
  Use

• 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 throwaway 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 provide must be intuitive and shouldn’t require training.

There’s a new wave of products — like Semaphor — that are taking this approach.

Introducing Semaphor

Semaphor is a fully customizable analytics package for delivering user-facing analytics in your apps.

We took our inspiration from Stripe! Just like when you want to collect payments in your app, you don’t build a full-blown payments collection infrastructure from scratch. You use something like Stripe! With just a few lines of code, you can start collecting payments. This way, you can focus on what makes your product unique.

We do the same for analytics. If you want to launch fully-responsive, AI-powered, interactive analytics in your app, you 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 what Semaphor brings:

• Open Standards: We understand SQL and Python and you get complete 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.

If you want to learn more, set up a demo here.