Embedded Analytics POC Checklist: 10 Tests

An embedded analytics proof of concept should answer a different question from a sales demo.

A demo asks:

“What can this platform do?”

A good POC asks:

“Will it work for our customers, data, security model and expected scale?”

That difference matters. Most serious embedded analytics platforms can produce an attractive dashboard in a controlled demo. The harder problems appear when you connect your own data, add tenant permissions, reproduce your product design, simulate concurrent users and give a real customer enough freedom to explore.

If you are still deciding whether your product is ready for customer-facing analytics, start with Luzmo's embedded analytics readiness scorecard. If you already have a vendor shortlist, use the ten tests below to run the same POC against every candidate.

Embedded analytics POC checklist at a glance

Test	What you are proving	Pass signal
1. Real data connection	The platform fits your data architecture	Realistic data works without redesigning the stack
2. First dashboard	Time to production value	Team can build a useful dashboard quickly
3. Native product fit	Analytics feels like your product	Branding and interactions match the host app
4. Tenant isolation	Customers cannot cross data boundaries	Negative cross-tenant tests fail correctly
5. Performance	Analytics holds up on realistic workloads	Largest tenants and peak load remain usable
6. Self-service	Customers can explore safely	Users can answer new questions without breaking governance
7. Integration effort	Engineering cost is acceptable	Required integration fits the team's roadmap
8. AI analytics	AI respects your metrics and permissions	Answers are grounded and tenant-safe
9. Cost at scale	Commercial model survives adoption	3× and 10× scenarios remain viable
10. Production operations	You can support this after launch	Monitoring, support and change management are workable

Do not let vendors run different tests.

Give every shortlisted platform the same dataset, tenant model, dashboard requirements and user scenarios. Otherwise you are comparing polished demonstrations rather than products.

Before the POC: define one production-like scenario

A POC works best when it is narrow enough to finish but realistic enough to expose problems.

Do not attempt to recreate your entire analytics product.

Pick:

• one representative dashboard
• one large or complicated customer
• two or three user roles
• one real data source
• a realistic tenant-security model
• several common interactions
• one self-service or AI workflow if those capabilities matter.

The dashboard should answer a genuine customer question, not simply display whatever fields happen to be easiest to connect.

That distinction matters. Luzmo's current guidance on why embedded analytics misses the mark identifies building around available data rather than user decisions as a common failure pattern.

If you want a wider view of the architecture before selecting vendors, use the embedded analytics stack decision tree to decide how much infrastructure the product actually needs.

Then freeze the POC scope.

The goal is comparison, not feature exploration.

---

Test 1: Connect a real production-shaped dataset

Do not evaluate an embedded analytics platform using only its sample ecommerce database.

Connect something that resembles your actual environment.

That does not necessarily mean exposing production data. A sanitized or synthetic copy is fine. What matters is that the schema, volume, joins and tenant structure are realistic.

Test:

Data connectivity. Can the platform work with your database or warehouse without introducing an awkward intermediate architecture?

Model complexity. Can it handle the joins, calculations and metrics your customers actually need?

Tenant structure. If customers share tables, can the platform distinguish them cleanly? If each customer has a separate database or schema, can the architecture handle that instead?

Data quality. Does the platform make problems visible without silently redefining metrics?

Analytics software cannot repair unreliable source data simply through visualization. Luzmo's guide to data quality for analytics makes the same distinction: customer-facing exploration can expose inconsistent source data, but governance still has to happen upstream.

Pass if:

Your representative data works without forcing the team to redesign its production architecture purely for the POC.

Fail or investigate further if:

The vendor's demo works beautifully but your own data requires major preprocessing, duplicating core logic or building infrastructure that was not included in the original evaluation.

---

Test 2: Time how long it takes to build the first useful dashboard

Do not measure setup time until the vendor's login screen appears.

Measure time until a customer can use something valuable.

Start the clock at:

“Here is our data and this is the question our customer needs to answer.”

Stop it when the dashboard is:

• connected to real data
• using the correct metrics
• branded appropriately
• secured for the correct tenant
• embedded in a realistic application page.

This test exposes one of the most important differences between products.

