In-app announcements get dismissed instantly when they are broadcast noise: one untargeted modal, shown to everyone, about a feature most viewers will never use. The fix is discipline, not louder design. Announce only to the segment the feature serves. Show the announcement at a moment when it is relevant, never on first launch. Give it exactly one action. Cap how often any single user sees announcements, measure whether the audience follows through, and retire every announcement on a schedule. This post covers the formats, the targeting rules, and the frequency hygiene that make announcements worth reading.
Why most announcements get dismissed on reflex
The typical feature announcement is a modal shown to the entire user base about something most of that base will never touch. A free user sees a spotlight for an enterprise admin console. A runner opens the app to start a workout and gets interrupted by news about a feature she adopted three weeks ago. Every irrelevant interruption teaches users that your announcements can be closed without reading. By the time you ship the one announcement that genuinely matters to a given user, the dismiss reflex is already trained.
The dismissal itself is not the real cost. The real cost is that you spent attention and got nothing back, and every later prompt, including a notification permission request or a review ask, inherits that earned skepticism.
Full-screen flow, banner, or badge: which format fits?
Match the format to the size of the change and the share of your users it affects. There are three workable tiers.
- Full-screen announcement flow: for changes that alter how a segment of users works day to day. A short multi-screen announcement flow can show the feature in context, explain what changed, and end with one button that takes the user straight there. Reserve this tier for the handful of announcements per year that justify a takeover.
- Banner or inline card: for useful but optional features. It sits inside the UI without blocking anything, so users act on their own schedule. This is the sensible default for most launches.
- Badge or dot: for changes discoverable inside an existing menu. Lowest cost and lowest reach. Works well as a lingering secondary cue after a banner retires.
If you reach for a full-screen takeover more than a few times a quarter, the problem is usually your targeting, not your format.
Who should see the announcement?
The highest-leverage rule in this whole discipline: announce to the segment the feature serves, and to nobody else. A new export scheduler goes to users who have exported a report. A team permissions feature goes to workspace admins on a paid plan. Everyone else should never know the announcement existed. Just as important, exclude people who already found the feature on their own; congratulating an existing user on a launch reads as noise too.
This is where Setgreet earns its place in the workflow. Announcement flows are targeted with the same condition builder as onboarding: user attributes, event properties, and reusable segments, combined with AND/OR logic. You can require that plan equals pro, trigger off the related event with property filters, and exclude users whose attributes show they have already adopted the feature. Each announcement's audience becomes exactly the group with a reason to care.
When should it appear, and how often?
Relevance has a time dimension. The best moment to announce the export scheduler is right after someone finishes an export, because the announcement answers a problem the user just had. Trigger announcements off related events and screens rather than app open, and the same message reads as help instead of marketing.
Then apply frequency hygiene. Never announce on first launch: to a new user everything is new, and the announcement only competes with your onboarding. Show at most one announcement per session. Put a cool-down of several days between announcements so back-to-back launches do not stack. Cap total impressions per user; if someone has dismissed an announcement twice, a third impression will not convert them, it will annoy them. And when several announcements are eligible at once, show only the highest-priority one.
Measure reach and follow-through, then retire it
An announcement has exactly two numbers that matter. Reach: what share of the target segment actually saw it. Follow-through: what share of those viewers took the one action and then used the feature. A high dismissal rate with low follow-through means the targeting or the moment is wrong; low reach means the trigger is too narrow or the audience was smaller than you assumed. In Setgreet, each announcement flow reports what happened in flow analytics, including how users dismissed it, so you judge the announcement on adoption rather than on gut feel.
Retirement is the step almost everyone skips. Decide the end date when you publish, not later: an announcement still running two months after launch is noise by definition. This is much easier when publishing is not coupled to app releases. Apple reviews 90% of submissions in under 24 hours, but a release still means building, submitting, and waiting for users to update. Because Setgreet publishes flow changes to live apps without an App Store release, an announcement can go live the day the feature ships and disappear the day it stops earning its impressions.
Frequently asked questions
What is the difference between an in-app announcement and a push notification?
A push notification interrupts someone outside your app; an in-app announcement reaches someone who already chose to open it. That makes in-app the right channel for feature news: intent is already present, and you can target by in-app behavior at the exact moment of relevance. Reserve push for genuinely time-sensitive messages that justify an interruption, and let feature announcements wait for the next session.
How long should a feature announcement stay live?
Set the retirement date at publish time and treat extensions as the exception. A practical rule: run a full-screen announcement until reach of the target segment plateaus in your analytics, which for most apps happens within a few weeks, then retire it and let a badge or a changelog entry carry the long tail. An announcement without an end date slowly turns into the broadcast noise you were trying to avoid.
Should new users ever see feature announcements?
Not in their first sessions. A new user has no baseline, so a feature announcement is indistinguishable from the rest of the product and only competes with onboarding for attention. Gate announcements on account age or a lifecycle attribute so they start appearing once a user has an established routine that the feature actually changes. Anything truly essential for new users belongs in the onboarding flow itself, not in an announcement.