drewguy

That would be ideal, but its creator has gone missing from flyertalk.

It does need to be updated to reflect at least new status levels (no plat. on it) and also new routes.

My preference is to go that way, but if the owner can't be reached . . .

(ETA: I sent an email to the person listed as the owner on Whois)

aacharya

Great ideas - and seatguru already links flight #s to in and outbound routes as well as the time

crnk

I like it too. Also if there was room to add on a few other data points that I find useful:
Cabin size
# upgraded
# not upgraded
Status level: Nonrev (my brother cleared SLC-ORD at christmas a couple of years ago, with empty seats in F)
# empty seats in F (actually quite a few of my holiday time flights go out this way)
Notes? I wasn't going to clear on flight A so I moved to earlier flight B at T-18, and cleared 4 hours after that, IIRC. I'll likely be trying to repeat this feat tomorrow for Friday if it looks the same situation.

initforthelonghaul

I would rather see integration into openflights.org or another platform, since I update it there anyways!

mgcsinc

Thanks for the feedback, everyone! Here are some responses to the issues that folks raised:

On the issue of compliance, I’m inclined to agree with drewguy – I think that some data is better than no data, and I think that flyertalk and prior use of udustats (from what I can tell, as I was never a user) shows that people are quite ready to log data about their upgrades (among other things). My understanding was that use of udustats had fallen off because things were all messed up during the merger, and the site hasn't been updated to reflect the new program.

I think that concern about data bias depends a bit on how people are using the data. If a Silver takes a look at unfiltered data made up almost entirely of 1K’s and Platinums in trying to determine her likelihood of getting an upgrade, she’s gonna be mistaken. But if people understand the nature of the pool, and the data is available in filtered form, it shouldn’t be so bad. I understand that some people here might have ways of ending up with an abnormally high upgrade percentage for their level of status (e.g., calling and complaining when they don’t appear on the upgrade list), I doubt that that has earth-shattering implications to the aggregate upgrade percentages. Maybe I’m underestimating flyertalk folks.

It’s true that you might not be able to find a record of people with your exact level of status, boarding flights between your exact origin and destination, at the exact time and on the exact day of the week that you’re flying. Such is the nature of sampled data. I do think that you can glean a lot from aggregated data – say, of people with your status, also flying a non-hub to hub short-haul route, on a heavy weekend day (fri/sun). I hope to build in options that make this easy on both the reporting and data display sides.

I would love to have someone build an awesome script-based system that automatically scrapes from emails or that can act as a browser plugin and get data automatically. Nonetheless, I chose to go with the simple Google form route for three reason: (1) I haven’t produced a significant amount of code since I was in eighth grade, (2) keeping this super-simple means I’ll actually get it done and data will start getting recorded, and (3) using simple platforms means a lot more people will have the ability to maintain it in the future, so it doesn’t go the way of udustats.

One way to encourage compliance would be to have username collection and then provide a way to keep track of flyertalk users’ success rates. Some people seem to like to report that info in their signatures.

I will absolutely try to design the form to make it as easy as possible to fill out the minimum info necessary to be useful, which should increase reporting. Everyone hates long, convoluted forms. I’ll be asking you all about ways to do that in a follow-up post.

I, too, think it would be great to see the old version revived, or to incorporate this reporting into another tool. I'm just working with what I've got. I also worry that an alternative might suffer from the same issue of not being updated.

Google forms has its drawbacks, including ugly spacing and a lack of features like pop-up calendars. I'll look a bit into how to remedy some of those.

As I mention above, I personally think that the flexibility and approachability of Google forms, including the ability to feed info directly into a publicly viewable spreadsheet with graphs and pivot tables and the capacity for maintenance by non-tech-people, makes up for its shortcomings.

One thing that's nice is that, regardless of how people type the date, Google seems to figure it out and put it in the spreadsheet in a nice formatted way.

Suggestions all noted -- I will definitely be making many improvements and additions to the form itself; this was just a very rough cut.

cyclogenesis

Let me add my support! I often check udustats and would love to see a reboot..

I can code some python if you need.. Make a github repo and I can fork and contribute

drewguy

This is the most important one that's missing. Also add "at booking" and >120 hours.

Date can be coded to day of week, but that should show up somehow.

I would also consider not using "insider" plane types (772, etc.). Instead, used the actual model number, and then whatever extension is necessary to distinguish it. Even better if set so when choosing, eg, 737, a submenu for types will show up--that will allow people who don't know the variants to still input the info.

You might combine RPU and GPU--aren't the two "equal" for purposes of upgrades, other than limits on where RPUs can be used and fare classes for GPUs?

No need to have "UA" at the beginning of the flight number.

jbsay

This is a great idea; I strongly support it. And if you launch a page on a crowdfunding platform (e.g. IndieGoGo), I'll happily throw down some cash.

