Missing Trackables-Part 01, Definitions and Methods

[+shellbadger]

When is a trackable really missing? That is a question that has vexed me for all the years I have been maintaining records on my trackables. I keep my larger caches stocked with new trackables because those caches are the chief means of distributing them. I routinely revisit those caches soon after a visit by another cacher because I have learned that almost 60% of the time, one or more trackables will have been taken from my caches without a retrieve-log on the date of the actual retrieval. Is such a trackable missing?  

 

It is true that about 16% of the new trackables left in one of my containers will never be heard from again.  However, I can’t know that until years have passed. I estimate that only half of my trackables are logged in real time. The other trackables will be held without logs for periods ranging from days to years. So, when is it possible to conclude a given trackable is missing?

 

For this project, I needed a practical definition of missing for which the wait-and-see is not inordinately long, but is long enough that the reappearance of a few long-missing trackables would not materially change the study results. To make this determination, I referred to the drop-interval table for my trackables (see the 2010-22 Drop Interval table below).

 

The Drop Interval Table is an accounting of days between drops or exchanges of possession of my trackables between cachers. The table shows the frequency distribution of the 34,633 drop intervals occurring among my trackables over a 13-year period, ending 31 Dec 2022. This table is regenerated automatically with the recording of every new trackable drop.

 

The data show that a little more than 60% (the first line) of the drops occur within two months (60 days) of the previous drop. I take this to mean that a missing trackable without an appropriate log for up to 60 days is very likely still in play. The table also shows (the blue cell) that a little over 95% of the intervals occur inside one year, meaning the chances are still good for a trackable to resume activity for up to a year. After a one-year-missing interval, the probability of a trackable resuming travel drops dramatically, but it can occur out to more than ten years.

 

As for the definition of missing for this project, I settled on a more-than-three-years criterion (the yellow cells). Thus, my missing trackable pool includes 2,675 trackables without an appropriate log for the years 2010-19. This is 70.5% of the 3,793 trackables released in the same period. I accept that having assembled this pool of missing trackables, about 0.6% of them may reappear while I am working up these data. I will not update the missing-trackable pool during this project, but will trust that the number of reappearing trackables will remain so small that the work will not be compromised.

 

A missing trackable is defined as one having no appropriate log, that is, no logged drops, grabs, retrievals, or visits for at least three years. As with all projects documenting my trackable longevity, I read but mostly ignore discovery-logs. Discoveries will sometimes continue for years after a travel bug has disappeared, depending on how long a list of tracking numbers gets circulated. However, if a last-log is a discovery which includes words to the effect that a trackable was retrieved, that date was used. Similarly, if a cacher note referred to a retrieval, grab or visit, that date was also used.

 

Once the pool of missing bugs was fixed, I recorded details about every trackable, a good bit of which I may never use. I chose to record too much information at the outset, rather than to be confronted with the possibility of wishing I had captured something more when I was summarizing the data.

 

The data pool started with my existing trackable catalog, which is in spreadsheet form. That catalog initially included the trackable name, the ID and tracking numbers, the date released, where released and two numbers based on a combination of the date of release and the ID number. One number sequence is the overall catalog number starting with 0001, the other is an annual sequence which begins with 001 with the first release of each year. For example, The State Flag of Idaho (TB6CA4N), the first release of 2015, is 15-001, but also 1723, the overall release number.

 

For the present project, new information about each trackable was added to the existing catalog. This included, but was not restricted to, last-log dates, last cache ID numbers and their respective locations (with coordinates), last cache status, drops achieved, age in days/years, miles traveled, and, when known, the cacher holding the trackable.

 

The later posts about of this project will be a series of overviews of the findings. I have no idea how many posts there will be. Because of the large amount of information that can be sorted and resorted, there is a huge potential for new revelations…maybe the use of the term revelations is an overstatement, because much of the information will be suspected by experienced cachers, but just never quantified.

Edited May 3, 2023 by shellbadger
error

[Darwin473]

It would be so nice if there was some magical way of knowing exactly what happens to a TB when it drops off the map. Did it accidentally fall out of someone's pocket? Did a bird grab something shiny? Is it on display on someone's shelf? Realistically, it would really have to be magic - as was demonstrated by the semi-recent discussion I saw about a TB with an Apple Airtag on it.

 

I completely disagree with your three year line in the sand as being the definition of "missing" - but I can't dispute your data sample or conclusion! I'd have wanted a much shorter time frame to declare one MIA, but that's because I like to re-release mine with proxies. I haven't yet had the circumstance of having two copies come up in play at the same time, but it is entirely possible.

 

Thank you for another well-researched post. Your insights and available data pool are fascinating!