Providing complete details upfront helps us resolve your issue faster. Here's what to include:

General information:

• App Key(s)
• SDK Version(s)
• App Name (as shown in the app store)
• App Store Link
• Mobile User ID(s) affected

For message delivery issues:

• Message Delivery Name
• Campaign Name
• Message Type (Simple, Rich Inbox, or In-App)
• How it was sent (Campaign UI or API)
• Date/Time Sent (GMT)
• Platform(s) affected (iOS, Android, or both)
• Scope (one device or multiple devices)

Quick checks before contacting support:

• iOS: Verify your push certificate is valid and push is enabled on the device
• Android: Check if battery or security settings are blocking notifications
• Confirm whether the device has received notifications before
• Verify if the app has successfully delivered push to this device in the past

For API sending issues:

• Which API was used
• Response/Error Message from API
• Whether the API accepted or rejected the call(s)

For crash-related issues:

• Device(s) and OS Version(s) affected
• Steps to reproduce the crash (if possible)
• Device logs (with verbose logging enabled, if available)
• Approximate number of crashes observed
• Number of users on this app version
• Any direct user reports
• User experience during crash
• SDK Setup (manual or modified)
• Android Manifest file (attach if possible)

For attribute update issues:

• Mobile User ID(s) affected
• Attribute name(s) not updating
• Attribute value(s) not updating
• Date/Time attribute update was sent (GMT)

Your options depend on the message type. Only Simple Push messages can be suppressed.

Simple Push: If you sent a Simple Push message, we can suppress it by creating a suppression job that lasts up to 24 hours. You'll need to provide the Campaign Name used when sending the message.

Keep in mind:

• Suppression only works from the moment the job is created forward—messages already delivered cannot be recalled
• If your campaign used Recipient Time Zone, we may need multiple suppression jobs to cover all time zones
• If your push was sent via API without a Campaign Name, it cannot be suppressed

In-app and Inbox messages: These message types cannot be suppressed. Once sent, they're already assigned to each recipient's device inbox and exist on the device after it syncs with the server. At that point, we can't block or remove them.

Recovery options: If your message contains a URL target, you can:

• Redirect or remove the page (return a 404 error)
• Add a message to the page explaining the push was sent in error

This applies to both in-app messages (if the URL is not a deep link and you control the website) and inbox messages.

High uninstall counts immediately after a push campaign are normal and expected.

When you send a push notification, the push providers (APNS for iOS and FCM for Android) report all devices that no longer have the app installed. This is the system's only way to detect uninstalls.

If you message the same audience again soon after, the number of detected uninstalls will be very low because those devices were already flagged as uninstalled.

For campaigns sent to an entire app key (like monthly broadcasts), most uninstalls are detected during that large send. Subsequent sends will show far fewer uninstalls because the system has already identified the devices that were removed.

The high uninstall count doesn't indicate a problem with your campaign—it simply reflects the system catching up on devices that had already uninstalled the app since the last push.

This error appears when your organization isn't provisioned for Mobile Push yet. Until push is enabled, the system blocks the creation of push messages.

To resolve this: Make sure your organization is enabled for Mobile Push. Before contacting Support, gather:

• Database Name
• Database ID (the database must be flexible)

Submit a Support Case with these details. Once our Support team enables your organization, you'll be able to add App Groups and Contact Sources without encountering the error.

This error usually occurs when importing or updating an APNS P12 file for iOS push notifications. Here's how to troubleshoot:

Understanding P12 files: An APNS P12 file is encrypted and contains at least one certificate and private key pair, which must match. A P12 file can have one production and one development certificate, but import fails if it contains multiple certificates of the same class (like two production certificates).

Common causes and solutions:

1. Improperly formatted P12
   • The P12 must be generated using Apple's documented process: https://developer.apple.com/documentation/usernotifications/registering-your-app-with-apns
   • Using third-party tools can create formatting errors
2. Multiple certificates of the same class
   • Only one certificate per class should be included
   • Solution: Export a new P12 with one production and/or one development certificate
3. Missing certificate of required class
   • The system requires you to specify production or development during import
   • Solution: Make sure the P12 includes the correct certificate type; generate a replacement if needed

Troubleshooting with OpenSSL: On Linux or Mac OS, you can inspect your P12 by converting it to PEM format:

openssl pkcs12 -in filename.p12 -out filename.pem -nodes -clcerts

Open the resulting .pem file in a text editor to check its contents. (Tip: Drag and drop the P12 file into the terminal if the command cannot locate it.)

Understanding P12 contents:

Production certificate example:

friendlyName: Apple Push Services: com.company.app
-----BEGIN CERTIFICATE-----
{certificate data}
-----END CERTIFICATE-----

Development certificate example:

friendlyName: Apple Sandbox Push Services: com.company.app
-----BEGIN CERTIFICATE-----
{certificate data}
-----END CERTIFICATE-----

