> For the complete documentation index, see [llms.txt](https://docs.digia.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digia.tech/digia-engage/developer-guides/screen-targeting.md).

# 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`**.

{% hint style="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.
{% endhint %}

***

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

{% tabs %}
{% tab title="React Native" %}
React Native has no built-in observer — report the screen on each navigation change (React Navigation shown):

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

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

{% endtab %}

{% tab title="Android" %}

```kotlin
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")
}
```

{% endtab %}

{% tab title="iOS (Swift)" %}

```swift
import DigiaEngage

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

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

{% endtab %}

{% tab title="Flutter" %}
Add `DigiaNavigatorObserver` for automatic tracking (it reports the route name), or call `setCurrentScreen` manually:

```dart
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');
```

{% endtab %}
{% endtabs %}

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

{% hint style="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.
{% endhint %}

***

## 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](/digia-engage/developer-guides/inline-content.md) — 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](/digia-engage/start-here/core-concepts.md)
* [Campaign Actions](/digia-engage/developer-guides/campaign-actions.md)
* [Managing Inline Content](/digia-engage/developer-guides/inline-content.md)
* [Developer Integrations](/digia-engage/developer-guides/developer-integrations.md)