In-app messaging

In-app messaging presents information while someone is using an app. A useful message helps with the task at hand, explains a relevant change or offers a timely choice. Start with the person's need, then decide whether a message is needed at all.

Even a message inside the app interrupts attention. A short hint beside an unfamiliar control may help; an offer during payment may get in the way.

Give each message one job

A hint about saving a draft belongs near the draft, where it can be used. An offer for extra storage serves a different purpose and should be assessed separately from task guidance.

Choose a suitable presentation

Put information that everyone needs in the normal interface. Use a message when it applies to a particular person or moment. Reserve a blocking presentation for a decision that requires a response before the task can continue. Android describes dialogs as modal controls normally used for that kind of decision.

Give the message a specific action and a clear way to dismiss it. If it points to an unfinished booking, check that the booking and destination are still available. Declining an optional offer should leave the original task usable. Check rendering on supported devices; a console preview cannot show exactly how a message will appear on every phone.

An in-app message reaches someone who is using the app. A push notification may reach them outside it and calls for a separate interruption strategy. Neither should remind someone about a completed task.

Firebase In-App Messaging offers four templates. Banner resembles a notification and uses little screen space; Card presents a structured message with two action buttons; Modal is a flexible dialogue with one action button and requires only a title; Image only accepts your own uploaded creative.

Images are supplied as an HTTPS URL, which Firebase Hosting can serve. Background and text colours can be set with a hexadecimal code or a gradient. In the Modal and Image-only templates an X button lets the person dismiss the message, and a button's default action is to dismiss unless a URL is provided.

Decide how the message behaves

Firebase is one implementation example: styling, targeting and scheduling are configured in the Firebase console with almost no code. Adding the SDK integration lets the app respond to clicks and dismissals, record verified impressions and surface display errors reported by the SDK.

On iOS the SDK exposes a display delegate. A class conforming to InAppMessagingDisplayDelegate can implement messageClicked, messageDismissed, impressionDetected and displayError. A card carrying two links can then record which link a person tapped and follow up with more information. The product is not available for macOS, Mac Catalyst, App Clip or watchOS targets.

Check eligibility against current state

Combine an audience, a meaningful trigger and a check of the current task. A trigger might be opening a relevant screen or encountering an error. Before showing the message, check whether the task still exists, whether it has been completed and whether another sensitive flow is under way. A delay after first open does not establish any of those conditions.

For each campaign, define what ends eligibility: dismissal, an action, task completion or the campaign's end date. Suppress the message after those conditions are met, and set an exposure cap so it does not keep recurring. Choose the cap to suit the message, then review it against dismissals and task outcomes rather than assuming one limit suits every campaign.

Firebase In-App Messaging is one implementation example. Its campaign composer supports targeting and event triggers.

Give campaigns an end date or review point. The task, offer or destination may change, including on another device.

Firebase A/B Testing experiment targeting supports options including app version, Analytics audience, user property, country or region, device language, first open and last app engagement. One documented example targets people whose last engagement with the app was between one and seven days ago, to reach users who are still active.

The SDK can let people control whether their personal information from message interactions is shared. In Australia, the Privacy Act 1988 binds businesses above the s 6D small business threshold of $3 million in annual turnover.

Measure the task outcome

Define who was eligible, who was assigned or shown the message, and what counted as task completion. Record dismissals and exits as well as actions. An impression shows that a message appeared; a tap does not prove it helped.

To assess a prompt's effect, compare comparable eligible groups with and without it. Firebase's documented In-App Messaging experiment compares message variants, with an in-app message as its baseline. A prompt-versus-no-prompt question needs a genuine no-message holdout and an appropriate way to measure both groups.

Firebase's A/B testing runs statistical analysis to judge whether a variant beats the baseline for the chosen objective. The workflow is to create an experiment, validate it on a test device and then manage it. Google Analytics must be enabled in the project so the experiment can use Analytics data. Experiment targeting also accepts a percentage of the target user base to divide equally between variants.