HomeEngagementContentDiscoveryOther resources
Guides

Multiple mobile apps per project

Suggest Edits

You can configure and manage push notifications for multiple mobile applications within a single Bloomreach Engagement project. This enables centralized customer management, unified profiles across apps, and precise targeting for each mobile application.

🚧

Warning

This feature requires SDK versions released on or after September 26, 2025.

New to push notifications? See Mobile push notifications for complete setup instructions before configuring multiple apps.

What's changing

Event-based token storage

Push notification tokens are now stored as notification_state events rather than customer profile attributes. Each event contains the Application ID, device identifier, and push token.

Previous approach:

  • Tokens stored as customer attributes (apple_push_notification_id, google_push_notification_id, huawei_push_notification_id).
  • One token per platform per customer.
  • Attributes available for filtering and segmentation.

Current approach:

  • Tokens stored as notification_state events.
  • Multiple tokens per customer (one per app and device).
  • Events expire after 90 days.

For details on the legacy token storage method, see Customer property.

Key impacts

Segmentation changes: You can no longer filter customers based on push token attributes. Use other customer properties or behavioral events for segmentation.

Event requirements: The notification_state event must be allowed at the project level. If event creation is disabled or blocked by schema validation, push notifications will not work.

Event expiration: Events expire after 90 days. Users who haven't opened your app within this period must reopen it to regenerate tokens.

How multiple mobile apps work

When you send a mobile push campaign, you select a target Application ID. The system retrieves notification_state events matching that Application ID and uses those tokens to deliver notifications only to devices associated with your selected application.

This enables you to maintain a single customer profile across multiple apps while sending targeted notifications to specific applications based on user behavior or preferences.

Prerequisites

Before setting up multiple mobile apps:

  • Updated Mobile SDK (released on or after September 26, 2025).
  • Administrative access to Bloomreach Engagement.
  • Project permissions allowing notification_state event creation.

Set up multiple mobile apps

Step 1: Set up integrations

Go to Data & Assets > Integrations and configure your integrations:

  • Configure multiple integrations per platform (Firebase, Huawei, Apple).
  • Each integration corresponds to a different mobile app.
  • Use clear, descriptive names: Int_fire_brand, Int_huawei_brand, Int_apple_brand.
  • Maintain consistency across platform integrations.
  • Document your naming convention for team reference.

Step 2: Configure project settings

Navigate to Project Settings > Campaigns > Channels > Push notifications:

  1. Select the appropriate platform integrations (Android-Firebase, Huawei, or iOS).
  2. Set a distinct Application Name for identification.
  3. Set a unique Application ID that exactly matches your mobile SDK configuration.

The Application ID is critical: It maps notifications to the correct app and must match identically in both SDK and dashboard.

Push notification settings interface showing multiple app configurations

Step 3: Update mobile SDK configuration

Configure your mobile SDK with the Application ID that exactly matches your dashboard settings. Each platform requires specific configuration steps:

Migration and backward compatibility

The default Application ID

If you don't specify an Application ID in your SDK configuration, the system uses default-application. This special ID maintains backward compatibility by supporting both legacy customer property tokens and new event-based tokens.

During the feature release, all existing mobile applications were assigned default-application to ensure continuity.

Keeping existing subscribers

To retain existing push subscribers when upgrading:

  1. Continue using default-application as your Application ID.
  2. Don't set a custom Application ID in your SDK configuration.
  3. The system automatically supports both legacy and new tokens.

Switching to custom Application IDs

🚧

Warning

Switching from default-application to a custom Application ID breaks legacy token usage.

When you switch:

  • Legacy tokens stop working.
  • Only customers who generate new tokens after the SDK update receive notifications.
  • All existing subscribers must reopen the app to generate new tokens.

Only switch to custom Application IDs when:

  • Setting up genuinely separate mobile applications.
  • All active users are on the new SDK version.
  • You're prepared for users to regenerate tokens.

Create and target notifications

Target applications in campaigns

When creating push notification campaigns:

  1. Go to Campaigns > Scenarios.
  2. Add a Mobile Push Notification action.
  3. In the settings, select which application should receive the notification.
  4. The platform integrations associated with your selected application are used automatically.

Create notification content

Create notifications using:

Testing and tracking

Limitations

  • Maximum of 5 apps per project.
  • Each customer has 1 token per app.

Troubleshooting

Notifications not delivering:

  • Verify Application ID matches exactly between SDK and dashboard (case-sensitive).
  • Check platform integration is configured and selected correctly.
  • Confirm notification_state events are being created.
  • Ensure users granted push notification permissions.

Legacy tokens not working:

  • You switched from default-application to a custom Application ID.
  • Solution: Use default-application to support both token types.

Events not being stored:

  • Verify event creation is allowed in project settings.
  • Check schema validation isn't blocking notification_state events.
  • Confirm SDK has correct project credentials.

Cannot filter by push token:

  • Expected behavior—tokens are now events, not attributes.
  • Use other customer properties or behavioral events for segmentation.

Updated about 2 hours ago