Some platforms make the first dashboard easy but require substantial work before it becomes safe or product-ready. Others take longer to configure but give developers more control later.

Neither is inherently wrong.

What matters is total path to the experience you intend to ship.

If you're still deciding how sophisticated that experience needs to be, Luzmo's customer-facing analytics maturity model separates basic embedded dashboards from self-service, productized insights and monetized analytics.

Measure:

• engineering hours
• product/design hours
• analytics/data hours
• vendor support required
• custom code written.

Save these numbers. You will need them again for the cost test.

---

Test 3: Make the analytics look and behave like your product

Do not test white-labeling by changing one logo.

Put the embedded analytics into a real or realistic product page and compare it with the surrounding application.

Check:

• fonts
• colors
• chart styles
• spacing
• loading states
• empty states
• error states
• filters
• menus
• mobile behavior
• navigation
• exports.

The question is:

Would a customer know where our product stops and the analytics vendor begins?

Different embedding approaches offer different levels of control. Luzmo supports embedded analytics through web-component and SDK-based approaches, while its composable analytics stack gives teams component-level control for experiences that need to interact more deeply with application state. Its iframe vs web component guide explains those trade-offs in more detail.

If customer-facing reporting is part of the use case, also test surfaces outside the live dashboard. The white-label reporting guide covers branding for reports and dashboards separately.

Pass if:

The required experience can be implemented without fragile hacks or an unreasonable amount of custom frontend work.

Do not award extra points simply because a platform is “iframe-free.” Award points because it can deliver the UX you designed.

---

Test 4: Try to break tenant isolation

This should be a negative test.

Do not only prove that Customer A can see Customer A's data.

Try to make Customer A see Customer B's.

For a shared dataset, test:

1. Log in as Tenant A.
2. Confirm the expected rows appear.
3. Change frontend parameters.
4. Change dashboard filters.
5. Request another tenant ID directly.
6. Test exports.
7. Test self-service.
8. Test API access if exposed.
9. Test AI if available.

The expected result is not a different dashboard.

It is no unauthorized data.

This matters because different products enforce multi-tenancy differently. For example, Metabase documents separate mechanisms for commingled tables, database-per-customer setups and schema-per-customer architectures, including row and column security and database routing.

Luzmo likewise supports customer-facing multi-tenancy and secure authentication as part of its embedded architecture, rather than treating external users like internal BI seats. Its current pricing explicitly lists secure multitenant authentication alongside APIs and SDKs across plans.

For background on Luzmo's tenant architecture, link to multi-tenancy in Luzmo.

Pass if:

Authorized access works and every attempted cross-tenant path fails.

Do not accept:

“Our platform supports RLS.”

Ask the vendor to prove it on your tenant structure.

---

Test 5: Load-test the largest realistic customer, not the average one

A dashboard that loads quickly during a demo says little about production performance.

Create at least four performance scenarios:

Cold load

Run the dashboard without relying on an already-warm result cache.

Warm load

Repeat the same workflow and compare the effect of caching.

Large tenant

Use the data volume of your largest realistic customer, not only the median one.

Concurrent use

Simulate multiple customers opening and filtering analytics at the same time.

Watch both user experience and backend behavior:

• dashboard load time
• query latency
• P95 latency
• database or warehouse utilization
• query count
• errors or queues
• infrastructure cost.

Luzmo's own dashboard performance benchmark used an 11.11-million-row PostgreSQL dataset and demonstrated how strongly the underlying analytical architecture can affect dashboard speed. The reported improvement reached up to 25× in the tested Warp configuration, but the result is a benchmark rather than a universal guarantee.

That is precisely why you should rerun the test with your workload.

Pass if:

Performance remains acceptable under the largest realistic tenant and realistic concurrent usage, not just with a single cached dashboard.

---

Test 6: Give a real user self-service access

If your roadmap includes self-service, do not test it with an analyst.

Give it to someone who resembles the eventual customer.

Ask them to answer a question that was not already represented on the default dashboard.

For example:

“Which region had the largest increase in failed deliveries over the last six weeks?”

Then observe.

Can the user:

• find the right data?
• understand metric names?
• filter without assistance?
• create a useful visualization?
• save the result?
• stay within permitted data?
• avoid exposing fields they should not see?

