image credit: wisconsinfree.com
In my days as an advancement services professional, the database I used had a whopping three gender options: Male, Female, and Unknown. This table was not editable by administrator-level users. This mostly worked for my organization with some exceptions - in an incredible PreK-12 school where community members felt safe to express themselves genuinely, we occasionally learned of students or employees who identified with a gender other than the one on their birth certificate. In those cases, we updated the individual’s record to reflect their gender of identification and documented the change to ensure it wasn’t reversed by some well-meaning future employee. But this always left me with the feeling that this wasn’t enough.
For many non-profits in the Portland area, their very missions depended on knowing the detailed gender identities of their constituents, representing gender on a spectrum rather than as a binary outcome. Most of my colleagues in this situation were forced to create custom tables to track this information - not impossible, but clunky and confusing for users who expect to find this information in one area of a record and instead have to find it buried elsewhere.
In fundraising and in business, knowing your donors and customers is key. Not just knowing their names, where they live and how they spend their money (although for many nonprofits and businesses, even that is apparently difficult to do), but their interests and important life details. This isn’t just due to the advent of big data - imagine a savvy shopkeeper in a small town, remembering your social network and knowing you’ll need the perfect shoes for an upcoming wedding that’s sure to be the social event of the season. This type of commerce is as old as commerce itself, we just have different ways of capturing this information now. So it’s surprising to me that in predictive modeling and analytics in general, something so personally important as gender is still stored near-exclusively as a binary variable.
I’m not an expert on gender issues. But I think I’m right when I say you wouldn’t want to try to sell a transgender woman a GQ subscription because your database still said she was male. Just as importantly, you wouldn’t want to try to sell her tampons. Browsing data should be able to tell us this to some extent, but we should also let our constituents/customers tell us this themselves on sign-up forms if they’re willing. And for individuals who don’t identify strictly as male or female, we should spare them the discomfort every time they have to decide between “male” “female” and “prefer not to answer”.
Culturally we’re getting better (in small pockets, but getting better) at ending gender assumptions. So why are we stuck in the past when it comes to our data architecture?
UPDATE: I don’t know the exact answer to this, and I think a meeting of minds is in order. I suppose my vote (for now) would be to continue viewing gender as a categorical variable but with more options than Male/Female/Other. I would propose including Transgender Male, Transgender Female, and Intersex. I know that’s not comprehensive, but I think it’s a step in the right direction.
Of course, transitioning to this kind of thinking will have growing pains - most customers don’t think twice about providing their gender on a form for a business, but would a transgender man appreciate the inclusivity of options or rather think to himself “what on earth are they going to do with this information?” Again, I’m not an expert. I just know we can, and need to, do better.
What do you think?