문제 해결

Basic Checks

My in-app message wasn’t shown for one user

1. Was the user in the segment at session start, when the SDK requests new in-app messages?
2. Was the user eligible or re-eligible to receive the in-app message per campaign targeting rules?
3. Was the user affected by a frequency cap?
4. Was the user in a control group? Check whether your campaign is configured is configured for AB Testing.
5. Was a different, higher priority in-app message displayed in place of the expected message?
6. Was my device in the correct orientation specified by the campaign?
7. Was my message suppressed by the default 30-second minimum time interval between triggers, enforced by the SDK?

My in-app message wasn’t shown to all users on this platform

1. Is your campaign configured to target either Mobile Apps or Web Browsers as appropriate? As an example, if your campaign only targets Web Browsers, it will not send to Android devices.
2. Did you implement a custom UI, and is it working as intended? Is there other app-side custom handling or suppression that could be interfering with display?
3. Has this particular platform and app version ever shown in-app messages successfully?
4. Did the trigger take place locally on the device? Note that a REST call can’t be used to trigger an in-app message in the SDK.

My in-app message wasn’t shown for all users

1. Was the Trigger Action set up properly in the dashboard, as well as in the app integration?
2. Was a different, higher priority in-app message displayed in place of the expected message?
3. Are you on a recent version of the SDK? Some in-app message types have SDK version requirements.
4. Have sessions been integrated properly in your integration? Are session analytics working for this app?

For more in-depth discussion of these scenarios, visit the advanced troubleshooting section.

Issues with Impressions and Click Analytics

Impressions and Clicks aren’t being logged

If you have set an in-app message delegate to manually handle message display or click actions, you must manually log clicks and impressions on the in-app message.

Impressions are lower than expected

Triggers take time to sync to the device on session start, so there can be a race condition if users log an event or purchase right after they start a session. One potential workaround could be changing the campaign to trigger off of session start, then segmenting off the intended event or purchase. Note that this would deliver the in-app message on the next session start after the event has occurred.

Advanced Troubleshooting

Most in-app message issues can be broken down into two main categories: delivery and display. To troubleshoot why an expected in-app message did not display on your device, confirm that the in-app message was delivered to the device, then troubleshoot message display.

Troubleshooting in-app message delivery

The SDK requests in-app messages from Braze servers on session start. To check if in-app messages are being delivered to your device, you’ll need to make sure that in-app messages are being both requested by the SDK and returned by Braze servers.

Check if messages are requested and returned

1. Add yourself as a test user on the dashboard.
2. Set up an in-app message campaign targeted at your user.
3. Ensure that a new session occurs in your application.
4. Use the event user logs to check that your device is requesting in-app messages on session start. Find the SDK Request associated with your test user’s session start event.
   • If your app was meant to request triggered in-app messages, you should see trigger in the Requested Responses field under Response Data.
   • If your app was meant to request original in-app messages, you should see in_app in the Requested Responses field under Response Data.
5. Use the event user logs to check if the correct in-app messages are being returned in the response data.
   

Troubleshoot messages not being requested

If your in-app messages are not being requested, your app might not be tracking sessions correctly, as in-app messages are refreshed upon session start. Also, be sure that your app is actually starting a session based on your app’s session timeout semantics:

Troubleshoot messages not being returned

If your in-app messages are not being returned, you’re likely experiencing a campaign targeting issue:

• Your segment does not contain your user.
  • Check your user’s Engagement tab to see if the correct segment appears under Segments.
• Your user has previously received the in-app message and was not re-eligible to receive it again.
  • Check the campaign re-eligibility settings under the Delivery step of the Campaign Composer and make sure the re-eligibility settings align with your testing setup.
• Your user hit the frequency cap for the campaign.
  • Check the campaign frequency cap settings and ensure they align with your testing setup.
• If there was a control group on the campaign, your user may have fallen into the control group.
  • You can check if this has happened by creating a segment with a received campaign variant filter, where the campaign variant is set to Control, and checking if your user fell into that segment.
  • When creating campaigns for integration testing purposes, make sure to opt out of adding a control group.

Troubleshooting in-app message display

If your app is successfully requesting and receiving in-app messages, but they are not being shown, device-side logic may be preventing display:

• Triggered in-app messages are rate-limited based on the minimum time interval between triggers, which defaults to 30 seconds.

• Failed image downloads will prevent in-app messages with images from displaying. Check your device logs to ensure that image downloads are not failing.

• If you have set a delegate to customize in-app message handling, check your delegate to ensure it is not affecting the in-app message display.

• If the device orientation does not match the orientation specified by the in-app message, the in-app message will not display. Make sure that your device is in the correct orientation.

자산 로딩 문제 해결(NSURLError 코드 -1008)

Braze를 서드파티 네트워크 로깅 라이브러리와 통합할 때 개발자는 일반적으로 도메인 코드 -1008과 관련된 NSURLError에 직면할 수 있습니다. 이 오류는 이미지 및 글꼴과 같은 자산을 검색할 수 없거나 캐시하는 데 실패했음을 나타냅니다. 이러한 사례를 해결하려면 해당 라이브러리에서 무시해야 하는 도메인 목록에 Braze의 CDN URL을 등록해야 합니다.

도메인

CDN 도메인의 전체 목록은 아래와 같습니다:

• "appboy-images.com"
• "braze-images.com"
• "cdn.braze.eu"
• "cdn.braze.com"

예시

다음은 Braze의 자산 캐싱과 충돌하는 것으로 알려진 라이브러리와 문제를 해결하기 위한 예제 코드입니다. 프로젝트에서 사용 불가능한 리소스 오류를 발생시키고 아래에 나열되지 않은 라이브러리를 사용하는 경우, 유사한 사용 API와 관련하여 해당 라이브러리의 설명서를 참조하세요.

Netfox

• swift
• objective-c

1
NFX.sharedInstance().ignoreURLs(["https://cdn.braze.com"])

1
[NFX.sharedInstance ignoreURLs:@[@"https://cdn.braze.com"]];

NetGuard

• swift
• objective-c

1
NetGuard.blackListHosts.append(contentsOf: ["cdn.braze.com"])

1
2
3
NSMutableArray<NSString *> *blackListHosts = [NetGuard.blackListHosts mutableCopy];
[blackListHosts addObject:@"cdn.braze.com"];
NetGuard.blackListHosts = blackListHosts;

XNLogger

• swift
• objective-c

1
2
let brazeAssetsHostFilter = XNHostFilter(host: "https://cdn.braze.com")
XNLogger.shared.addFilters([brazeAssetsHostFilter])

1
2
XNHostFilter *brazeAssetsHostFilter = [[XNHostFilter alloc] initWithHost: @"https://cdn.braze.com"];
[XNLogger.shared addFilters:@[brazeAssetsHostFilter]];