How Product Hunt can optimize their analytics to understand user behaviors and more

Introduction

Product Hunt's iOS app went native in August 2022. We show you 3 things in app version 5.1.0 that could be improved.

View a map of their app. View their event tracking plan.

First—Validate events

The event app_store_review_requested fires, but no request was displayed. Any conversion analysis including this event would be incorrect. In fact, while using the app, this event fired 4 times, with no request.

Second—Use unambiguous naming

The event names and properties should be improved so that everyone on the team can understand, and they're future-proof to allow easy segmentation.

There's an excellent Reforge post on common problems with analytics, which includes insight on naming and abstraction for events and properties. Importantly, anybody on the team, whether they be a business user or a developer should be able to easily understand what an event means just by reading its name.

Here are three events that have ambiguous names, and need better properties to future-proof and make segmentation easy:

1) Event onboarding_login

The event name onboarding_login is ambiguous. Did a user login, or did they see the login screen? Adding further confusion is that there's also a screen property for this event with the value onboarding_login.

Ideally, this event would be named viewed_login, with a property user_flow that has a value of onboarding.

Then it would be clear what the user actually saw or did, and the property allows you to disambiguate where they saw the login CTA. For instance, in the future, they may want to add a login CTA on their home page. In that case, they can re-use the event name, then change the property value. That makes it easy to segment by the source of their login CTA's.

2) Event onboarding_loginclicked‍

 Applying this same logic, the event onboarding_loginclicked with a property onboarding_type that has value Google would ideally be named login_method_selected, with property user_flow and value onboarding, and property type and value Google.

3) Event onboarding_newsletter

The event onboarding_newsletter is also ambiguous, and the screen property's value, onboarding_newsletter, is redundant. The event should be named viewed_newsletter_subscription, with a user_flow property value of onboarding.

Third—Optimize the UX

The account profile flow after signup is confusing if you select a username that is already taken.

On my first attempt, I got a generic error message: "There was an error processing your request". Pretty frustrating because I didn't know what the problem was. Was there a problem on their end, or did I enter an illegal value in one of the 4 fields?

It turns out the response to their network POST included the actual error: "username duplicated". Thus in order to improve the error message (and likely improve conversion), their app team would only need to make a front-end change.

Shameless plug

Well, not too shameless. After all, you've read this far.

Literal helps app team auto-document their features on a multiplayer board with screens, events, and API calls. Teams can review new features, or feature updates, all in one tool. The right amount of technical detail is exposed so that anyone on the team can understand and contribute.

You can also integrate Mixpanel or Amplitude to view live data with your screens and events. Point and click funnels make it trivial to see and understand conversion dropoffs—with visual context.

Seeing and understanding your data is a necessary condition for your team to effectively use your data. After all, seeing is believing.