How to Choose an Embedded Analytics Platform

Once build vs buy is settled, choosing an embedded analytics platform takes six steps: write a test spec, give each part of the evaluation an owner, shortlist three vendors, run the same proof of concept with each, get prices in writing at today's size, 3x and 10x, then decide on the results.

This is different from buying an internal BI tool. Your customers will use the analytics inside your product, so the platform needs to work with your authentication, tenant permissions, interface and infrastructure. A convincing demo doesn't tell you whether any of that will hold up in production.

The six-step process below gives product teams a way to compare vendors using the same requirements and evidence. For the individual tests, use our embedded analytics POC checklist.

Before you start: settle build vs buy, write down your sizing numbers

Start only once you've decided to buy, with four sizing numbers written down: tenants today, viewers per tenant, data volume and, if AI is in scope, expected AI questions a month.

If the team is still debating whether to develop analytics internally, settle that first. Our build or buy guide covers the decision.

Next, define the customer experience you're buying the platform to deliver. Which users get analytics? What information should they see? Will they only view dashboards, or will some customers create their own reports and ask questions about their data?

A property management product might give landlords dashboards covering their buildings, while regional managers need aggregated views across several properties. Those are different reporting requirements even when they use the same underlying data.

Keep your sizing numbers available throughout the evaluation. You'll need them when vendors discuss capacity, commercial terms and what happens as adoption grows.

Step 1: Write the test spec

Write a one-page test spec before the first demo, because it is what every vendor gets tested against.

Start with three to five views customers genuinely need. For each one, record where analytics will appear in your product, who can access it and what the user should be able to do with the information.

Add your sizing numbers, then define one representative POC scenario.

A useful scenario includes one dashboard, one large or technically complicated customer, two or three user roles, one real data source and your tenant-security model. Include a few common interactions, such as changing filters or drilling into data. If self-service reporting or AI is part of the planned product, include one workflow for that too.

For example, a logistics platform could test a delivery-performance dashboard used by a customer account manager and a regional operations lead. Both roles use the same underlying data, but their permissions and available views differ.

Use the production-like scenario described in our POC checklist to keep the test realistic.

The specification should also reflect your analytics platform architecture, especially how identity, data access and rendering fit into the existing application.

Don't write separate requirements for each vendor. A single test spec makes the eventual comparison meaningful.

Step 2: Give each part of the evaluation an owner

Give every part of the evaluation one lead owner: evaluations stall when one person owns everything, or when security only shows up at the end.

An embedded analytics platform touches the product experience, infrastructure, data model and budget. Expecting a PM or engineering lead to evaluate all of those independently almost guarantees that something gets overlooked.

Assign the work before inviting vendors into the POC.

Owner	Responsibility	POC checklist
CPO or VP Product	Owns the business case and obtains written pricing proposals.	Test 9
Product Manager	Runs the POC, timeline and scorecard. Tests self-service and look and feel with a real customer user.	Tests 3 and 6
CTO or engineering lead	Evaluates the first dashboard, embedding, tenant isolation, integration effort and production readiness.	Tests 2, 3, 4, 7 and 10
Data team	Tests connectors, the data model, performance and whether AI answers stay grounded in governed metrics. Works with engineering on AI tenant safety.	Tests 1, 5 and 8
Finance	Reviews and signs off on the 3x and 10x commercial scenarios.	Test 9

This doesn't mean every department needs to attend every vendor call. It means each evaluation area has someone accountable for producing evidence and recording a decision.

The PM can coordinate the process, but engineering should own technical acceptance. Finance should see projected costs before the preferred vendor reaches contract negotiation, not after.

Product leadership also needs to establish stakeholder buy-in early. Agree on which requirements are non-negotiable and who has authority to reject a vendor.

A scorecard is much less useful when participants disagree about the decision criteria after testing has finished.

Step 3: Shortlist three vendors

Cut the long list to three vendors on paper, before any demo.

A long comparison spreadsheet can make an evaluation look thorough without bringing the team closer to a decision. The useful work is eliminating obvious mismatches early.

Remove vendors that primarily serve internal BI workflows and cannot support analytics used by customers inside your product. Rule out solutions without an embedding method that fits your stack, a viable commercial model for your sizing numbers or satisfactory answers to essential security questions.

Native embedding doesn't require one particular technology. An iframe, SDK or web component may be suitable if the resulting experience meets your product requirements.

Use the criteria in our embedded analytics tools guide to narrow the field, and ask each potential vendor to answer the relevant security questions in writing.

Three vendors are enough to compare substantially different approaches without turning the POC into a second full-time project.

Attuned Education Partners followed a similar process. Two senior engineers evaluated eight BI tools, hands-on tested three and ultimately selected Luzmo. Its case study documents how commercial fit and implementation support influenced that decision.

The lesson isn't that every team must start with eight vendors. It's that preliminary research should eliminate weak candidates before engineering starts building anything.

Step 4: Run the same POC with each vendor

Run the same proof of concept with every vendor, in the same window and the same order, so the results compare.

