Skip to main content

Troubleshooting

Problems common to all mobile SDKs. Platform specific problems: iOS Troubleshooting.

Diagnostic steps​

When events, contact data or notifications seem to be missing, go through these steps in order.

  1. Find the contact the device really uses. Read the contact key from the SDK and open that contact in the panel: on iOS UserSDK.default?.userKey (userId before 1.3.0), on Android RegisterResponse.getKey() in the register callback. Flutter has no public API for the key: read it from the network traffic, see step 6. Compare it with the contact you were looking at.
  2. Check how your app identifies contacts. If anything besides the SDK on the device creates or updates the same users (the REST API, an import, another integration), the SDK may be working on a different contact. See Contacts.
  3. Check that the first ping succeeded before the first event of a fresh installation.
  4. Check that screens are tracked in code. No SDK tracks screens unless you call it or enable it.
  5. Check the event names and attribute types against the rules in Events.
  6. Capture the network traffic to *.user.com with a proxy tool, if the steps above do not explain the problem.

Problems​

Nothing reaches the panel, the ping fails with 401​

Symptom: no contact is created for the device and no events appear. The ping response is 401 with an invalid token message.

Causes:

  • the app uses the REST API key instead of the Mobile SDK key,
  • the Mobile SDK key was regenerated in the panel, so the old key no longer works,
  • the key belongs to another workspace than the domain passed to the SDK.

Without a successful ping the SDK has no contact, so no events are recorded.

Fix:

  1. Copy the Mobile SDK key from the panel again. See Setup and Configuration.
  2. Check that the key and the domain come from the same workspace.
  3. Read the result of the ping in your app and confirm that it succeeds before you look for events.

Events are missing in the panel​

Symptom: your app sends events, but you cannot find them on the contact.

Causes:

  • the events are recorded on another contact, because your app identifies users in more than one way,
  • events were sent before the first successful ping of a fresh installation,
  • the ping fails, for example with 401 because of a wrong Mobile SDK key (see above),
  • the contact was deleted or merged in the panel, so the key stored on the device no longer exists,
  • the app was switched to another workspace without a reinstall, so it still uses the key from the previous workspace,
  • an attribute name is an empty string, which rejects the whole event. On iOS from 1.3.0 the completion reports invalidData and nothing is sent.

Fix:

  1. Open the contact with the key the device reports.
  2. Identify users only through the SDK on the device.
  3. Send events only after the first ping succeeds.
  4. After deleting or merging a test contact, reinstall the app or log out in the app.
  5. Do not send empty attribute names.

Screen events are missing​

Symptom: the contact has events, but no screen events.

Cause: the SDK does not track screens unless your app calls it or enables automatic tracking. iOS has no automatic screen tracking. On Android and Flutter it is optional.

Fix: call the screen tracking method of your platform for every screen. Updating the SDK does not change this.

The event is recorded, but attributes are missing​

Symptom: the event is on the timeline, but some attributes are not.

Causes:

  • the value type differs from the first value ever sent for that attribute,
  • the attribute name contains only emoji, or is empty after removing HTML,
  • the attribute name is timestamp.

Fix:

  1. Keep one type per attribute name.
  2. Use plain, stable attribute names.

An event name never appears​

Symptom: one event name never shows up, while other events work.

Causes:

  • the same name was used before with different letter case or separators, for example Purchase after purchase,
  • the name contains HTML, or is longer than 255 characters. On iOS from 1.3.0 the completion reports invalidName and nothing is sent.

Fix: use one exact spelling for each event name.

Events with user typed content are lost​

Symptom: events that contain text typed by users sometimes never arrive.

Cause: content that looks like an attack, such as SQL or file path fragments, can be blocked by the firewall. On iOS and Flutter the event is lost after the first attempt. Android keeps the event and sends it again, and the firewall blocks it again.

Fix: avoid sending free text typed by users as event attributes.

Push notifications go to the wrong device or contact​

Symptom: a contact does not get push notifications, or another contact gets them.

Causes:

  • a token belongs to one contact at a time and moves to the contact of the latest ping that sent it,
  • a contact with several devices gets push notifications only on the device with a token that sent a ping most recently,
  • after logout, the token was not removed from the previous contact,
  • on iOS 1.2.x and earlier, the app was woken in the background on a locked phone and moved the token to a new anonymous contact, see the next problem.

Fix:

  1. Pass the token at login together with the contact data.
  2. On iOS, pass the token to logout(fcmToken:_:). On Android logout() gets the token itself, and on Flutter logoutUser() takes no token.
  3. Open the app on the device you test with, so it sends the most recent ping.

Duplicate anonymous contacts from one iOS device​

Symptom: a logged in user gets no push notifications or in-app messages, while the app reports no errors and events reach the contact. The panel shows anonymous contacts with the same device model and iOS version as the logged in contact, without events or data. They were created around the time a push notification or in-app message campaign was sent. The logged in contact has no device with a push token, or a device shown as "None".

Cause: iOS SDK 1.2.x and earlier. When a silent push (for example an in-app message) woke the app in the background on a locked phone, the SDK could not read the stored contact key. The ping sent then created a new anonymous contact and moved the push token to it. After the phone was unlocked, the app kept using the old key, so push notifications and in-app messages went to the anonymous contact.

Fix: update to iOS SDK 1.3.0. The anonymous contacts created before the update stay in the panel.

FAQ​

What if I have two SDK Admin keys in the panel?

Positive User uses both keys to attempt delivery. Make sure every key belongs to a Firebase project that still exists, otherwise deliveries through it fail.

Can one FCM token belong to several contacts?

No. When a ping sends a token that another contact has, the token moves to the contact of that ping. A common case: an anonymous contact registers a token, then logs in, and the token moves to the identified contact.

Contact support​

If the problem persists, contact Positive User support through the chat widget in your workspace or on user.com, or your Customer Success Manager. Include the platform and SDK version, the contact key (see Diagnostic steps, step 1), the time of the test, what you expected to see in the panel, and any errors your code received.