This Got Slightly Out of Hand

I never had a master plan for Track3D. The idea of setting up an online presence wasn't even a distant concept.

I made a couple of gifts for friends and then, holy shit, so many people wanted one of their own that it was easier to set up a proper ecommerce site just to manage the admin side of things.

A few months of getting that site to where I was happy with it and I started wondering if the Race Planner project I had been working on could become a useful web based race planner for the community.

That led to the Ultra Marathon Race Planner.

The Race Planner led to wanting a better way of pacing an ultra. I could make assumptions about how terrain and fatigue affected runners, but I wanted real data to understand what actually happened during races.

That led to creating a data lake with tens of thousands of real world ultramarathon race splits.

The data lake then became the foundation for researching and developing what eventually became Track3D Course Aware Pacing.

Then it became: I have this really useful Race Plan, I wonder if I can use it during a race to help crew understand where their runner actually is and when they are likely to arrive.

A tracker can tell you where someone was when it last sent a location. That doesn't necessarily tell crew what they really want to know.

When are they getting here?

That led to seeing if I could use my Garmin inReach Mini as a source of satellite tracking data.

Tracking led into satellite devices, watches and apps.

What started as a web app eventually became the Track3D Crew iOS app.

Even after getting a pacing model I was happy to release, I didn't stop collecting a ridiculous amount of race data. That turned into building tools to understand what runners actually do during ultras and using that information to keep testing the assumptions behind Track3D.

So yeah, it got slightly out of hand.

It all started with a need to do hard things

Ultra running became a big part of my life long before Track3D became what it is now.

Like most people who get into these events, I didn't suddenly wake up one morning and decide running 100 miles sounded like a normal weekend activity.

It happened gradually.

You enter something that feels massive, train for it, suffer through it and finish swearing that is the last time you do something that stupid.

Then you want to know if you can do something harder.

There is a lot about ultra running I enjoy, but one of the things that has always interested me is how much there is to learn.

Each course has its own challenges and each challenge needs to be broken down and dealt with.

Every climb has its own unique way of making you suffer.

Checkpoints are havens you never want to leave, but eventually have to.

Your stomach becomes your worst enemy. You get sick of having to eat constantly. The weather is the wild card you can prepare for but never really be ready for.

And after enough hours, apparently things like how long you sit down in a chair become a major strategic decision.

There is a huge amount going on around something that, at its simplest, is still just moving from a start line to a finish line.

A lot of it comes down to finding solutions to whatever problem is in front of you.

That same need is what eventually pushed Track3D well beyond its original idea.

Track3D started somewhere much simpler

A couple of mates completed some pretty stupid distances, I was playing around with 3D printing, and I wanted to make them something that represented what they had actually done.

The first pieces were never intended to become a business.

They were just supposed to mean something to the people receiving them.

That part of Track3D hasn't changed.

We still make terrain pieces, Elevation Curtains and Special Editions built around the routes, climbs and places that made a race memorable.

There is something about seeing the actual terrain of a race sitting in front of you that a medal or a GPX line on a screen doesn't quite capture.

But working with those courses also meant I was spending more time looking at the data behind them.

Eventually I became just as interested in understanding a race before it happened as I was in representing it afterwards.

That was where things started heading in a completely different direction.

The Race Planner

Like plenty of runners, I had a go at making plenty of race spreadsheets.

Distance between checkpoints.

Expected pace.

Arrival time.

Cutoff.

Stop time.

Repeat until Finish.

They work, but the maths can be a little optimistic about how cooperative mountains are.

Ten kilometres of flat runnable trail and ten kilometres with a large climb in the middle might look identical in a spreadsheet if all you are using is average pace.

Anyone who has actually run those two sections knows they aren't the same thing. Not even close.

The same applies later in a race.

A kilometre at 20 km doesn't feel nearly as hard as a kilometre at 120 km.

So I wanted to build something more detailed that was simple to use.

The first objective wasn't particularly ambitious.

Take a GPX course, add checkpoints, set a target finish time and create a useful Race Plan.

Seemed simple enough at the time.

Turns out, it wasn't.

Average pace didn't last very long

Once the basic Race Planner worked, average pace immediately started annoying me.

It was too simple and generic, it didn't factor in the things that actually make one part of an ultra harder than another, so the plan could look neat without being particularly useful.

The GPX already gave me a lot of the course information I needed to do something better.

Elevation.

Grade.

Climbing.

Descending.

But knowing the terrain was only part of the problem.

