Problem Statement

=================

In Customer Insights – Journeys, the If/Else condition for “Push notification bounced” does not route contacts to the Yes branch when a push notification is marked as Blocked in delivery analytics.

Current Behavior (By Design)

==========================

• Journey branching supports only a limited set of push interactions (Opened, Clicked, Bounced).
• A Blocked push notification is suppressed at the device/OS level after being sent.
• Because this suppression happens outside the journey runtime, it is not detected as a bounce event.
• Consequently, SMS or other fallback paths cannot be triggered based on blocked push notifications.

Proposed Enhancement

=====================

Introduce Blocked Push Notification as a first-class event or condition in real-time journeys by:

• Treating Blocked push notifications as a distinct outcome (or optional subtype of Bounce) during journey execution, or
• Providing a new If/Else condition such as “Push notification blocked”, or
• Allowing customers to configure fallback logic based on delivery analytics signals (including Blocked status) within journeys.

Benefits of This Feature

=====================

• Improved Journey Reliability
• Ensures customers can reach users via alternative channels when push notifications are blocked, increasing overall delivery success.
• Eliminates confusion when analytics show “Blocked” but journeys cannot act on that signal.
• Enables true fallback strategies (e.g., Push → SMS → Email) based on real-world delivery outcomes.
• Enhanced Customer Experience
• Prevents missed communications caused by silent push suppression at the OS level.

As mobile operating systems increasingly restrict push notifications, customers expect engagement platforms to adapt. Supporting Blocked push notifications in journey logic would significantly improve effectiveness of real-time journeys, especially for time-sensitive or critical communications.