5.3 In-App Messaging & Web In-Browser Delivery

5.3 In-App Messaging and Web Delivery

In-app and web channels change an active digital experience rather than sending a traditional inbox message. They require the correct SDK, surface, configuration, and trigger context.

In-app messages

An in-app message appears while a user is actively using the configured mobile application. Common layouts include modal, full-screen, banner, and custom experiences. The app and Adobe Experience Platform Mobile SDK must be configured for the channel, and the mobile implementation must support the interactions the author designs.

An in-app campaign or action can use rules and context to decide when content is shown. Consider:

• application and surface identity;
• trigger event and rule;
• start/end schedule;
• frequency and dismissal behavior;
• deep-link or button handling;
• orientation and device sizes;
• app version compatibility;
• consent and sensitive-data exposure.

In-app is not the same as push. Push can reach a device outside the active app when OS permission and token are available. In-app content is presented inside the app experience and does not require a push notification permission merely to render, though privacy and marketing permissions still apply.

Do not promise that every in-app message is instant, local-only, or available offline. SDK configuration, rules, content availability, network state, caching, and app code determine actual behavior.

Web channel

The web channel personalizes configured web pages or surfaces using Adobe Experience Platform Web SDK and Journey Optimizer's authoring workflow. Authors can use visual editing for supported page elements or code-oriented options where required.

A web implementation needs:

1. a working Web SDK/datastream setup;
2. the correct page or surface URI;
3. selectors that remain stable on the target page;
4. content and interaction rules;
5. consent handling;
6. conflict and priority behavior where experiences overlap;
7. browser and responsive testing.

A change that looks correct in the visual editor can fail if a site's DOM, selector, content-security policy, or single-page-app route differs in production. Coordinate releases with the web team and test the actual deployed site.

Frequency and competing experiences

A person can qualify for more than one in-app or web experience. Use campaign schedules, priority, frequency caps, and surface planning to avoid overlapping banners or repeated modals. “Eligible” does not mean every experience should render simultaneously.

Define what counts as a display and ensure feedback events are collected where measurement or capping depends on them. A page request, proposition returned, proposition displayed, and proposition interacted with are different events.

Personalization and decisioning

Profile and contextual personalization can tailor content where the authoring surface exposes the data. Decisioning can select a proposition for a placement. Still apply fallback content: a visitor without a recognized profile or an eligible offer should receive a safe default experience.

Web and in-app content may expose information on shared screens. Avoid using sensitive profile attributes simply because personalization makes them technically available.

Landing pages and subscriptions

Journey Optimizer landing pages provide hosted web experiences for forms and subscription workflows. A practitioner can create and publish a page, configure form fields and actions, and link to it from a message. Verify the subdomain, published URL, data collection purpose, required consent language, success/error states, and mobile rendering.

Subscription lists can represent a person's opt-in to a communication topic. A landing page can support subscription or unsubscription, but the form, list, consent model, and downstream channel use must be configured coherently. Do not treat a click alone as proof of valid consent when the workflow requires additional information or confirmation.

Test plan

For in-app, test active/inactive app state, supported app versions, each layout, dismiss and click actions, frequency, and profiles with missing data. For web, test target URLs, SPA navigation, responsive breakpoints, browser differences, selectors, conflicts, and consent states. For landing pages, test validation, submission, error handling, subscriptions, and confirmation content.

Use test profiles and approved environments. A screenshot in the editor is not an end-to-end test.

Choosing the channel

• Need a message inside an actively used app: in-app.
• Need an OS-level notification outside the app: push.
• Need to alter a configured site surface: web.
• Need a hosted form or subscription destination: landing page.
• Need a durable inbox message: email.