Update persistent window logic to not show for new users

[danielrvidal]

Based on this thread, we need to update the logic so we do not show the persistent window to new users, including non admins.

@KJ21-ENG gave a great update on the background:

The video confirms that the August member window appears during the first authenticated session, which matches the fresh-member test in PR #98565. We previously agreed in the PR #98441 review, with the follow-up recorded on issue #95791, that suppressing the product marketing window during a user’s first session would be preferable. However, that work has not shipped. The existing follow-up, issue #98951, is currently scoped to returning Collect/Control admins. We should clarify whether first-session suppression should apply to every product-marketing campaign and audience. If so, issue #98951 should be broadened or a separate generic follow-up issue should be created.

cc: @Huu Le

Issue Owner

Current Issue Owner: @huult

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[danielrvidal]

Assigning @huult who is going to be C+ reviewer. @mallenexpensify can you help in creating the issue?

[trasnake87]

Proposal

What is the root cause of that problem?

ProductMarketingWindowManager has no notion of onboarding or of a first session. Its only relationship to onboarding is a route check: ONBOARDING_MODAL_NAVIGATOR is in CENTERED_MODAL_SCREEN_NAVIGATORS, so the window is hidden only while that navigator is the topmost root route.

App/src/components/ProductMarketingWindow/ProductMarketingWindowManager.tsx

Lines 99 to 112 in 1d0d7de

	if (
	!announcement ||
	!variant ||
	isMemberVariantUnavailable ||
	isLoading ||
	isProductMarketingWindowCovered ||
	isAnonymousSession ||
	isActingAsDelegate ||
	isCoveredByCenteredModalScreen ||
	shouldShowRequire2FAPage ||
	isIn2FASetupFlow
	) {
	return null;
	}

Tracing the fresh-signup path: the manager mounts with RootNavigatorExtraContent when AuthScreens mounts, so it is alive for the entire first authenticated session. During guided setup isCoveredByCenteredModalScreen is true and nothing renders. The moment the user finishes (or exits) guided setup, that navigator is popped, isCoveredByCenteredModalScreen flips to false, lastDismissedMarketingWindow is empty for a brand-new account, and targetAdminPolicyID is undefined for an invited member — so getProductMarketingAnnouncementVariant returns the member variant and the August window renders in the same session. That is exactly the video: the window appears during the first authenticated session, right after onboarding.

This is why simply reading hasCompletedGuidedSetupFlow and hiding while it is false does not fix the report — that flag flips to true mid-session, at precisely the instant the bug fires. The suppression has to be latched for the rest of the session.

That latch already exists in the sibling promo surface, useAIFeaturesPromoModal, as observedActiveOnboardingThisSession:

App/src/hooks/useAIFeaturesPromoModal.ts

Lines 64 to 69 in 1d0d7de

	useEffect(() => {
	if (hasCompletedOnboarding !== false) {
	return;
	}
	observedActiveOnboardingThisSession = true;
	}, [hasCompletedOnboarding]);

The marketing window never got the equivalent.

What changes do you think we should make in order to solve the problem?

