Best Practice for Recording Catches by Auto Traps?

Help & Support
#1

Hi team,

We’ve recently started collecting catches from A24’s, and I wanted to check best practice for recording them within TrapNZ. I’d be keen on peoples thoughts please.

I’m conscious of trying to keep good clean data, accurate stats, and not creating misleading data/stats like assuming the catches were rats.

Date -
With Chirp, enter the actual dates. With the strike counter, spread the catches evenly over the period, eg if 4 catches over 4 months, log 1 for each month. (avoids screwing up stats with artificial peaks).

Recorded by -
We’re putting down a make believe trapper called “auto traps” to again avoid skewing the the counts by trapper. For example, avoiding bad stats where someone comes in every few months, clears the auto traps, yet they show as a top trapper over the team that is in there every week clearing traps.
Who recorded (and the check date) it is still captured, but in the comments.

Species Caught -
Unless there are some obvious remains under the trap, this must be recorded as unspecified. Again bad stats if we assume it’s a rat, or mouse, or stoat etc.

Strikes -
Generally 1 if we are following the date rules above.

Status -
Still set, bait ok; unless we’re doing a bait refill and gas recharge.

Rebaited -
Yes, as it’s effectively always rebaiting. However this might be better suited to recording when the lure and gas were changed?

Bait Type -
Must record, even if showing no in the above rebaited data. Endter ss appropriate, eg with rat and mouse or rat and stoat etc. Must record again for good stats, so the following catches are recorded against the bait used.

Trap condition -
as appropriate

Comments -
Record who and when checked, as we are using the “Auto Traps” trapper name, and using actual dates as given by Chirp.

General Practice -
I was thinking that after entering the actual catch dates, enter a check record for the today (with no strikes) so we can see when the trap was last checked. For example, I’ve just entered 8 catches for the last 5 weeks, and a 9th recorded showing I checked and sync’ed with the trap today.

Thanks
Grant

#2

Some excellent questions and suggestions. There are some logical assumptions we could make for pre-populating certain fields, and some additional status only applicable to multi-catch.

The consensus here is it would be misleading to spread the dates or add a ‘make believe’ trapper in the base data. Better to record these as the actual dates checked and the trapper entering the data. You can later derive the assumed dates and add a fictional trapper (based on trap type) when generating the reports. That’s a seperate discussion I think, but one worth having with the increasing use of mult-catch installations.

Does that sound fair?

#3

Thanks Andy,

I’m not suggesting or asking for the system to pre-populate anything, just what we’d manually enter when recording auto trap data. However if there is any improvements that can be made for multi catch traps I’d support them.

I can see the admin benefit of using a real person under the “recorded by”, this is why I think it still needs recording in comments. Using the real person potentially skews the report “catches by trapper” where someone who does very little work for the project starts coming out on top. However I’m not too precious about this and can use the real person who recorded it.

What do you mean by deriving assumed dates later when reporting?
It’s for the reports that I’m suggesting we spread the catches out since the last check date, so we can run the normal reports the system provides and they remain useful ie we are not having to constantly try and figure out if we are seeing an increase for any given month, or having to ignore that month as we know its when we recorded a huge bulk count from the auto traps, or trying to work out if it’s a mix of both.

With a strike counter, with no date info, we can either assume a even spread, or load them all in as 1 bulk count on the day as you suggest. Your team suggests spreading them is misleading, however neither is the truth, both are misleading, but isn’t a single bulk count much more misleading, and averaging the catches out while also not true, is the lesser of 2 evils?

With the Chirp counter, where we have the real dates and don’t have to assume an average, surely we want to use those real dates and not throw away that information about catch rates and when we see an increase or decrease in pest activity?

Thanks
Grant

#4

I can see the admin benefit of using a real person under the “recorded by”, this is why I think it still needs recording in comments. Using the real person potentially skews the report “catches by trapper” where someone who does very little work for the project starts coming out on top. However I’m not too precious about this and can use the real person who recorded it.

I don’t think it skews the report, the report is still valid and accurate, it’s just not an indicator of trapper effort. That would be a seperate report “trap visits by trapper” which doesn’t exist yet, but could…

