Analytics: Attach the selected site to My Site dashboard card impressions

[jkmassel]

The My Site dashboard shows exactly one site, but my_site_dashboard_card_shown fired without a blog_id for two of its cards — posts and Blaze — so Data Science measured the site present on only 56.1% of jpios_my_site_dashboard_card_shown rows over a 14-day window (6,510,007 fires). This attaches the site to every card's impression.

Root cause

BlogDashboardAnalytics.track(_:properties:blog:) took blog as an optional defaulting to nil, and only routed through the site-attaching path when a blog was supplied:

if let blog {
    WPAnalytics.track(event, properties: properties, blog: blog)  // sets blog_id
} else {
    WPAnalytics.track(event, properties: properties)              // no blog_id
}

Of the six cards that fire the event, three passed blog (activity_log, todays_stats, pages) and three did not: post — whose two sub-types are the highest-volume rows — and blaze. The optional made it possible to add a card and ship it without a site, which is how coverage drifted to ~56%.

Changes

• Require blog. BlogDashboardAnalytics.track now takes a non-optional Blog and always calls WPAnalytics.track(_:properties:blog:), which sets blog_id to the site's dotComID. The dashboard always has one site, so the type system now guarantees every impression carries it and no future card can drop it. This mirrors Android's trackWithSiteDetails(...).
• PostsCardViewModel — pass the view model's blog for the .posts and .error sub-types.
• DashboardBlazeCardCell — thread the already-unwrapped blog from update(with:) into the card-shown call.
• DashboardPostsListCardCell — delete trackPostsDisplayed(). It fired the same event without a site but had no callers; the live posts impression is PostsCardViewModel.trackCardDisplayedIfNeeded(). Removing it closes a path that would double-count if it were ever wired up.

The three cards that already passed blog are unchanged.

Not in this PR

• Self-hosted sites. blog_id comes from blog.dotComID, which is nil for self-hosted sites, so those impressions still carry no site — the same behavior as the three already-correct cards, and the reason the target is ~95% rather than 100%.
• Event registration (Part 2 of CMM-2213) is a Tracks-side task, not an app change.
• dynamic_dashboard_card_shown and free_to_paid_plan_dashboard_card_shown are separate events.

Test plan

• WordPress scheme compiles clean — cold build, 0 errors.
• Sign in to a WordPress.com or Jetpack site and open the My Site tab. In the Xcode console, each card logs 🔵 Tracked: my_site_dashboard_card_shown <blog_id: <site id>, sub_type: …, type: …> — confirm the post and blaze lines now include blog_id (they previously had none).
• After deploy, re-run the CMM-2213 verification query and confirm blog_id_pct for jpios_my_site_dashboard_card_shown and wpios_my_site_dashboard_card_shown is at or above 95.

Related

• Android fix: CMM-2213: Attach selected site to My Site dashboard card impressions WordPress-Android#23186
• CMM-2213

[dangermattic]

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	33657
	Version	PR #25882
	Bundle ID	org.wordpress.alpha
	Commit	2617daa
	Installation URL	1p8ofseeuhsb0

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	33657
	Version	PR #25882
	Bundle ID	com.jetpack.alpha
	Commit	2617daa
	Installation URL	6di7h5eeg5m7o

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[jkmassel]

This wasn't called anywhere