---
title: "When NOT to Show a Nudge: Building a Suppression Logic"
description: "Learn how suppression logic reduces notification fatigue, protects user trust, and improves retention with blacklists, cooldowns, and session caps."
publishedAt: "2026-06-10T14:35:00.000Z"
updatedAt: "2026-06-10T14:35:00.000Z"
author: "Nitin Gaur"
categories: []
canonical: "https://www.digia.tech/post/nudge-suppression-logic-guide"
---

# When NOT to Show a Nudge: Building a Suppression Logic

> **TL;DR:** Most nudge systems are built entirely around trigger logic, the conditions that make a nudge fire. Very few have an equally explicit set of rules for when a nudge must not fire. That asymmetry is what produces over-messaged apps, eroded trust, and users who dismiss everything reflexively. This guide covers how to read engagement fatigue in your data, how suppression logic works mechanically, which user states and screens belong on a permanent blacklist, and how to build a nudge suppression system that protects long-term retention rather than sacrificing it for short-term delivery metrics. **Sourcing note:** Where specific benchmark figures are cited, the source is attributed. Where no published study covers a specific claim, the article says so.

Most teams who build nudge strategies spend the bulk of their effort on two questions: what should the nudge say, and who should receive it. Both are worth answering carefully. Both are also secondary to a question that gets far less attention: under what conditions should a nudge explicitly not fire, even when targeting and content are correct?

The answer to that question is suppression logic. It is the set of rules that tells your nudge system to hold delivery under specific conditions, regardless of whether a user qualifies for a campaign. Suppression logic is not about sending fewer nudges because someone decided to be conservative. It is a deliberate architecture decision that protects the signal value of every nudge you do send, by ensuring that nudges only reach users when the conditions exist to process them without friction.