What do you mean by deriving assumed dates later when reporting?
It’s for the reports that I’m suggesting we spread the catches out since the last check date, so we can run the normal reports the system provides and they remain useful ie we are not having to constantly try and figure out if we are seeing an increase for any given month, or having to ignore that month as we know its when we recorded a huge bulk count from the auto traps, or trying to work out if it’s a mix of both.

With a strike counter, with no date info, we can either assume a even spread, or load them all in as 1 bulk count on the day as you suggest. Your team suggests spreading them is misleading, however neither is the truth, both are misleading, but isn’t a single bulk count much more misleading, and averaging the catches out while also not true, is the lesser of 2 evils?

With the Chirp counter, where we have the real dates and don’t have to assume an average, surely we want to use those real dates and not throw away that information about catch rates and when we see an increase or decrease in pest activity?

I think we agree that spreading them has merit, no argument there. I’m suggesting that the reporting mechanism should work out the offset dates (it does the spreading) rather than entering incorrect and assumed dates. Lets say your single kill traps only started catching in the last week of the month, its a fair assumption that the multi-kill were only catching in the same week. If you were to evenly spread them you more than likely will skew the results. What should probably happen is the dates are spread intelligently in the period the others were active.

With chirp data it would be individual records, one strike on the given date as per any other record.

There is a seperate forum thread on reports for kills per trapper compared to visits per trapper (i.e. effort put in, doesn’t exist yet btw.) By spreading your dates in the data your ‘effort’ reports would be skewed, and skewed the other way if you put a fake name.

Does that clarify our thinking, and would it work for you?

#5

Caveat: in my opinion…

This (or any similar) website should be viewed as a tool to be used by and for the benefit of the trapping project. In that regard, the interface should be used as conveniently as possible to still achieve the needed outcomes.
So, first, the outcomes need to be identified. For example, are kill reports needed for funding applications (if so, does it matter who killed what?)? Or, does the project replace CO2 cartridges on a schedule or on demand? Understanding what you want to get ‘out’ of the website helps you understand what you must put ‘into’ the site.
Convenience, in this instance, applies primarily to data entry since that task is done many times more frequently than data analysis. So if the data analysis step requires some extra manipulations, that’s many times better than (needlessly) doing manipulations at data entry time. Besides, if those post-processing manipulations are shown to be valid and relevant to many/all projects, then the website will be upgraded to incorporate those manipulations.
Further, data entry is generally done by more people than data analysis so keeping uniformity among the people doing the entries is important. So, the easier the better.
Another example would be in terms of “rebaiting”. If what you need to accomplish is to determine when ALPs should be replaced, then using this field of the data to record replacement date of the ALP seems appropriate to me. Ticking a box every time that says “Rebaited” only because there’s an automatic lure used is gratuitous and provides no value to the recorded data.
Recording when a CO2 cartridge is replaced is important as well since often A12/A24 failures are due to gas leakage in the mechanism, emptying the cartridge fruitlessly. I believe many people even write the replacement date on the cartridge itself so that it becomes obvious to the trapper that a unit has failed.
Hope this is helpful.

1 Like
#6

I think that sums things up pretty well. The reports are used for all sorts of purposes (Funding, marketing, trapper bonuses etc.) The current set have been requested by projects at some point. Creating reports is trivial and safe compared to changing data collection UI’s and data structures.

Other considerations:

Battery replacement along with CO2 and lure.
New tools like the ZIP Motolure used in conjunction with a trap/camera-trap.

#7

We only have one A24 trap that we look after, alongside 180 more standard traps. Recently it caught 3 juvenile rats in one night after a bit of prebaiting with peanut butter, and they were verified because it rained afterwards, stopping pilfering by other pests. We use a shock counter on the cannister. But we only record a kill when we can identify it. I suspect that slugs are crawling up inside the cavity to eat the bait, just like they eat the bait in our traps. I use Quash to stop the slugs more safely. Ultimately we should be able to stop pilfering of kills by getting rid of the higher order pests, but that’s not easy, is it…?