Why nobody downloads your app.

Across 110 museum apps in Germany and Austria, the average app was downloaded by 1.3% of visitors, and nine in ten reached 3% or fewer. A separate count of 175 museum audio guide apps in Europe and the United States put the average at 2.47%.

Both studies were published by companies that sell guides you don't have to download, so read them with that in mind. Both estimate downloads from public store figures rather than counting them, and both publish their method. The finding is consistent anyway, and it matches what anyone who has commissioned an app already suspects. The problem is the install. No amount of good content survives being behind it.

The friction chain

Nobody decides not to use an app in one go. They decide four or five times, and any one of those decisions going the wrong way ends it.

First they have to find it. A poster says to search the app store for the trail's name, and the search returns several apps with similar names and no obvious way to tell which is the real one. Every second spent working that out is a second in which the walk could already have started.

Then they have to install it, usually standing outside, on mobile data, with a phone that may want to update itself first or free up storage. An app that carries its own audio and maps is rarely small. On a weak signal that is a long wait, and the walk was supposed to start five minutes ago.

Then it asks for things. Location, so it can show where you are. Notifications, which nobody needs on a forty-minute walk. Each prompt is a fresh decision about whether this is worth it.

Then, too often, it asks for an account. An email address, a password, a confirmation link sent to an inbox nobody checks on a day out. Nobody publishes a clean drop-off figure for each of these steps in a tourism app, but the nearest well-measured equivalent is not encouraging. In online shopping, where people have already chosen what they want, Baymard Institute's research finds that 18% of abandoned purchases, setting aside people who were only browsing, were abandoned because the site wanted an account.

And the people who get through all of that mostly don't come back. Across 125 million phones, analysis by Andrew Chen and Quettra found that the average app had lost 77% of its daily users within three days of being installed. For a trail that is walked once, that matters less than the download itself, which is the point. The barrier is at the start, and it is the same height for every visitor.

The arithmetic

The arithmetic follows directly. At 1.3%, a site with 50,000 visitors a year can expect around 650 downloads. To reach a thousand people at that rate you need around 77,000 visitors, and to reach ten thousand you need more than three-quarters of a million.

Greenwich ran the experiment years ago. The council spent over £5,000 on an app to promote the borough, £2,550 of it on the script, studio time and narration. A freedom of information request in December 2010 found it had been downloaded 563 times, in one of the most visited boroughs in London. That is nearly £9 a download, before anyone had opened it, let alone listened to the narration. The content was paid for properly. Hardly anyone reached it.

Do visitors download destination apps? Some do. The best app in the German and Austrian study reached 10.5% of visitors, eight times the average. But planning on the high end is planning on being the exception, and most budgets are approved on the assumption of being typical, so the typical figure is the one to plan with.

What offline really covers

The first objection to anything that isn't an installed app is the signal, and it is a fair one. Valleys, coasts, old town centres with thick walls: a trail goes exactly where coverage is worst.

What matters is what has been stored on the phone, not what kind of software it is. A web page can be built to save itself the first time it opens, using what browsers call a service worker, and then work with no signal at all. An installed app can work offline too, because everything was downloaded at install. Either way, the phone's position comes from GPS, which works without a data connection, though it takes longer to settle without one.

What caching does not cover is anything that wasn't stored. Map tiles for an area nobody has viewed, audio for stops further along that haven't been fetched, a photograph loaded on demand. And caching can't help with the very first load. A QR code on a board in a valley with no signal fails a web page and an app store link equally.

So the honest answer to the offline question is about where and when the route is first opened, not about apps. Put the link where there is signal: the car park, the station, the visitor centre, the website people read before they set off. Build the route so that opening it once stores the whole thing, the text, the map for the area and the audio. Then it works in the valley.

At the trailhead

A link-first route is a sign at the start with a short web address and a QR code beside it. It opens in the browser people already have. It doesn't ask for an account. It asks for location only when it needs it, and it works if the answer is no. It stores itself for the walk, and it is there again next time without anyone remembering a password.

None of that makes the content better. It just means the content is read by the people standing in front of the sign rather than the few who were willing to install something first. Which option that points to depends on what each one costs to keep running, and what a self-guided trail actually costs sets those side by side.

If you have an app already and want to know how many visitors it is really reaching, we'll help you work it out from the figures you have.