Count

Which data the product can reach and how it stays current: native connectors to databases and warehouses (PostgreSQL, MySQL, SQL Server, BigQuery, Snowflake), to business applications (accounting, ERP, CRM, shop, help desk, ad platforms) and to files and spreadsheets (Excel, CSV, Google Sheets), live queries versus imported extracts, scheduled and incremental refresh with its minimum interval, joining data from several sources, light data preparation, access to databases behind a firewall (gateway, SSH tunnel, IP allow-list), and a generic REST or custom connector for what is not listed.

0 — Not a reporting product, or data can only be typed or pasted in by hand.

3 — Spreadsheet and file uploads plus a handful of named connectors; refresh schedules, live queries and blending sources are basic or not described.

5 — A published connector list covering the common databases, warehouses, spreadsheets and several named business applications, scheduled refresh with its interval stated, live queries or extracts at the customer's choice, data from two sources combined in one report, and a documented way to reach a database behind a firewall.

8 — Hundreds of maintained connectors or a full SQL layer over every major warehouse, incremental refresh and caching explained, a built-in data preparation or modelling step, a gateway or agent for on-premise sources, a generic REST or custom connector SDK, and connector limits (rows, API calls, history) stated per plan.

10 — Connectivity an organisation can standardise on: every source reachable live or by extract with the trade-offs documented, refresh down to minutes with lineage from report back to source, source changes detected and reported, and connector behaviour, quotas and failure handling published.

What can be built and how readers use it: the range of chart types, tables and pivot tables, maps, KPI tiles with targets and comparisons, dashboard layout, filters and date controls that apply across a dashboard, drill-down and drill-through, cross-filtering by clicking a chart, templates for common sources, mobile and TV display, theming to the company's design, number formatting and localisation (decimal comma, currencies, German date formats), and accessibility of the result.

0 — No charts or dashboards; the product only stores or moves data.

3 — Standard bar, line and pie charts and a table on a dashboard; filters, drill-down and mobile display are basic or not described.

5 — A broad chart library with pivot tables, maps and KPI tiles with comparison to a previous period or target, dashboard-wide filters and date ranges, drill-down, templates for common sources, a mobile view, and number and date formats localised.

8 — Cross-filtering and drill-through between dashboards, custom visuals or a chart SDK, conditional formatting and annotations, dashboards themed to a brand, TV and presentation modes, pixel-exact or paginated reports for print, and accessibility of charts documented.

10 — Dashboards that a whole organisation reads daily: every interaction (filter, drill, cross-filter, parameter) available to readers without editor rights, performance on large data stated, accessibility conformance (WCAG) published, and every chart reproducible from a documented query.

Whether people outside the data team can answer their own questions and whether everyone gets the same answer: a visual query builder, a SQL editor for analysts, calculated fields and formulas, a semantic layer or data model where metrics such as revenue or churn are defined once and reused, metric definitions under version control (Git, dbt integration), questions in natural language with the generated query shown, forecasting and anomaly detection with the method stated, and notebooks or Python for deeper analysis.

0 — Dashboards can only be viewed; no one can ask a new question of the data.

3 — Charts are configured from a field list and simple calculated fields; shared metric definitions, SQL and a query builder are basic or not described.

5 — A visual query builder for business users and a SQL editor for analysts, calculated fields and formulas, saved questions reused across dashboards, a data model or dataset layer where joins and metrics are defined once, and natural-language questions that show the query they ran.

8 — A semantic layer with governed metrics and dimensions reused across every report, definitions in code under Git version control or synced with dbt, certified or endorsed datasets, forecasting and anomaly detection with the method stated, and Python or notebook analysis beside the dashboards.

10 — Self-service that stays consistent at scale: every metric defined once and traced to every chart that uses it, changes reviewed and tested before they reach readers, AI answers grounded in the semantic layer with their limits documented, and the model exportable in an open format.

How results reach the people who need them: sharing a dashboard with colleagues and with external parties, public or password-protected links, scheduled reports by email or chat (Slack, Microsoft Teams) as PDF, image or data, threshold alerts, comments and annotations, export to PDF, PowerPoint and Excel, embedding dashboards in an intranet, a website or the company's own software product, white-label options, and per-customer data separation for embedded use.

