Sticky mpknowledgedrop

Troubleshooting in-app message delivery

  • 13 February 2020
  • 0 replies
  • 370 views
Troubleshooting in-app message delivery
Userlevel 6
Badge +4

Every week, we will release tips to help you get the most out of Mixpanel. Want to see more? Click here to see other #mpknowledgedrop articles.

 

Let me guess —

You read the Mixpanel help article on how to set up an in-app message, you followed the steps on how to get your in-app messages up —  installing the latest library, identifying your users, creating user profiles — and then you started building your in-app. But now you are running into issues and you suspect that your in-apps are not sending. 

 

Take a look at the steps below to help narrow down what might be happening:

  1.  Make sure your in-app message is active and the sending button is on.

    P2r9lfgkt7O4O8JQEVZ_CErh_1Gxfgm-J_B041ez-nmidWimDxiPSN459shSEaaUX-lOBo_UCA4PI4sJ1pKabMV_dLgqmvfm4lMiiPYyF1w1P2raSKQloHZGUWi_Pm6EUUKcUoIb
    •  Under your message board, take a look at if your in-app is under the active tab/sending mode .

    • If your messages are under the Inactive/Drafts section and you see that the sending button is not on, your in-app message will not send.

  2. Make sure your identity management is in a good state. 

    • In-app messages rely on the identify call to send out an in-app message. The rule of thumb for identity management is to make sure you mixpanel.identify() your users at log-in and mixpanel.alias() (if you would like to track anonymous events) at the account created step.  Essentially, making sure your identity management is implemented correctly

    • Clean identity management is important because the in-app relies on the identify call at log-in to check our Decide API and see if that user qualifies for an in-app. If a user qualifies, the in-app will be displayed, but if the identify call does not point back to the correct profile, then the user will not qualify and the in-app will not be displayed. 

    • To read more on Identity management, take a look at our help doc

  3. Make sure you have created a profile for your users to send an in-app message to them.

    • If you have not created user profiles to target, the in-app message will not be sent. To learn how to create user profiles in your projects, read our dev documentation here.

  4. Make sure that you have qualifying users to receive your in-app message. 

    • Under target criteria in your message, you can see the amount of users that will qualify for it. If it does not have any users qualifying, no users will receive the message. HXEiojCC_79aDaKGeyYiLDwFzsvH7nGSEf9BrRqRqOSFCBY2UmTDbfmFwu0di4pNTSWYKvkVAEISGIUculL8rd8KpjH4QKhR91TNTKO5L88b9yClG4fG_LrvImpqYqnIbVqW1wxi

    • If you do not see any qualifying users, go back to steps 2 - 3 to check your identity management and profile creation

  5. If you are targeting users via event properties or a cohort selector, there can be a slight delay of when the message will show. 

    • It can take up to 5 minutes for users being targeted by event properties to start seeing the in-app for the first time. 

    • It can take up to 30 minutes for a user being targeted by a cohort selector to see the message. 

    • This is because event properties and cohorts can take some time to be updated and qualify the user for the message.

  6. Check the Mixpanel status page for possible delays (look under Notifications).

    • By default, during data delays, Mixpanel pauses sending messages to ensure the targeting criteria for a message is correct in real-time. This is because a data delay can cause either people property values or events for a distinct_id to not be up to date. 

    • If you would like, you can still send messages during ingestion delays. To see how to send messages during this time,  take a look at our help article here

  7. Make sure you do not have any duplicate profiles.

    • Sometimes we can accidentally create two user profiles for the same user. If this is the case, the in-app message might fail to load and your message will not be delivered. 

    • You can use our explore report to see if there are any duplicate user profiles in your project. 

  8. Confirm how many users are affected

    • Check to see if this is an isolated incident for one device or one user. To test this, you can use another web browser (chrome, safari, firefox, etc) that is different from the one that you are currently using,  or ask a friend to see if they can trigger the in-app message on a different computer/device.

    • If this is isolated to one user, it can be due to default non-tracking settings in the browser or an installed ad blocker. To read more on this, take a look at our #mixpanelknowledgedrop article on what can prevent you from being tracked. 

For event-triggered In-Apps: 

  • Make sure that the event you are targeting is firing on our client side library.

    • Make sure that the event being used is firing on the web client side and not server-side (or via Segment). If you try to target an event that is coming from a server-side library or segment, the in-app will fail.

    • To check which library your events are coming from, you can do a report in Insights where you target the event used in the in-app message, and breakdown the report by “Mixpanel Library”
      bCuTmJpjjm4Uk9ZzrK5IW0n5YzioYVgMzrkBRXdds0zv-CDAjViHUyoLhOhLcDTScbZp34aQj9jw8Gry4JRtEaRb3rpQ2uC2sa5V-AAV059u-_DI6V0En1_knXMyrKhCgkvsg7kd 

This list covers the majority of in-app message issues, if you are still stuck, share your issue in the comments below!


0 replies

Be the first to reply!

Reply