FIRST: Darn, darn darn … I fumble fingered a spreadsheet lookup formula and missed some voter visits to Talk. Voters are better Talk followers than I have reported. Thankfully, Chris Marlow was double checking the lists, helped identify a handful of voters I could not match up to Talk usernames and then came up with larger numbers of Talking Voters than I did. Research turned up my goof. Apologies.
SECOND: Many members have multiple names on voter rolls, talk rolls and even different usernames on the two rolls … so getting every last member properly assigned to a category is really challenging. There may still be a tiny few who are not exactly correct based on these totals. At the present time, it adds up to 21 voters who don’t Talk and 314 who do on some frequency greater than never. Not sure we actually have 335 voters, but it is at least something in the low 330’s. The following is based on those totals.
THIRD: Nothing different on general member visits to Talk (the upper two lines associate with the Left hand Y axis.
FOURTH: Voters do visit more often than previously reported. Data is the lower line and associates with the Right hand Y Axis.
Based on the total of 335 Voters:
200 voters visited during the last 7 days of April (59.7%)
An additional 30 last visited Talk to look at something during the rest of the month of April (April total = 68.7%)
A total of 35 additional voters last visited Talk sometime during the first quarter of 2019. (79.1%)
That leaves approximately 70 voters who haven’t visited Talk at any time during 2019. (20.9%)
This is much more encouraging news than I reported (in error) previously. Shout out to Chris Marlow for double checking ID’s on Talk and Voter List and for raising an alarm when the numbers were not adding up correctly.
Unfortunately, I had to make 3 stabs at this to get it correct. Apologies again.
@John_Marlow would you post the data set for these please. I would like to graph them from a zero origin to show the rate comparisons better. This would also remove the need for the improper double y axis.
That is very easy to understand at first glance.
Seeing the data this way, it make me wonder if we should be look for ways to classify the members between active and inactive.
This question isn’t targeted at you Bert, unless you have already figured this out. But, those that have access to the data of DMS, is there a way to estimate active compared to inactive members of DMS. Maybe, a category of the members that badge into DMS meat space in the past 6 months or year and still have an active membership.
Back when our group was smaller (less than 1000 members) it seemed about 50%+ of our membership was inactive. These members had a active account, but no longer used the resources of DMS. They were effectively just donating dues to support our group. Bert, this may also be important to you as well. As measuring the ability to contact members that do not use the resources of DMS may not matter to your want to understand contacting those that use the resource you help maintain.
Others have asked about comparing feet on the floor at DMS and eyes on Talk and I looked to see if it is possible. Unfortunately, the badge system used a different ID tag from either voters or members so mapping one to the other is very hard to do and harder still to claim it is accurate when you finish.
You would think there would be some common number or ID that identifies a specific individual, but I guess these system grew up organically and have their own unique approach as seemed best at the time. Creative chaos at work I suppose!
The data is being collected and stored by the door RFID system, but there is currently no easy way to correlate individual door swipes to any particular member.
My hope is that a future version of MakerManager will automatically produce that type of information, and produce actionable information such as charts showing percentage of members by age/gender/tenure on a day/week/month/year basis. This type of information would be very handy if we ever start seriously chasing grants or corp. donations.
A byproduct of this type of information would be individual flags for inactive/active/very active members. What is done with those flags (if anything) is very much up for debate. Once we have the individual information, and we have a map of members to Talk handles, creating graphs like Bert’s would be much easier.
The Chinese door controller that we use stores the RFID numbers in a different format than what we use.
The 10 digit number that you see on the key fobs is what we use. It is stored as a 24 bit number. We use it as a straight 10 digit integer. The door controllers store it as an 8 bit Facility Code and a 16 bit Card Number. You can see both of these represented on the wallet card RFIDs.
How did you manage to correlate the info for Kris when y’all looked into the badge-ins of the previous BOD members? Is there a way to do that process at a larger scale?
It was done with some laborious Excel-fu… which is not the best way of doing it, and won’t work with historical data where someone has replaced their keyfob with a new one. That requires some relational database work for old swipes… but once that information has been worked thru, and a unique identifier such as the MM id for a member has been attached to the historical data, creating charts would be easy. Getting to that point requires some coding.
One thing to keep in mind here is that we capture MOST of the members entering DMS, but NONE of them leaving. We have a percentage that tailgate, or walk up the ramp when it is left open (again). Most of those that we miss will eventually be captured as they go thru the internal doors, but we will never have 100% capture every day.
I’m a database guy (Teradata / SQL / SAS analytics), and I’d be glad to help, but while I’m doing “database guy” stuff my computer is blocked from accessing the DMS network, and my home computer doesn’t have “database guy” stuff on it.
I’m glad to help, appropriately paranoid Information Security procedures notwithstanding.
I’m definitely willing to work with you on this. What I would think we would need is not all badge ins, but just the badge ins from the last six months. Then a database of the members, the names can be replaced with generated numbers to so we don’t know who they are. then we can do the simple sorting and see what all data is left that doesn’t meet the simple sorting needs and if we need to dive in all that much further.
Not tackling all historical data should make our misses less of an issue at first.
