Premium Analytics: move Top tags & categories to Traffic and follow the date picker by dognose24 · Pull Request #53299 · Automattic/jetpack

dognose24 · 2026-10-07T13:03:43Z

Blocked on the WordPress.com half, WOOA7S-2235 (wpcom PR 245720), which lets stats/tags take a date window. Until that is merged and deployed, WordPress.com strips every date parameter from the request and the widget keeps showing the seven days ending yesterday whatever the picker says. This PR stays a draft until then.

Why

Top tags & categories sat on the Insights tab as a fixed last-7-days list, because the endpoint behind it ignored every date parameter. Product asked on the soft-launch thread for it to sit on Traffic and follow the date picker like the other list widgets.

Proposed changes

statsTagsQuery takes the report params like the other Stats list queries and sends date and start_date, from which the endpoint sizes its window. It sends summarize=1 at every length, so the endpoint ranks the window's top posts in one pass: the per-day path keeps 50 posts a day while one pass keeps 50 for the window, so switching between them by length would let a longer range count fewer posts than a shorter one. A 7-day range therefore no longer matches the per-day ranking classic Stats reads, which is deliberate. days stays off the request.
The widget reads reportParams from WidgetRoot and hands the window to useStatsTags(). It opts out of the comparison, since stats/tags reports one period.
The widget moves from get_insights_section_default_layout() to get_traffic_section_default_layout(), as a new row after File downloads. Row placement is a provisional pick, not a design call; the remaining Insights rows keep their widths and close up by one order.
widget.json: the title drops "in the last 7 days" (the picker names the period now); the description and help say what the number is, a breakdown of the most viewed posts by their current tags and categories, not a filter over all traffic.
The Tags report page gets the same date filters as the other Traffic reports and passes the window to its records hook. Its registry entry moves to the traffic section too, so the report is gated on the Traffic tab rather than Insights.
The CSV export names the window in its filename, as the dated exports do.
A customized layout does not follow a default change, so a reader who customized Insights keeps the Tags tile there (now on the Insights year picker) and one who customized Traffic does not gain it. Whether to move it for them once or only add it on Traffic is a product call, WOOA7S-2291; the migration is built and parked as a draft in Premium Analytics: move a stored Top tags & categories tile from Insights to Traffic once #53381, stacked on this PR.
Tests: query window and summarize at every length; the widget's request carries the window and refetches when the period changes; the report hook passes the window; the default layout tests follow the move; the CSV parity case for Tags moves to the dated set.

Related product discussion/links

WOOA7S-2236, WOOA7S-2235
Product ask: p1790692858546939-slack-C06FSDTSN82

Does this pull request change what data or activity we track or use?

No.

Testing instructions

Needs a site whose WordPress.com side carries wpcom PR 245720 (a sandbox with that branch, or after it deploys).

Stats → Traffic: the widget sits at the bottom. Change the period: the rows change and the stats/tags request carries date and start_date for it. Whatever the range, the request also carries summarize=1.
Stats → Insights: the widget is gone.
With a layout saved on both tabs from before this change (customize each tab on trunk first): the stored layouts are untouched, Tags stays on Insights and follows its year picker there. Moving it is Premium Analytics: move a stored Top tags & categories tile from Insights to Traffic once #53381.
Widget → View all: the report page has the date filters, follows the same range, and its CSV download names the range.
Last 12 months and Year to date return in reasonable time on a site with traffic.
jp test js packages/premium-analytics and jp test php packages/premium-analytics pass.

🤖 Generated with Claude Code

