Appcues tracks every page view for identified users. That data answers one of the most fundamental questions in product adoption: where do your users actually go? Knowing your highest-traffic pages helps you decide where to place Flows, Pins, Banners, and Embeds for maximum reach — and knowing your lowest-traffic pages reveals features users aren't discovering.

With an MCP-compatible AI assistant, you can pull top pages, analyze navigation patterns, cross-reference page traffic with your existing experience placement, and find gaps where you have traffic but no content (or content but no traffic).

Where to run these prompts

These prompts work in two places:

• Captain AI — Appcues' built-in AI assistant, available directly in Studio. No setup required. Good for quick page traffic lookups while you're deciding where to target an experience.
• External MCP clients (Claude, ChatGPT, Cursor, or another MCP-compatible tool) connected to the Appcues MCP. See Connect the Appcues MCP for setup. Significantly better for this use case — external clients like Claude can generate traffic heatmaps, bar charts comparing page volumes, trend visualizations over time, and formatted placement-gap reports that are hard to produce in a text-only interface.

Both options access the same underlying data. Captain AI works for quick checks; external clients are the stronger choice when you want visual traffic analysis or cross-referencing with experience placement.

Prerequisites

• Captain AI access in Studio, or an external MCP client connected to the Appcues MCP.
• Appcues installed and tracking page views. For single-page apps (SPAs), confirm your app calls Appcues.page() on every route change — without it, Appcues only sees the initial page load.

Find your highest-traffic pages

Start with the most basic and useful question: where do your users spend their time?

Example prompts:

• "Show me my top 20 most-visited pages over the last 30 days."
• "Which pages in my app get the most traffic? Rank them by unique users, not just total views."
• "List my top 10 pages and tell me which ones have Flows, Pins, or other Appcues experiences targeting them."

What you can learn:

• High-traffic pages without experiences — These are missed opportunities. An Embed, Banner, or Launchpad item on a page that gets thousands of visits a week can drive significant awareness.
• Pages with high views but low unique users — Users visit these pages repeatedly (dashboards, inboxes, settings). These are better suited for persistent, non-interruptive experiences like Pins or Banners rather than Flows that show once.
• Pages with low traffic — These may not be the best placement targets for broad-reach content, but they may be exactly right for targeted experiences aimed at specific user segments.

Cross-reference pages with experience placement

The real power is combining page view data with your experience inventory. Where do you have traffic but no content, and where do you have content but no traffic?

Example prompts:

• "List my top 20 pages by traffic, then check which ones have published Flows, Pins, Banners, or Embeds targeting them. Show me the gaps — pages with high traffic but no experiences."
• "I have Flows targeting /settings, /billing, and /reports. Which of those pages actually gets the most traffic? Am I targeting high-impact pages?"
• "Show me all published experiences and the pages they target. Are any of them targeting pages that get fewer than 100 views per month?"

What to look for:

• High-traffic pages with no experiences — Your biggest reach opportunity. Even a subtle Pin or contextual Banner on a page users visit daily can drive feature adoption.
• Experiences on low-traffic pages — If a Flow targets a page that barely gets visited, its reach will be low regardless of how good the content is. Consider moving the trigger to a higher-traffic page, or using event-based targeting instead.
• Redundant coverage — Multiple experiences targeting the same page may overwhelm users. Check whether priority settings are preventing conflicts.

Analyze traffic for specific pages

When you're planning a new experience, check how much traffic the target page actually gets.

Example prompts:

• "How many users visited /settings/billing in the last 7 days? Break it down by day."
• "Compare traffic between /dashboard and /reports over the last 30 days. Which gets more unique visitors?"
• “Show me page view trends for any page containing /onboarding in the URL. Is traffic growing or declining?”

What to look for:

• Enough volume to matter — If your target page gets 50 visits a week, a Flow there will have limited reach. Consider whether the page is the right trigger.
• Traffic patterns by day — Some pages spike on certain days (billing pages at month-end, reporting pages on Mondays). Time your experience launches to align with peak traffic.
• URL splitting — If your app uses dynamic URL parameters or hash fragments, page views may be split across many variations. Ask: "Are page views for /dashboard being split across different URL parameters?"

Understand user navigation patterns

Page view data reveals how users move through your product — which helps you place experiences in the user's natural path instead of fighting against it.

Example prompts:

• “Show me the page view activity for user user-123 over the last 7 days. What pages do they visit most and in what order?”
• "What's the typical path for users who visit /pricing? Where do they go before and after?"

What you can learn:

• Real user journeys — A user's actual page-by-page path reveals whether they're following the journey you designed or wandering. If trial users skip your setup page, a Checklist or event-triggered Flow to bring them back may be more effective than a page-targeted one.
• Feature discovery gaps — Pages that trial users never visit may contain features they don't know about. These are opportunities for Pins, Tooltips, or Launchpad items to surface hidden functionality.
• User-level differences — Comparing page view patterns across users (trial vs. paid, admin vs. member, enterprise vs. starter) helps you tailor experiences to each audience's actual behavior rather than assumptions.

Tips for better results

• Start with top pages — If you've never looked at page view data, begin with "Show me my top 20 pages." This single prompt often reveals surprises about where users actually go versus where you assume they do.
• Combine with experience performance — Cross-reference high-traffic pages with experience completion rates: "I have Flows on /dashboard and /settings. Which page's Flow has a higher completion rate?" Traffic × completion rate = actual impact.
• Check SPA page tracking — If your top pages list looks surprisingly short, your single-page app may not be calling Appcues.page() on route changes. Without that call, Appcues only sees the initial load.
• Audit quarterly — Run "List all published experiences and the pages they target — flag any targeting pages with fewer than 50 views in the last 30 days" to find stale content that isn't reaching anyone.

Limitations

• Aggregate page views, not clickstream — The MCP shows page views and top pages, but not in-page behavior like scroll depth or element clicks. Use your product analytics tool for in-page interaction data.
• URL normalization — Pages with dynamic parameters may appear as separate entries. The MCP reports what the SDK tracks. If URL variations are splitting your data, standardize how your app reports URLs to Appcues.
• Bot traffic — Appcues tracks page views for all identified users, which may include automated scripts or bots if they call Appcues.identify(). If numbers seem inflated, check whether non-human traffic is being identified.
• Read-only — The MCP reports page view data but can't change your SDK configuration or page targeting. Make changes in your app code or Appcues Studio.