How to embed Looker into your SaaS product cleanly

Embedded analytics is the feature that gets greenlit in a single executive call and then sits in the backlog for nine months. Sales promises it. PMs scope it. Engineering looks at the auth model and finds something else to do.

When teams finally ship something, it's usually a Looker iframe behind an SSO redirect, dropped onto a page called "Analytics" with no further thought. Customers click in once, see a generic dashboard that doesn't match the rest of the product, and never come back. The product team writes it off as a feature nobody wanted, and the Looker bill keeps coming.

Looker is the right tool for customer-facing analytics. The semantic layer means every customer sees consistent numbers, row-level security keeps tenants isolated, and the embed SDK supports theming down to the chart-tooltip level. The reason most embeds fail isn't the tool. It's that no one treats the embed like a product surface. Below is what mid-market SaaS teams typically miss, the five plays we build to fix it, and the failure modes worth knowing before you start.

The Embed Problem Most Looker Customers Have

• A single dashboard gets embedded, and every customer sees the same one regardless of plan tier, persona, or use case.
• The iframe loads inside the app but the styling jumps. Different fonts, different colours, default Looker chrome. It feels like a third-party tool because it is one.
• Row-level security is implemented with one global rule that filters by customer_id. As soon as the product adds teams, roles, or sub-accounts, the model breaks and engineers patch it with view-specific hacks.
• Customers can't act on what they see. The dashboard shows a problem (failed deliveries, declining usage, an at-risk metric) but there's no way to click through to fix it. Analytics is read-only.
• No one tracks who actually uses the embed. The product team can't answer a basic question: is this driving retention, or is it dead weight we're paying Looker licences for?

Automation Plays We Build with Looker

These are the five builds we run for SaaS companies shipping Looker as a customer-facing feature. None of them require a Looker overhaul. They sit on top of the semantic layer you already have.

1. Signed embed with tenant-aware row-level security

Trigger: a customer opens the analytics tab in your app. Workflow: your backend mints a signed Looker embed URL with user-attributes for org_id, role, and plan_tier. Looker's access_filter clauses inside LookML enforce row-level filtering automatically, so a junior PM at customer A literally cannot query customer B's data, even if they craft a request manually. The same model handles internal users via a different role attribute, so your CS team sees everyone, your customers see only themselves, and there's one source of truth for both. Outcome: a single embed config that scales to every tenant without per-customer dashboards or duplicated models.

2. Themed dashboards that disappear into your product

Trigger: the embed loads. Workflow: a custom Looker theme matches your product's fonts, colours, chart palette, and border radius. We pass the user's theme preference (light, dark, or system) through the embed SDK and Looker re-renders accordingly. The iframe drops the Looker chrome entirely. Outcome: customers don't realise they're looking at a third-party BI tool. The analytics tab feels like part of the product, which is the only way users treat it that way.

3. Click-through from chart to action

Trigger: a customer clicks a row in an embedded Looker table, for example a failed payment, an at-risk user, or a slow campaign. Workflow: Looker's Data Action posts the row's payload to your backend, which routes it to the right next step in the app: retry the payment, send a re-engagement email via your sequencing tool, or open the relevant settings page. Outcome: the dashboard stops being a museum exhibit and becomes the entry point to fixing things, which is what customers actually want when they look at data.

4. Conversational analytics inside your app

Trigger: a customer types a question into a chat input embedded next to the dashboard. Workflow: the question hits Looker's Conversational Analytics API, which uses Gemini grounded in your LookML model to translate it into an Explore query and return a chart plus a written summary. Outcome: non-technical users at your customer org get answers without needing a CS rep or a custom report. Power users keep the dashboards. Everyone else gets a natural-language interface to the same data, and they all see numbers that match because the semantic layer is the only place those metrics get defined.

5. Threshold alerts that route to the right team

