Step 5: Telemetry Plan
Every modern app uses telemetry. What will we record with our telemetry in this MBTA commuter rail mobile app, and what use will we make of that information?
In order for our app to provide the seamless capabilities we are asking of it, we need to make steadily better guesses as to what the users want. As you have seen, much of our logic is based on the time of day and the location at which the user makes requests. For example, when the user looks at the schedule in the morning in the suburbs, we deduce that he wants to see the inbound trains and come up with that tab showing. If he’s in the city in the morning, he probably has a reverse commute, or pulled an all-nighter, so we bring up the morning outbound trains.
For each UX event, we need to record the time of day and the location of the phone. We won’t use GPS location because of the power drain, and also potential privacy problems. But cell-level location, easily available on all phones, will serve well enough for our needs. We won’t be able to tell if the user looks at our app on First Street versus Second Street. But we’ll certainly know if the guy is in Salem or in downtown Boston.
The first thing most telemetry focuses on is the feature usage profile. How often do users use each feature? We went to a great deal of trouble to figure out which schedule tab to show. Did we get it right? How often do users change it? We make our best guess as to which trains to show in the schedule displays. How often do users scroll? We infer the station from the tickets the user purchases. How often does anyone change it? Does anyone ever use the Schedule for Other Days link?
Since we’re selling tickets with this app, we’ll want to know how often that feature gets used. We can compare that data against other channels. What percentage of monthly pass users do as Claire did, setting up her monthly pass on a Web browser on her PC, versus doing it on her phone? How many tickets does Charlie buy at a time? At what time of day does Charlie buy his tickets, and what is the peak load?
We’d learn a lot from this feature tracking. We probably shouldn’t go any further until we’ve digested this amount of data and iterated our UX a few times based on it. We can then evolve it to almost anything we care about. Our data miners will certainly have their requests.
If we really wanted to get fancy, we could gather data from the phone’s accelerometer, compare it with location and time, and figure out how often anyone ever runs for a train.