More Route Data Needed

[schro]

In the era of CBD, it's very difficult to track how routes improve/disimprove performance over time as there's only a couple of weeks of data in the route management screens to look at, but there are trends that happen over the course of months, if not years, to demand that can impact it. The lack of information is much like the proverbial boiling of the frog.

For example, in GW2, it appears that some sort of Nerf(tm) was applied to cargo traffic and there was a distinct down turn 4 weeks ago where I lost about 10% of my cargo revenue. Now that I'm realizing it, there's no real way that I can go and see which routes were most impacted to make appropriate adjustments - I need to be able to view sales/costs over a longer period of time to be able to identify the routes that were impacted by this particular Nerf.

I'm sure this will hold true in many cases - 2-3 weeks of data is not enough to average out to understand CBD's impact.

[CU]

I would strongly support more transparency: Right now CBD just leads to endless clicking through maps, airports lists and route pages in order to look up all the potential route pairs that could "steal" your cargo demand.

We need full transparency in order to make this mechanic accessible for everyone: If you look up PVG - JFK you should be automatically given information about the dozens of other route pairs that you are indirectly competiting with. I don't want to do tons of clicking before realizing that someone is stealing your demand via Nantong - Westchester.

[DanDan]

I would strongly support more transparency: Right now CBD just leads to endless clicking through maps, airports lists and route pages in order to look up all the potential route pairs that could "steal" your cargo demand.

We need full transparency in order to make this mechanic accessible for everyone: If you look up PVG - JFK you should be automatically given information about the dozens of other route pairs that you are indirectly competiting with. I don't want to do tons of clicking before realizing that someone is stealing your demand via Nantong - Westchester.

i think this thread is more about the idea of having more/longer historical data for each route/flight. and yes, it would be great if one could see a history of the last 2 or 3 years of each flight, rather than just two weeks (which in case of separate flights per day results in sometimes no data being available at all!).

regarding this issue, i would think it would be also great if data would not be erased if the flight is edited. e.g.: flight number 123 is operated at 08:00; now the time of flight 123 is changed to 09:00 - would be great if one could see the changes in the graph still, so to make comparisons more easy.

[Sami]

Problem with longer route history is quickly the database size. The current (3 weeks was it?) data takes already a very big chunk. However if we'd store only parts of the data (not the full detailed history) then it might be easier to do. So what sort of data would you need in the long run, and how long you'd need to be able to view them?

[DanDan]

Problem with longer route history is quickly the database size. The current (3 weeks was it?) data takes already a very big chunk. However if we'd store only parts of the data (not the full detailed history) then it might be easier to do. So what sort of data would you need in the long run, and how long you'd need to be able to view them?

well... i guess whats most relevant is the load per flight. i doubt its such a big amount of data:

Data: GW;AirlineID;Flight Number;Date;From;To;Y-Pax;C-Pax;F-Pax;L-Cargo;S-Cargo;H-Cargo

.) Everything else can be determined from these values, Id guess.
.) Pax and Cargo, I would save as absolute values: Nr of Pax, kg of Cargo, and not as Loadfactor, so if the plane is changed, one would still see the absolute values transported before and after).
.) The "From" and "To" Airports I would save because if the flight number is being used for a different destination, then of course it should not be displayed anymore.
.) If something minor is edited about the flight number (takeofftimes, blocked seats, etc.) the information should still be available in the historic context.
.) Would also be great since then its continuous for flights on different days that are separate routes (otherwise one can only see the data for the same-weekday-flight, for two weeks, which is rather little information to see any change).


Duration: in my opinion thats 2 or 3 years, after that, delete the data after that. so you could see a graph were one could see the effects of price changes, demand changes...

.) yes, its somewhere like 700 to 1000 lines per flight number.
.) Considering all alliances in GW2 have currently 700k routes, most of those probably separated by weekday, makes maybe 200k flight numbers. Multiply by 700 or 1000, that makes 500M to 700M lines per gameworld... ok, it is a lot 
.) maybe half a year? 

[Sami]

Yes and you need to count those at max levels with 700+ players and 2035 with a LOT of routes.. etc. So multiply those by three.

[DanDan]

Yes and you need to count those at max levels with 700+ players and 2035 with a LOT of routes.. etc. So multiply those by three.

i get it, that there is a lot of routes, but currently no GW has more than 300 players...

[schro]

I don't think we need years of data for this - a year would probably be the most.  The use cases are for movement of CBD when new competition opens (as it's a slow boil for the shift) as well as things (or bugs, in my opinion) like this - https://www.airwaysim.com/forum/index.php/topic,78338.0.html (I'll be commenting there next).

As far as what to keep beyond the current three weeks, I think total revenue as well as pax/cargo transported would be sufficient. I don't think we need to keep cost information, on time statistics, etc for an extended period. This would allow one to see the trend of sales on a given route - i.e. for the changes noted in the GW1 thread above, it would be a bit easier to find the routes that were impacted, especially if it takes 6+ game months from the time of the change to the leveling out of demand (you'd think in those cases a sudden drop in demand would be easier to spot).

There may be a need for additional statistics to look at - in the Route Management page we do have the trend data for profit but it's very short term - having a stat that's compared to say, 6 months ago and/or 1 year ago would also be useful (though, presented in revenue format rather than profit - could more columns, could be a new chart, who knows).

[Silentlysailing]

In GW1 I spent hours manually clicking through *all* the route planning pages at my main base last night trying to identify routes and trends. I can only imagine how bad it'd be for the european counter parts having to check the one way freight from the US.

Plus it requires manually going through nearby airports and competitors flight schedules, and checking demand on their routes. A bit crazy imo.

[JumboShrimp]

Yes and you need to count those at max levels with 700+ players and 2035 with a LOT of routes.. etc. So multiply those by three.

One thing that could possibly be done with existing data:
:
On Manage Routes, on both Financial and Destination tabs, there is a +/- change, which is based on 1 week.  An option here, to toggle 1 week and 4 week change would show longer trend.

[groundbum2]

we had a open request that asked that we could download route (and plane etc) data to Excel. That would then allow IT savvy players to create historical tracking without any extra hit on server storage...

Simon

[baarhus]

Problem with longer route history is quickly the database size. The current (3 weeks was it?) data takes already a very big chunk. However if we'd store only parts of the data (not the full detailed history) then it might be easier to do. So what sort of data would you need in the long run, and how long you'd need to be able to view them?

I would be plenty happy with just being able to see the most previous price, so I can get an idea if my price change caused a huge dip in load factor. This shouldn't cause a dramatic increase in database size since it's just an extra column on the route table.