Extract that latch into a shared hook and consume it in the manager, so suppression is audience-independent (it sits in the manager's guard, not in variant selection) and every future campaign inherits it.

Add src/hooks/useHasActiveOnboardingThisSession.ts:

function useHasActiveOnboardingThisSession(): boolean {
    const [onboarding, onboardingMetadata] = useOnyx(ONYXKEYS.NVP_ONBOARDING);
    const [hasObservedActiveOnboarding, setHasObservedActiveOnboarding] = useState(false);
    const hasCompletedGuidedSetupFlow = hasCompletedGuidedSetupFlowSelector(onboarding);

    useEffect(() => {
        if (hasCompletedGuidedSetupFlow !== false) {
            return;
        }
        setHasObservedActiveOnboarding(true);
    }, [hasCompletedGuidedSetupFlow]);

    // Fails closed while the NVP loads so the window can't flash before onboarding status is known.
    return hasObservedActiveOnboarding || hasCompletedGuidedSetupFlow === false || isLoadingOnyxValue(onboardingMetadata);
}

Component state — not a module-level flag — is the correct scope here: AuthScreens unmounts on sign-out, so the latch resets per authenticated session by construction and cannot leak into a subsequent copilot or account switch.

Then in ProductMarketingWindowManager, add the hook and one clause to the existing guard at line 99:

+    const hasActiveOnboardingThisSession = useHasActiveOnboardingThisSession();
...
         shouldShowRequire2FAPage ||
-        isIn2FASetupFlow
+        isIn2FASetupFlow ||
+        hasActiveOnboardingThisSession
     ) {

hasCompletedGuidedSetupFlowSelector returns true for empty/migrated onboarding NVPs, so old and OldDot-migrated accounts are unaffected, and the user still sees the campaign on their next session:

App/src/selectors/Onboarding.ts

Lines 16 to 27 in 1d0d7de

	function hasCompletedGuidedSetupFlowSelector(onboarding: OnyxValue<typeof ONYXKEYS.NVP_ONBOARDING>): boolean | undefined {
	// Onboarding is an empty object for old accounts and accounts migrated from OldDot
	if (isEmptyObject(onboarding)) {
	return true;
	}
	if (!isEmptyObject(onboarding) && onboarding?.hasCompletedGuidedSetupFlow === undefined) {
	return true;
	}
	return onboarding?.hasCompletedGuidedSetupFlow;
	}

No existing clause is removed or loosened — this is purely additive.

To see the current behavior: sign up a fresh member account, complete guided setup, and stay in the session; the member window appears as the onboarding modal closes.

Answering the open question in the issue: yes, suppression belongs to every campaign and audience, which is why it goes in the manager's shared guard. useAIFeaturesPromoModal's local flag is the same latch and should collapse onto this hook, but I'd keep that out of this PR rather than perturb the promo modal's runAfterTransitions timing.

What alternative solutions did you explore? (Optional)

Adding the check to useShouldSuppressPromotionalUI, the existing shared promo-suppression hook. Rejected: useOnboardingFlow consumes it, so making it true for onboarding users would prevent the onboarding flow itself from ever launching.

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The persistent bottom-right product marketing window is shown to brand-new users during their very first authenticated session, right after they sign up. It should be suppressed for new users in that first session, for every audience — members as well as admins — and the suppression should be generic enough to apply to any product marketing campaign, not just the current August 2026 one.

What is the root cause of that problem?

ProductMarketingWindowManager decides whether to render the window purely from campaign/dismissal/overlay state. Its early-return gate checks the active announcement, the resolved variant, the member beta, Onyx loading, covering overlays, anonymous sessions, delegate sessions, centered-modal screens and the 2FA flows — but there is no condition at all for "this user is brand new / is in their first authenticated session":

App/src/components/ProductMarketingWindow/ProductMarketingWindowManager.tsx

Lines 99 to 112 in 1d0d7de

	if (
	!announcement ||
	!variant ||
	isMemberVariantUnavailable ||
	isLoading ||
	isProductMarketingWindowCovered ||
	isAnonymousSession ||
	isActingAsDelegate ||
	isCoveredByCenteredModalScreen ||
	shouldShowRequire2FAPage ||
	isIn2FASetupFlow
	) {
	return null;
	}

Because eligibility is derived only from getProductMarketingAnnouncementVariant, which returns a variant whenever the announcement has not been dismissed, a freshly created account qualifies immediately: nvp_lastDismissedMarketingWindow is unset for a new account, so the announcement is not dismissed and a variant is always produced.

App/src/libs/ProductMarketingWindowUtils.ts

Lines 114 to 123 in 1d0d7de

	function getProductMarketingAnnouncementVariant(
	announcement: ProductMarketingAnnouncement | null,
	hasActiveAdminPolicies: boolean,
	lastDismissedMarketingWindow: OnyxEntry<string>,
	): ProductMarketingAnnouncementVariant | undefined {
	if (!announcement || isProductMarketingAnnouncementDismissed(announcement, lastDismissedMarketingWindow)) {
	return undefined;
	}
	return hasActiveAdminPolicies ? announcement.admin : announcement.member;
	}

The manager gates on isLoadingApp, so it waits for OpenApp and then renders as soon as the app finishes loading — which, for a new signup, is inside the same first session in which they go through onboarding. Since the audience split only picks admin vs member content, non-admin new users get the member variant rather than being excluded, which is exactly the reported behaviour.

App/src/components/ProductMarketingWindow/ProductMarketingWindowManager.tsx

Lines 82 to 90 in 1d0d7de

	const variant = getProductMarketingAnnouncementVariant(announcement, !!targetAdminPolicyID, lastDismissedMarketingWindow);
	const isMemberVariantUnavailable = variant === announcement?.member && !isBetaEnabled(CONST.BETAS.CUSTOM_AGENT);
	const isVendorMatchingBetaEnabled = isBetaEnabled(CONST.BETAS.VENDOR_MATCHING);
	const shouldPrefetchTargetPolicyConnections = isVendorMatchingBetaEnabled && !!targetAdminPolicyID && targetAdminPolicyID !== activePolicyID;
	const {isFetchNeeded, isLoadingFetchedFlag, hasBeenFetched} = usePolicyConnectionsPrefetch(targetAdminPolicy, shouldPrefetchTargetPolicyConnections);
	const isAdminCtaPending = shouldPrefetchTargetPolicyConnections && (isLoadingFetchedFlag || (isFetchNeeded && hasBeenFetched === undefined));
	const isAdminPolicyConnectionDataAvailable = !shouldPrefetchTargetPolicyConnections || hasBeenFetched === true;
	const isCoveredByCenteredModalScreen = !!topmostRouteName && CENTERED_MODAL_SCREEN_NAVIGATORS.has(topmostRouteName);
	const isLoading = isLoadingOnyxValue(lastDismissedMarketingWindowMetadata, targetAdminPolicyIDMetadata, activePolicyIDMetadata, isLoadingAppMetadata, accountMetadata) || isLoadingApp;

The app already has a first-session suppression concept for promotional UI, but the product marketing window never adopted it. useAIFeaturesPromoModal tracks, in a session-scoped module flag, whether onboarding was ever observed as incomplete during this session, and refuses to show the promo when it was:

App/src/hooks/useAIFeaturesPromoModal.ts

Lines 64 to 82 in 1d0d7de

	useEffect(() => {
	if (hasCompletedOnboarding !== false) {
	return;
	}
	observedActiveOnboardingThisSession = true;
	}, [hasCompletedOnboarding]);
	const isAllOnyxLoaded = !isLoadingOnyxValue(isLoadingAppMetadata, dismissedProductTrainingMetadata, tryNewDotMetadata, onboardingMetadata);
	const isEligible =
	isAllOnyxLoaded &&
	!!session?.authToken &&
	!isLoadingApp &&
	!shouldSuppressPromotionalUI &&
	!hasRedirectedToAIFeaturesPromoModal &&
	!isAIPromoModalDismissed &&
	!isMigrationModalPending &&
	!observedActiveMigrationModalThisSession &&
	!observedActiveOnboardingThisSession;

What changes do you think we should make in order to solve the problem?

Give the product marketing window the same first-session suppression that the AI features promo already uses, and factor it out so it is generic across campaigns and audiences.

1. Add a small shared hook (for example src/hooks/useHasOnboardedThisSession.ts, or an equivalently named "is the user in their first authenticated session" hook) that reads ONYXKEYS.NVP_ONBOARDING through the existing hasCompletedGuidedSetupFlowSelector and keeps a module-level sticky flag: once the selector has reported false at any point in the current session, the flag stays set for the rest of that session. This is the same mechanism as observedActiveOnboardingThisSession in useAIFeaturesPromoModal, just hoisted so more than one surface can consume it. The stickiness is the important part — a new user completes onboarding mid-session, which flips the value to true, and without the sticky flag the window would simply appear a moment later in that same session.

2. The check must be strictly against false, never a truthiness check, because undefined from that selector means "not loaded yet", not "new user". The selector already normalizes old and OldDot-migrated accounts — an empty or field-less nvp_onboarding is reported as true — so a strict comparison keeps those existing users eligible while a loose check would suppress the campaign for them:

App/src/selectors/Onboarding.ts

Lines 16 to 27 in 1d0d7de

	function hasCompletedGuidedSetupFlowSelector(onboarding: OnyxValue<typeof ONYXKEYS.NVP_ONBOARDING>): boolean | undefined {
	// Onboarding is an empty object for old accounts and accounts migrated from OldDot
	if (isEmptyObject(onboarding)) {
	return true;
	}
	if (!isEmptyObject(onboarding) && onboarding?.hasCompletedGuidedSetupFlow === undefined) {
	return true;
	}
	return onboarding?.hasCompletedGuidedSetupFlow;
	}

3. In ProductMarketingWindowManager, consume that hook and add its result to the early-return list alongside the existing isAnonymousSession / isActingAsDelegate conditions. Placing it in that gate — rather than inside getProductMarketingAnnouncementVariant — means it applies before the admin/member split, so both the admin and the member variant are suppressed and the "including non admins" part of the request is covered by construction.

4. Include the nvp_onboarding metadata in the existing isLoadingOnyxValue call that computes isLoading in the manager. The window must fail closed while that key hydrates, otherwise a new user can still get a brief flash of the window in the window between OpenApp finishing and the onboarding NVP arriving.

5. Leave dismissal persistence alone: this is suppression for the first session only, not a dismissal. We should not write nvp_lastDismissedMarketingWindow for these users, because that would permanently burn the current campaign for an account that never actually saw it.

Because the gate lives in the manager and keys off the announcement-agnostic first-session signal, it automatically covers whatever campaign is set as ACTIVE_PRODUCT_MARKETING_ANNOUNCEMENT in the future, which is the generic behaviour the issue asks us to clarify.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/99389-marketing-window-first-session?expand=1

What alternative solutions did you explore? (Optional)

Deriving "new user" from a timestamp instead of onboarding state — for instance treating the account as new when the session is young. This does not work: Session.creationDate is written on every login and token refresh, so it measures the age of the current session, not the age of the account, and there is no account-creation timestamp exposed on the account Onyx key.

App/src/libs/actions/Session/updateSessionAuthTokens.ts

Line 15 in 1d0d7de

return Onyx.merge(ONYXKEYS.SESSION, {authToken, encryptedAuthToken, creationDate: new Date().getTime()});

Having the backend pre-set nvp_lastDismissedMarketingWindow to the active update key at signup. That would also hide the window for new accounts, but it is a backend change outside this repo, it does not help accounts that were created before it ships, and it permanently marks the campaign as dismissed rather than merely deferring it past the first session.

[Abdukhamid000]

Proposal

What is the root cause of that problem?

ProductMarketingWindowManager's only relationship to onboarding is a route check — ONBOARDING_MODAL_NAVIGATOR is listed in CENTERED_MODAL_SCREEN_NAVIGATORS, so the window is hidden only while that navigator happens to be topmost:

App/src/components/ProductMarketingWindow/ProductMarketingWindowManager.tsx

Lines 99 to 112 in 1d0d7de

	if (
	!announcement ||
	!variant ||
	isMemberVariantUnavailable ||
	isLoading ||
	isProductMarketingWindowCovered ||
	isAnonymousSession ||
	isActingAsDelegate ||
	isCoveredByCenteredModalScreen ||
	shouldShowRequire2FAPage ||
	isIn2FASetupFlow
	) {
	return null;
	}

A route check answers "is something covering the screen right now", not "is this user new". The manager mounts with AuthScreens and stays mounted for the whole first session, so the moment that navigator is popped the guard opens: lastDismissedMarketingWindow is empty on a fresh account, getProductMarketingAnnouncementVariant returns the member variant, and the window renders in the same session the user just signed up in.

This is also why reading hasCompletedGuidedSetupFlow directly does not fix it — the flag flips to true at exactly the moment the window becomes eligible. The suppression has to be latched for the rest of the session.

Invited members — the "including non admins" case — never get the route check at all, because useOnboardingFlow returns early for them and the onboarding navigator never mounts:

App/src/hooks/useOnboardingFlow.ts

Lines 107 to 112 in 1d0d7de

	const isMigratedUser = hasBeenAddedToNudgeMigration ?? false;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const isInvitedOrGroupMember = (hasNonPersonalPolicy || wasInvitedToNewDot) ?? false;
	if (isMigratedUser || isInvitedOrGroupMember || shouldSuppressPromotionalUI) {
	return;
	}

Their flag still goes false → true during that first session, just through the OpenReport guided-setup path instead (Report/index.ts:1634 → ReportUtils.ts:12811-12817). So a state-based signal covers both audiences, where the route check only ever covered one.

What changes do you think we should make in order to solve the problem?

Latch "onboarding was observed incomplete during this session" and add it to the manager's existing early return, so suppression sits ahead of the admin/member split:

const hasCompletedGuidedSetupFlow = hasCompletedGuidedSetupFlowSelector(onboarding);
const [hasObservedActiveOnboarding, setHasObservedActiveOnboarding] = useState(false);

useEffect(() => {
    if (hasCompletedGuidedSetupFlow !== false) {
        return;
    }
    setHasObservedActiveOnboarding(true);
}, [hasCompletedGuidedSetupFlow]);

Two details that decide whether this actually works:

Keep the latch in component state, not a module-level flag. AuthScreens unmounts on sign-out, so component state resets per authenticated session by construction. A module-level flag survives an account switch inside the same JS context and would then suppress the window for the next user — which is a live bug in useAIFeaturesPromoModal's observedActiveOnboardingThisSession, and not something to copy while hoisting it.

Fail closed while NVP_ONBOARDING hydrates by adding its metadata to the isLoadingOnyxValue call that already computes isLoading at :90. Without it a new user can still catch a flash between OpenApp finishing and the NVP arriving.

hasCompletedGuidedSetupFlowSelector reports true for empty and OldDot-migrated NVPs, so existing accounts are untouched and the user still gets the campaign on their next session.

On the question the issue raises: this belongs in the manager's guard rather than in variant selection, which makes it audience-independent and campaign-independent by construction — so #98951 does not need re-solving per audience.

One limitation worth stating rather than hiding: this is scoped to the JS session, so a new user who finishes onboarding and then hard-reloads will see the window. Closing that needs a persisted marker; happy to add one if first-day rather than first-session is the intent.

What alternative solutions did you explore? (Optional)

Marking the active campaign dismissed once onboarding completes (writing nvp_lastDismissedMarketingWindow). Durable across reloads and needs no latch, but no single completion hook covers every new-user path — organic signups finish through the onboarding modal, invited members through OpenReport — and it records a dismissal for a window that was never shown.

Excluding new users inside getProductMarketingAnnouncementVariant. Rejected: variant selection runs after the admin/member split, so the exclusion would have to be repeated per audience, which is the shape the issue is explicitly trying to get away from.

[Tyleresch]