Some considerations in the realm of data collection.
Pieces of data we're collecting
The trick that we will attempt to do/did attempt to do. We need to know this piece of data so that we can keep tracks of which tricks we've attempted and keep track of the other data about our trick attempts (especially the outcome of trick attempts). I've learned that when I'm recording data in the field, it's easy for me to refer to tricks with a shorthand reference to their full names that I can encode fully later on. Note that in the moment of recording the data, I'm inputting a reference to the trick's name that is less than optimal for later analysis. And I've inputted many different forms of references to the same trick (many-to-one relationship), such as, for a kickflip: kickflip, "kflip", or "kick". This especially occurs when I'm having fun and am eager to get to the next attempt or write down a new trick. Though the shorthand references help shorten the time involved with inputting tricks while in the field, it makes electronic data entry take longer and analysis more difficult (if you don't catch cases in which one trick is recorded under different names, your analyses of that trick might exclude data that's listed under other names, which is unhelpful).
The outcomes (recording whether we landed a trick or not). This is one of the most important pieces of data that we're collecting. While the jury's still out about how useful the odds system (above) is, the outcomes are useful. We can already do fun and interesting things with them. For an entire book about how you can use data like this, binary data (yes/no, heads/tails, success/fail, landed the trick/did not land the trick), check out the book Bayesian Statistics the Fun Way; it's what I'm using to get this whole thing going, and it gives us a great guide towards fun analyses.
The "betting"/odds system.
The date of the trick attempt.
Aspects of data collection to consider
The role of omissions in the record. I suspect that so long as an omitted trick attempt was omitted randomly — for instance, the omissions should not be intentional, such as if you only recorded cases where you landed a trick but did not record cases where you did not land a trick — omissions should be OK. This is good for later statistical analysis. Plus it's convenient because since omissions can arise quite naturally. For instance, I've occasionally been too caught up in the moment of trying tricks and being goofy with them to stop after each one and record them or to want to keep a log in my memory (which I would record somehow, with time) of the tricks I've done, the sequence in which I did them, and whether I landed them or not (I also don't have a great memory, so though I do use the memory log method, my limit is usually about three or four attempts, often of only to same trick to avoid getting confused).