---
type: feature
title: "Data Visualization Tools for Storefront Analytics"
description: "Evaluate data visualization tools in Runner AI using storefront analytics views, filters, mappings, and saved dashboard cards you can review in one project."
category: ai-cro
h1: "Review Data Visualization Tools Inside Your Store Project"
image: "https://storage.googleapis.com/runner-blog/features/data-visualization-tools/hero.png"
keyword: "data visualization tools"
legacyKind: structured
---

**Data visualization tools** turn storefront activity into charts that an operator can inspect before making a decision. Runner AI keeps that work inside the store project: choose a storefront analytics view, scope its query, map returned fields to a visual format, and save the resulting cards as a reviewable dashboard rather than exporting the question to a disconnected reporting workspace.

![A storefront analytics dashboard with trend, funnel, map, and retention views ready for review](https://storage.googleapis.com/runner-blog/features/data-visualization-tools/hero.png)

## Evaluate data visualization tools by the decisions they support

A useful evaluation starts with the decision, not the prettiest chart. A store operator may need to compare traffic over time, inspect where a configured funnel loses sessions, review retention by week, locate an error pattern, or see whether a page has poor web-vitals readings for a particular device. Each question needs a different data view and a different visual treatment. Runner's dashboard builder exposes storefront analytics views for traffic, pages, sessions, visitors, locations, funnels, retention, attribution, errors, tracking, experiments, and web vitals, subject to the data available in the project.

The builder then lets the operator choose how a card should communicate that result. Supported formats include tables, line and area charts, vertical and horizontal bars, pie charts, single statistics, maps, and calendars. That range is useful only when the mapping is honest. A trend needs an x-axis and one or more numeric series. A map uses the locations view. A calendar needs date and value fields. Runner validates those requirements before a dashboard configuration is saved, reducing the chance that an attractive card quietly represents the wrong shape of data.

This is narrower than a general business-intelligence suite, and that is the differentiator. Runner does not ask a store operator to rebuild storefront context in a separate warehouse before reviewing a project question. It works with the analytics views available for the current storefront, then keeps the visual result beside the store work it may inform. For a broader analysis-to-merchandising workflow, see [AI ecommerce analytics](/ai-ecommerce-analytics).

## Start with storefront inputs, filters, and a clear comparison

Before creating a card, define the question in terms the project can answer. Choose a time range, confirm the project timezone, identify the relevant analytics view, and state which dimensions or events matter. A traffic trend might use date on the x-axis and visitors as the numeric series. A location card needs a country field. A conversion review needs an explicitly configured funnel rather than a vague request to "show drop-off." Queries can also narrow results by pathname, device, browser, operating system, campaign source, country, event, or other supported fields.

These inputs are part of the review trail. Runner stores the dashboard name, date range, timezone, cards, query arguments, field mappings, value formats, and grid positions as one project-scoped configuration. An operator can therefore inspect why a card looks the way it does instead of seeing a chart with no visible definition. If the query is incomplete, a required argument is missing, or a card mapping does not fit the selected visualization, the configuration should be corrected before it becomes the shared view.

The safest workflow starts small. Add one card for a question with a known definition, compare its result with the underlying analytics view, and label it in language the team understands. Add another card only when it answers a distinct question. This avoids a wall of interchangeable charts and makes disagreements easier to diagnose. If the goal is to turn a supported finding into a storefront revision, continue with [AI ecommerce conversion optimization](/ai-ecommerce-conversion-optimization) after the evidence has been reviewed.

## Build a saved dashboard that remains reviewable

Runner's custom dashboard surface separates editing from viewing. A manager can create a named dashboard, add cards, choose each endpoint and visualization, define mappings and query arguments, position cards on a twelve-column grid, and save the configuration. The normal dashboard view renders the saved cards using the selected date range and timezone. That distinction matters because a draft mapping can be inspected and corrected before it becomes the project view other people rely on.

Card titles should describe the measure and scope, not imply a conclusion. "Checkout funnel, last 7 days" is safer than "Checkout problem" because a funnel can show a change without establishing its cause. The same rule applies to retention, errors, attribution, and web vitals. A chart is evidence to examine, not a diagnosis by itself. Confirm event definitions, bot inclusion, filters, date boundaries, and any required identifiers before interpreting a visible difference as customer behavior or commercial impact.

Persistent dashboards also make iteration deliberate. An operator can edit a saved configuration when the business question changes, add or remove cards, and preserve a useful layout for recurring review. Deletion uses a separate confirmation step, while card and dashboard inputs are validated against bounded schemas. These controls support a stable review artifact, but they do not certify data completeness. Tracking configuration, traffic volume, role access, and the project state still determine which views are meaningful and what evidence is available.

## Compare Runner with general visualization software

General data visualization software often begins with imported spreadsheets, database connections, or a separate modeling layer. That flexibility is valuable for cross-company reporting, finance, or research, but it can add setup when the immediate question concerns one storefront. Runner's dashboard builder begins with the storefront analytics endpoints already defined for a project. Operators choose from those supported views and map their returned fields into a saved visual layout without presenting Runner as a replacement for every enterprise BI use case.

Use Runner when the review should stay close to storefront behavior and possible follow-up work. Use a broader BI platform when the task requires arbitrary corporate sources, organization-wide semantic models, regulatory reporting, or visualization types Runner does not support. The right boundary prevents two common mistakes: exporting a simple storefront question into an unnecessarily large reporting stack, or claiming that a project dashboard can answer questions beyond the data and definitions it actually has.

The practical evaluation criteria are therefore specific. Check whether the needed storefront view exists, whether its query can express the segment or event, whether the card mapping matches the returned fields, whether the date range and timezone are explicit, and whether the saved result is understandable to the person making the decision. Then review the dashboard alongside the related store context. Use [website optimization tools](/website-optimization-tools) when a supported measurement needs a focused storefront follow-up. Browse the [Runner AI feature catalog](/) when the next task moves from measurement into storefront, marketing, or commerce work.

[Build a reviewable storefront analytics dashboard in Runner AI](https://www.runnerai.com/auth/login?prompt=Build%20a%20reviewable%20storefront%20analytics%20dashboard%20from%20my%20project%20data.%20Use%20my%20selected%20date%20range%2C%20timezone%2C%20analytics%20views%2C%20filters%2C%20and%20field%20mappings.%20Return%20a%20saved%20card%20layout%20with%20clear%20chart%20titles%20and%20no%20unsupported%20causal%20or%20revenue%20claims.)

## Data visualization tools FAQ

### What inputs do Runner AI dashboards use?

Runner dashboards use the storefront analytics data available to the current project. A card records a selected analytics view, supported query arguments and filters, field mappings, a visualization type, and its grid position. The dashboard also records a date range and timezone. Availability and usefulness depend on the project's tracking, traffic, configuration, role access, and stored data; the builder does not invent missing observations.

### Which visualization types can I add?

The dashboard contract supports table, line, area, bar, horizontal bar, pie, stat, map, and calendar cards. Different formats require different mappings. Trend charts need an x field and numeric series, maps use location data, and calendar cards need date and value fields. Choose the simplest format that communicates the question clearly, then verify the mapped columns before saving the dashboard.

### Can a visualization explain why a conversion metric changed?

Not by itself. A chart can expose a trend, segment, funnel step, error series, or performance pattern, but it does not automatically prove causation. Check the event definition, filters, date boundaries, bot handling, tracking state, and relevant store changes before drawing a conclusion. Treat the saved dashboard as reviewable evidence and label uncertainty rather than turning a visible correlation into a guaranteed explanation.

### Does creating a dashboard change or publish my storefront?

No. Creating or editing a custom analytics dashboard saves a project-scoped review configuration; it does not publish storefront code or apply a conversion change. If the evidence supports a storefront revision, define that work separately, inspect the proposed page and device previews, and publish only after approval. The dashboard remains the measurement view, while the storefront workflow owns any customer-facing change.