Skip to main content
The dashboard lives at app.traffical.io. It’s where you create projects, define parameters, run experiments, watch metrics, and manage everything that doesn’t fit in code. This is a tour. Each section links to a deeper walkthrough.

​
The hierarchy

The URL structure mirrors the hierarchy: organization → project → resource.
The sidebar follows the same structure, in four groups: the project pages (under the project’s name), the pipeline pages, project settings, and the organization pages.
Dashboard home placeholder

Dashboard home — pick an organization

​
What’s where

Some sidebar items appear only when you hold the matching permission or when the feature is enabled for your organization — if you don’t see Changes or Billing, that’s why.

​
Project

Overview

The project’s landing page — KPIs, aggregated impact, traffic, recent activity. Toured below.

Setup

Step-by-step wizard for wiring up a new project — warehouse, SDK, first parameters — with progress tracked in the sidebar.

Changes

Governed change lifecycle — wizard, approvals, transitions. Enabled per organization; if you don’t see Changes in the sidebar it isn’t enabled for you yet.

Surfaces

The product contexts changes land in — where risk is classified and measurement protocols attach.

Layers

Traffic containers and the policies inside them. The bulk of day-to-day experiment work.

Parameters

All parameters in the project — synced (from CLI) and dashboard-only.

Events

Event definitions, property schemas, the event explorer.

Metrics

Metric definitions and their results.

Decisions

Audit log of every policy lifecycle change.

AI Status

Every adaptive policy, grouped by convergence state. Toured below.

​
Pipeline

Definitions

Entities, assignments, facts — for warehouse-native metrics.

Workflow Runs

Every pipeline run — status, timing, per-run detail.

Data Freshness

How current the computed warehouse data is, per definition.

​
Settings

The settings group holds project settings: warehouse connection, SDK sync, hashing config, pipeline scheduling, maintenance.

​
Organization

Teams

Members, roles, and team ownership of parameter groups.

Notifications

Choose which alerts you get and where they’re delivered.

API keys

Create and revoke traffical_sk_... keys (SDK or management scope) per project + environment.

Billing

Plan, usage, invoices.

​
The project overview

The project’s landing page answers “how is this project doing right now”:
  • KPI cards — active layers broken down by policy state, plus exposures, unique users, and reward rate over the last 24 hours, each with a trend sparkline.
  • Impact — what your concluded changes are worth (below).
  • Traffic Overview — decisions, exposures, tracks, and rewards per day, alongside a view of layer bucket allocation.
  • Recent activity — the latest project events, so you catch what teammates (and the optimizer) did.
Data refreshes automatically about every five minutes; the header shows the timestamp of the data you’re looking at.

​
Impact

The Impact section aggregates concluded changes and standalone policies into one program-level answer: what has shipped, and what is it worth per day?
Impact section on the project overview: program strip, per-metric table, and in-flight block

Project overview — the Impact section

  • Program strip — shipped winners (with inconclusive conclusions counted alongside as learning), win rate, reverted changes (counted as avoided harm, never as impact), and velocity versus the previous window of the same length.
  • Per-metric table — one row per affected metric: daily impact with a confidence interval, the window total (a change shipped mid-window accrues only for its live days), footprint, and a cumulative-impact sparkline. Expand a row to see each contributing change.
  • Filters — narrow to a single surface, restrict to results where the metric was the change’s primary metric, and pick any window with the date-range picker (default: the last 90 days).
  • In flight (unshipped) — current readings of still-running changes, shown separately and never summed into the totals. A live lift isn’t a realized win until the change ships.
  • Optimization (adaptive policies) — the estimated value of adaptive traffic allocation, versus a uniform split (and versus control where that comparison is causal). Also display-only, never summed into the totals.
Impact figures are estimates, not measurements. Each shipped win’s ship-time result is projected to full rollout, then discounted by its false-positive risk using the program’s observed win rate; group totals assume independence between changes, and interactions between overlapping changes and novelty decay are not modeled. The always-visible note under the table restates this, and its popover carries the exact formulas — see Impact methodology for the full math.

​
The AI optimization page

The AI Status entry in the sidebar opens the AI Optimization page: every adaptive policy in the project on one screen, grouped by where it is in its learning lifecycle.
AI Optimization page with summary strip and Converged and Learning policy groups

AI Optimization — adaptive policies by convergence state

  • Converged — the optimizer has settled: one allocation now carries most of the traffic. These prompt you to review the result and complete the policy to lock in the winner.
  • Learning — still exploring: each card shows the live allocation split, the algorithm (Thompson Sampling, Epsilon Greedy, UCB1), the goal it optimizes, and exposures so far.
Above the groups, a summary strip totals running adaptive policies, 24-hour exposures, estimated lift, and the time of the optimizer’s last action. Non-running policies collapse out of the way below, and a Recent Activity feed shows each traffic shift the optimizer made — previous split and new split side by side — so allocation moves are never a mystery. (Optimization milestones also land in the decision log.) Use this page as your daily check on autonomous optimization: is anything converged and waiting on you, is anything erroring, is the lift holding up. See Choosing an algorithm for picking between the algorithms.

​
Day-to-day flow

Most teams work like this:
  1. Author parameters in code via .traffical/config.yaml and traffical push.
  2. Create policies in the dashboard — that’s where experiments are configured.
  3. Watch metrics during the experiment — visit the policy detail page.
  4. Promote the winner — update the parameter default and mark the policy complete.
Parameters live in code (the source of truth). Policies live in the dashboard (because they change frequently and need approval workflows). Events and metric definitions can live in either, depending on team preference.

​
Roles

Every member of your organization holds one role — Viewer, Member, Admin, or Owner. Viewers read everything, members do the day-to-day building, and a small operate tier — starting live traffic, executing change transitions, promoting defaults — is reserved for admins and owners. Teams can narrow write access further by owning parameter groups. The full model, including API key scopes, is in Roles, teams & API key scopes.

​
Audit trail

Every change in the dashboard is captured in the decision log — policy state transitions, allocation overrides, rollout actions, manual completions, optimization milestones. Use it to answer “who turned this on / who paused it / who promoted that variant”.

​
Next steps

Your first experiment

The end-to-end flow from traffical init to reading results.

Parameters

Walkthrough of the parameters page.

Layers & policies

Where experiments live.

Settings → Warehouse

Connect Postgres, BigQuery, Snowflake, Databricks, or ClickHouse.