I still needed to understand what runners actually did as a race progressed.

I could come up with increasingly complicated rules about fatigue and how pace should change later in a race, but that didn't mean those rules reflected reality.

At some point I needed to stop asking whether something looked sensible and start asking whether real runners actually behaved that way.

So instead of just building a more complicated pacing model and hoping it was better, I started collecting data.

Which is how a fairly innocent Race Planner turned into a research project.

Then the data took over

I started collecting race results and checkpoint splits.

Not just finish times, but how runners progressed through events.

Where they slowed down.

How that changed later in races.

What happened across different courses.

What happened across different runners.

The more data I collected, the more useful it became.

Eventually that became a proper research data lake containing tens of thousands of real world ultramarathon race splits.

That changed the way I approached the pacing problem completely.

Instead of deciding how I thought runners should slow down, I could look at what actually happened.

Instead of guessing how fatigue affected different parts of a race, I could test ideas against real race data.

If I changed the way Track3D handled fatigue, I could measure whether it improved things.

If I thought a different approach might describe a race better, I could test it against actual results.

If something didn't work, I could throw it away.

That research eventually gave me enough evidence to start building and testing a better pacing approach against real races rather than just my own assumptions.

This became Track3D Course Aware Pacing.

And even after I had a pacing model I was happy enough to release, I didn't stop collecting data.

That process has now become its own part of Track3D.

There is a separate modelling environment, a growing research data lake and a fairly strict process around testing ideas before they make their way anywhere near the Race Planner.

That wasn't part of the original plan, because there wasn't actually an original plan.

But I like where it has gone.

Ultra runners generate an enormous amount of useful information simply by racing. There is a lot we can learn from it if we are careful about what the data actually tells us and equally careful about what it doesn't.

The Race Planner kept expanding as well

Pacing turned out to be only one part of planning an ultra.

Once I was using the Race Planner for my own races, other things started becoming obvious.

I wanted proper checkpoint information.

Cutoffs.

Planned stops.

Aid station services.

Notes.

Course maps.

Elevation profiles.

A compact summary that could actually be carried during a race.

A larger report that could be useful for the runner while planning and for crew on race day.

Then there was race strategy.

The pacing model was built by learning from what runners actually did, but that creates an interesting problem.

What runners actually do isn't necessarily how I want to run my race.

A lot of middle and back of pack runners go out hard. Sometimes much harder than they can sustain later in the race.

That behaviour is still real data and it is useful for understanding how races unfold, but when I looked at some of the early section pacing it was more aggressive than the way I normally want to approach a long race.

My normal strategy is to be more restrained early and protect the back half.

Other runners will approach it differently.

That led to Race Strategy.

The Course Aware model still does the work of distributing time around the actual course, but the runner can now choose how they want to approach the race, from more restrained early through to much faster early, while keeping the same overall finish target.

The data tells us something about how runners tend to race.

Race Strategy lets the runner decide how they want to race.

Garmin created another rabbit hole

Race planning is useful, but eventually the runner has to leave the computer and actually go running.

I already use Garmin for tracking and navigation, so trying to rebuild all of that inside Track3D would have been fairly pointless.

Garmin made billions at being Garmin, so I let them do what they do.

What interested me was getting the useful information from Track3D into that environment.

That led to Garmin FIT Course export, Course Points, checkpoint cutoffs, planned rests and runner notes.

It also led to building the Track3D Garmin Connect IQ Data Field.

Interestingly, that ended up going in a different direction to where I first expected.

Instead of trying to cram an entire Race Planner onto a watch, the first release is deliberately simple.

It turns a compatible Garmin watch into another Track3D tracking source.

The watch knows where the runner is.

Track3D can make that location useful elsewhere.

That distinction became increasingly important.

Crewing changed how I thought about tracking

Running an ultra gives you one view of the race.

Crewing gives you another.

When you are running, you are generally occupied.

Keep moving.

Eat.

Drink.

Solve problems.

Try to remember why you thought this was a good idea.

Get to the next checkpoint.

Crew get a lot more time to think.

Usually while standing somewhere wondering where you are.

A Race Plan might say the runner should arrive at 4:15 pm.

Then 4:15 comes and goes.

Maybe they are twenty minutes away.

Maybe they are two hours away.

Maybe the tracker hasn't updated.

Maybe the last climb was horrible.

Maybe they spent half an hour at the previous aid station trying to convince their stomach to accept food.

