[Analytics] Events around new onboarding

Tracks

• Tapped get started: Fired when tapping the “Get Started” button, one of two options on the start screen splash
  • properties: {}
• Tapped onboarding search: Fired when tapping the onboarding search field in categories or artists context
  • properties: {context_type: [artists, categories]}
• Follow artist: An artist can be followed from artist page, from fair artist pages, or during onboarding
  • properties: {artist_slug, artist_id, source_screen:[artist page, artist fair page, onboarding top artists, onboarding search, onboarding recommended]}
• Follow category: A category can be followed from a gene page or during onboarding
  • properties: {gene_id, source_screen: [gene page, onboarding top categories, onboarding search, onboarding recommended]}
• Budget selected: Fired when user selects a budget option during onboarding
  • properties: {budget: [under 500, etc.]}
• Tapped sign up: Fired when tapping “Join” or “Connect with facebook” on the sign up screen (last step of onboarding)
  • properties: {context_type: [email, facebook]}
• Created account: Fired when acocunt was successfully created
  • properties: {context_type: [email, facebook]}
• Sign up failed: Fired when a user tapped “Join” or “Connect with facebook” on the sign up screen but an account was not created for some reason (passowrd too short, invalid email, etc.)
  • properties: {context_type: [email, facebook], errors: [“invalid email, invalid password”]}
• Tapped log in on start screen: Fired when tapping the “Log in” button, one of two options on the start screen splash
  • properties: {}
• Tapped log in on log in screen: Fired when tapping “Login”, “Connect with facebook”, or “Connect with twitter” on the login screen
  • properties: {context_type: [email, facebook, twitter]}
• Successfully logged in: Fired when user log in successfully
  • properties: {context_type: [email, facebook, twitter]}
• Log in failed: Fired when a user tapped “Login”, “Connect with twitter”, or “Connect with facebook” on the login screen but the login was not successful for some reason (wrong password, a user with that email does not exist, etc.
  • properties: {context_type: [email, facebook, twitter],errors: [“wrong password, inexistent user, etc”]}
• Artsy notification prompt response: Fired when user responds to Artsy notification prompt
  • properties: {outcome: [yes, cancel], context_type: [onboarding, artist follow]}
• Apple notification prompt response: Fired when user responds to Apple notification prompt
  • properties: {outcome: [yes, cancel], context_type: [onboarding, artist follow]}

Screens

• Onboarding start: screenshot
• Onboarding follow artists: screenshot
• Onboarding follow categories: screenshot
• Onboarding select budget: screenshot
• Onboarding signup: screenshot
• Onboarding login: screenshot

Questions

• Do we need a search_keyboard_dismissed event as indication of search completion or is the current eventing enough?
• Do we need a property on the onboarding_follow_artists and onboarding_follow_categories screen views to indicate which version of the screen the user is seeing: top, searched, you may also like
• Do we need unfollow_artist and unfollow_category events?
• Do we need an artsy_notification_propmpt_viewed event? cc @mennenia @katarinabatina

[anipetrov]

Questions:

@anipetrov

1. On our current Follow Artist event (from other source pages), we only send the Artist ID and under the artist_slug property for you. In Eigen artist_slug and artist_id are the same. Can I keep this behaviour in the onboarding source screens also?

This means you get: artist_slug : “artist_ID” and source_screen : onboarding top artists for instance.

Sounds good @mennenia!

1. For the follow category event:

Seeing as this is event is also triggered when you follow a category in the app, I didn’t change the naming. The event is currently called gene favorite for you, so I’ve kept it that way rather than naming it follow category. That ok or would you like it all to change to follow category?

Let’s keep the current naming convention! I will amend the spreadsheet

[mennenia]

Do we need a search_keyboard_dismissed event as indication of search completion or is the current eventing enough?

Unless there is something learnt from the behaviour of dismissing (“can a user dismiss the keyboard?”), I don’t believe so… cc/ @katarinabatina

Do we need a property on the onboarding_follow_artists and onboarding_follow_categories screen views to indicate which version of the screen the user is seeing: top, searched, you may also like

By default, the screen will always start with “Top Artists / Popular Categories”. The only way to get to searches and recommendations is by actually searching, and tapping artists / categories, which are events we’re already tracking. So I would assume we don’t need this additional event.

Do we need unfollow_artist and unfollow_category events?

This behaviour isn’t currently supported anyway, as when I discussed with @katarinabatina, the onboarding flow isn’t really designed to follow/unfollow, rather to get you started with populating some of your favourites.

Do we need an artsy_notification_propmpt_viewed event?

We can add that, if you’d like. There is no way to dismiss the popup without pressing either OK or Cancel so, in some ways, if you add those two events up together you’d get the total amount of times the popup had been shown. Up to you.

---

Questions:

@anipetrov

1. On our current Follow Artist event (from other source pages), we only send the Artist ID and under the artist_slug property for you. In Eigen artist_slug and artist_id are the same. Can I keep this behaviour in the onboarding source screens also?

This means you get: artist_slug : "artist_ID" and source_screen : onboarding top artists for instance.

1. For the follow category event:

Seeing as this is event is also triggered when you follow a category in the app, I didn’t change the naming. The event is currently called gene favorite for you, so I’ve kept it that way rather than naming it follow category. That ok or would you like it all to change to follow category?

Current implementation notes and FYIs:

There won’t be specific “sign up failed because invalid email” event, because we disable the sign up button if you don’t have:

• at least 6 characters in your password
• the email field has an @ in it

There is still a possibility of sign up failing, where we do show an alert to the user saying that they should check their email / password. This error is: possible email or password issue for you.

Errors added:

Sign up:

• could not get facebook credentials
• possible email or password issue
• account already exists

Log in:

• could not get twitter credentials
• could not get facebook credentials
• no artsy account associated with facebook profile
• invalid email and or password (we can’t distinguish which)