Screen Targeting

Scope Digia Engage campaigns to specific app screens — how setCurrentScreen works, how to report the current screen, and which campaign types honor screen targeting.

Screen targeting lets a campaign owner scope a campaign to specific screens of your app. A checkout tooltip appears only on the checkout screen; a home-page offer only on home. The campaign owner picks the target screens in the Digia Engage Dashboard; your app tells Digia which screen the user is on. Digia shows a screen-scoped campaign only while those two agree.

For this to work, your app must report the current screen with Digia.setCurrentScreen.

Screen targeting is a Digia Engage core SDK capability and behaves the same across React Native, Android, iOS, and Flutter — and across every CEP (CleverTap, MoEngage, WebEngage). The name you report is also forwarded to your CEP's own screen tracking, so this one call replaces any manual CEP "record screen" call you had.

---

1. Why it's useful

Without screen targeting, a campaign fires wherever its trigger happens — which can put a guide or nudge on a screen it wasn't designed for. Screen targeting gives a campaign owner two guarantees, with no app release:

• It only appears on the right screen. A campaign scoped to checkout never renders while the user is somewhere else.

• It's cleaned up when the user leaves. Navigating away from a targeted screen tears down the experience for it, so a tooltip anchored to a checkout button doesn't linger over the home screen. Exactly which experiences are torn down on a screen change differs by platform — see What leaving a screen tears down.

This makes screen-dedicated experiences (onboarding tours, contextual tooltips, screen-specific offers, exit surveys) safe to run without the app hard-coding where each one shows.

---

2. Report the current screen

Call Digia.setCurrentScreen(...) whenever the user lands on a new screen — early, and on every navigation. Where a framework offers a navigation observer, wire it once; otherwise call it manually per screen.

Reporting the Current Screen is the implementation guide: where the call goes in each stack, recipes for GoRouter, React Navigation, Expo Router and the rest, and how to handle tab bars and app foregrounding.

Passing a blank name clears the current screen — every screen-targeted campaign is dropped until you set a screen again.

---

3. Names must match the dashboard exactly

The name you report is matched against the campaign's target screens with an exact, case-sensitive comparison. There is no fuzzy or partial matching.

• Checkout, checkout, and /checkout are three different screens.

• An automatic navigation observer reports the route name (for example /checkout). If the campaign owner enters checkout in the dashboard, it will not match — either align the dashboard to the route name, or report a custom name with setCurrentScreen.

Agree on a single screen-name vocabulary between developers and campaign owners, and use those exact strings on both sides. A mismatch fails silently — the campaign is simply dropped, with only a debug log.

---

4. What screen targeting applies to

Screen targeting is evaluated for every campaign type, but the effect differs for inline:

Campaign type	Behavior with screen targeting
Nudge	Shown only on a matching screen
Survey	Shown only on a matching screen
Guide (tooltip / spotlight)	Shown only on a matching screen (a guide is also tied to its on-screen anchor)
Inline	Delivered only while on a matching screen — but once it loads into a DigiaSlot it stays there. Control where inline content appears with the slot's location, not with screen targeting.

So use screen targeting for nudges, surveys, and guides. For inline content, place the DigiaSlot on the screen where it belongs and manage its lifecycle with Managing Inline Content — screen targeting an inline campaign only gates the moment it's delivered, not where it ultimately renders.

---

5. What leaving a screen tears down

When the user navigates away from a targeted screen, the SDK tears down the experience that belonged to it. Which experiences are torn down differs by platform today:

Experience	React Native / Android / iOS	Flutter
Nudge	Dismissed on leaving	Stays until dismissed normally
Survey	Dismissed on leaving	Stays until dismissed normally
Guide (anchored)	Dismissed on leaving	Torn down when its anchor leaves the tree
Guide (anchorless spotlight)	Dismissed on leaving	Dismissed on leaving
Floater / PiP	Ends on leaving the screen it started on	Ends on leaving the screen it started on
Inline	Never dismissed by a screen change	Never dismissed by a screen change

In practice a Flutter anchored guide still disappears when the user leaves, because its anchor is unmounted with the screen. The difference that matters is a nudge or survey on Flutter, which stays on screen across navigation until the user dismisses it or an action closes it.

Untargeted (global) campaigns are never dismissed by a screen change on any platform.

---

6. How matching resolves

• A campaign with no target screens is unaffected by screen targeting — it can show on any screen.

• A screen-targeted campaign shows only while the current screen is one of its targets. If the current screen is unset — you never called setCurrentScreen, or cleared it with a blank name — targeted campaigns are dropped. Set the screen early so a launch-triggered campaign scoped to the first screen isn't missed.

• A dropped campaign is not retried. If a campaign triggers while the current screen doesn't match, it is dropped then and there — it does not reappear when the user later arrives on a targeted screen. Your CEP has to trigger it again. This is why reporting the screen before campaigns trigger matters so much.

On Android and iOS, the current screen also feeds screen-based frequency capping. Flutter does not apply screen-based capping today.

---

7. Use it correctly

• Report every screen the user lands on, as early as possible and on every navigation — including the first screen after launch, so launch-triggered campaigns can match.

• Keep names identical to the dashboard (exact, case-sensitive). This is the most common reason a screen-targeted campaign doesn't appear.

• Wire it to your navigation properly — see Reporting the Current Screen for the per-stack and per-router recipes.

• Don't screen-target inline campaigns. Use slot placement instead.

• One call, two jobs. setCurrentScreen also drives your CEP's screen tracking — remove any separate CEP "record screen view" call and use this instead.

Related pages

• Reporting the Current Screen — where to call setCurrentScreen in each stack

• Core Concepts

• Campaign Actions

• Managing Inline Content

• Developer Integrations