@CaraDavies: You are most likely seeing actual user behavior. Perhaps the user is interested, but is hesitant about creating an account. Perhaps they downloaded your app, decided against signing up, and then have forgotten what the app was all about and come back to check it. Perhaps there is something about your sign-up screen that they find confusing. This is something you’ll almost certainly run into when starting to use analytics: behavior you can’t explain and that goes against your expectations. We certainly have our share of similar puzzles.
One thing to remember about user behavior analytics is that they tell you what happens, but they never tell you why it happens. You can make educated guesses, but you’ll never know for sure. That’s where surveys and A/B tests come in, to complete the feedback loop.
One note about taxonomy: we are seeing a string of events called app_screen_view. How do you tell they are all from the same screen? By using event properties? If that’s the case, you are limiting your ability to use all the tools Amplitude offers, Pathfinder for example. At least your most important screens (and first-time user flow is always very, very important for mobile apps) should have their own, uniquely named events.
Hey @CaraDavies
@MikkoKarvonen’s answer is really insightful and spot on here!
Ideally, the app should set a user ID once a user has created an account or logged in. If a user is just coming to the signup screen and not performing the login event, then all the events will be tagged as anonymous with just the amplitude_id and device_id and not attributed to a user_id.
If a user is able to login and use the app normally and you aren’t still seeing the user_id, then this could be an instrumentation bug.
Also, to Mikko’s second point - by not using unique names to your screen view events, you might be missing on using some key Amplitude charts to generate your insights. You can get some key insights by leveraging the Funnel Analysis chart to see where the users are dropping off in your onboarding flow.
Hope this helps!
Hi team,
@Saish Redkar @MikkoKarvonen really appreciate your responses. This is what I thought was the case but just wanted to confirm.
We have the app_screen_view with event properties of the screen_name e.g. tabSearch-userSearchResult (for user searching). Are you suggesting we call all the screens different things not just as an event property ?
We just set up the a funnel analysis for onboarding using screen_names as our steps and it has been quite illuminating.
Thank you !!
Cara
We have the app_screen_view with event properties of the screen_name e.g. tabSearch-userSearchResult (for user searching). Are you suggesting we call all the screens different things not just as an event property ?
Yes. That will make your data easier to use and help you make the most of the tools Amplitude is offering. With your current setup, there are features you wouldn’t be able to utilize fully. Also, by giving them unique names you’ll also be able to give them unique event properties when necessary.
Although “all the screens” might be bit overdoing it, depending on what your app UI structure is like. All the main views and key optimization points, such as sign-up flow and first time user flow in general, would definitely benefit from having unique events. But if you want to track the usage of less important screens (say, different pages under Settings), for those your current approach might be enough. You’ll have to evaluate this case-by-case. Over-instrumenting is also a thing.
awesome thank you @MikkoKarvonen
Will get onto this now !