0 — Results cannot leave the editor; no sharing, export or embedding.

3 — Dashboards shared with other users of the account and exported to PDF or CSV; scheduled reports, alerts and embedding are basic or not described.

5 — Sharing with colleagues and by link, scheduled email reports with PDF or image, alerts when a metric crosses a threshold, export to PDF and Excel, and dashboards embedded in a website or intranet with an iframe or script.

8 — Reports delivered to Slack or Microsoft Teams, comments and annotations on dashboards, signed embedding with row-level filtering per viewer, an embedding SDK for a software product with white-label styling, client or guest portals, and an embedding licence model documented.

10 — Distribution as a product: multi-tenant embedded analytics with per-customer data isolation, theming and custom domains, end-user self-service inside the host application, every delivery channel automatable through an API, and usage of shared and embedded content reported to the customer.

What a company needs before it gives the tool to everyone, and what leaving would cost: roles and folder or workspace permissions, row-level and column-level security, single sign-on (SAML, OpenID Connect) and user provisioning (SCIM), audit logs and usage analytics, content certification and lifecycle, environments for development and production, a public REST API for administration and content, export of dashboards and definitions in a reusable format, open-source code, and a self-hosted or on-premise edition the customer runs on its own servers.

0 — A single shared login with no permissions; dashboards cannot be exported or administered.

3 — Users with view and edit rights; row-level security, single sign-on, an API and export of definitions are basic or not described.

5 — Roles and folder or workspace permissions, row-level security documented, single sign-on on at least one stated plan, an audit log, a documented REST API, and dashboards and data exportable on termination.

8 — Column-level security and data permissions inherited from the source, SAML and SCIM provisioning, usage analytics for admins, development and production environments or content promotion, dashboards and definitions as code that can be versioned and moved, and a self-hosted or on-premise edition with its own documentation.

10 — Governance and an exit that can be verified: open-source code under a named licence that runs fully self-hosted with feature parity stated, every object (data model, dashboards, permissions) exportable in a documented format another instance imports, audit logs streamed to the customer's own systems, and deletion of every copy on termination documented.

Who the contracting entity and the parent company are, where the connected business data is queried, cached, extracted and stored, and who the subprocessors are (hosting, query engine, AI model providers, email delivery of reports, support and payment tools). Independently sourced by the sovereignty pipeline; a BI tool reads revenue, customer and employee data from many systems, so every place a copy or cache lands counts, not only the account database. A self-hosted or open-source edition the customer runs on its own European servers counts as the customer's chain, whatever the vendor's seat.

0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.

5 — EU hosting available and an EU contracting entity or EU representative, but parts of the chain (query engine, extracts and caches, AI features, report emails, support, payment) run through non-EU providers without a stated safeguard.

8 — EU hosting on named infrastructure, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, where extracts and caches are stored stated, and security certifications (ISO 27001, SOC 2) stated — or a self-hosted edition documented that keeps every query and cache on the customer's own servers.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor including AI features, or a self-hosted open-source edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.

Whether a buyer can compute the real annual cost from public pages alone: price per creator or editor seat and whether viewers are free or paid, capacity or usage pricing (rows, refreshes, queries, AI credits), which features (row-level security, SSO, embedding, API, more connectors, faster refresh) sit behind a higher tier or "contact sales", the price of embedding for external users, the self-hosted edition's licence, the free tier and its limits, minimum term and setup.

0 — No public prices at all; every customer is a sales call.

3 — A starting price or a free tier exists, but how cost scales with viewers, data volume or features is unclear.

5 — Tiers are public with their seat price and main inclusions, but at least one commonly needed piece (viewer seats, row-level security, SSO, embedding, extra connectors or refresh frequency) is unpriced or "on request".

8 — Every tier priced publicly with its scaling rule (creators, viewers, capacity, rows), viewer pricing stated, add-ons and usage overage priced, embedded and self-hosted pricing stated, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given number of creators and viewers, data volume and feature set, with every add-on, embedding, setup, support and overage fee and the cancellation and data-return terms published.