Ito World was a relatively small company when you joined in 2016. How has it changed?
In the last couple of years, what we’ve done is get more ambitious about the work that we want to do, in the strategy that we have, in this geographic expansion and customer expansion that we wanted to pursue, as well as the product set. We were focused initially on selling data to large journey planners around the world and global emerging Mobility as a Service (MaaS) providers. We take the operational data which is designed to manage fleets of vehicles and rostering, and drivers and that sort of thing. And we transform that data into highly detailed, human, navigable information. And there’s a huge gap between those two things. “We fill that gap” is the easiest way to think about what we do. We built a tech stack that allows us to ingest all of that operational data, where we remodel it for an entire city or region or country as the case may be. And because we’re remodelling, that it allows us to intervene in that data in very specific ways to improve it and augment it with other data sources and so on. And then we can export it in a format that really works well for our downstream customers.
What sort of scale are we talking about?
In the UK, for instance, in order for us to deliver a product that’s suitable, we have to make about 130,000 changes to the data every single time we pull it through our system. That’s just to the schedule data of the transit data - then we add real-time data and arrival time predictions, and we ship that to our clients every 30 seconds. And we do that for cities all over the world. So it’s a big data processing job. We have, obviously, lots of tech that does that. But we also have a team of transit professionals that can relay that tech. And they intervene in the data when it’s more complex. So for instance, in New York City, we will remodel parts of the subway system to account for planned disruptions. It is a 24/7 system so they have to maintain it as they’re running, which means they shut down parts of the system or switch platforms, whatever it might be. And we ensure that we take that data and use the information to remodel the schedule and overlay the real-time data on that, so that if you’re using Apple and Google they’re never going to send you to the subway stop that’s closed.
What specific challenges do different cities throw up?
There are some really challenging data structures that make it very hard for companies to get a single view of all modes of transportation in order to do sophisticated routing analysis. If you’re using your [transit] app, what’s actually going on behind the scenes is that it’s looking at the real-time data and if you are in a train that’s delayed, it’ll match you to another. But it means that they have to have a complete view of the entire network for all modes of transportation for a region in order to do that every 30 seconds. So in Singapore they have good data about buses, for instance, but it’s on a stop basis. So you can ask: Hey, is there a bus [near this] stop? And they’ll say, yes, about one minute away, three minutes and five minutes away. We don’t know what line it’s on, we don’t know what schedule it’s running. [In another three minutes you can ask] Are there any buses? Yes, there’s one three minutes [away], one five minutes, one seven minutes. I don’t know if those are the same buses. And it’s a
large system. From there, our platform is able to take that data and basically create a picture of the entire bus network in all of the state of Singapore - that is, an always-up-to-date model. And then we derive schedules from that. Those are extremely challenging things to do, as you can imagine.
Has your work in Australia thrown up any lessons?
Sydney has really good data, but the data overlaps. So if you want one single clean view of it, you actually have to pull all of that data apart, re-stitch it back together and then sum it up as a clean single layer. There are all kinds of complications that happen in different parts of the world that have different challenges. And every city has different custom [application programming interfaces] APIs. And so our specialty is taking data from wherever it is in terms of level of quality, and then raising that bar up to a standard that’s good enough. And so when we ingest that data into our system, we run around 100 tests to ascertain the quality of it. And we measure quality as it pertains to the human navigability of that data, if you will. We use 40 different quality metrics or areas that we’re looking at and then we tried to raise the quality in each one of those sort of areas to ensure that we’re delivering consistent datasets. We create scorecards for every city in which we operate, where we can show this is the data and here’s what we can do with it’, to quantify the value that we can deliver to our downstream customers. But a lot of the work that we do is really managing the upstream’s flow of data. So it might be that a new part of data comes out and it’s not quite right, there’s a problem with it.
What happens then?
We tell the operator but we can’t wait for them to fix it because our customers need consistent data all the time. So we might have to take the existing data and also the new dataset and create a new version and then push it out the door. And, you can imagine with the kinds of customers that we have, they need data that works 24 hours a day, seven days a week, no matter what. There can never be a disruption in the data. It always has to be correct. It always has to be timely and there can’t be interruption. We manage all of that upstream interaction with the operators, to authorities and agencies around the world to make sure that we’re taking care of that for our downstream clients. So we’re the ones that get a call at three in the morning, and something’s happened in the other side of the world. Because of that, we formed very close relationships with operators and agencies. As you can imagine, we’re often the ones that realise that there’s something wrong with our public data feed fast because we’re monitoring that 24 hours a day. So when there’s a problem, we’ll reach out to them, we will work with them to help resolve those things.
Where do you intersect with MaaS?
We have several customers that are building MaaS applications. From a business perspective, they are very similar to the other journey planners that we work with. The way they make money is a little bit different than those folks but in terms of what we deliver to them, it’s the same thing. Some people start with payments and then work their way backwards and some people start with the data and work their way forwards to the payments - but at the end of the day, if you can’t deliver clean, accurate, timely data that helps your customers get to where they need to go, without too much friction, your app is going to fail. No matter what you do in payments, you can have a beautifully designed application with a perfect subscription model. But if you get your customers lost along the way, you’ve still failed. So it all starts with having the highest possible quality data that holds the hand of the customer through these complex journeys that they make using public transportation, because it’s inherently pretty complicated.
Otherwise journeys can be frustrating?
We’ve all experienced that when we go to a new city and we try and figure out, you know, the Paris Metro system or bus system. And it’s really hard. When I first moved to the UK in the 1980s, I didn’t dare use the system at all because it was wickedly intimidating. You’d go to those bus stops and they’d be this thing that looked like it was written in a foreign language. It is really intimidating. And I sort of defaulted back to using the tube as a result of that. Fast forward to when I moved back [to London] in 2016: boy, was it a different world, right? Because you had these apps to hold your hand and they would help you through the experience. Our goal at Ito is to deliver data that is as close to the real-life customer experience as possible. So if you’re standing by a bus stop, we want to make sure the obvious things are right: that the bus stop is in the right location on the right side of the road. Oftentimes, it isn’t in the road data. We want to make sure that, when the bus arrives, the sign information we send to the user’s app actually matches the real-life headline on the bus. So we have to ‘curate’ that. And there are lots and lots of those pretty specific examples, there are many, many data elements that are required in order to create a seamless journey.
And, for users, first impressions count…
You will recall when Apple first launched their maps - not transit data, but their maps in general - when they switched away from using Google, it was bit of a disaster and there’s still people today that refuse to use Apple Maps because they had a bad experience a decade ago. Apple is great now - but they had a bad first impression. When you’re being routed around a city to a destination that matters to you, getting there on time and being helped is the most important thing. Each of these things seem relatively trivial when you say them, but they’re all very impactful, and it’s quite personal. So when we talk about those 130,000 changes we make, you have 130,000 opportunities to create a bad user experience. That’s very significant, you know, the odds are against you if you’re using that little data, right? So you have to do something to improve that data and create a better user interface. That’s especially true for MaaS. Many of the MaaS players are quite small. They’re beginning to do business and trying to gain customer traction. It’s extraordinarily important for them to make sure that they never lose a customer. They’re already competing against very, very large incumbents. So they have to get it right.
But MaaS is still not happening very quickly?
You know, the speed of adoption of MaaS is an interesting question. It’s a very complicated world. And I think MaaS means something different to everybody, which is part of the problem. And in some ways, I think, we’ve kind of gone up in that classic sort of hype cycle, where we’re [now] starting to get into the trough of disillusionment. In some cities, it’s not irrelevant - but it’s not as important. If you look at London: what would it mean to bring MaaS to London? I mean, I pay for everything with [my watch]. That’s my MaaS. It’s not a subscription, but [I will use it] unless you can give me a subscription that guarantees that I always save money. You choose things that are convenient and cost-appropriate. London is probably a bad example because there is less of a ‘need’ for MaaS. But MaaS is very important in certain areas where there’s complex ticketing which is all over the place. And the goal isn’t MaaS per se – the goal is to improve the way people get around. Cars are not all bad – and buses are not all good. The car isn’t the enemy, it has a place in the ecosystem. But it’s been given a status in our society over the last 100 years that isn’t sustainable. As we become more urbanised, it just won’t work. We really are at the beginning of this change.