Trigger: a Looker scheduled plan detects a metric crossing a threshold (a paying account drops below its expected usage band, churn risk for a segment spikes, a key customer's API errors climb). Workflow: Looker fires a webhook into n8n or directly to Slack and your CRM. The right CS rep, AE, or on-call engineer gets a message with context, a deep link to the dashboard, and the account record opened in Salesforce or HubSpot. Outcome: the team finds out about problems on the same day they show up in data, instead of in the next QBR.

How Looker Should Integrate With Your Stack

• Warehouse first. BigQuery, Snowflake, Redshift, or Databricks should be the only source of truth Looker queries. Production database read replicas are an anti-pattern. Model in dbt, expose to Looker via LookML.
• Auth from your IdP. Customer SSO into the embed runs through your app's existing session, then your backend signs the Looker URL. No separate Looker user accounts for customers. Internal users sign in via Okta or Google Workspace SSO.
• Action Hub wired to your CRM. Internal Looker users should be able to push customer health scores, churn risk flags, and product-qualified-lead signals from a dashboard row directly into Salesforce or HubSpot.
• Slack for alerts, not for dashboards. Threshold alerts and scheduled summaries belong in Slack. Full dashboards stay in the app or Looker. Don't try to make Slack into a BI viewer.
• Usage analytics on the embed itself. Pipe Looker's system__activity (queries, dashboard views, embed sessions) back into your warehouse so the product team can see which customers actually use analytics and which never open the tab.
• CI/CD on LookML. Spectacles or Looker's native CI validates every PR against your warehouse. A junior analyst can ship a model change without breaking the embedded customer dashboard.

What ROI Actually Looks Like

Ranges below are indicative, not promised. Outcomes depend on your existing data maturity, customer base, and how aggressively you treat the embed as a product surface.

• Analytics tab adoption: typically lands between 25% and 60% of paying accounts touching the embed monthly, up from the 5% to 15% most static iframes get.
• CS team reporting workload: usually drops 30% to 50%. Customers self-serve answers that previously required a CS rep to pull a custom report.
• Engineering time spent on internal reporting tickets: usually cuts in half. Internal teams stop asking engineers for one-off queries because the embed and Conversational Analytics cover most cases.
• Net revenue retention lift: harder to attribute directly, but customers who actively use embedded analytics typically retain 5 to 15 points higher than ones who don't. Treat that as correlation worth investigating, not a guaranteed lever.
• Time-to-first-insight for a new customer: usually drops from days (raise a ticket, wait for a CS rep, get a custom export) to minutes (open the analytics tab, ask the question in plain English, get an answer). That speed compounds across thousands of sessions.

Where Teams Go Wrong

Four failure modes show up over and over. None are about Looker itself. All are about how it gets deployed.

Skipping the semantic layer

Teams that want to ship fast often build dashboards in Looker's SQL Runner instead of modelling in LookML. Six months later they have 40 dashboards, 12 conflicting definitions of "active user", and no way to refactor. Build the model first, even when it slows the first dashboard by two weeks. The compounding cost of not modelling is huge: every new report becomes a forensic investigation, and the AI features stop working because they have nothing reliable to reason over.

Row-level security as an afterthought

Multi-tenant isolation must live in LookML access_filters from day one, not in the application layer. A customer seeing another customer's data once is a breach. Build the auth model before you build the second dashboard.

No theming budget

Companies invest months in a design system, then ship an embedded analytics surface that uses Looker's default fonts and colours. The visual jump tells customers "this is a third-party tool we bolted on" and they treat it accordingly. Theming is two days of work, not optional.

Ignoring the embed's own usage data

Most teams don't track which customers use the embed, which dashboards get viewed, or where users drop off. Without that, you can't tell if the feature is worth the Looker spend or which charts to kill. Pipe system__activity into your warehouse and treat embed usage like any other product metric.

Where Moonira Comes In

We build customer-facing Looker embeds end to end: the LookML model, the access_filter security layer, the signed-URL backend, the theme, the Data Action wiring, and the Conversational Analytics integration. We also wire up the internal side, so your CS and revenue teams get the same numbers your customers do, with alerts and CRM write-back.

If you've already invested in Looker and the embed feels like an iframe nobody uses, that's the build we run. If you're choosing a BI tool and Looker is on the shortlist, we can scope the work before you sign the contract.