Premium Analytics: Add email post detail views

[dognose24]

Part of WOOA7S-1623.

Proposed changes

• Add fixed Email opens and Email clicks compositions to the post detail page.
• Reuse the existing email highlights and breakdown widgets for opens, clicks, devices, clients, countries, and top links.
• Combine the opens and clicks summaries for the Email clicks highlights.
• Add the country map variant used by the wide Location clicks card while keeping the adjacent leaderboard capped.
• Gate the email tabs on the post's send summary: they only show when total_sends from the per-post opens rate summary is positive — the same query the Email top row reads, so React Query shares the result and the gate costs no extra request. It fails closed (hidden while loading/errored), and deep links to a gated tab fall back through the existing hidden-tab path. Calypso infers the same availability from subscription settings, post metadata, and a 2023-05-30 date cutoff because it decides before fetching; the send summary is the direct signal.
• Align the cards with the design spec: the highlights row is titled Newsletter performance with Sent / Total unique opens / Total opens|clicks / Open|Click rate tiles, and each breakdown card carries its design title (Location/Platforms/Clients opens|clicks, Top links) via page-local aliases of jpa/email-breakdown — the host titles a card by widget type, so the fixed page clones the resolved type (render module and all) under variant names that can never leak into a widget gallery (this page has none).
• Drop the header dropdowns: the top row's Opens/Clicks switch duplicates the tab split and the breakdown's view selector would fight the fixed composition, so both attributes return to default (low) relevance.
• Email clicks lays out as 3/1 + 2/2 (mapped Location clicks + Platforms, then Clients + Top links).
• Bound the breakdown list height so every view scrolls inside its card (the non-map wrapper's flex sizing was inert inside WidgetState's plain-block ready container, so overflow was clipped instead of scrolling).
• Hold the hidden-tab URL normalization until the email gate's send summary settles, so a deep link to an email tab survives the first load instead of being rewritten to Post traffic (review follow-up).
• Split out per review: the rate-fraction fix moved to Premium Analytics: Email top row rates are 0–1 fractions, not percentages #50563 and the date-filters relocation to Premium Analytics: move the post detail date filters below the tab bar #50562; this PR no longer contains either.
• Keep the performance chart out of scope for this PR (tracked in WOOA7S-1738).

Related product discussion/links

• WOOA7S-1623
• WOOA7S-1622

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

No. It presents existing email Stats API data in the post detail page.

Testing instructions

• Open Premium Analytics and navigate to a post detail page with newsletter statistics.
• On a post never emailed to subscribers (or a site without newsletter), the Email opens/clicks tabs stay hidden and a deep link to them falls back to Post traffic.
• Select Email opens and confirm the highlights row is followed by the countries/devices/clients cards in a 2/1/1 layout.
• Select Email clicks and confirm the highlights show Sent, Total unique opens, Total clicks, and Click rate.
• Confirm Email clicks shows the wide Location clicks card with a country map, Platforms clicks, Clients clicks, and Top links.
• Confirm Top links renders internal link types and safe user-content links.
• Confirm no card shows a header dropdown (the Opens/Clicks split lives in the tabs), each breakdown card carries its design title, and lists longer than a card scroll inside it (the Location card scrolls its list while the map stays put).
• Run pnpm test -- --runInBand and pnpm run typecheck from projects/packages/premium-analytics.
• Run pnpm run build from projects/packages/premium-analytics.

Screenshots

Email Opens

Email Clicks

[github-actions]

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:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. 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!

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report

[chihsuan]

Thanks for this @dognose24

This PR seems cover a few separate concerns: the rate fix, reusable Email widget enhancements, Post Details layout changes, and the final tab integration.

Would you be open to splitting these into smaller PRs? I think it would make the changes easier to review and reduce the risk of unrelated regressions. 🙏

[chihsuan]

While this query is loading, data is undefined, so an email-opens deep link gets replaced with post-traffic before we know whether Email stats exist. Should we wait for the query to settle before normalizing the URL?

[dognose24]

Good catch — this was real: the normalization effect fired during the first load and rewrote a legitimate email-opens deep link before the gate knew whether email stats exist.

