17. Understanding Ride Volume
• New
vs
Return
Customers
• Distribu/on
by
plaMorm
• Distribu/on
by
fleet/geographic
region
• Distribu/on
by
day
of
week
and
/me
of
day
21. Components of Our System
• Every
development
request
has
a
goal
• Every
goal
has
quan/fica/on
• Architecture
review
includes
analy/cs
• Code
review
includes
analy/cs
• Every
PROD
deployment
requires
hooks
to
monitoring/analy/cs
tools
Today we’re going to talk about vanity… but probably not in the way that you expected
Downloads, app opens, app reviews, # of registered users
But if you were to overstate their significanceDanger… you run the risk of losing sight of what really matters.
Rides.
The understanding of the metric is incomplete if we don’t understand why it’s changing
Ridership metrics subject to the following factors which are completely out of our hands and may completely invalidate all would-be meaningful conclusions
Ridership metrics subject to the following factors which are completely out of our hands and may completely invalidate all would-be meaningful conclusions.
You don’t even know if all the “great changes” you’re making are actually improving the product, or if it was getting better in spite of your efforts.
How do we get to meaningful conclusions?
Examples of how we could do this. Callback to things that do/don’t impact metrics. Such as rain. We know it increases ridership, but we can’t control whether or not it rains, at least, not yet.
Meaningfulanalytics and metrics empower you to draw intelligent conclusions that you might not have been able to determine otherwise. It lets you validate and challenge your assumptions.
Targeting this conversation at small companies (>30 and <100). Speak to my experience. Talk about systems.
NOTE: THIS IS NOT PERFECT
If you send me 30 pages of reports I will read 0 pages of reports
On that note, I’d like to close out and leave some time for questions