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 dismissed when the user leaves. If the user navigates away from a targeted screen, the active nudge, survey, or guide for that screen is torn down automatically — so a tooltip anchored to a checkout button doesn't linger over the home screen when a new screen pushes on top.

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.

React Native

React Native has no built-in observer — report the screen on each navigation change (React Navigation shown):

import { Digia } from '@digia-engage/core';

navigationRef.addListener('state', () => {
  const routeName = navigationRef.getCurrentRoute()?.name;
  if (routeName) Digia.setCurrentScreen(routeName);
});

Android

import com.digia.engage.Digia
import com.digia.engage.digiaScreen

// Compose (or anywhere):
Digia.setCurrentScreen("checkout")

// View / XML — from the screen's onResume():
override fun onResume() {
    super.onResume()
    digiaScreen("checkout")
}

iOS (Swift)

import DigiaEngage

// Manual:
Digia.setCurrentScreen(name: "checkout")

// From a view controller:
override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    digiaScreen("checkout")
}

Flutter

Add DigiaNavigatorObserver for automatic tracking (it reports the route name), or call setCurrentScreen manually:

import 'package:digia_engage/digia_engage.dart';

// Automatic — reports the route name on every push/replace:
MaterialApp(
  navigatorObservers: [DigiaNavigatorObserver()],
  builder: (context, child) => DigiaHost(child: child!),
);

// Or manual, with your own screen name:
Digia.setCurrentScreen('checkout');

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; dismissed when the user leaves it
Survey	Shown only on a matching screen; dismissed when the user leaves it
Guide (tooltip / spotlight)	Shown only on a matching screen; dismissed when the user leaves it (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. 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.

• Leaving a targeted screen dismisses the active experience for it (nudge, survey, or guide). Untargeted (global) campaigns are never dismissed by a screen change.

---

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

• Prefer the navigation observer where your framework has one; otherwise call setCurrentScreen from each screen's appear/resume hook.

• 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

• Core Concepts

• Campaign Actions

• Managing Inline Content

• Developer Integrations