Skip to main content

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.

info

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.

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.

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.

info

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.

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.
warning

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.

What screen targeting applies to​

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

Campaign typeBehavior with screen targeting
NudgeShown only on a matching screen
SurveyShown only on a matching screen
Guide (tooltip / spotlight)Shown only on a matching screen (a guide is also tied to its on-screen anchor)
InlineDelivered 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.

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:

ExperienceReact Native / Android / iOSFlutter
NudgeDismissed on leavingStays until dismissed normally
SurveyDismissed on leavingStays until dismissed normally
Guide (anchored)Dismissed on leavingTorn down when its anchor leaves the tree
Guide (anchorless spotlight)Dismissed on leavingDismissed on leaving
Floater / PiPEnds on leaving the screen it started onEnds on leaving the screen it started on
InlineNever dismissed by a screen changeNever 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.

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.
info

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

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.