[As covered in Digia's earlier article on frequency, placement, and context](https://www.digia.tech/post/designing-non-annoying-nudges-frequency-placement-context/), the absence of suppression logic is what typically produces the over-messaging experience that teams try to solve by cutting total nudge volume. Reducing total volume is the right instinct and the wrong fix. The correct intervention is selective suppression targeted at the specific conditions generating friction, not across-the-board reduction that also kills nudges that were working.

This article is the companion piece to that framework. It covers suppression specifically: what the data signals for engagement fatigue look like, how trust erosion works over time, which triggers should block delivery, and how to build a suppression blacklist for states, screens, and sessions that should never be interrupted.

## What Suppression Logic Actually Is

Suppression logic is a conditional layer that sits between the targeting evaluation and the delivery decision. When a nudge qualifies for delivery based on its trigger conditions and its audience, suppression logic runs a second check: is this the right moment to deliver it? If any suppression rule matches the current user state, the nudge is held. It is not cancelled permanently. It is held for a better moment, or queued behind a cooldown, depending on the rule.


![Diagram showing suppression logic sitting between targeting evaluation and nudge delivery.](https://cdn.sanity.io/images/53loe8pn/production/76fc33d84aa64e3502164ffbff9a1efeae44becf-1024x490.jpg?w=1200&fit=max&auto=format)


The distinction between suppression and reduced targeting is important. Targeting decides who receives a nudge based on segment membership or historical behaviour. Suppression decides whether this specific user, right now, in this session, is in a state where delivery is appropriate. A user can be perfectly qualified for a campaign but suppressed from receiving it because they just encountered a payment error, are mid-transaction, or have hit the session impression cap.

Suppression logic requires real-time session state awareness. A nudge platform that can only evaluate targeting at campaign setup time, without access to live session events, cannot implement session-level suppression. This is one of the clearest differentiators between platforms built specifically for in-app engagement and general-purpose customer engagement platforms where in-app is one channel among many.

[Digia Engage's event-based trigger architecture operates within 100ms of qualifying events](https://www.digia.tech/products/nudges), which is the same speed requirement for suppression logic. A suppression rule that fires after the nudge has already appeared is not suppression. It is damage control.

## Engagement Fatigue in Data: What It Looks Like Before It Becomes a Problem

Engagement fatigue is not a moment. It is a trajectory. By the time it shows up clearly in your headline retention metrics, it has usually been building for weeks in leading indicators that most teams are not watching closely enough.

[Appbot's 2026 analysis of notification strategy found that engagement drops and opt-out spikes typically appear weeks after fatigue has already accumulated](https://appbot.co/blog/app-push-notifications-2026-best-practices/). Users tolerate unwanted nudges for longer than teams expect before taking action. When they do act, the action is permanent: disabling notifications, ignoring everything from the app, or uninstalling.

The data signals that show up before the lagging indicators move:

**Rising dismissal rate without change in targeting.** When a campaign's dismissal rate starts climbing week-over-week without any change to its audience or content, the nudge has not become less relevant. The user has become less receptive. Dismissal velocity is the leading indicator. A dismissal rate above 60% on a nudge that was previously performing at 30% is a fatigue signal, not a content quality signal.

**Shrinking time-to-dismiss.** A user who reads a nudge before dismissing it is processing it, even if they are not converting. A user who dismisses it within one second is not reading it. Tracking median time-to-dismiss across campaigns shows you when users stop engaging with nudges as information and start treating them as screen clutter to be cleared.

**Flat engagement rate despite impression volume growth.** If your nudge impressions are growing month-over-month but your engagement rate is flat or declining, you are reaching the ceiling of your current audience's receptivity. [Research from Airship found that 46% of users will opt out of push if they receive 2 to 5 messages in one week](https://www.mobiloud.com/blog/push-notification-statistics), and while that data covers push specifically, the pattern transfers to in-app: volume beyond the user's tolerance threshold yields diminishing returns before it yields visible opt-outs.

**Increased opt-out or notification permission revocation.** On Android 13 and iOS, users can revoke notification permissions at the system level from the lock screen, without opening the app. [Android's push opt-in rate dropped from 85% to 67% in a single year following Android 13's explicit consent model rollout](https://batch.com/ressources/etudes/benchmark-notifications-push-crm-mobile). While in-app nudges do not require notification permission, the same users revoking permissions are the ones who have reached tolerance saturation. Treat permission revocation as a downstream signal of in-app fatigue for users who had been active.

**Declining session depth on nudge-exposed cohorts.** If users who receive nudges are completing fewer actions per session over time compared to a matched control group that receives none, the nudges are creating friction inside the session rather than guiding it. Session depth decline in the nudge-exposed cohort is one of the clearest signals that suppression is needed.

## The Trust Erosion Model: How Over-Nudging Damages Long-Term Retention

Trust erosion from over-nudging is not an event. It is a slow, compounding process that operates below the level of conscious user awareness. Users do not usually think "I've been over-nudged by this app." They develop a diffuse negative association with the app's communication style, which then applies to every nudge that follows, including ones that would otherwise have been useful.

The mechanism has three stages:

**Stage 1: Selective dismissal.** The user starts encountering nudges that are not relevant to what they are currently doing. They dismiss them, but they process them first. The cognitive cost is low because the dismissal is conscious and the user still trusts that the next nudge might be worth reading.

**Stage 2: Reflexive dismissal.** After repeated exposure to nudges that did not serve their current goal, the user stops processing the content before dismissing. The tap to dismiss becomes a reflex. [This is the in-app equivalent of banner blindness, the pattern-ignore behaviour documented by Nielsen Norman Group for positional ad placement](https://www.nngroup.com/articles/banner-blindness-original-eyetracking/). Once a user has developed reflexive dismissal behaviour for a specific nudge type or screen position, that channel has effectively closed.


![Eye-tracking heatmap showing users focusing on content while ignoring banner-style interface elements.](https://cdn.sanity.io/images/53loe8pn/production/4a59b8a710835de1532bcb792c0b742bda9bf1e9-1107x895.png?w=1200&fit=max&auto=format)


**Stage 3: Cumulative uninstall consideration.** [Research on communication overload in mobile apps shows that perceived overload reduces user pleasure and contributes to app discontinuation intentions](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9855135/). The user who has reached reflexive dismissal is a user who is evaluating whether the app is worth the daily friction it creates. This is the stage at which retention metrics move. By the time Stage 3 is visible in your data, Stages 1 and 2 have already completed.

The trust damage is asymmetric. It accumulates faster than it recovers. A user who spent four weeks building reflexive dismissal behaviour does not reverse it in two weeks of better nudge discipline. This is why front-loading suppression logic, before fatigue develops, is far more effective than trying to repair it afterward.

**The compounding effect on power users.** The users most vulnerable to trust erosion from over-nudging are not casual users. They are your most engaged users, the ones who open the app frequently and interact with it deeply. Casual users have fewer opportunities to accumulate fatigue because they open the app less often. Power users are exposed to your nudge system at full frequency, session after session. They also hold the highest standard for the experience, because they chose the app on merit. Over-nudging a power user cohort is one of the most expensive mistakes a nudge strategy can make.

## Suppression Triggers: Which User Behaviours Should Block Delivery

These are the behavioural signals that, when present, should automatically suppress nudge delivery regardless of which campaigns the user qualifies for.

**Recent dismissal of the same nudge.** A user who dismissed a nudge in the current session should not receive the same nudge again in that session. A user who dismissed it two sessions ago should receive it again only after a defined cooldown window. The appropriate cooldown depends on nudge type: for onboarding tooltips, 3 to 7 days; for promotional nudges, 7 to 14 days; for re-engagement nudges, 30 days. Re-delivering dismissed content within these windows signals that the app does not track user responses, which damages the impression that nudges are personalised.

**Repeated dismissal across multiple sessions.** When a user has dismissed the same nudge three or more times across different sessions, the content is not landing and adding more impressions will not fix that. Suppress permanently and flag for content review. The signal is that the nudge either addresses something the user does not value, fires in the wrong context, or contains a friction point that the user cannot resolve.

**Active high-intent task.** Any session state where the user is executing a multi-step action with a clear completion goal is a suppression trigger. This includes payment and checkout flows, form completion sequences, KYC or identity verification steps, onboarding steps with a defined completion path, and search-result review (the user is evaluating options with intent to act). The user's attention is fully allocated to their current task. A nudge delivered here competes with that task directly and creates interruption cost regardless of content relevance.

**Error state.** When the user has just encountered an error, a payment failure, a form validation issue, a 404, a timeout, or a connectivity problem, they are in a frustration state. Delivering any nudge, promotional or otherwise, into a frustration state compounds the negative emotional context. [Paytm's cross-sell architecture explicitly suppresses promotional and cross-sell nudges during active transactions and within a short window following transaction errors](https://www.digia.tech/post/designing-non-annoying-nudges-frequency-placement-context/). This is the right pattern for any app where transactions, payments, or account actions are core to the user journey.


![Mobile payment failure screen where promotional nudges should be suppressed.](https://cdn.sanity.io/images/53loe8pn/production/697a8efaf682aa5edd8743801406de1da8afc0b6-1254x1086.png?w=1200&fit=max&auto=format)


**Session cap reached.** Each user has a maximum number of nudges that are productive within a single session. That number varies by app type and session length, but the principle is fixed: beyond a certain threshold, additional nudges in the same session add annoyance without adding engagement. When a user has received N nudges in the current session, suppress all subsequent nudge delivery for that session regardless of campaign priority. A starting point for most apps: 1 to 2 nudges per session maximum, adjustable upward only after data shows non-degrading session depth at higher volumes.

**Post-negative lifecycle event.** A user who just churned and returned, who recently had a failed transaction that was never resolved, or who recently contacted support is in a different emotional state from their standard usage pattern. Suppress promotional nudges for a defined recovery window (typically 3 to 7 days following a negative event) to allow the relationship to re-stabilize before making commercial asks.

## The Trust Erosion Model Applied: How Dismissal Spikes Appear in Your Analytics

The relationship between suppression failures and dismissal data has a specific shape that is worth internalising, because it tells you where to look in your analytics to find suppression gaps before they compound.

When suppression logic is weak or absent, dismissal spikes tend to cluster around specific patterns:

**Campaign launch windows.** When a new campaign launches and fires without adequate suppression against existing active campaigns, users in multiple campaign segments receive stacked nudges. The dismissal rate spike for all active campaigns, not just the new one, is the signal. If your existing campaigns' dismissal rates rise when you launch a new campaign, cross-campaign suppression is missing.

**Onboarding sequence boundaries.** When an onboarding sequence ends but its suppression rules are not updated, users who completed onboarding continue receiving onboarding-style nudges. The dismissal rate for those nudges spikes among users who have been in the app for more than 30 days, because the content is no longer contextually appropriate for their lifecycle stage.

**Feature launch overlaps.** When a feature launch campaign runs simultaneously with retention campaigns and re-engagement campaigns without cross-campaign frequency governance, users who are already active in the app and in multiple segments receive multiple nudges per session. The dismissal pattern here is characteristic: dismissal rises sharply for the first 48 to 72 hours of the feature launch, then stabilises as users drop out of some campaign segments or reach suppression thresholds.

## High-Stakes Moments to Never Interrupt: Transactions, Errors, and Critical Flows

Some user states are not just suboptimal moments for nudge delivery. They are moments where delivery is actively harmful. These states form the non-negotiable core of any suppression blacklist.

**Transactions in progress.** Any flow where the user is executing a financial action, a purchase, a payment, a fund transfer, a bill payment, or an investment initiation, is a transaction flow. This includes the initiation screen, the confirmation screen, and the success or failure screen. No nudge should fire at any point during a transaction flow. Not a tooltip, not a persistent banner, not a floater. The user's full cognitive load is on accuracy and completion. An interruption that causes a mis-tap can result in incorrect transaction details being submitted. Beyond the UX risk, a nudge that fires during a payment creates association between the app's messaging system and moments of financial vulnerability. That association is what damages fintech app trust permanently.


![Financial transaction and identity verification screens where in-app nudges should always be suppressed.](https://cdn.sanity.io/images/53loe8pn/production/1ed3f63dd12f36eff0d50129f363ebd9a5ec870e-1600x1200.png?w=1200&fit=max&auto=format)


**Identity verification flows.** KYC screens, two-factor authentication steps, and document upload flows require sustained attention and carry high emotional stakes. Users completing KYC in a fintech app are making a meaningful trust commitment to the product. A nudge during that flow tells them the app is prioritising its own agenda over theirs. Suppress all nudge delivery during identity verification flows, including after the flow is initiated but before it is confirmed complete or abandoned.

**Password reset and account recovery.** A user who is in a password reset or account recovery flow is in an anxious state. They are potentially locked out of something they value. Any nudge that fires here, regardless of content, will be processed as an obstacle.

**App permission request flows.** When the system is about to present a native permission dialog (location, camera, notifications, contacts), the user is making a trust decision about the app. A nudge that fires before or during the permission request context shifts the user's attention away from the decision and toward the nudge. This increases the probability of a reflexive deny on the permission dialog, which is one of the highest-cost outcomes in early-stage user acquisition. Suppress all nudges for a window before any planned permission request.

**Onboarding completion steps.** The specific steps that complete onboarding (the last step before the user reaches the product for the first time) should not carry any additional nudge delivery. The user is almost at first value. Any interruption at this stage is an interruption of the single most important conversion event in the user lifecycle.

**Active media and content consumption.** In media, gaming, and content apps, a user who is watching a video, reading an article, listening to content, or playing a level is in a consumption state. Nudges that fire during active consumption are the equivalent of an unskippable ad in the middle of a video. The user's response is reliably negative regardless of the nudge content. Suppress during active playback, active reading (determined by scroll activity or time-on-screen indicators), and active gaming sessions.

## Building a Nudge Blacklist: States, Screens, and Sessions to Always Suppress

A nudge blacklist is a defined set of states, screens, and session conditions that permanently suppress nudge delivery, regardless of campaign priority or targeting accuracy. It is the implementation of the high-stakes moment list above, expressed as actual rules in your nudge platform.

The blacklist operates differently from individual campaign frequency settings. Campaign frequency settings limit how often a specific campaign fires. The blacklist prevents any nudge from firing when specific conditions are present. The two systems are complementary, not interchangeable.

**Screen-level blacklist.** Define a list of screens where no nudge overlay fires under any circumstances. This list should include all payment and checkout screens, the KYC flow (all steps), the authentication screens (login, password reset, biometric verification), any screen displaying a transaction confirmation or failure state, and any screen containing a native system permission dialog. The screen-level blacklist is the simplest suppression rule to implement and the highest-return suppression investment.


![Example blacklist of mobile app screens where nudges are permanently suppressed.](https://cdn.sanity.io/images/53loe8pn/production/f28b1920f9c952a34e9eaac08660505a5a7d8ef7-1728x1080.png?w=1200&fit=max&auto=format)


**Session state blacklist.** Beyond specific screens, define session states that suppress delivery. These are broader than a single screen: the transaction in progress state (from the moment a payment is initiated to the moment the result is confirmed), the error recovery state (from the moment an error fires to the moment the user navigates away or resolves it), and the session-close state (when the user is navigating back toward the home screen or exit point). Session state detection requires event instrumentation beyond screen tracking, but the investment returns directly in reduced error-state nudge delivery.

**Behavioural blacklist.** Define user behaviours that remove a user from nudge eligibility for a defined window. These include: dismissed the same nudge 3 or more times (permanent suppression for that nudge), reached the session impression cap (session-level suppression for all subsequent nudges), triggered a churn-risk event such as initiating account deletion or filing a support ticket with a negative category tag (time-limited suppression on promotional nudges).

**Lifecycle stage blacklist.** Some nudge types should be suppressed based on where the user is in the lifecycle, regardless of their current screen or session state. Onboarding nudges for users who completed onboarding 90 or more days ago. Promotional nudges for users who have made zero transactions (they have not yet established the product's value to them). Re-engagement nudges for users who opened the app in the last 24 hours (they are not lapsed users; the re-engagement trigger has mis-fired on a still-active user).

**Cross-campaign conflict suppression.** When multiple campaigns would fire in the same session, only the highest-priority nudge should deliver. Priority should be determined by a scoring system that factors in the nudge's proximity to the user's current goal, the time-sensitivity of the campaign, and the user's response history to each campaign type. The remaining campaigns are not delivered in that session. They are held for the next qualifying session or evaluated again at next screen change.

## Suppression Logic and A/B Testing: The Variable Nobody Accounts For

Most nudge A/B tests compare two versions of a nudge: different copy, different design, different CTA. The suppression conditions under which both variants run are typically identical and unexamined.

This creates a measurement problem. If both nudge variants are being suppressed inconsistently, or not at all in certain session states, the conversion and dismissal data is contaminated by delivery quality, not just content quality. A variant that performs worse might be performing worse because it fires more frequently into high-friction states (mid-task, post-error), not because its copy is weaker.

Before drawing conclusions from nudge A/B test results, verify that both variants have identical suppression conditions applied. If suppression logic is absent, the test is measuring delivery circumstances as much as content. The more controlled the suppression, the cleaner the test signal.

This also applies to holdout group design. If your holdout group (users who receive no nudge) is not also subject to the suppression conditions you would apply to active nudges, the comparison is not clean. The holdout group's session behaviour will reflect an app experience that is genuinely not interrupted. The nudge groups' behaviour should reflect the same base experience with only the targeted nudge added, not an experience with additional interruptions that the suppression logic would have filtered out.

## The Priority Hierarchy: When Multiple Nudges Qualify Simultaneously

Suppression logic is only half of the cross-campaign conflict resolution system. The other half is a priority hierarchy that determines which nudge fires when multiple campaigns qualify for the same user in the same session.

Without a priority hierarchy, the nudge that fires is determined by whatever the system resolves to first, usually a combination of campaign creation date and trigger order. That is random prioritisation dressed up as a system.

A functional priority hierarchy scores each qualifying nudge on several dimensions and delivers the highest-scoring one. The dimensions worth scoring:

**Proximity to current user goal.** A nudge about the feature the user is currently using scores higher than a nudge about a feature they have not visited in this session. Goal proximity is the strongest signal for contextual relevance.

**Time-sensitivity of the campaign.** A nudge with an expiring offer, a limited-time onboarding window, or a one-session relevance event scores higher than an evergreen feature education nudge. Time-sensitivity is a decay factor: the campaign loses value if not delivered soon.

**User response history.** If a user has previously engaged with (rather than dismissed) a specific nudge type, campaigns of that type score higher. If a user has previously dismissed campaigns from a specific category, those campaigns score lower. Historical response data turns the priority hierarchy into a personalised ranking, not a generic one.

**Lifecycle appropriateness.** Campaigns that are appropriate for the user's current lifecycle stage score higher than campaigns designed for a different stage. An activation campaign scoring high against a new user and a retention campaign scoring high against a 90-day user ensures that lifecycle mismatch does not deliver the wrong message through priority gaming.

Once the scoring is complete, deliver the highest-scoring nudge. Hold the rest. Do not deliver the second-highest-scoring nudge later in the same session unless it qualifies again on the next screen and the session impression cap has not been reached. Session caps override priority scores.

## User-Controlled Suppression: Giving Users the Off Switch

Every suppression system described above is platform-controlled: your team decides when nudges are suppressed, based on data and rules. There is a separate category of suppression that most apps underinvest in: user-controlled suppression.

User-controlled suppression means giving users explicit control over the nudges they receive, by type, by frequency, or by time window. The primary objection to this approach from growth teams is that users will turn off everything, reducing campaign reach. The data does not support this fear. [Research consistently shows that giving users granular control over notification types reduces total opt-outs and increases trust](https://clevertap.com/blog/push-notification-metrics-ctr-open-rate/). Users who feel in control of their experience are less likely to exercise the nuclear option of revoking all permissions or uninstalling.

The practical implementation for in-app nudges: a notification preferences screen that allows users to indicate which categories of nudges they want to receive. The categories should map to actual user value, not to your campaign taxonomy. "Tips and guidance" (onboarding and feature education), "offers and promotions" (commercial nudges), "updates about my account" (account status nudges), and "new features" (feature launch nudges) are categories users can evaluate against their own needs. A user who opts out of "offers and promotions" but keeps "tips and guidance" active is not a lost audience for all campaigns. They are a user who has told you which channel they trust.

This data also becomes suppression logic. A user who has opted out of a nudge category should have that category suppressed at the platform level, not just at the campaign level. Campaign-level opt-out requires every campaign manager to remember to exclude that user. Platform-level opt-out enforces the preference automatically across all campaigns.

## The Relationship Between Suppression Logic and Long-Term Retention

The business case for suppression logic is not that it reduces annoyance. Annoyance reduction is a user experience outcome. The business case is that suppression logic preserves the signal value of nudges over the lifetime of the user relationship, which directly determines how effective nudges are at driving retention events over time.

[Research from Urban Airship's benchmark study found that app users who received any notifications in the first 90 days after first app open had nearly three times higher 90-day retention rates than those who received none](https://grow.urbanairship.com/rs/313-QPJ-195/images/WP_App_Retention_Rates_Benchmarks.pdf). The same study also found that 95% of users who opted in to notifications but received zero in 90 days churned. Both extremes fail. The middle ground, relevant and well-timed nudges within the user's tolerance threshold, is where long-term retention lives.

Suppression logic is what keeps your nudge system in that middle ground as the user base scales. Without suppression, nudge volume tends to increase over time as new campaigns are added without retiring old ones. Campaign calendars fill up. Multiple teams contribute nudges without cross-visibility. The cumulative delivery per user grows without any individual team being responsible for the growth. Suppression rules enforce a ceiling on per-user delivery that the campaign structure cannot self-regulate.

[Companies using in-app messaging increased user retention by 3.5 times compared to those who did not use it](https://webengage.com/blog/mobile-app-retention-strategies/). That multiplier reflects well-implemented in-app messaging, not all in-app messaging. Poorly implemented in-app messaging, without suppression, without lifecycle adaptation, without frequency governance, produces the opposite outcome: users who are more likely to churn than a matched control group with no in-app messaging at all.

The suppression layer is what separates the retention benefit from the retention cost.

## Implementing Suppression Logic in Digia Engage

Digia Engage supports suppression logic natively through its event-based trigger architecture. Because triggers fire on real-time user events rather than scheduled delivery windows, suppression conditions can be evaluated at the moment of delivery decision rather than at campaign setup time.

The implementation path for teams building suppression logic in Digia Engage:

**Step 1: Define the screen-level blacklist.** In the trigger configuration for every campaign, add negative conditions for blacklisted screens. If the user is on a payment screen, a KYC screen, an authentication screen, or any other blacklisted screen, the delivery condition fails regardless of other trigger states. This is the fastest and highest-impact suppression investment.

**Step 2: Add session state suppression.** Instrument the events that define high-friction session states: transaction initiated, error occurred, onboarding step completed (for campaigns that should not fire during onboarding). Add these events as negative trigger conditions on campaigns that should not fire during those states.

**Step 3: Configure cross-campaign frequency governance.** Use Digia Engage's user-level frequency controls to set a global session impression cap. This cap applies across all campaigns simultaneously, not per campaign. Set the per-session cap, the per-day cap, and the per-rolling-7-day cap. Review these caps against your session depth and engagement rate data quarterly.

**Step 4: Define the priority hierarchy.** For campaigns that will run simultaneously, assign priority scores based on the dimensions covered in this article. Digia Engage's trigger priority configuration determines which nudge fires when multiple campaigns qualify for the same user in the same session.

**Step 5: Add behavioural suppression rules.** Configure dismissal-based cooldown rules: after the Nth dismissal of a specific nudge, suppress it for a defined window or permanently. This prevents dismissed content from continuing to consume session impression quota that should be allocated to campaigns the user has not yet evaluated.

[See the Digia Engage Nudge Builder for the full configuration options across trigger logic, frequency governance, and suppression conditions.](https://www.digia.tech/products/nudges)

## Topics Growth Teams Miss When Building Suppression Logic

The sections above cover the core suppression architecture. These are additional dimensions that most teams discover only after encountering the failure mode they create.

**Multi-team governance.** Suppression logic built by one team does not automatically apply to campaigns built by other teams. In organisations where product, marketing, CRM, and growth run separate nudge campaigns, suppression rules need to be managed at the platform level with cross-team visibility, not just at the individual campaign level. A shared suppression framework with ownership assigned to a single person is the structural requirement. Without it, teams will exception-request suppression rules into irrelevance within a few campaign cycles.

**Seasonal suppression adjustment.** During high-volume commercial periods (festive seasons, sales events), campaign volume spikes. Without proactive suppression adjustment, per-user delivery also spikes, pushing many users over their tolerance threshold precisely when engagement is commercially most valuable. Counter-intuitively, tightening suppression during high-volume commercial periods, reducing the number of campaigns that can stack on any individual user, produces better per-nudge conversion than loosening it.

**Re-engagement campaign suppression.** Re-engagement nudges for lapsed users are among the most misapplied nudge types. A user who has been absent for 15 days and returns organically has already made the decision to re-engage. Delivering a re-engagement nudge to a user who is actively in a session is redundant at best and confusion-inducing at worst. Suppress re-engagement campaigns for any user who has opened the app in the last 24 hours. They are not lapsed. The trigger has mis-fired.

**Onboarding completion detection.** Onboarding suppression rules should be triggered by a completion event, not by a time condition. Suppressing onboarding nudges after 7 days means users who complete onboarding in 2 days receive onboarding nudges for 5 unnecessary days. Users who take 12 days to complete onboarding stop receiving them before completion. Tie suppression to the actual completion event, not to a calendar estimate.

**Experiment interference suppression.** When A/B tests are running on core app flows, nudges that fire over those flows contaminate the experiment. A/B test infrastructure should register running experiments as suppression conditions, preventing nudge delivery from adding a variable to flows that are being measured for other purposes.

**First-session suppression for acquisition channel clarity.** For new users acquired through performance marketing channels, the first session is both an onboarding moment and an attribution measurement window. Promotional nudges that fire in the first session before the user has completed the attributed conversion event create attribution interference and reduce measurement clarity. Suppress promotional nudge delivery until after the first attributed conversion event for users tagged with a paid acquisition source.

## Key Takeaways

Suppression logic is not a volume reduction strategy. It is a signal preservation strategy. The goal is not to send fewer nudges because fewer is inherently better. The goal is to send each nudge only under conditions where it can be received without friction, so that every nudge that does fire carries full signal value.

Engagement fatigue shows up in leading indicators before it reaches headline retention metrics. Dismissal velocity, time-to-dismiss, and campaign dismissal rate trends are the signals to watch. By the time opt-out rates move, the trust erosion is already established.

Trust erosion from over-nudging is asymmetric: it accumulates faster than it recovers. Front-loading suppression logic, before fatigue develops, is a far more effective strategy than building a recovery program after it has.

The non-negotiable suppression conditions are: all active transaction flows, all error states, active onboarding completion steps, identity verification flows, and any screen presenting a native system permission dialog. These belong on a permanent blacklist with no exceptions.

A nudge blacklist should operate at three levels: screen-level (specific screens where no nudge fires), session-state level (specific user states that suppress all delivery), and behavioural level (specific user response patterns that trigger suppression for a defined window or permanently).

The priority hierarchy that resolves cross-campaign conflicts should score on goal proximity, time-sensitivity, user response history, and lifecycle appropriateness. The highest-scoring nudge fires. The rest wait.

User-controlled suppression by category reduces total opt-outs and increases trust. It also generates preference data that can be enforced as platform-level suppression rules, ensuring that user preferences are respected across all campaigns automatically.

Suppression logic requires cross-team governance with a defined owner. Without ownership, suppression rules erode under campaign pressure. The session impression cap and the screen-level blacklist are the two rules most likely to be exception-requested away without a governance owner holding them.

## Further Reading

**From Digia Engage:**

- [Designing Non-Annoying Nudges: Frequency, Placement, and Context](https://www.digia.tech/post/designing-non-annoying-nudges-frequency-placement-context/) - the companion piece covering frequency governance, context-aware triggering, and lifecycle-adaptive nudge volume
- [What Are In-App Nudges and How Do They Work?](https://www.digia.tech/post/in-app-nudges-mobile-growth-guide) - the complete guide to nudge formats, trigger types, and use cases by journey stage
- [Breaking Down CRED's Subtle In-App Nudges That Drive User Engagement](https://www.digia.tech/post/cred-in-app-nudges-breakdown) - how restraint as a design principle produces better long-term engagement than maximum delivery
- [How Swiggy Uses Bottom Sheets to Drive Repeat Orders](https://www.digia.tech/post/swiggy-bottom-sheets-repeat-orders) - post-completion placement in practice
- [Digia Engage Nudge Builder](https://www.digia.tech/products/nudges) - frequency controls, suppression configuration, and event-based triggers from one dashboard, no engineering ticket needed
- [Behavioral Segmentation in Practice: From Raw Event Data to Actionable Cohorts](https://www.digia.tech/post/behavioral-segmentation-mobile-apps) - the upstream segmentation work that makes suppression logic more precise

**External Sources:**

- [The Great Push Notification Benchmark 2025](https://batch.com/ressources/etudes/benchmark-notifications-push-crm-mobile) - Batch (Android opt-in rate decline; in-app message delivery regardless of push opt-in status)
- [50+ Push Notification Statistics for 2025](https://www.mobiloud.com/blog/push-notification-statistics) - MobiLoud (Airship data on opt-out rates by message frequency)
- [Push Notification Statistics 2026](https://www.businessofapps.com/marketplace/push-notifications/research/push-notifications-statistics/) - Business of Apps (46 daily notifications per user; 40% opt-out at 3 to 6 weekly pushes)
- [App Push Notification Best Practices for 2026](https://appbot.co/blog/app-push-notifications-2026-best-practices/) - Appbot (fatigue builds before headline metrics move; review sentiment as leading indicator)
- [BENCHMARKS REPORT: How Push Notifications Impact Mobile App Retention Rates](https://grow.urbanairship.com/rs/313-QPJ-195/images/WP_App_Retention_Rates_Benchmarks.pdf) - Urban Airship (95% churn for zero-notification users; nearly 3x retention for engaged notification users)

_Every suppression rule in this article is configurable in Digia Engage's nudge builder without an engineering ticket. Frequency caps, screen-level blacklists, dismissal-based cooldowns, and session impression limits run from the same dashboard that manages your campaigns. [Book a demo](https://calendly.com/anupamsingh-digia/connect) to see how suppression logic works inside your app, or [see the Nudge Builder](https://www.digia.tech/products/nudges) for the full configuration options._