Fixed in d2e94a2: the hidden-tab URL normalization now waits for the send summary to settle (isLoading is false while the query is disabled and once it resolves or errors, so only the first load holds it off). The visible fallback still renders immediately — only the URL write waits. Added a regression test for the loading + deep-link case.

[dognose24]

Thanks for the review @chihsuan! Split done where the pieces were genuinely independent:

• Date-filters relocation → Premium Analytics: move the post detail date filters below the tab bar #50562 (it changes the whole post detail page, not only the email tabs — agreed it deserved its own review and screenshots). Reverted here.
• Rate-fraction fix → Premium Analytics: Email top row rates are 0–1 fractions, not percentages #50563. Reverted here.

I kept the email widget enhancements and the tab integration together: the fixed compositions directly reference the new widget surface (the showMap attribute, the merged Clicks summary, and the page-local title aliases), so splitting them would leave an intermediate state that can't be exercised or reviewed on its own — the enhancements only become observable once the layouts place them. Happy to split further if you still prefer it after this trim.

Also fixed the deep-link race you flagged inline — good catch. The URL normalization now waits for the send summary to settle.

[kangzj]

Thorough review of the package (full-file reads, JS tests, typecheck). Findings from the review of cac0788:

• [blocker — already fixed in d2e94a2] Deep links / refreshes on an email tab bounced to Post traffic: the hidden-tab URL normalization raced the send-summary gate query and always won on a cold load. The gateSettled = ! opens.isLoading guard resolves it, and I verified the disabled-query edge: on @tanstack/react-query v5, a disabled query (no post scope) reports isLoading: false, so normalization still runs there. The added regression test covers the loading deep-link case. ✅
• [moot] A stale test name (“converts the 0–100 rate”) flagged against the 0–1 fraction change no longer applies after the rate handling was split out and reverted in d2e94a2.
• [suggestion] One minor note posted inline: the hidden country map still mounts Google Charts below 720px.

Also verified: changelog entry valid; i18n domains correct; new CSS uses logical properties with a proper container-type ancestor; jpa/email-breakdown / jpa/email-top-row have no consumers outside the post detail page, so the relevance removals and layout wrapper are safe; package tests (32 PR-scoped) and typecheck pass locally. The one unrelated local test failure (WordAds window clamp in packages/data) is byte-identical to trunk and green in CI.

LGTM once the inline note is considered — nothing blocking remains.

[kangzj]

[suggestion] Below a 720px container the map is display: none (container query in style.module.css), but GeoChart still mounts here, so narrow layouts pay the Google Charts load for a chart that's never visible. Fine to defer — a JS-side width check or lazy-mount on visibility would avoid the dead weight.

[dognose24]

Went ahead and implemented it in 84b8a01 rather than deferring — GeoChart now mounts only once the measured container is ≥ the same 720px the CSS query needs to show it (ResizeObserver on the widget root, first paint defaults to unmounted), so a narrow layout never loads Google Charts at all. CSS still owns the visual fallback.

[kangzj]

Approving — the deep-link race flagged earlier is fixed in d2e94a2 and nothing blocking remains (full findings in my review above). The PR is on the larger side, but given the deadline I'm happy for it to merge as is; the one remaining inline note (lazy-mounting the hidden map) can land as a follow-up.

[chihsuan]

Thanks for the thoughtful update! @dognose24

I left one concern about the email-tab gate treating a failed request as a completed availability check but it's minor.

The rest of the data merging and shared-query approach looks sensible to me. 🙏

Pre-approving.

[chihsuan]

One small concern: if this request fails or times out, isLoading becomes false while the data is still unavailable. We would then hide the Email tabs and rewrite an Email deep link to Post traffic, even though we don’t know whether the post has email stats yet.

Could we preserve the requested section on error and only normalize the URL after a successful response?

[dognose24]

Fixed in 84b8a01 — normalization now requires the query to have succeeded (opens.isSuccess), not merely settled: on a failed/timed-out request the URL keeps the requested email section (the tabs stay hidden, fail-closed, and a later successful refetch settles it). Non-email deep links don't depend on the gate and normalize right away. Added a regression test for the errored deep-link case.