An even better idea, however, would be to scrape United.com upgrade data and make it available on a public web database. The number of successful upgrades - and pax on the upgrade waitlist - is publicly available for every UA flight several days out. So if you could figure out how to scrape this data and present it in a usable format, anybody booking a ticket could easily figure out the historical average number of upgrades requested/confirmed on any particular UA flight or routing

To be sure, with this method you wouldn't know how many instruments were used on a flight versus CPUs, or the distribution of status pax. But using rough estimates based on public data (e.g. 2005 UA "elite pyramid" stats) you should be able to generate some pretty robust information about which routes/flights/days tend to offer the greatest CPU opportunities.

mgcsinc

Okay, people seem interested enough, so let's do this.

Moving on to the next step:

1. Conceptual stage.
2. Question and form design.
3. Data presentation design.
4. Ongoing use and improvement.

I'd like some feedback on how to provide a simple, quick experience for those who don't have time to fill out the whole form. What 5-10 questions do people think are the most important?

Some questions about some of the suggestions I've gotten:

These are great points.

For plane types, is there some definitive way of referring to different versions that people recognize? Something better than SeatGuru's 777-200 V6?

Not sure on the RPU/GPU issue. Is there any effect on priority?

When and why do downgrades happen?

I assume that you mean numbers upgraded and not upgraded based on the lists at the gate?

Are nonrevs in a particular booking class?

I appreciate both of the offers of support and the ideas. Sadly, my job is a bit too full time to take on real coding or something I could justify asking people to support financially, but I'm hoping that maybe once this gets (back) off the ground, someone might go crazy with it.

Some edits made, many more to come.

drewguy

My feeling is most of the questions you have are necessary. Perhaps the question about planes could be optional (or put it last) because a lot of routes have the same or similar planes flying them regularly.

Here's my suggestion of importance:

Must have:

• city-pair
• date/time
• status
• whether upgrade cleared

Nice to have:

• fare class (not everybody focuses on this, and it's second tiebreaker)
• flight number (these change a lot, so less useful)
• time before flight upgrade cleared (useful to know, but bottom line is whether you cleared)
• type of upgrade (possibly could put miles/rpu/gpu all in same bucket because they're supposed to be same priority)
• plane type (for some routes, it's often the same type of plane so not always relevant)

Optional

• waitlist rank/total at gate (gives some sense, but might be better in notes for those not upgraded. Hard to know the number upgraded because of people paying for F/C and upgrades that happen in advance--useless to see how many cleared at gate)
• downgrades (happen rarely and tracking it is a separate issue--perhaps leave to notes)
• non-rev passenger upgrades (limited audience. Could add as a option in fareclass)
• whether cash upgrade was offered (it's an interesting question, but not very useful to figuring out upgrade chances)

For 777s it might be as simple as 777: UA New config [or layflat]; UA Old config [or recliner]; CO config. If you're flying TATL, unless you really check carefully it's unlikely you could tell between a 77Q and a 77K, and even a 77D has very little difference in appearance.

737s might be more complicated (or maybe I just don't know all the variants).

initforthelonghaul

Contact the openflights.org author and add a feature request (better yet, it's open source, and I am happy to help too). I would much rather have the forms added to that system then use "yet another site".

PVDProf

I am very curious about who's up in F, now that it's no longer me (without a meaningful change in my flying behavior). I would definitely contribute and use the data.

I would add to upgrade types YB(M)-elite upgrades, buy-up at booking and buy-up at check-in (rather than just asking whether there was an offer). My hunch is that is where all the CPUs have gone.

drewguy

We ought to define the purpose for collecting these data.

In my mind, the objective is to inform other flyers of what flights are more or less likely to result in upgrades.

Information about buy-ups, Y/B/M upgrades, etc. don't really inform that question. Rather, they are, as you say, providing information about who is in the F seats. But, even so, they are incomplete because completeness would require us also to ask about paid F tickets. What's more, they won't provide a "rate" of anything terribly useful, unless the goal is to figure out what the likelihood of being offered a TOD upgrade is.

PVDProf

I agree that defining a purpose is useful, and that the objective is to help us plan for what flights are more likely to result in upgrades. But I'd argue that, in addition to helping us understand who is in the F seats, knowing about buy-ups and YBMs advances that cause. In particular, it helps answer the question of, if I am on a particular flight, or set of flights, what instrument do I need to use to have a shot at an upgrade? On some flights, CPUs will work for a 1K like me. On others, I might need to apply an instrument. On others, instruments might not work well, so then I might consider buying (and possibly wait listing) an M-up, or a Y-up. On a busier flight, I might need to realize that I need to take the buy-up offer, because that's my only shot. And on ORD-SFO on Monday morning, I might need to know that buying F is my only realistic option.

sbm12

Yes, but that doesn't mean the information is necessarily beneficial to others.

Self-reporting will never have a sufficient quantity of data to allow for good analytics to happen.