In-app Message

For a long time every channel for talking to customers sat outside the product. You sent an email, or you fired a notification onto the device's lock screen. Both of them aim at the hours when someone isn't using the product at all, which means every message has to pull a distracted person back in. That makes the channel narrow and expensive. Email that slides down an inbox gets opened days later or never, and notifications that turn annoying get switched off — and once someone switches them off, there is no way to switch them back on.

Meanwhile, a large share of the people you want to tell about a new feature are already inside the product. If you just shipped sharing, the people who will use it are the ones with a document open right now. Emailing them means asking for two steps: read the message, then come back. Plenty of people fall out between the two.

The pattern repeated often enough to be obvious. A team ships a feature, sends an announcement to the whole list, gets an open rate in the low twenties — and finds that two percent of users actually touched the feature that week. The email was read; nobody's hands moved. In-app messages close that gap. The place where the notice is read is the same place where the feature lives, so there is no trip to make.

You define who should see a message, when it should appear, and what shape it takes, and the message fires the moment a matching user lands on that screen.

1. Choose the audience. Sending to everyone is reserved for things like maintenance notices; normally you narrow it with conditions, mixing behavior and time — signed up within the last seven days and hasn't invited a teammate yet. Skip the narrowing and you end up introducing a feature to the people already using it daily.
2. Pick the moment. Entering a particular screen, clicking a particular button, or spending a few seconds on a page are the usual choices. Because it fires right when a behavior happens, this is one form of a trigger message.
3. Pick the shape. Common ones are a modal that blocks the screen behind it, a thin banner across the top or bottom, a tooltip pinned next to a specific control, and a small card that slides in from a corner. A modal is impossible to miss but interrupts whatever was in progress; a banner interrupts nothing and gets walked past.
4. Set frequency and stop rules. Once per person, never again after it's dismissed, and only one message when several qualify on the same day. Leave this out and users see the same notice at every login.
5. Read the results. Look at impressions, the share who clicked, and then the share who actually used the feature afterward. When that last number won't move, the thing to doubt is the feature rather than the copy.

The most common home is onboarding, the stretch right after signup where a new user finds their footing. A single line on the first screen saying what to do first belongs here. Walk someone through several steps in order and it becomes a product tour.

Second is announcing new features, where it works directly on feature adoption — the share of users who have tried a given feature. Firing only on the screen that contains the feature reaches the people who might want it without bothering anyone else.

Third is nudging people toward a paid plan. The moment a free user reaches for a paid capability is the moment the argument lands best, which is why these messages pair with the paywall, the point that blocks progress until someone pays. Warnings that usage is approaching a plan limit sit in the same category — a note saying 8 of 10 documents are used lands harder than the same line in an email a week earlier.

Fourth is announcements and surveys — planned maintenance, policy changes, and short satisfaction questions tucked into a corner of the screen. Surveys only get answers when they arrive right after the user finished something, and keeping them to two or three options raises the response rate noticeably.

"Let's do this in-app instead of by email. Only people already inside are going to use it anyway."

The audience is in the product, so there's no reason to call them out of it.

"The in-app got 8,000 impressions and 40 clicks. The copy needs another pass."

The message displayed fine; it just never gave anyone a reason to go in.

"A modal here breaks people out of their work. Let's use a banner."

Choosing the less disruptive form over the more visible one.

When Pagedeck shipped comments, Ravi ran it in this order: an announcement email to the full list, and in the same week an in-app banner for anyone who opened a document. The email went to 20,000 people and 4,000 opened it. The banner appeared for 6,000. By reach alone, email wins by more than three times.

Far more people actually left a comment that week from the banner. The people who saw it already had a document open, and the button they needed was on the same screen. The rule Mia drew from it was short: say it in-app when you're talking to people who are using the product, and say it by email when you're talking to people who haven't been around.

The first misreading is treating it as a wide-reach channel. It fills the screen, so it feels like a lot of people must be seeing it. But an in-app message only reaches people who come in. Someone who visits once a month has to hit that exact screen on that one visit, and someone who has stopped visiting never sees it at all. Try to win back dormant users this way and not one message lands with the people who needed it. That job belongs to email or push.

The second is assuming that displayed means read. People arrived with something to do, not to read announcements, so a window covering the screen sends them hunting for the close button before they read a word. Lean on modals repeatedly and dismissing becomes reflex, and the genuinely important notice later gets closed at the same speed. That's why many teams cap how many in-app messages one person can see in a week, and why the ones that survive tend to be a single line of text rather than a full screen.