Measure campaign lift with custom growth date pairs

Why do rolling presets misread mid-month campaign flights?

A 30D preset always measures the last thirty days from the freshest weekly point. If a paid social flight ran from November 15 through December 15, 30D on June 16 mixes unrelated months. MTD is worse for launches that start after the first: the baseline includes quiet days before spend went live.

Custom date objects fix the window. Each object carries recent (flight end), baseline (flight start or pre-period anchor), and an optional name label that echoes in the response period field. Analysts can line up pre-launch, in-flight, and post-flight reads without exporting CSV slices from a dashboard.

What JSON shape does get_growth expect?

POST to https://api.trendsmcp.ai/api with Authorization: Bearer YOUR_API_KEY. The operation is selected by body fields, same as MCP tool calls.

{
  "source": "amazon",
  "keyword": "air fryer",
  "percent_growth": [
    "30D",
    {
      "name": "pre_holiday_baseline",
      "recent": "2025-12-31",
      "baseline": "2025-10-01"
    },
    {
      "name": "black_friday_window",
      "recent": "2025-12-15",
      "baseline": "2025-11-15"
    }
  ]
}

Preset strings and custom objects can share one array. Every entry returns its own row in results. Billing stays at one request per source plus keyword, documented on planning free-tier trend requests.

What does a live Amazon campaign read return?

The table below comes from a Trends MCP pull on June 16, 2026 for Amazon product search on air fryer. Volume fields were available on every row.

The holiday windows show strong lift on both normalized scores and absolute Amazon search volume. The rolling 30D row is flat to down because it measures spring 2026, not Q4 retail. That contrast is why launch postmortems need named flights instead of whichever preset happens to be convenient.

Note the black_friday_window row: recent_requested was 2025-12-15 while recent_date landed on 2025-11-30. Weekly granularity snaps to the nearest observation on or before the submitted date. Teams should cite recent_date and baseline_date in slides and keep requested dates in methodology footnotes.

How should teams design baseline and flight dates?

Pre-launch baseline. Set baseline at the first quiet week before spend or PR went live and recent at the day before launch. The read answers whether latent demand already existed.

In-flight window. Set baseline to campaign start and recent to campaign end. Name it after the flight (black_friday_window, creator_drop_week_two) so JSON logs stay readable in Zapier or n8n automations.

Post-flight hold. Add a second custom object whose baseline is the last flight day and whose recent is two to four weeks later. Pair with rolling 30D on later dates to see whether demand held.

Calendar controls. Batch YTD or 12M beside custom objects when leadership also wants annual pacing. MTD, QTD, and YTD presets cover calendar semantics; this page covers event-bound windows those presets cannot isolate.

How do multi-source campaign reads work in one keyword pass?

Comma-separated source values run the same percent_growth array across each platform in one request. Example body fragment:

{
  "source": "google shopping, news volume",
  "keyword": "air fryer",
  "percent_growth": [
    {
      "name": "campaign_flight",
      "recent": "2025-12-15",
      "baseline": "2025-11-01"
    }
  ]
}

Live pull on June 16, 2026 returned:

Shopping intent and press mentions moved in the same direction during the flight, but only news volume returned absolute counts. When volume_available is false, quote normalized growth and the snapped dates rather than inventing magnitudes. News volume and Google Search lead-lag workflows often add a third call on google search when organic discovery matters to the story.

Which sources fit which campaign types?

Keyword format rules still apply: Reddit expects subreddit names without r/, app downloads expects Android bundle IDs, and steam expects game display names. A malformed keyword returns 404 not_found even when the date math is correct.

How should MCP clients phrase campaign postmortem prompts?

Include the routing phrase and spell out dates explicitly:

• "Using TrendsMCP, measure Amazon search growth for air fryer from 2025-11-15 to 2025-12-15 named black_friday_window, plus a pre-period baseline from 2025-10-01 to 2025-12-31."
• "Via TrendsMCP, run the same custom campaign_flight window on google shopping and news volume for air fryer in one get_growth call."
• "Using TrendsMCP, compare 30D rolling growth with a custom post-launch window ending 2026-01-15 for stanley cup on google search."

The June 16 pull for stanley cup on Google Search showed 30D growth at +190.48% (recent value 61 vs baseline 21) while a custom post-launch window labeled post_launch_window read +27.27% because it compared quieter January endpoints. Same brand, different questions. Named objects keep those reads side by side in one response.

When should analysts open get_trends after get_growth?

Growth rows summarize two endpoints. A viral news day can lift recent_value without sustained demand. If custom flight growth looks extreme, pull weekly get_trends on the same keyword and source and scan weeks inside the flight. Product launch trend research templates use the same pattern when launch decks need both headline growth and curve shape.

For sub-weekly resolution inside the last month, REST callers can set data_mode to daily on supported Google sources. MCP clients omit data_mode by default; daily pulls are a REST-only knob today.

How do Python and TypeScript clients express custom periods?

Python (trendsmcp package):

from trendsmcp import TrendsMcpClient, CustomGrowthPeriod

client = TrendsMcpClient(api_key="YOUR_API_KEY")
growth = client.get_growth(
    source="amazon",
    keyword="air fryer",
    percent_growth=[
        "30D",
        CustomGrowthPeriod(
            name="black_friday_window",
            recent="2025-12-15",
            baseline="2025-11-15",
        ),
    ],
)

TypeScript (trendsmcp npm package) accepts the same object inline in percent_growth. Field names match REST exactly, which keeps agent-generated code aligned with Postman collections from search trend API docs.

What mistakes show up in campaign attribution reads?

Single preset conclusions. Reporting only MTD after a mid-month launch overstates or understates lift because the baseline mixes pre-launch days.

Ignoring snap fields. Comparing recent_requested across keywords without checking recent_date misaligns flights when series lack observations on exact calendar days.

Volume silence. Stating percent lift without checking volume_available overstates precision on sparse keywords.

Source mismatch. TikTok hashtag growth during a flight does not prove Amazon conversion; multi-source reads exist to show where demand registered, as covered in performance creative trend testing workflows.