Use your own engineers, representative data and the test spec from Step 1. A vendor-led demo can be useful for orientation, but it should not determine the score.

Run the tests in this order:

1. Connect two tenants' data. Establish that the platform can work with your data structure and distinguish customer contexts. This corresponds to Test 1.
2. Build and embed the first useful dashboard. Have your engineers measure how long the work takes, including tenant-token integration. Use Test 2 and the basic embedding portion of Test 3.
3. Test tenant isolation. Before judging visual polish or advanced capabilities, run Test 4 and the security guide's negative tests. Include export and API access checks. A vendor that fails isolation should not continue through the evaluation.
4. Check look and feel. Complete the remaining part of Test 3 using your own product interface, not the vendor's demonstration environment.
5. Complete the remaining technical tests. Run Tests 5 through 8 and Test 10 with the owners assigned earlier. Test 9, commercial evaluation, belongs in Step 5.

The POC checklist contains the individual tests and scoring guidance. Our security guide details the negative tests, including checks that need to be repeated for self-service and AI workflows.

For Luzmo, the free 10-day trial gives teams access to the complete product, including white-label embedding, self-service and AI. Those capabilities are not reserved for a higher plan.

Actual hands-on use can change a vendor evaluation considerably. InTouch spent two months comparing analytics platforms before selecting Luzmo. The team's case study describes how the ability to create and maintain dashboards independently mattered more than an impressive demonstration.

That's what your POC should establish: whether your team can build, operate and support the analytics experience customers will actually use.

See how it works

Step 5: Get prices in writing at today's size, 3x and 10x

Ask every shortlisted vendor for a written price at today's size, at 3x and at 10x, on whatever they bill on.

Vendors may charge for monthly active users, sessions, capacity, AI conversations or a combination of variables. A low starting price tells you little about what happens when more customers adopt analytics.

Ask for a comparable commercial response using your sizing numbers.

Scenario	Information to request
Today	Platform fee, included usage, billable metrics and expected monthly cost
3x adoption	Expected charges as customers, usage and data grow
10x adoption	Expected charges, capacity assumptions and any contractual changes

Get the responses in writing. Test 9 in the POC checklist covers the commercial exercise, while our guide to how pricing models compare explains the different structures.

Luzmo publishes one Embedded Everywhere plan starting at €1,995 per month, billed annually. It combines a fixed platform fee with adoption-based usage and includes white-label, self-service and AI. The license includes 500 AI conversations and 100 million Warp rows monthly. Additional Warp usage costs €0.25 per million rows; additional AI conversations follow the contracted unit rate. Some contracts use monthly active users as the adoption metric.

Luzmo also states that usage spikes do not trigger retroactive back-billing, re-tiering or renegotiation before renewal.

Model those terms at 3x and 10x, exactly as you would for another vendor. Confirm the applicable currency and your specific billing variables on the Luzmo pricing page and in the written proposal.

Step 6: Decide on the results, then sign

Decide on test results, not on the demo, and take a one-page decision memo to the people who sign.

Use the POC scorecard and its decision rule. Tenant isolation remains a hard pass or fail, regardless of a vendor's performance elsewhere.

The decision memo should contain the scores, the written 3x and 10x prices, the expected integration effort and any unresolved risks.

A short memo makes the reasoning visible to people who weren't present throughout the evaluation. It also prevents a final sales conversation from replacing the evidence collected during the POC.

Before signing, work through the contract questions, including what happens when usage changes and how the team can exit the platform later.

Lansweeper's experience illustrates why the full business case matters. The company chose Luzmo rather than continuing its internal analytics build. Maarten Saeys, its CPO, explained that the engineering effort and opportunity cost made buying the more sensible option.

As Saeys put it, choosing Luzmo was "just the sensible thing to do." The Lansweeper case study describes how the team avoided years of additional dashboard development.

The winning vendor should be the one your team can use safely, maintain independently and afford as adoption grows. The most impressive demonstration is not necessarily the best long-term product decision.

Start building for free

Common evaluation mistakes

Most evaluations go wrong in one of five ways.

• Judging the vendor's demo data instead of your own. A polished dashboard using carefully prepared sample data tells you little about your real integration.
• Leaving the evaluation to one person. Product, engineering, data and finance need clearly assigned responsibilities.
• Shortlisting five or more vendors. A large shortlist spreads engineering effort across too many experiments and makes meaningful comparisons harder.
• Pricing only today's usage. A platform that fits your current budget may become expensive when customer adoption increases.
• Testing AI on a vendor's prepared questions. If AI is in scope, test whether it stays grounded in your governed metrics, respects tenant permissions and handles questions from your own users.

None of these requires a complicated procurement process to avoid. A shared test spec, clear ownership and comparable evidence solve most of the problem.

Choose with evidence, not a demo

Use the same test spec, owners, POC and written pricing scenarios for every shortlisted vendor. Once you know which platform meets the requirements, the contract decision becomes considerably easier.

Book a demo to evaluate Luzmo against your product's requirements.