…he date picker stats/tags takes a date window now (wpcom #245720), so the widget and its report read the dashboard period: date and start_date on the request, summarize past a month. The widget moves from the Insights default layout to the Traffic one, its copy stops naming seven days, and the CSV export names the window. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

github-actions · 2026-10-07T13:05:04Z

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the add/premium-analytics-tags-widget-traffic branch.
To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/premium-analytics-tags-widget-traffic

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

github-actions · 2026-10-07T13:05:21Z

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

✅ Include a description of your PR changes.
✅ Add a "[Status]" label (In Progress, Needs Review, ...).
✅ Add testing instructions.
✅ Specify whether this PR includes any changes to data or privacy.
✅ Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

Follow this PR Review Process:

Ensure all required checks appearing at the bottom of this PR are passing.
Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
You can use GitHub's Reviewers functionality to request a review.
When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

Jetpack plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

Wpcomsh plugin:

Next scheduled release: Atomic deploys happen twice daily on weekdays (p9o2xV-2EN-p2)

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

Premium Analytics plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

jp-launch-control · 2026-10-07T13:20:32Z

Code Coverage Summary

Coverage changed in 3 files.

File	Coverage	Δ%
projects/packages/premium-analytics/packages/data/src/queries/stats-tags-query.ts	3/3 (100.00%)	0.00%
projects/packages/premium-analytics/routes/reports/tags/page.tsx	9/9 (100.00%)	0.00%
projects/packages/premium-analytics/widgets/tags/render.tsx	17/18 (94.44%)	0.33%

Full summary · PHP report · JS report

A customized layout does not follow the default, so the first section layout migration rewrites the stored map: Tags leaves a customized Insights and joins a customized Traffic, recorded by id so a tile the reader removes afterwards stays removed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

chihsuan

Nice work on moving Tags onto the date picker! @dognose24 I left a few inline notes.

Have we confirmed with Gary how saved layouts should handle the move? I wonder if we should move Tags automatically, or only add it to Traffic and leave the existing one on Insights.

chihsuan · 2026-10-08T04:29:44Z

+ * instead of day by day, which keeps a long window to a few queries.
 */
-export type StatsTagsParams = {
+const SUMMARIZE_MIN_DAYS = 31;


Could we double-check how the numbers line up across the 31-day switch? I noticed the summarized path in wpcom PR 245720 keeps the top 50 posts for the whole window, while the per-day path keeps 50 per day. So Last 90 days can show fewer tags and views than Last 30 days.

You're right, and it is not a rounding difference: the per-day path keeps 50 posts for each day table, the summarized path keeps 50 for the whole window after the post_type filter, so a 30-day range could count a few hundred posts and a 90-day range only 50. Views fall as the window grows.

Fixed in 802a935 by dropping the 31-day switch: stats/tags now gets summarize=1 at every length, so every range reads the same way, the window's top 50 posts by tag. It is also cheaper, one UNION per partition instead of one query per day. The endpoint accepts summarize=1 for any length, nothing to change on the WordPress.com side.

The trade-off is deliberate: a 7-day range no longer matches the per-day ranking classic Stats reads, and Premium Analytics does not need to.

chihsuan · 2026-10-08T04:29:44Z

 			1,
 			2
 		),
+		// Row 6: tags & categories, ranked over the tab's period.


Should tags.dashboardSection in routes/reports/registry.ts move to 'traffic' too? It still says 'insights', so the Tags report is gated on the Insights tab being available.

Good catch, it was still gated on Insights. Moved to traffic in 29a3858, with the registry test's tab map updated.

chihsuan · 2026-10-08T04:29:44Z

 /**
 * `stats/tags` has no "all rows" value (see `StatsTagsParams`), so the report names a ceiling
- * past what a real site produces (the endpoint ranks at most ~51 posts a day over seven days).
+ * past what a real site produces (the endpoint ranks at most ~50 posts a day).


nit: Would it be worth dropping the per-day math here? With a window up to a year it no longer explains the 1000, and processing/stats/tags.ts still says the endpoint "takes only max".

Suggested change

* past what a real site produces (the endpoint ranks at most ~50 posts a day).

* past what a real site produces.

Dropped the per-day math, and reworded the note in processing/stats/tags.ts that still said the endpoint takes only max. Same commit.

chihsuan · 2026-10-08T04:29:44Z

+/**
+ *
+ * @param key
+ */


nit: Could we drop this leftover stub?

Suggested change

/**

*

* @param key

*/

Removed in 29a3858.

…es and a leftover stub Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Per-day ranking keeps 50 posts a day and the summarized pass keeps 50 for the whole window, so switching between them at a month let a longer range count fewer posts than a shorter one. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

…s-tags-widget-traffic # Conflicts: # projects/packages/premium-analytics/routes/reports/tags/page.tsx

… follow-up Whether a reader who customized Insights should have Tags moved for them, or only added on Traffic, is a product call still open on the review. The mechanism ships separately once it is made. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

dognose24 · 2026-10-08T19:14:48Z

Good question, and not one I should settle in this PR. I pulled the migration out: 7ee6ece leaves stored layouts alone, so a reader who customized Insights keeps the Tags tile there (on the Insights year picker now) and one who customized Traffic does not gain it. The move-it-once mechanism is parked as a draft in #53381, stacked on this one, and the call between moving it and only adding it on Traffic is WOOA7S-2291 for the product side.

dognose24 added Enhancement Changes to an existing feature — removing, adding, or changing parts of it [Status] In Progress labels Oct 7, 2026

dognose24 self-assigned this Oct 7, 2026

github-actions Bot added [Package] Premium Analytics [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Plugin] Premium Analytics [Plugin] Wpcomsh [Tests] Includes Tests labels Oct 7, 2026

github-actions Bot added the Docs label Oct 7, 2026

dognose24 marked this pull request as ready for review October 7, 2026 14:42

dognose24 requested a review from a team as a code owner October 7, 2026 14:42

dognose24 added [Status] Needs Review This PR is ready for review. [Status] Blocked / Hold and removed [Status] In Progress labels Oct 7, 2026

dognose24 requested a review from chihsuan October 7, 2026 15:24

chihsuan reviewed Oct 8, 2026

View reviewed changes

dognose24 and others added 4 commits October 9, 2026 00:55

Address review: gate the Tags report on Traffic, drop the per-day not…

29a3858

…es and a leftover stub Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/trunk' into add/premium-analytic…

24689f9

…s-tags-widget-traffic # Conflicts: # projects/packages/premium-analytics/routes/reports/tags/page.tsx

dognose24 mentioned this pull request Oct 8, 2026

Premium Analytics: move a stored Top tags & categories tile from Insights to Traffic once #53381

Draft

dognose24 requested a review from chihsuan October 8, 2026 19:20

	* past what a real site produces (the endpoint ranks at most ~50 posts a day).
	* past what a real site produces.

Conversation

dognose24 commented Oct 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

Proposed changes

Related product discussion/links

Does this pull request change what data or activity we track or use?

Testing instructions

Uh oh!

github-actions Bot commented Oct 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Oct 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jp-launch-control Bot commented Oct 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage Summary

Uh oh!

chihsuan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dognose24 commented Oct 8, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dognose24 commented Oct 7, 2026 •

edited

Loading

github-actions Bot commented Oct 7, 2026 •

edited

Loading

github-actions Bot commented Oct 7, 2026 •

edited

Loading

jp-launch-control Bot commented Oct 7, 2026 •

edited

Loading