> 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/reference/screen-targeting.md).

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

{% 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 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](#5-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.

{% hint style="info" %}
[**Reporting the Current Screen**](/digia-engage/developer-guides/reference/screen-tracking.md) 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.
{% endhint %}

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                                                                                                                                                                |
| **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](/digia-engage/developer-guides/reference/inline-content.md) — 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.

{% hint style="info" %}
On Android and iOS, the current screen also feeds screen-based frequency capping. Flutter does not apply screen-based capping today.
{% endhint %}

***

## 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](/digia-engage/developer-guides/reference/screen-tracking.md) 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](/digia-engage/developer-guides/reference/screen-tracking.md) — where to call `setCurrentScreen` in each stack
* [Core Concepts](/digia-engage/start-here/core-concepts.md)
* [Campaign Actions](/digia-engage/developer-guides/reference/campaign-actions.md)
* [Managing Inline Content](/digia-engage/developer-guides/reference/inline-content.md)
* [Developer Integrations](/digia-engage/developer-guides/developer-integrations.md)