What are the limitations to has_app?

Several pieces of Journeys functionality rely on Branch’s understanding of whether an end-user has a customer’s app installed (indicated in Branch’s system using the has_app flag). For example, the CTA text on a Journey will only switch from “install” to “open” if Branch believes the app is installed on that user’s device.

Unfortunately, Branch does not - and cannot - know with 100% accuracy whether a given user actually has the app installed, since the operating systems (e.g. iOS, Android) do not make this information available to developers. We’ve developed our own methods for gleaning this information and while our methods are quite accurate, there are nevertheless opportunities for both false positives and false negatives. While these limitations shouldn’t discourage you from using features that rely on “has_app”, keep them in mind when designing your Journeys.

Several complicating factors are:

  • Install vs. Open: If a user installs an app but doesn’t open it, we won’t know that they have the app installed.

  • Uninstalls: We won’t necessarily know if a user uninstalls an app, which could result in a false positive.

  • Apple’s Intelligent Tracking Prevention: As a result of ITP, we’re less accurate on Safari on iOS than on all other browsers.

  • Time to update: Latency in our system occasionally means that for a given user, in the moments (or minutes) following an install, Journeys may not know that the install has occurred.

Updated about a year ago


What are the limitations to has_app?


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.