How to build a trends dashboard

A trends dashboard is only as good as its data pipeline. Most attempts fail at the data layer: scrapers that break, single-source coverage, or relative-only values that cannot be compared. This guide covers building a live trends dashboard on Trends MCP.

Live data as of 2026-08-05 · Updated 2026-08-05

A trends dashboard sounds simple: chart some trend lines, add growth percentages, ship it. The reality is that most early attempts collapse at the data layer within a few weeks. The scraper breaks. The data from different sources uses incompatible scales. The refresh runs into rate limits. This guide walks through building a dashboard that does not have those problems, using Trends MCP as the data source.

Start with the data architecture, not the UI

The most common mistake is starting with the visualization (choosing a chart library, designing the layout) before solving the data problem. Design the UI last. First, answer:

  1. What sources need coverage?
  2. What keywords or topics are being tracked?
  3. How frequently does the data need to refresh?
  4. How will the data be stored and served to the frontend?

Trends MCP as a backend simplifies questions 1 through 3 significantly. One connection gives a data pipeline access to Google, TikTok, Reddit, YouTube, Amazon, Wikipedia, news, web traffic, app downloads, npm, PyPI, and Steam, all normalized to a consistent 0-100 scale. Question 4 still depends on the stack.

What does demand for trend data look like in August 2026?

The market context explains why the MCP route beats the scraper route right now. Trends MCP data pulled on August 5, 2026 shows Google Search interest in "google trends api" down 77.78% over 30 days, from a normalized 63 to 14, and flat year over year. Interest in "google trends" itself fell 51.35% over the same month, from 74 to 36, and is down 14.29% year over year from 42. Meanwhile the plumbing for assistant-native data access is compounding: the official mcp Python package hit 88.8 million weekly PyPI downloads, up 1654.39% year over year from 5.1 million and still up 26.1% in the last 30 days.

The interpretation for a dashboard builder: end users increasingly consume trend data inside AI assistants, and the durable bet is a clean normalized data layer that can serve both a dashboard UI and an MCP-connected assistant from the same store.

Query architecture for a dashboard

Time series charts: get_time_series

For the main trend line charts, use get_time_series per keyword and source. It returns the full historical series with normalized values and, for sources like Amazon, npm, and PyPI, absolute volume alongside. Query each keyword-source pair to display and store the results.

One get_time_series call covers one source. Showing Google, TikTok, and Reddit lines for the same keyword is three calls, so plan the daily query budget accordingly.

Growth scorecards: get_growth

Growth rate numbers (30-day, 90-day, 1-year) are the most-read data points on any trend dashboard. Use get_growth with a comma-separated source list, for example source='google search, tiktok, reddit', to get cross-platform growth in a single call. This is the most efficient query pattern for dashboard scorecards.

The response includes percentage change, exact baseline and recent dates, direction, and a volume_available flag per source. Use that flag to decide whether a tile can show absolute volume or should show normalized values only.

Live trending and discovery: get_top_trends

For a "trending right now" section with no fixed keyword list, get_top_trends requires no seed keyword and returns what is actually trending at query time across 21 feed types, from Google Trends and Reddit Hot Posts to TikTok Trending Hashtags and Amazon Best Sellers. Run it once or twice per day and let users promote board entries into their tracked keyword list.

Normalization and display

All Trends MCP values are normalized to 0-100 per platform. This is designed for cross-platform comparison on a shared axis. When plotting multiple sources for the same keyword, they can share a chart without a second Y-axis or any transformation.

What not to do: mix normalized values and absolute volume estimates on the same axis. If absolute volume is displayed, keep it to single-source charts. If normalized values are displayed, cross-source comparison is legitimate.

Refresh strategy and caching

Daily refresh for time series: Run a scheduled job (for example cron at 2am UTC) that re-fetches the weekly series for all tracked keywords. Store results in a database or object store. This keeps charts current without continuous polling.

Real-time for live trending: get_top_trends can be refreshed every 15 to 60 minutes for a "trending now" section. The underlying boards update frequently for sources like TikTok and Reddit.

Cache growth scorecards for 24 hours: get_growth results change slowly. A 30-day growth figure on Monday and Tuesday is nearly identical. Serving cached results with a timestamp ("updated 6 hours ago") is accurate enough and cuts query volume.

Common mistakes

Mixing relative and absolute values: Google Trends' native 0-100 scale is relative to the peak in the query window. Trends MCP's 0-100 is normalized differently, calibrated consistently across time and sources. Do not mix them. If some imported data comes from pytrends, the scales are not compatible.

Querying too many keywords on initial load: Dashboard load time degrades quickly if every keyword is queried on page load. Pre-fetch and cache server-side; serve stale-while-revalidate. Users should see charts instantly from cache, with a background refresh.

Ignoring volume availability: Not every source returns absolute volume. A tile that implies real search counts from a normalized-only source misleads users. Check the volume_available flag and label tiles accordingly.

Single-source dashboards: A dashboard that only shows Google Trends displays 1 of 15+ available signals. Users relying on it for decisions miss the 2 to 4 week lead time that TikTok and Reddit signals provide before Google Search catches up. Multi-source is not extra complexity; it is the minimum for a trustworthy trend picture.

Minimal viable implementation

The fastest path to a working trends dashboard:

  1. Set up a Trends MCP connection (one config entry in an AI client, or call the API endpoint from the backend; the Claude setup guide shows the connection shape)
  2. Run get_growth(keyword='your keyword', source='google search, tiktok, amazon', percent_growth=['1M', '3M', '12M']) for the keyword list to populate scorecard numbers
  3. Run get_time_series(keyword='your keyword', source='google search') per keyword to build time series charts
  4. Run get_top_trends(type='Google Trends', limit=20) for a discovery section
  5. Store results, then build the UI against the cached data

This four-query pattern covers the core of a production-grade trends dashboard. Add sources, keywords, and scheduled refresh once the baseline works. For a demand-side example of the same data in action, see the e-commerce product research page.

Common questions

The hardest part is not visualization, it is data architecture. Most teams start with a single source (usually Google Trends via pytrends) and hit rate limits within weeks. When they add a second source like Reddit, the data scales are incomparable and the visualization becomes misleading. Trends MCP solves both problems: one connection for 15+ sources, with all values normalized to a consistent 0-100 scale that can share a chart axis.
For most use cases, daily refresh is sufficient. Google Search and most social trend data does not change meaningfully hour to hour except during breaking news. A daily scheduled run (for example at 2am UTC) covers about 95% of dashboard use cases without burning quota. For near-real-time monitoring, get_top_trends can be polled every 15 to 60 minutes, but historical series from get_time_series should still refresh daily, not continuously.
Trends MCP normalizes all sources to a 0-100 scale. A value of 70 on Google Search and 70 on TikTok reflect proportionally equivalent interest on each platform, so they can share an axis without transformation. For absolute scale charts, use the volume field that sources like Amazon, npm, and PyPI return, but never mix absolute volume and normalized values on one axis.
Three query types cover about 90% of dashboard requirements: get_time_series for each keyword on the primary source to build time series charts, get_growth with a comma-separated source list for the scorecard headline numbers, and get_top_trends once per day to surface new keywords worth tracking. Each get_growth call can cover multiple platforms in one request, keeping total query count manageable.