Trail counters — use data from the trail itself

Counters are the infrared or inductive units you put out on a trail to count people passing. TrailsIQ stores each unit, its location, and the readings you dock off it — so use data lives next to the trail it describes rather than in a spreadsheet somebody has to find.

Adding a counter

You do not have to add one by hand. Importing a file creates any counter it does not recognize, using the serial number, name, mode, battery voltage and dock time out of the file's own header. For most people the first import is also the registration.

Adding one manually from Counters → New is worth doing when you want it named and attached before its first dock. Either way, a counter carries:

• Name — what you call it. "Lower Oak Ridge trailhead" beats "Counter 3". Once set in the dashboard, later imports leave it alone — the file's name does not overwrite yours.
• Serial number — as printed on the unit, and the key everything else matches on.
• Mode — how the unit counts. Refreshed from each import.
• Battery voltage — refreshed from each import.
• Last dock time — refreshed from each import.

Those last three update themselves every time you import, which is what makes them useful: a unit that has not been docked in three months either has nothing to say or has stopped saying it, and you cannot tell which from the trail.

Where a counter lives

A counter can be attached to a network, a trail, or a piece of infrastructure — a trailhead sign or a bridge it is strapped to.

Attach it to the most specific thing that is true. A counter on a trail gives you that trail's numbers; one attached only to a network tells you somebody came through the area but not where. The attachment is also how you find the unit again: "somewhere near the north end" has cost more than one organization a counter.

Getting readings in

Readings arrive by import. Dock the unit, export from its own software, and upload the file — Counters → Import.

Everything is matched by serial number, read from the file itself. A file can carry several counters' worth of data and they will each land against the right unit.

Re-importing an overlapping file is safe. Readings are keyed by counter and timestamp, so the same reading arriving twice is stored once. This matters because the usual real-world export covers "everything on the unit" rather than a tidy date range — you can dock and import as often as you like without inflating your numbers. After each import the summary reports new readings separately from the counter's total, so you can see exactly what that file added.

One error you may meet: "Counter {serial} belongs to a different organization." Serial numbers are unique across all of TrailsIQ, because a physical unit cannot be in two places at once. If you see this, the unit is registered to somebody else's organization — usually a second-hand counter, or one moved between organizations you both administer. It refuses rather than silently reassigning; get in touch and we will move it.

Reading the numbers

Open a counter to see its readings and statistics — totals over time, and the shape of use across days and seasons.

Two things to keep in mind when interpreting them:

• Most counters count passages, not people. An out-and-back walker crosses the sensor twice. Whether you halve the number depends on your unit's mode and where it sits, and it is a decision to make once and apply consistently rather than per report.
• A counter measures its own spot. A trail with three entrances counted at one of them undercounts by a factor nobody can derive after the fact. Note where the gaps are before quoting a total to anyone who will repeat it.

Exporting

Two buttons on the counter's page export whatever date range you have selected, so the numbers can go into a grant application, a board pack, or whatever your funder wants them in.

Export PDF is the one to send. It carries your organization's name, logo and color, the range you picked, and the readings — with the total count, the number of readings and the busiest single reading worked out at the top. The total is usually the number the application is asking for.

CSV is the raw readings and nothing else, on purpose — anyone doing statistics with your numbers wants to do their own aggregation, and a pre-summarized file is the one they ask you to re-send.

What counters are good for

Use data is the argument you cannot make from anecdote:

• Funding. "This trail carries 40,000 passages a year" is a fundable sentence. "It's busy" is not.
• Prioritising work. Maintenance effort is better spent where the traffic is, and intuition about which trail is busiest is wrong more often than people expect.
• Showing impact. A new connector's effect on use is visible in the counts on both sides of it.
• Managing pressure. Seasonal and daily patterns tell you when a trail is under strain, which is the input to a closure or a hardening decision.

Common gotchas

• A typo'd serial makes a second counter, not an error. Since the import creates unknown serials, hand-entering a serial wrongly and then importing gives you two counters with the readings split between them. If a unit's numbers look halved, check for a near-duplicate in the list.
• Serials are unique across all of TrailsIQ. A second-hand unit still registered to its previous owner will refuse to import rather than move itself.
• Dock regularly. Battery voltage and dock time only update on import, so a unit you never dock looks healthy forever at whatever it last reported.
• Passages are not people. Decide your convention once and state it wherever you publish a number.
• Moving a counter breaks the series. If you relocate a unit, its history before and after describe two different places. Note it, or the trend line will lie to you later.