<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=634504) </details> <!--IssueSummary end--> ## Problem Changes to GitLab.com often apply to some tiers before others. The 2026 rate limit changes hit Free first, with Premium and Ultimate following in January 2027. We announced the Free preview windows with broadcast messages, which can only target by role and URL path. Paid users saw a Free-only notice and asked their account teams why the date applied to them. Targeted messages fit this better: they are GitLab.com only, scoped to namespaces, and filter by role. For this use case they're missing three things: 1. Message content. The banner copy is hardcoded today (https://gitlab.com/gitlab-org/gitlab/-/work_items/514256). 2. Placement beyond the group Billing page (https://gitlab.com/gitlab-org/gitlab/-/work_items/528871). 3. An audience that isn't an uploaded list. Uploads are capped at 50,000 namespace IDs, so reaching everyone on a tier means building and uploading lists by hand. ## Proposal Add a `plans` attribute to targeted messages. - A message with plans and no namespace list reaches every top-level group on those tiers. Subgroups and projects inherit from their top-level group. - A message with both applies plans as an extra filter on the list. - Admins pick tiers (Free, Premium, Ultimate). Trials and open source count as the tier they unlock. - Dismissing a plan-wide message hides it everywhere for that user. Dismissals of listed messages stay per namespace. ## Draft merge requests I built this locally in Caproni with GitLab.com simulated, and the work is in two draft MRs: 1. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/263236 fixes three bugs in the current code (below). It stands on its own. 2. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/263237 adds plan targeting on top of it, behind a new `targeted_messages_plan_audience` flag that can roll out by root group: an explicit audience, title, body and CTA, a server-rendered banner on group and project pages, UTC hints and a preview in the admin form, and plan-wide dismissal. Its description has screenshots, a demo video and the test results. ## Bugs in the current code 1. `TargetedMessageResolver` doesn't check `starts_at` or `ends_at`. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/216492 added the schedule so messages display during set windows, but nothing filters on it, so a message shows as soon as it's created and never expires. 2. `starts_at_not_in_past` runs on every save. Once a message has started, any edit fails validation, including moving the end time to end it early. 3. The admin form's CSV limit hint never renders, because `GlFormFields` reads descriptions from `groupAttrs`. ## Performance From the prototype, so read the timings as relative cost, not production latency. - Production traffic, from Kibana (`pubsub-rails-inf-gprd*`, 24 full hours to 12:00 UTC on 19 October 2026): signed-in users loaded 5.83M group and project HTML pages, 67 a second on average and 200 a second in the busiest hour. - A first draft fetched the banner with a GraphQL request from each page. That came to 11 SQL queries and 64 ms of server time per page view, which at the peak would have meant about 200 extra GraphQL requests a second. - The MR now renders live messages into the layout on the server: one extra SQL query on the page and no extra request. While no message is live, a cached check skips even that. - Plan-wide messages are stored with an explicit audience, so the lookup needs no join against the namespace list. The dismissal check uses the existing `(user_id, namespace_id, targeted_message_id)` index: 0.02 ms at 5M rows on synthetic data. - Plan-wide messages add one dismissal row per user who dismisses them. https://gitlab.com/gitlab-org/gitlab/-/work_items/521640 covers retention. ## Questions for Growth 1. Is gitlab-org&16371 still planned, and who owns it now? The last code change was in June, and the last human comments on its child issues were in January. 2. Should plan targeting live here, or reuse the audience logic in https://gitlab.com/gitlab-org/gitlab/-/work_items/632721? 3. Can someone on the team review the two MRs, or tell us if you'd rather take this in a different direction? ## Out of scope A permission short of full admin, git CLI output, tracking, and messages on personal namespaces. <!-- AI-Sessions dir: ~/.claude/projects/-Users-samwiskow-projects/ 6e7d7887-42e9-4f47-8969-27146eb10ab5.jsonl (2026-10-19) -->