Trackable Travel Rates-Part 2, Release and Drop

[+shellbadger]

At the heart of evaluating of rates of travel is documenting the start and finish and the time between. For this study, the starting point, or Time 0, is date when a trackable is released from my possession, and is either logged into a cache or grabbed from me by another cacher.  The release is not the activation date, which can be months earlier because I assemble and activate trackables in batches.

As of 2 Jan 2023, a total of 5,045 trackables have been released in in eight countries (see the release locations table below).  By far, the greatest number were released in the United States (mostly in northwest Texas). Historically, the number released outside the US has totaled about five percent per year. However, in 2022, I released 25 at an event in Scotland and sent another 41 to England, to bring to total released abroad to over six percent for the first time.

As for milestones, I do not define survivorship, or longevity, in terms of time passing or distance traveled, but rather as the number of challenges met and overcome. In the context of geocaching, these challenges are the drops achieved…somewhat like the trials of Hercules, but not on the scale of subduing a lion or stealing an Amazon’s girdle.

A drop is defined as a surrender of possession of a trackable, or that point at which there is an immediate change in risk to the trackable resulting from different behaviors among individual cachers and cache owners. A drop is usually a release into a cache, or sometimes at an event, but it can also be a direct handoff from one cacher to another. Though not investigated, I believe direct handoffs between cachers, and even drops at events, are the safest changes of possession, since those transactions bypass the risk of resting in untended caches. If that distinction had occurred to me when I started keeping records, I could have addressed that question with certainty, but I am not now going to re-examine the more than 34,000 drops accrued by my trackables.

 

I accept drop-log dates at face value. While many log dates are scrupulously correct, I know others are recorded at times of convenience, sometimes stretching into months post-event. Some drops are not logged at all, requiring some interpretation of actions. For example, the typical sequence is a drop-log followed by a retrieve-log, then another drop-log, and so on. Some cachers use the “grab” function instead of the designed “retrieve” function. A series of grabs by different cachers without intervening drop logs, still means exchanges have occurred. Other cachers simply write a note that a trackable was dropped off, frequently without other details. Then, there are the occasions when email notifications fail and no drop-, grab- or retrieve logs are received. In those instances, I may only learn of a drop if an email of a later drop is received…I always go back to the last recorded log in my files to check. The point being, the total drops I report represent the minimum number achieved.

 

Varying trackable stewardship issue aside, inaccurate log dates do not affect this project because the time-line is essentially self-correcting. For a given trackable, if a drop-date log is tardy by X days, the elapsed days to the next drop date is decreased by the same X number of days. What really matters is the total number of drops and the total days from release to the last drop.

 

Part 3 of this post details how trackable attrition profoundly affected the study design

[Darwin473]

I agree with your method of using drops / exchanges as a measure of "success". I could have dropped at TB at GCG822 just after it was placed in 2022 and it would have survived in the wild for two decades so far. But I doubt that would count as it would be essentially impossible for someone else to retrieve.