> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt # Dashboards – Product Analytics pocket guide Canonical URL: https://posthog.com/learn/product-analytics/pocket-guide/dashboards > **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://app.posthog.com` (app host for links). ## On this page - [Build an overview dashboard](#build-an-overview-dashboard) - [Build a drill-down dashboard](#build-a-drill-down-dashboard) - [Compare cohorts side by side](#compare-cohorts-side-by-side) - [Use dashboards as evidence](#use-dashboards-as-evidence) - [Build a dashboard for your product](#build-a-dashboard-for-your-product) Chapter 05 # Dashboards – Product Analytics pocket guide Twig's engineers have recorded filter selections, connected visits to signed-in guests, and built insights for filter use, booking completion, and repeat bookings. Now they need a way to view that data together and use it to decide what to build next. A dashboard puts saved insights on one page. Twig starts with an overview, then builds two dashboards to answer narrower questions. ## Build an overview dashboard The engineers build their first dashboard, and name it **Exploring and booking stays**. They add three saved insights: their trends insight for weekly filter use, funnels insight for booking completion, and retention insight for repeat bookings: Reset +Filter users+Booking completion+Repeat bookings ### Exploring and booking stays Beside the funnel, the engineers add a note: one booking request failed, and three other drop-offs need inspecting. That gives them a place to start when booking completion changes. The tiles measure different things: weekly filter users, booking completion within 14 days, and monthly repeat bookings. The engineers leave **No date range override** on so each saved insight keeps its own dates and interval. ## Build a drill-down dashboard Twig's Trends insight shows more people using filters in week 2, but it doesn't show which destinations they chose. The engineers create a **Finding stays** dashboard and put the destination breakdown beside the weekly trend: Reset +By destination+Filter users ### Finding stays The destination breakdown counts unique people, just like the trend. Coast rises from two people in week 1 to five in week 2; Forest and City stay flat. That gives Twig a specific change to investigate. The engineers can inspect Coast selections with `has_results: false` to see whether the filter returned no stays. ## Compare cohorts side by side Twig also wants to know whether guests who saved a stay before their first booking return more often. The engineers build a **Returning guests** dashboard with three views of January 2025: all first-time bookers, the four who saved a stay, and the six who didn't. The last two use their static cohorts as filters: Reset +Repeat bookings+Saved before booking+No saved stay ### Returning guests Of the 10 January guests, three booked again in Month 12. Two of four in the saved group did (50%); one of six in the other group did (17%). This small comparison doesn't show that saving caused another booking. The engineers would compare later first-booking cohorts after they reach Month 12. ## Use dashboards as evidence The booking funnel gives the engineers an immediate lead. Of 10 people who started booking, four didn't finish within 14 days and one had a failed request. Twig's `request_id` connects that person's `booking_started` event to the server response. The engineers inspect the other three booking trails and the failed response before deciding what to fix. A [Session Replay](https://posthog.com/docs/session-replay.md) can show what a visitor saw, but not why the server request failed. After a booking-flow change, they check the funnel again after a full 14-day conversion window, keeping its events, order, and filters the same. A higher completion rate means more starters finished within that window. It doesn't prove their change caused the increase – they could test that with [Experiments](https://posthog.com/docs/experiments.md). ## Build a dashboard for your product Start with one question about your product and check which events and people PostHog records, build an insight with the right count and time period, and save it to a dashboard. The following prompt asks PostHog AI or your MCP-connected agent to inspect your events and build a dashboard from the data you have. Happy building! Prompt ```text Inspect this project's events from the last 30 days. Find a meaningful user action with data and create a daily trend of unique users who did it. If there is a clear next action, add a two-step funnel. Save the insights to a dashboard named Product journey overview, reusing it if it exists. Summarize one result and one question to investigate next. If data is missing, tell me what to track first. Don't invent events. ``` ### PostHog AI Run this prompt in your PostHog project. [Build with PostHog AI](https://app.posthog.com/#panel=max:!Inspect%20this%20project's%20events%20from%20the%20last%2030%20days.%20Find%20a%20meaningful%20user%20action%20with%20data%20and%20create%20a%20daily%20trend%20of%20unique%20users%20who%20did%20it.%20If%20there%20is%20a%20clear%20next%20action%2C%20add%20a%20two-step%20funnel.%20Save%20the%20insights%20to%20a%20dashboard%20named%20Product%20journey%20overview%2C%20reusing%20it%20if%20it%20exists.%20Summarize%20one%20result%20and%20one%20question%20to%20investigate%20next.%20If%20data%20is%20missing%2C%20tell%20me%20what%20to%20track%20first.%20Don't%20invent%20events.) ### PostHog MCP Open this prompt in your editor. Open in Claude CodeOpen in Codex Need to connect PostHog MCP? `npx @posthog/wizard mcp add` **Explore further**[Dashboards](https://posthog.com/docs/product-analytics/dashboards.md) · [Creating insights](https://posthog.com/docs/product-analytics/insights.md) · [Experiments](https://posthog.com/docs/experiments.md)