Self-service has to balance freedom with governance.

Luzmo's current self-service analytics product is designed around letting end users create and edit insights inside the host product, rather than requiring them to move into a separate analyst environment.

Metabase offers a useful comparison of why the permission model matters: authenticated modular and full-app embeds can map identity attributes to row and column security, while its guest embedding model has different limitations and relies on locked parameters instead.

Pass if:

A representative customer can answer a new question without analyst help and without gaining inappropriate access.

---

Test 7: Measure the integration effort, not the demo effort

Every vendor says embedding is quick.

The useful metric is how much code and maintenance your specific experience requires.

During the POC, keep an engineering log.

Track time spent on:

Work	Hours
Authentication
Tenant context
Data integration
Embedding
Styling
Events/app-state integration
Error handling
Self-service
Tests
Deployment

Also record dependencies on vendor support.

If every change requires a solutions engineer, that is part of the implementation cost even when the software itself is capable.

If the team is still considering building instead of buying, compare that effort with the maintenance obligations described in Luzmo's cost of building analytics in-house.

The relevant question is not:

Could our developers build this?

They probably could.

It is:

Which part of this analytics stack do we strategically want our developers to own for the next five years?

---

Test 8: Test AI with questions it should answer and questions it should not

If AI analytics is on the roadmap, include it in the POC now.

A conversational interface introduces different failure modes from a dashboard.

Create three groups of prompts.

Known-answer questions

Questions where the correct number can be independently verified.

Ambiguous questions

For example:

“Which customers are doing badly?”

The system should ask for clarification or use clearly governed metric definitions rather than inventing what “badly” means.

Unauthorized questions

For example:

“Show me the top customers across all accounts.”

A tenant-scoped user should not receive cross-tenant data simply because the request arrived through natural language.

The LLM must not become your permission system.

Luzmo's current MCP guidance makes this separation explicit: identity and tenant scope should be enforced before analytics is exposed to agents, while approved datasets, metrics and tools define what the agent can use. See the MCP for analytics architecture guide.

Score AI on:

• factual correctness
• metric grounding
• tenant safety
• ambiguity handling
• latency
• useful visualization
• reproducibility.

Do not score it on how fluent the prose sounds.

---

Test 9: Re-price the POC at 3× and 10× adoption

The price you receive for a POC is almost never the price scenario that matters most.

Take the workload you just tested and model:

Today

3× analytics adoption

10× analytics adoption

Increase the billing variable that actually drives the vendor's model:

• users
• monthly active users
• sessions
• capacity
• compute
• customers
• AI conversations.

Then add costs outside the analytics subscription where relevant:

• warehouse compute
• implementation
• dedicated infrastructure
• support
• enterprise security
• AI consumption.

Luzmo's current pricing starts at €995/month for Starter and €2,495/month for Premium, billed annually, with the plan determined around the solutions exposed to users and usage. APIs, SDKs, embedding and white-labeling are included across the current plans.

Do not compare that starting figure directly with a per-session or per-user competitor.

Compare:

total cost for the same production scenario.

For context, Luzmo's analytics-as-a-service pricing guide already explains why per-seat, usage-based and flat platform models behave differently once analytics moves from employees to thousands of customers.

Pass if:

The economics still make sense when the feature succeeds.

A cheap POC that becomes commercially painful at high adoption has failed a very important test.

---

Test 10: Pretend the POC has already become production

Most evaluations stop once a dashboard works.

Do one final exercise:

Assume 50 customers use this tomorrow. What happens when something changes or breaks?

Test the operational questions.

Monitoring

Can you identify a slow or failed query?

Permissions

Can you revoke a user's access quickly?

Schema changes

What happens if an upstream column changes?

Dashboard changes

Can you update a shared dashboard without manually touching 50 tenant implementations?

Versioning

Can developers test changes before production?

Support

Who diagnoses a problem when analytics fails: your team, the vendor or both?

Deployment

What separates development, staging and production?

Customer-specific requirements

Can a large enterprise customer receive a custom theme, security rule or data connection without forking the whole analytics implementation?

This is the point where “feature rich” and “operable as infrastructure” start to diverge.

