BI Dashboards

Routy's Dashboards page lists two kinds of dashboard, and from your side they open the same way.

The BI dashboards are Metabase dashboards. Routy holds the filter set for each one and, when you open it, mints a signed token carrying the dashboard and the resolved filter values, then loads the dashboard at that token. Some of those values are locked on our side, which is what lets one dashboard serve every publisher without anybody seeing anybody else's figures.

The in-app dashboards are built in Routy rather than embedded, and there are three: Account Performance, Routy Performance and Page Performance. Each one reads a report-builder report over the same views your own reports read, so a number on a chart and the same number in a report you built come from one place. They started as ports of Metabase dashboards and kept the questions while changing the controls.

Neither kind is something you build. Dashboards, their folders, their filters and who can see them are set up on our side. If you want a chart that doesn't exist, that's a conversation with your account manager, not a builder screen.

• Three in-app dashboards. Account Performance gives a month of one account with clicks, signups, FTDs, qualifieds and commission, and a mode switch for whose number you're reading: Routy's, the program's, or the two side by side. Routy Performance breaks the event stream down by brand, traffic source and country, with a funnel and a volume-against-efficiency quadrant. Page Performance answers which landing pages convert and which brand placements are costing you FTDs, with a placement optimiser, a funnel and a page explorer.
• Filters that live in the address bar. Change the dates, the account, the traffic source, the brand or the country and the URL changes with them, so the view you're looking at is a link you can bookmark or paste to someone who has access to the same data. Nothing you filter is saved onto the dashboard for other people.
• A date range with a comparison against the previous period, so each KPI carries its own change rather than needing a second tab.
• Click a row or a segment to filter the whole dashboard by it, and clear that filter from the same chip. The explorer groups by one dimension, then by a second, and expands a row to fetch what sits underneath it.
• Export and print on the in-app dashboards, so a monthly figure can leave as a file rather than a screenshot.
• Currency per view. Figures convert to the currency you pick, and on Account Performance the conversion is applied at month grain rather than per row.
• BI dashboards in folders. Each dashboard carries a path, and the paths nest, so reporting/revenue puts it two folders deep and the Dashboards page walks the tree. Folders come out of the paths rather than being maintained separately.
• Defaults that resolve when you open the dashboard, not when it was built. A filter's default can be {today}, {yesterday}, {first_day_of_month}, {last_day_of_month}, {first_day_of_year}, an offset like {-7d} or {-3m}, or your own currency, timezone or account. Dates resolve in your time zone.

What you don't get: a dashboard you assemble yourself, a chart type beyond what Metabase draws, or a dashboard link that works for someone with no Routy access. For a question we haven't built a dashboard for, the report builder is the self-serve route, and the data export is how a figure reaches a tool of your own.

Opening a BI dashboard

GET /v1/reports/dashboard/available returns the dashboards you're allowed to see, each with its display name, description, path and filter set. Opening one calls GET /v1/reports/dashboard/{reportId} with your filter values as query parameters, and Routy returns the embed address to load.

Each filter is declared with a name, a type, a display order, whether it's required and a default. The filter's name is its key, so Start Date is both the label you see and the parameter you send. A default written as {expression} is worked out on our side when you open the dashboard, and you can still override it. A default written as {server:expression} is worked out on our side and locked: whatever the browser sends for that key is thrown away. Your affiliate id is the obvious one to lock, and locking it in the signed token is why the dashboard can't be made to show another account's rows.

Who sees which dashboard

Each dashboard is public or private, and each has a list of accounts with access. A public dashboard is visible to everyone except the accounts explicitly excluded. A private one is visible only to the accounts explicitly added. Inactive dashboards don't appear at all.

Where the in-app dashboards get their numbers

The browser never queries the warehouse. Every figure comes through a report-builder report, the same path your own reports take: account_performance behind Account Performance, routy_performance and routy_performance_players behind Routy Performance, page_performance and page_placement behind Page Performance. Each report returns its dataset in one call, and the dashboard pages, sorts and searches it in the browser, which is why changing a sort doesn't go back to the server.

Two of those reports exist because a report builder can't express them. page_placement returns one row per traffic source, page and brand with the click rank, the FTD rank and the potential FTDs already computed, because working those out needs window functions and a self-join. routy_performance_players exists because player counts don't add up across dimensions, so they come from their own grain rather than being summed.

What changed on the Page Performance filters

Three things, in October 2026. The account filter now shows each account the way the link management filter does, with its program, software and network next to the name, and a search matches the program and software names as well as the account name. Before that both the account and program filters showed a bare id and name, so two accounts on the same program were impossible to tell apart. The program filter now shows each program's logo.

The country filter lists country names instead of two-letter codes, and an applied country reads as a name in the chip with the code still on hover, for when you're matching it against a report that uses codes.

And narrowing the dates no longer empties the traffic source, brand and country filters. Those lists now cover everything on your account rather than only what falls inside the dates on screen, because shortening the range to work out why a figure looks wrong is the worst moment to lose the controls. The page filter still follows the dates, since that list has one member for every URL you have ever had traffic on.

A tracking report answers a question you already know how to ask. You pick the dimensions, you pick the window, you read the rows. The dashboards cover the questions you answer from a ranking or a scatter rather than a total: a brand placement sitting fourth that converts like a first, a country whose click-to-FTD has been sliding for three weeks, a traffic source whose volume is fine and whose efficiency isn't. Those are visible in a quadrant or a ranked table and close to invisible in a row of totals.

The locked filters are the part that makes a shared dashboard safe. One Metabase dashboard serves every publisher because your account is pinned inside a signed token rather than passed as a parameter your browser could change. Without that, a shared dashboard is either rebuilt per account or not shared at all.

And the in-app dashboards read report-builder reports on purpose. A dashboard on its own query path drifts from the reports beside it, and then you have two numbers for one thing and an argument about which is right. Same report, same view, same number.