The next stage of the journey history modifications has just gone live. The old, very difficult to understand, version has been discontinued in favour of an option to expand details for every journey. You no longer need to have bought online credit to access journey history and you can also see touches on pink validators and journeys covered by your travelcard. It even shows you when a journey is part travelcard and part pay-as-you-go. There are also buttons to produce a printer-friendly version and a CSV format file to load into spreadsheets. Unfortunately these additional formats do not seem to include the charging detail, but hopefully this can be added in a future release.
They are still collecting feedback and actively responding to it. There are even some features which are already earmarked for a future version, including more detail about how the charges are calculated, ability to sort and/or filter journeys, download to a PDF file and request a statement via email – presumably instantaneous rather than the current 2-3 day delay.
Perhaps the most useful addition is left to a single line at the bottom of the future improvements list. It says “Option to request adjustments to some pay as you go charges”. If this reduces the need to call the helpdesk to resolve issues then it will be a very worthwhile addition. I’ll be watching this one very closely.
The journey history page on this site will be updated shortly once I’ve had a chance to grab screen prints.
Being able to access your full journey history, even for travelcard journeys is awesome. Great to be able to download and look at your travel patterns, and also to remember where you went on a day.
Nice that you can also see the OSIs.
Now, if they just had a quick link next to each journey to request a refund due to a delay…
Immediate impressions are
I approve of the daily total been shown against each day you can immediatly tell if you have been capped correctly (if applicable).
Needs to re instate the show all available data option to the drop down menu (OK this can be done using custom dates) so when you download a csv version you have a full spreadsheet in one go.
Still overall a positive effort.
Hi Malcolm,
I agree, it’s taken a giant leap forward, but the flexibility of the screen displays need to be translated into the printer-friendly and csv options. Hopefully oysteronline will be visiting soon to take comments on board.
I’d love to know on what basis they decided this new version is better? How many people actually completed the survey that was running while they trialled the ‘improved’ version.
It used to be a simple cut and paste from the online journey history into my own spreadsheet, now I can see I’ll be wasting at least an hour reformatting everything…. Thanks TfL for dumbing down.
Thanks for featuring the latest improvements to journey history. As you can imagine, a lot of hard work has gone into making these changes, and it’s taken a little longer than we originally expected – mainly due to an intensive testing programme to weed out as many bugs as possible.
The biggest change is in the background, as the website is now getting its data via a direct link rather than manual file uploads. That means that you should always be able to see data up to the close of the previous travel day (although some bus journeys may still take longer to appear).
However, as this is a live link, there is a risk that it could be overloaded with requests. In order to protect the database it connects to, we have placed a limit on the number of concurrent connections; if that limit is reached, you will see a “high demand” message asking you to try again later. In most cases, simply hitting “Go” again will return the requested data. If not, trying again in a few minutes will probably suffice.
We will be monitoring performance closely over the next month or so, and will also be taking measures to improve the overall performance of the service (and the Oyster website in general).
We have temporarily removed the options to show 4 weeks and all available data to avoid the system being overloaded with speculative queries during this period. As noted, it is still possible to display this data using the new “custom date range” option, and it is more likely that customers will select the dates they require rather than just choosing the full eight weeks each time. Once we have a feel for how the new link is holding up to “real world” demand, we will reinstate these options; I know they are popular.
I took the decision not to include the charging detail in the printer-friendly and csv options for this release, but I will gauge demand for this via the customer feedback. The off-line options are aimed mainly at customers that need to submit expense claims, for which the clarity of being able to see the journeys and associated fares is of primary importance.
It’s probably fair to say that if we were starting from now, we would have only ever shown the statement in the form of compiled journeys, and I’m well aware of how confusing customers used to find the original, transactional format. However, for the sake of transparency, I have ensured that this charging detail can still be viewed online for those customers that want to check how their fare was arrived at. If there is sufficient demand to be able to see this detail in the downloaded data as well, then we will provide that, but I do not want to direct effort at that just yet, when there are still more important improvements in the pipeline.
Thanks for that detailed response, oysteronline.
Note: Simon’s comment had not been approved before this was submitted.
Simon,
Between the initial upgrade on 4th August, and the launch of the second phase last week, we received over 10,000 responses to the feedback survey.
Over 65% of respondents rated journey history as “satisfactory” or better, with around 34% rating it “very good” (the top rank in the survey).
The most prevalent requests in the survey, particularly amongst those that rated it “poor” (14.5%) or “very poor” (20%) were:
– to ensure that online data was more complete and up-to-date;
– to be able to see their history online without buying online;
– to be able to see all their journeys, not just pay as you go;
– to be able to select a date period of their choice (eg: a month);
– to be able to download data for use with Excel, Access, etc;
– to be able to see how much they’d spent in total each day.
We have addressed all of these points with this latest update, and will soon be adding a PDF download option in response to another popular request.
It’s early days, but since the launch of phase 2 last week, 77% of survey respondents are now rating the service as “satisfactory” or better, with 46% giving it the top rank of “very good”.
The reason I have kept the survey in place is because the feedback received has been invaluable, and it will be used to determine how to we can continue to improve journey history.
With regard to your second point, the fact that it is now possible to download journey history in csv format should mean it is no longer necessary for you to copy and paste data from the screen.
Thanks again, oysteronline. It’s interesting to know how the survey responses have been going.
At last I can just check my Journey History without having have to have had on-line topup! (Why was this ever a necessity?)
I’ve done the survey, making the following comments:
For the “Printer Friendly” & CSV options, it would be nice to have the option of “all charging detail”
For CSV version, I would like the journey Start & end locations to be separate fields
It would nice for a Daily Total which has been capped to be marked as such; with a distinction between ‘all journeys/charges within cap’ and ‘some outside’.
I don’t know if, in the situation of some journeys/charges not being within the daily cap, those counting towards the cap can be readily distinguished from those that don’t – if they can, that would be useful to see.
Distinction between peak and off-peak fares would be useful.
As regards the charging detail vs journey total issue, the problem is the number of times when the journey and fare are not what is expected, the charging detail is needed to work out what is going on (rightly or wrongly)
Looking a bit more, another omission has struck me – for Top ups, it gives no detail as to where or why (eg. purchase somewhere, on line, or autotopup)
Hi Jeremy,
Thanks for sharing those thoughts. I can see the logic behind all your points and I particularly like the idea of highlighting journeys which do not count towards the cap. One of the problems is what to do if you cap on buses and make one rail journey which doesn’t then trigger the appropriate travelcard cap, but is different to an incomplete journey where you forgot to touch out for example. The latter would never form part of a cap while the former would if you made more rail journeys.
On top-ups, I can confirm that it does give some detail. Auto top-ups are described as such including the location, helpdesk initiated refunds are described and I’m guessing that automatic refunds will also be marked. It would be helpful if the location of all manual top-ups could be added, though I wonder whether the database of shop names is perhaps not available. It does show where a top-up is made at an Underground station, maybe at ant TfL run station.
Thanks.
Regarding the capping issue, journeys which don’t/won’t contribute to a cap should easily be distinguished, those which could, but didn’t to the cap reached, could only I think be determined by post facto analysis, based on my understanding of how capping works.
On top-ups, my experience is of ones at NR stations, where it just says ‘topped up’…
Hi Jeremy,
I’ve also got a top-up at a NR station showing the same as you. I think that is quite poor. I’d understand not wanting to display the shop name because often that might be the legal trading entity rather than the name above the window, but surely all station names ought to be available.
Mike, Jeremy,
Capping:
As with phase 1, any journey for which the fare was capped will have the green capping icon shown against it, so even if you reach a particular cap, and then start incurring fares again (due to the zones or mode used), only those journeys where capping was applied will be thus indicated. It should therefore be immediately apparent on which days a cap was reached, without this detail being displayed in the daily header.
The only fares that don’t contribute towards a cap are entry/exit charges resulting from unfinished/unstarted journeys (which are already highlighted separately with the “info” icon) and Riverboat ticket purchases.
The next step is to provide information about which cap was reached, along with other aspects of pay as you go charging and season ticket usage; this is coming in phase 3.
Top-up locations:
The only places for which we don’t currently show the specific location are Oyster Ticket Stops and NR ticket vending machines (TVMs). Again, we are looking to address both these points in phase 3. In the meantime, the location at which a TVM top-up took place can usually be discerned from the previous exit or following entry.
As a critic of the first revamp, I have to say I am now really impressed. As well as the simple list of journeys, you can drill down to get every touch (which was what I missed). And yes it is a lot quicker, my journeys from yesterday are already available, it used to take several days. Well done guys.
Jeremy,
Looking at my online statement, it does show auto-topup and the location…
“13:18 Auto top-up, Queens Road Peckham [National Rail] +£40.00 £45.15 ”
OysterOnline,
Thanks for providing the survey information. From the requests you quote, at least four were things I asked for….
– to ensure that online data was more complete and up-to-date;
The paper statement sometimes contained PayG journies that weren’t available in the online version.
– to be able to see all their journeys, not just pay as you go;
Again, I thnk the paper statement would do this for journies made with a Travelcard.
– to be able to select a date period of their choice (eg: a month);
– to be able to download data for use with Excel, Access, etc;
To save cut-n-pasting from the online history into Excel.
I’ve gone back and re-viewed the ‘new’ online journey history. It is better than my first viewing led me to believe.
There are some things I’d like to see brought back….
I’d like to see the ‘Touch in’ / ‘Touch out’ split out into their own column and ‘Touch in’ reintroduced for bus journies – when extracted to Excel, they are a good way to do ‘countif’ scenarios.
I agree with Jeremy, for the CSV version, I too would like to see entry and exit points listed in separate rows.
I’d be happy to offer feedback on any other revisions you have coming up.
Lastly, and this has nothing to do with the ‘new’ journey history…. Why do the ex-Southern stations between New Cross Gate and Norwood Junction pretend to be ‘tube’ stations? e.g.
Overground/ELL
“Dalston Junction [London Overground]”
“Shadwell [London Overground]”
“West Croydon [London Overground/National Rail]”
but….
“Norwood Junction”
“New Cross Gate”
Elsewhere :
Explicitly National Rail…
“Selhurst [National Rail]”
“Queens Road Peckham [National Rail]”
Explicitly DLR…
“All Saints DLR”
“Bow Church DLR”
Explicitly LUL…
“Canary Wharf [Underground]”
“London Bridge [London Underground]”
Implied underground…
“Mansion House”
“Temple”
Is there any ‘standard’ for how the stations are described on Journey History?
Simon
Simon,
The station naming convention is an interesting point (for those that find such things interesting…).
The first thing to explain is that the station names shown on journey history are drawn from the same table that is used to provide the list of pick-up locations for online purchases, so they tend to be biased towards helping customers identify where they need to pick-up their purchases (which is why some also include line or station entrance identifiers).
Before 2010, we only included a “mode tag” for non-LU locations (ie: DLR and tram stops); with everything else being an LU station, it would not have made sense to tag those as well. When we added the 300+ National Rail stations in 2010, we included a tag to help differentiate them. At that time, we also tagged any LU station where there was an NR station with the same name (eg: Bethnal Green). Again, with the launch of London Overground, we adopted the same rule, so the stations were tagged – except where one entry covered all available modes at that location.
We have also started “grouping” some stations to make it easier for customers to place and collect orders. For example, we used to list Finsbury Park [LU] and Finsbury Park [NR] separately, but due to the layout of the station it was not clear to customers which gates/validators their order was waiting at. We therefore grouped the stations into one, so we now just list “Finsbury Park”, and orders can be collected from any gate/validator at the station. We have also done this for Waterloo, King’s Cross, Greenwich and Victoria NR. We included mode tags on the grouped stations even if they covered all available modes at that location, to make it clear to existing customers that the single entries replaced what had previously been two or more separate ones.
So, with reference to some of your examples:
– “Norwood Junction”/”New Cross Gate” cover all modes at those stations (ie: both LO and NR), so no tag;
– “Shadwell [London Overground]” is tagged to differentiate it from the DLR station;
– “West Croydon [LO/NR]” is tagged both because it is non-LU, and because it excludes the tram stop.
You should find that all the others follow suit (although there are no prizes for spotting anomalies).
When time permits, we will create a separate location table for journey history, so that the statement can show the mode for each station used even where grouping is in place. This will be particularly beneficial when showing OSIs, and will also make it more viable to extend grouping to other stations.
The comments regarding the format of the csv download file have been noted. I can’t say that this is a priority, but we will bear it in mind for future development.
Thanks for both replies, oysteronline. The stations history is fascinating. There is a user of this site from the West Country who keeps getting problems picking up at Waterloo. It looks like maybe some of the gates have been left off the grouping. I advised him to pick up from the other end of the tube journey last time as that was likely to be more reliable.
Mike, do you know whether he has contacted the Oyster helpline about that? They should be able to get it looked into.
oysteronline, there are about ten comments starting here between me and Toneser. The helpdesk were certainly aware of the issue but didn’t seem that concerned about fixing it.
I’ll get the gates at Waterloo checked out. It won’t be to do with the grouping per se, but it may be that some gates are (or were) not set to receive orders and refunds. It’s also possible that it’s been corrected since last May, as the gate settings and software tend to be updated quite frequently, and particularly at fare revisions.
With regard to refunds for occasional travellers, I’m surprised Toneser wasn’t offered a web credit, whereby the funds can sit on the customer’s web account indefinitely but will be deducted automatically from their next online order. There’s also an option to redeem the credit if they decide they will not be returning to London. The only customers web credits aren’t really suitable for are those that just use Auto top-up, as they’re unlikely to place an online order.
Hi,
My journey history shows all times since the clocks went forward as an hour later than they actually were. E.g. it shows me taking a bus at 14:37 where in fact I took it at 13:37 (BST!). That’s the case for every touch in/out shown since last Sunday.
I.e. they’ve put the clocks forward by two hours! As it happens none of my journeys were within an hour of the peak/off peak transition times, so I can’t tell if the incorrect time is just in the website display or is systemic (i.e. at the readers, and possibly causing people to be charged peak fare when they should have been charged off-peak or vice versa).
I’m surprised nobody else has noticed/reported it, I doubt I’m the only one affected!
Cheers! 🙂
You aren’t the only one who’s noticed, I did too and reported it to them as well. The Oyster system clock is correct because I have had a journey appear to be off-peak but charged correctly as peak. Thanks for letting us know.
well all I got was ‘Due to the current high demand for Journey History data, we are unfortunately unable to return your request at present. We apologise for any inconvenience this may cause.’
so their system needs some work on it .
It also asked me to log in three times when I was trying to read the history so their system is all over the place.
Its only because of the information on this site am I aware I can get a e-mail statement so that was the option I took although why they did not have a button on the account page is beyond me { please note I am only stating what I can see and as the system is not working correctly just now I cant say if it has changed } as that would make far more sense than having to hunt it out though the help area.
Anyway its a step in the right direction for many of us who up to now were unable to check our history ‘ online ‘ although until I see it working for myself I cant say how user friendly it will be.
Hi Brian,
I have to say that I haven’t yet managed to get the “system too busy” message. I’ve just tried one of my cards now and it is all working as it should. It does sound like there was an issue at some stage if you had to log in three times. I guess it proves that the safeguards to prevent the master system falling over are working.
As to the hidden request a statement option, I agree it would be better with a more prominent button. However, the intention is to include the ability to email a statement instantly from within journey history, so it won’t be an issue forever.
Mike, thanks for your response above.
Unfortunately the Oyster website was experiencing performance issues yesterday (3rd May) which affected various parts of its operation. These were mainly resolved by midday, but while they persisted customers would have seen the “high demand” message when trying to view their journey history.
In its current form, journey history will display this message if anything prevents it from returning data, regardless of the actual cause. We are looking to refine this in the near future, so that the message better reflects the issue where this can be determined.
We are also undertaking a significant hardware upgrade over the next two weeks (9th and 14th May) that will help prevent the issues we saw yesterday from recurring, as well as enhancing the site’s performance in general.
The email statements pre-date the Oyster website and are generated via a separate system. Rather than expending effort on integrating these two systems, we are instead working on adding a facility to generate a statement directly from the Oyster account, with the option of having it sent out each week or month. This will also mean that the emailed statements will benefit from any future refinements we make to the online journey history facility.
My oyster journey history has not been working I get the error “Due to the current high demand for Journey History data, we are unfortunately unable to return your request at present. We apologise for any inconvenience this may cause. Please try again later.”
its happened the last 3 times i have logged in
Hi Tony,
I’ve had this a couple of times recently, but it was ok a few minutes later on. I’m sure the helpdesk/IT team are monitoring what is happening.
We started seeing higher than usual instances of the “high demand” message on Friday. It was investigated as a matter of urgency and the cause was isolated yesterday. We will be taking action to correct it tonight, and will continue to monitor the service once the fix is in place.
In the meantime, I have put a banner message on the website to advise customers that the issue is being addressed.
I found this forum when searching the error message as I have been getting it for two days.
I know this post is from June 2012, but is there a problem again?
Error
‘Due to the current high demand for Journey History data, we are unfortunately unable to return your request at present. We apologise for any inconvenience this may cause. Please try again later.’
Hi Alex,
I’ve checked my history since then and it was fine. It is possible that there was a temporary issue.
It lets me go 2 weeks back, any further and it throws up the error message. I have been trying for two days at different times during the day but still getting the message:
‘Due to the current high demand for Journey History data, we are unfortunately unable to return your request at present. We apologise for any inconvenience this may cause. Please try again later.’
Hmmm. Not sure what is wrong but I can’t actually get in to any journey history at the moment, so I guess there is some sort of problem.
i’ve been getting the same “Due to the current high demand for Journey History data, we are unfortunately unable to return your request at present. We apologise for any inconvenience this may cause. Please try again later.” for days now.
but – only if i try to look at february 2013. if i go back earlier than that, it’s fine. looks like a bug to me. is there any way to report the issue to tfl?
Hi spiff,
I’ve just tried again and it seems to be working now.
odd, still does not work for me!
i still have the same issue (on ie9/w7, ff18/w7, ff10.mdv2010) – whatever i do, i can’t get any history beyond 01.02.13.
i guess my general question is, do you know of a way i can report this to tfl?
thanks,
Spiff
the oyster online site seems to be having problems at the moment
hmm. it’s even more specific now. basically 01.02.13-07.02.13 are not accessible and cause the error, anything else is fine. i guess it is an error in my particular history.
is there any way to request a report from tfl for a specific period. i know there is a weekly or monthly statement, but i guess that’s not going to cover the period if i subscribe now.
I have been having this problem for months, personally I think it’s to do with refunds. I mentioned to twitter account @tfloyster and eventually they passed it on the the web development team. You have to press hard don’t take any nonsense about your browser, emptying your cache, java/javascript enabled/disabled, maybe mention other people are having difficulties. Best of luck!
Hi Alun, spiff,
That’s interesting. I’m now not having any problems with Oyster online. I’d be very interested to know of any theories that either of you have as to the transactions causing the problem. It sounds like it’s an obscure issue that may take the developers some time to find.
i’ve never had the problem before. it may be a coincidence, but i’ve never had a daily cap on bus trips before either.
that was on 31.01.13, and from the day after i.e. 01.02.13 to a week later, ie. 07.02.13, my journey history is broken somehow. on the 8th day after i.e. from 08.02.13 inclusive, the journey history is fine.
Hi Spiff,
That’s an odd one. I often cap on buses in a day and it has never caused me a problem with journey history, so I don’t think it is that. It sounds like there is an obscure problem with your journey details.
If you used the tube (even for 1 small journey) you will be charged the tube cap rather than the bus cap.
How many buses did you use Spiff? You need at least 4 buses/trams for the cap to take effect?
Actually one tube journey would not stop the bus cap applying. If the £4.40* bus cap is reached before the £7.00 zone 1-2 off-peak cap then that is where it will stop charging on buses.
*Edited to correct typo.
You mean £4.40 🙂
On the contrary , my friends experienced this to their detriment as they had enough money for a tube journey plus £4.40 but their oyster went into negative and they had to top. It seems the tube cap overrides the bus cap. (Unless there was an error on his oyster…)
Yes, I did mean £4.40.
I have experienced travel where the bus cap has definitely applied after making a short rail journey, so I know it works. If you can get hold of the journey history when your friends had problems then I might be avle to see where it went wrong.
I am also now getting:
Due to the current high demand for Journey History data, we are unfortunately unable to return your request at present.
Is this issue ongoing? Been getting this error since Saturday and need to check my oyster credit
Hi Diane,
It’s working here for me. If you’re still getting a problem you might want to try clearing your internet cache. This resolved a similar issue on the TfL website for me recently.