A location dot helps, but it doesn't always answer the question the crew actually cares about.

When are they getting here?

That was what pushed Track3D further into tracking.

The Race Planner already knew the course.

It already knew the checkpoints.

It already had an expected schedule.

If Track3D could receive the runner's actual location, it could match that position to the course, work out race progress and start updating what was likely to happen next.

That became the foundation for Track3D Crew.

Tracking became bigger than the tracker

The first satellite device I worked with was Garmin inReach.

Then came Garmin Connect IQ.

Then SPOT.

ZOLEO is now another integration path.

The important lesson from that work was that Track3D shouldn't really care which logo is printed on the device.

Each device has its own way of getting a location to us, but once that location arrives the job should be the same.

Match it to the race course.

Work out reliable progress.

Understand which checkpoint is next.

Update the ETA.

Give that information to the people who need it.

That means a runner can use a satellite tracker, a Garmin watch, a phone or potentially more than one source during the same event.

Track3D owns the race context.

The devices provide evidence of where the runner is.

That has turned out to be a much more useful way of thinking about the problem.

Then Crew became its own thing

Once I started thinking seriously about the crew experience, simply showing race progress wasn't enough either.

Crew need practical information.

Checkpoint notes.

Where they need to go.

When they should start getting ready.

Whether the runner is approaching sooner or later than expected.

What the weather is likely to be at that checkpoint when the runner actually gets there.

Track3D Crew has grown around those problems.

There is the web experience, the native iPhone app, checkpoint alerts, navigation, Live Activities and work around CarPlay for the person actually driving between checkpoints.

Again, the objective isn't to give crew more numbers to stare at.

It is to help them make better decisions.

There is enough going on at 2am without needing a degree in tracker interpretation as well.

And now there is a Runner app

The runner has a different set of problems again.

Once the race starts, I don't particularly want to open a full Race Planner.

I want the small amount of information that matters right now.

What is the next checkpoint?

How far away is it?

What is the cutoff?

What did I write in my notes about this checkpoint three months ago when I was sitting comfortably at home and still capable of sensible thought?

That has led to Track3D Runner.

The idea is to take the useful parts of the Race Plan and make them available on the iPhone during the race, including when there is no network coverage.

It can also become another optional Track3D tracking source.

That project is still much younger than the Race Planner and Crew, but it follows exactly the same pattern.

There was a problem I wanted solved.

So I started building something to solve it.

Track3D is still about the physical journey too

With all of the software work it would be easy to make it sound like Track3D has somehow moved on from where it started.

It hasn't.

The physical products are still a major part of it.

In fact, the production side has become considerably more sophisticated as well.

The original experiments have turned into proper tools for generating terrain, Elevation Curtains, checkpoint overlays, artwork, mount plates, Special Editions and the media used to present them.

The Special Editions are becoming their own platform.

So while one part of Track3D is trying to understand how somebody might move through a race, another part is still doing what started all of this in the first place.

Taking the journey and turning it into something physical.

I like that those two sides now exist together.

One helps before and during the race.

The other remembers what happened afterwards.

Sharing what I have learnt

Another thing that has happened along the way is the Guides section.

I have spent a lot of time researching things because I needed to understand them myself.

Satellite tracking.

Garmin integration.

Crew strategy.

Aid stations.

Race planning.

Course Points.

Sometimes the useful outcome isn't another Track3D feature.

Sometimes it is just information worth sharing.

That is where the Guides fit.

If something I have learnt building Track3D or preparing for my own races can save another runner some time, help a crew understand something better or stop somebody discovering the same thing the hard way at 3am, it is probably worth writing down.

Not everything Track3D does needs to end with somebody buying something. In fact, far more of the site is there for the community to use for free than sits behind anything paid.

Helping the community is part of why I enjoy building it.

This got slightly out of hand

When I look at Track3D now, it is difficult to reconcile it with the first couple of prints I made for some mates.

There are still the physical terrain pieces and Special Editions.

But there is also the Race Planner, Course Library, race reports, Garmin integration, Course Aware Pacing, Race Strategy, satellite tracking, Garmin tracking, Crew on web and iPhone, the Runner app, research modelling, a growing race data lake and the Guides.

That definitely wasn't the plan.

But neither was running 100 miles when I first wondered whether I could run an ultra.

That is probably the connection between the two that makes the most sense to me.

I'm still not completely sure what Track3D eventually becomes.

Based on the evidence so far, leaving it alone doesn't appear to be an option.