Features / In-app Announcements
In-app announcements
In-app Announcements — Feature News Where Users Actually See It
A slim, dismissible banner across the top or bottom of your app — icon, headline, one button. Write it in a dashboard, target it, schedule it, publish it. No email campaign, no deploy, no engineering ticket.
$19/mo flat — no per-user pricing. No credit card required.
Realtime dashboards are here — your numbers update live, no refresh needed.
See what's newLast updated: August 2026
Positions
Four places to put it
Full-width strips push your page down so nothing gets covered; floating cards hover over it with a shadow. All four take the same content, theme, and targeting.
Top
The default. Full-width across the top of the page — the classic launch banner. Your app slides down to make room; nothing gets covered.
Bottom
Full-width along the bottom edge. Quieter than top — good for notices that should be present without leading the page.
Top floating
A centered card below the top edge, max 720px wide, with a drop shadow. Reads as a message rather than page chrome.
Bottom floating
The same card, bottom of the viewport — the spot users know from cookie notices, repurposed for news they actually want.
Definition
What are in-app announcements?
In-app announcements are banner strips that appear inside your product — across the top or bottom of the page, full-width or floating — carrying a short message, an icon, and one optional button. They're how you tell users about a launch, a price change, a maintenance window, or a webinar while they're actually using the product.
They sit between two other in-app surfaces: a product tour walks a user through a workflow step by step, and an in-app tooltip waits on a specific element until someone asks. An announcement is the broadcast: one banner, page-level, for news that isn't tied to any single button.
The channel is the point. A launch email competes with every other email; a changelog waits for a visit that rarely comes. A banner reaches users inside the product, where acting on the news is one click away — and because it's targeted and frequency-capped, it reaches the right users once, not all users forever.
The problem
Why nobody hears about your launches
- A launch email that lands in the Promotions tab and goes unopened.A banner inside the product, shown to people who are already using it.
- A changelog page nobody visits unless something is broken.The headline and the link, on the page where the new feature lives.
- A full-screen launch modal that blocks whatever the user came to do.A slim strip that nudges the page down a few pixels and dismisses in one click.
- An engineering ticket to hardcode a banner — and a second one to take it down.Published from a dashboard, scheduled to come down on its own.
A banner is also the easiest surface to overspend. It interrupts — politely, but it does — so the discipline is built in: one announcement shows at a time, show-once capping means a dismissal sticks, and the schedule takes the banner down without a follow-up ticket. Announcements work alongside feature adoption tours and user onboarding flows — the banner earns the attention, the tour spends it well.
Capabilities
What an announcement banner can do
Everything below is configured in the dashboard and takes effect without an app deploy.
An icon or an emoji
Lead the banner with one of 24 curated icons — megaphone, gift, rocket, alert, and friends — or any emoji you like. The icon rides in a small tinted disc so it reads as part of the banner, not a pasted-on picture.
stepskit.on("announcement_clicked", ...)One button, two actions
A link opens your changelog, launch post, or docs in a new tab — the URL is re-validated at click time and opened with noopener. Or fire a custom event your own JavaScript handles via window.stepskit.on(), so the button can open a panel or start a flow inside your app.
Schedule the window
Set a start and an end — either one optional — and the banner goes up and comes down on its own. The window is enforced on the server, so an expired announcement isn't even sent to the page, let alone rendered.
Corners, twice
Square, rounded, or pill — set independently for the banner and its button. A pill banner only applies to the floating positions; on a full-width strip it quietly clamps to rounded, because a 9999px radius on an edge-to-edge bar looks wrong and StepsKit knows it.
Theme it to your brand
Banner background, text, button, and button text colors. Set a project-wide default so every announcement matches your brand, then override any single banner — a dark maintenance notice, an indigo upgrade nudge — without touching the default.
Dismissible — or not
Dismissible by default: one click on the × and it's gone. Turn it off and no close control renders at all — for the maintenance window or the compliance notice that shouldn't be waved away.
Targeting
The right banner, to the right users, once
The same audience engine as every StepsKit surface — because a launch banner for the reports page shouldn't greet someone on the login screen.
On the right pages
Show the banner everywhere, or scope it with a URL pattern — /reports/* puts the announcement about the new export button on the reports pages and nowhere else. In a SPA, the rule re-evaluates on every route change without a refetch.
To the right people
Show by plan, role, company, or any custom attribute you pass via the embed — twelve operators combined with AND/OR, the same audience rules your tours and tooltips use. Plus a minimum screen width, so a banner never eats a phone viewport.
The right number of times
Cap an announcement to one appearance per visitor. Identified visitors are capped across sessions server-side; anonymous visitors fall back to session storage, so nobody sees the same launch banner every morning.
Publish
No second install, no global switch
<script
async src="https://cdn.stepskit.com/stepskit.latest.js"
data-api-key="sk_live_a3f...">Rides the same embed
Announcements ship in the same lightweight script as your tours, tooltips, and surveys. No separate install, no extra package, no extra request — if StepsKit is already on your site, you already have announcements.
Per-domain publishing
Publishing is per hostname, not a global switch. Push the banner to staging, look at it in place, then publish to production — and take either down independently. Changes reach visitors on their next page load, no deploy in between.
How it works
Four steps, no engineering handoff
Write, style, target, publish — from the dashboard, with the real banner previewed beside the form as you type.
- 1
Write the banner
Pick a position, type the message — emoji autocomplete included — and choose an icon. A live preview renders the real banner beside the form as you type.
- 2
Add the button
A label plus a link to your changelog or docs, or a custom event key your own code listens for. Or skip the button — a headline can carry a launch by itself.
- 3
Target and schedule
Scope it to URL patterns, audiences, and screen sizes; cap it to once per visitor; set the start and end so it takes itself down.
- 4
Publish per domain
Push to staging first if you like, then production. Live on the next page load — and editable or retractable just as fast.
Realtime dashboards are here 🎉
See what's newBuilt for real apps
The part announcement bars get wrong
Rendering a colored strip is the easy half. Not covering your navigation, not fighting your CSS, and not flickering on every route change is the half that breaks.
- Pushes your layout, doesn't cover it
- The banner measures its own rendered height and pads the page by exactly that much — then finds your fixed and sticky elements, navs and sidebars included, and offsets them too, so nothing is hidden underneath. Dismissal restores every value it touched, and a ResizeObserver re-applies the offsets when fonts load or the viewport changes.
- Your CSS can't touch it
- The banner renders in a closed shadow root with all styles reset — your stylesheets can't restyle the banner, and the banner's styles can't leak into your app. It looks the same on every site it's installed on, which is the point of theming it once.
- Plain text, on purpose
- Title and body render as text, never as markup — pasted HTML shows up as characters, not elements, so a banner can never inject anything into your app. Button URLs are checked against an https / http / mailto / tel allow-list at click time and always open in a new tab with noopener.
- Survives your SPA
- On a client-side route change, the embed re-evaluates URL rules against the payload it already has — no refetch, and a banner that still matches stays exactly where it is instead of re-rendering. No flicker on navigation, no re-initializing anything.
Examples
In-app announcement examples
Three moments where a banner beats an email, a modal, or a changelog nobody reads.
Launch day
A NEW banner across the top of the app, linking to the changelog entry. Capped to once per visitor, so everyone hears about the feature exactly one time — from inside the product, not a newsletter.
A maintenance notice that takes itself down
A dark, non-dismissible strip announcing Saturday's maintenance window, scheduled to appear three days before and disappear the moment the window closes. Nobody has to remember to remove it.
An upgrade nudge only free users see
A floating banner at the bottom of the viewport, themed to stand out, targeted to plan = free. Paying customers never see it — and the button fires a custom event that opens your own upgrade dialog.
Choosing a surface
Announcements vs. tooltips vs. tours
StepsKit ships three in-app surfaces, each for a different job — a broadcast, persistent contextual help, or a guided sequence.
Announcements
Tooltips
Tours
| Surface | Sequential? | Anchored? | Use when |
|---|---|---|---|
| Announcements | No | Page-level banner | Broadcasting news that isn't tied to one element |
| Tooltips | No | Per-element | Persistent contextual help that waits for the user |
| Tours | Yes | Per-step | Walking a user through a workflow in order |
Pick announcements when the news matters to a whole audience and isn't attached to one button — a launch, a maintenance window, an offer. Pick tooltipswhen the help belongs next to the thing itself — a NEW badge on the feature, a ? beside the confusing field. And pick tourswhen there's a workflow to learn in order. They compose: the banner announces the launch, and its button can hand off to the tour that shows it.
AI agents
The agent that ships the feature writes the banner
StepsKit ships an MCP server, so the coding agent that just merged your launch can draft its announcement in the same session.
Claude Code, Cursor, and any other MCP client can create, list, update, and delete announcements — content, position, icon, button, schedule, targeting, and theme included. Agents create announcements unpublished, so nothing reaches your users until you review it and publish in the dashboard.
$ npx -y @stepskit/mcp
✓ StepsKit MCP connected
> point out the new CSV export
✓ Tooltip created on #export-btnStop losing users before they see the value
Build your first tour in 5 minutes. No engineering ticket, no credit card required.