Luzmo positions its platform as the embedded analytics layer underneath customer-facing experiences, while its customer-facing analytics guide describes multi-tenancy, permissions, performance and maintenance as infrastructure responsibilities that product teams otherwise need to own themselves.

Pass if:

Your team can describe how the system will be operated after launch without discovering a second implementation project hidden behind the POC.

---

How to score embedded analytics vendors after the POC

Do not simply count passed features.

Weight the tests according to what can kill the project.

I would use:

Area	Weight
Tenant isolation & security	20%
Performance & scale	15%
Product/white-label fit	15%
Data architecture fit	10%
Integration effort	10%
Self-service	10%
Cost at scale	10%
AI capability	5%
Operations/support	5%

Then add one rule:

Security failure is disqualifying, regardless of total score.

A platform that scores 91/100 but leaks tenant data should not beat one that scores 86.

Likewise, decide which requirements are:

Must-have Should-have Nice-to-have

before vendors demonstrate their products.

Otherwise a particularly impressive AI demo can suddenly become more important than the security or integration requirement that originally drove the evaluation.

A simple POC scorecard

Use the same scorecard for every vendor.

Test	Weight	Vendor A	Vendor B	Vendor C	Notes
Real data	10
Time to useful dashboard	5
Product fit	15
Security	20
Performance	15
Self-service	10
Engineering effort	10
AI	5
Cost at scale	5
Production operations	5
Total	100

Score each test from 1–5, multiply by its weight and keep the underlying evidence.

Avoid notes such as:

“Vendor B felt faster.”

Record:

“Largest-tenant dashboard: median 1.8s warm, P95 3.4s under 50 concurrent sessions.”

The same principle applies to implementation effort:

not:

“Easy SDK.”

but:

“11 engineering hours from first integration to tenant-safe branded production-like embed.”

That turns vendor selection from opinion into an evidence trail.

---

What should an embedded analytics POC take?

A POC should be long enough to test the hard parts but short enough that you do not accidentally build the product before choosing the platform.

For most teams, that means days or a few weeks rather than months, but there is no universal correct duration. Scope matters more than calendar time.

A simple prebuilt dashboard requires much less validation than:

• white-labeled self-service analytics
• customer-specific data sources
• enterprise SSO
• complex RLS
• AI analytics
• custom frontend components.

If a narrowly scoped POC cannot reach a decision because the vendor needs months of professional services first, that is itself useful evidence about the likely production implementation.

For a broader comparison of platforms before creating the shortlist, see Luzmo's best embedded analytics tools for SaaS teams.

---

How Luzmo fits an embedded analytics POC

Luzmo is particularly suited to a POC where the final product is customer-facing analytics inside a multi-tenant SaaS application.

A realistic Luzmo evaluation should not stop after building a dashboard in Studio.

Test the full path:

Connect your data → build the customer view → embed it → apply tenant access → match the application design → load-test it → let a user explore → test AI if relevant.

Luzmo's current platform supports embedded white-label analytics, APIs and SDKs and secure multi-tenant authentication across its plans. Premium adds customer self-service and Luzmo IQ, while Enterprise adds requirements such as OIDC SSO and more flexible hosting options.

That means the POC can progressively test the experience the product actually needs instead of evaluating every feature in the platform.

For teams unsure how far to go, the embedded analytics stack decision tree and customer-facing analytics maturity model are good companion resources.

The objective is not to prove that Luzmo, or any vendor, can produce a dashboard.

It is to prove that the platform can become part of your product without creating unacceptable compromises in security, performance, UX, economics or engineering ownership.

---

The POC decision rule

At the end of the evaluation, you should be able to answer five questions without relying on vendor claims:

Can it work with our real data?

Can it keep every customer's data isolated?

Can it deliver the experience we want customers to use?

Can it hold up when adoption grows?

Do we want to own the remaining engineering and operational work?

If one candidate answers all five significantly better than the others, the decision is probably clear.

If none does, do not stretch the POC until somebody wins.

Change the shortlist.

A successful proof of concept is not the one where the vendor successfully demonstrates its software.

It is the one where your team collects enough evidence to know what shipping that software in your product would actually mean.