Each certificate has a matching private key.

Key takeaways:

• Always use Apple's documented process to generate P12 files
• Include only one certificate per class in a P12 file
• Verify the P12 using OpenSSL if import errors occur

Still having issues? If you continue to encounter errors after verifying the P12 file, open a Support Case. Provide:

• P12 certificate file
• Certificate password
• App Key associated with the push message

Our Support team can help validate the P12 and complete the import if needed.

This occurs when the contact record for the Mobile User ID (MUID) contains invalid attribute values in the push-enabled database.

During reinstallation, the system tries to update consent status. If the database contains invalid data, the update fails validation, so the opt-in/opt-out status doesn't change.

This issue only happens on reinstalls, not new installs.

Next steps: Open a Support ticket and include an example MUID that is affected. Our Support team can investigate and correct the consent status.

For scheduled Push Mailings or those using pre-processing, the Contact Source size on the Mobile Scheduled tab will always show 0 until the campaign is sent or processing is complete.

Example: A Push Mailing scheduled with 2 hours of pre-processing will display 0 contacts in the UI until sending finishes.

Immediate Push Mailings (no scheduling or pre-processing) will show the Contact List size correctly.

Solution: Wait until the Push Mailing is fully sent to view the actual Contact Source size. Keep in mind that the Contact Source size counts raw contacts, so multi-channel recipients may result in a larger send size, which you can verify in Mobile Reporting.

This usually happens if the Firebase account used to generate the JSON file lacks the proper roles or permissions. Without the correct role, the JSON file won't work in Mobile Push.

Error message: "There was an error with your request."

Resolution:

1. Check the roles assigned to the Firebase account used for the JSON file
2. Assign the appropriate role in your Firebase project
3. Regenerate the JSON file
4. Re-import the updated JSON into Acoustic Campaign

Note: We don't provide Firebase role guidance—these settings are controlled by Firebase. Default push messaging permissions typically work once configured correctly.

Acoustic Campaign uses a Mobile User ID (MUID) to uniquely identify each device installation. Without MUIDs, push notifications cannot be delivered.

How MUIDs are generated:

• The Android Device ID or iOS GUID from the SDK is combined with other metadata
• The service hashes this info to generate a unique MUID
• On app reinstall, the same Install ID retains the MUID unless invalidateExistingUser = true is set, which creates a new MUID

Common causes for missing MUIDs:

• SDK registration call not firing properly
• Incorrect MceConfig.json app configuration

Troubleshooting steps:

1. Enable verbose logging in MceConfig.json:

   "loglevel": "verbose",
   "logfile": true

2. Reproduce the issue: Delete and reinstall the app, then attempt push registration
3. Collect logs:
   • iOS: Xcode → Devices & Simulators → download container → extract verbose logs
   • Android: Run adb logcat > logcat.log and filter Acoustic SDK events
4. Share artifacts: Provide logs and MceConfig.json to Support

Best practices:

• Test on real devices, not emulators
• Confirm the push-enabled database has a mapped MUID field
• Keep App and SDK versions updated
• Review SDK initialization code with your development team

There's a known limitation when you use the Establish Identity API to merge mobile contacts. These contacts may be marked as Loss of Consent within a Program, and they won't receive push notifications sent through that Program.

This limitation specifically affects:

• Programs
• Mobile contacts
• Contacts merged via the Establish Identity API
• Push notifications sent through Programs

Consider this behavior when planning mobile push campaigns in Programs to avoid unexpected delivery gaps.

The SDK is responsible for generating unique identifiers for each device installation, which are then used to create a Mobile User ID (MUID).

The process works as follows:

1. The Android Device ID or a custom iOS GUID is generated by the SDK to create a unique install identity
2. These identifiers, along with other metadata, are sent in a registration call to the service
3. The service hashes this information to generate a unique MUID
4. The MUID is guaranteed to be unique within the system

Re-installation behavior:

• If a user deletes and reinstalls the app, the Install ID remains the same, so the same MUID is reassigned
• If the registration includes invalidateExistingUser = true, a new MUID is created and the old record is deleted

This ensures that each device is uniquely tracked while allowing control over re-install scenarios.

An Android device can enter a no-token state for several reasons:

• Poor or no internet connection preventing registration with Firebase
• Mismatch between configuration files: The app's google-services.json file and the FCM private key in the Acoustic dashboard must come from the same Firebase project
• Incompatibility: The Acoustic SDK version may not be compatible with the Android API levels defined in the app
• Incorrect SDK integration: Issues like misconfigured dual-provider setups can cause token problems

Review these areas to identify and resolve the no-token state.

No, app groups cannot currently be deleted. This is to prevent accidental disruption of active or scheduled campaigns and programs that may be using them.

Workaround: Rename old or unused app groups with a prefix like "z - DO NOT USE" to push them to the bottom of the list and avoid accidental use in future campaigns.