The appeal of Crazy Blind Date\ is immediately apparent, and seems custom-designed for busy city folks: “on very short notice we can set you up on quick dates with total strangers at public places like bars and coffee shops. You’re not allowed to see their picture or even communicate.” Created by the founders of OkCupid, a more traditional online dating site, CBD is an experiment in using the internet as a tool for organizing offline social interactions, owing as much to Meetup and Mechanical Turk as it does to Match.com. Rather than focus on carefully crafting witty email correspondence, CBD is designed to get you face-to-face with dates as quickly as possible, and then to get data from that very subjective and human experience back into the system.

Users schedule dates in advance and, if a compatible match is found in the right area at the right time, both users are sent a text-message-length profile and blurred photo, and asked if they can meet at a system-specified location in the immediate future. Until that point, backing out of the date is fair play, but once agreed, the users are both bound to show up and stay for at least twenty minutes. After the date, users must rate each other for both compatibility metrics (such as attractiveness and personality) and general datability metrics (such as promptness and politeness). These ratings are used to both improve personal results and to weed out users deemed inappropriate to the emergent community.

OkCupid has employed a user-generated polling system and a thoroughly complex algorithm to match potential suitors since 2004, which has worked well for them. But computation can only be performed on existing data, and users are only willing to answer so many poll questions. CBD is an experiment to see if injecting lots of data directly relevant to the compatibility and datability of other users into the system can improve results and produce better matches. From a software perspective, it’s a brute-force attack on the dating problem. From a user perspective, it’s a computer-optimized version of speed dating. And from a social perspective, it’s an attempt to compartmentalize the dating process and optimize it toward the strengths of either humans or computers.

personal identity is handled by the software

Personal identity on CBD is fairly limited from a user perspective. Instead of the typical online dating site, which presents an array of profiles to browse, CBD shows the user nothing about potential suitors before, during, or after the signup process. That notion of a profile, that hallmark of dating and social networking sites, isn’t even apparent at first. One is, in fact, being created behind the scenes, as users fill out the dating survey required at sign-up. (OkCupid users get a much shorter survey, with a lot of data being pulled from their existing profile.) Unlike other profiles, though, this one is not primarily for other users, but for the CBD software to run against its date-matching protocols. This makes a huge difference, both in the questions being asked and in the responses given. danah boyd talks about an entire generation which is learning to “write themselves into being” by constantly creating and re-creating online profiles, and this type of linguistic identity construction is critical to presenting oneself online. CBD replaces the traditional audience of one’s peers (and, on a dating site, potential lovers) with the software itself, diminishing the impulse to craft a perfect self image.

This anonymity among users is absolute on the website; using CBD requires relinquishing the choice of potential dates into the hands of the system in a demonstration of fatalistic trust in the algorithm. (Users can review profiles and photos of people they have already gone on dates with.) But because we’re talking about romance and sex and not job interviews, there needs to be some emotional hook to actually convince users to drop what they’re doing a go to meet their dates. (CBD seems designed for users to over-book their dates, since many scheduled times and locations will not line up with potential dates, and they are given the option to turn down a date just before it would happen.) As the first point of contact between users, the date invitation is both the emotional hook and the only subjective information about potential dates a user will see before meeting them. During sign-up, users are allowed a few sentences to provide to potential dates, which are mostly designed to get over the initial hump of meeting someone new: ways to spot them in the crowd, a few topics for potential conversation, and why they’re using CBD. This profile data is augmented by a single line at the time of scheduling, and sent along with the date invitation when all of the quantified data has aligned in the system. Then, if both users agree to meet, as described above, the whole process goes offline.

Until the point of a date, users are anonymous to each other, and identity is treated as irrelevant except as answers to a series of survey questions used in the matching process, under the assumption that software is the best way to handle the rough-grain sifting. The moment right before a date, minimal identity between two users is established in order to aid in coordination and test for any obviously erroneous matches. And then the software leaves the fine-grain sorting to the users, wherein personal identity is firmly established.

Up until this point, CBD would seemingly be placing users into a non-iterative prisoner’s dilemma, wherein defecting would be the natural course of action. In this scenario, defecting might mean arranging the date and then not showing up. While there might be reason not to defect – if the date were attractive, for instance – that would imply multiple iterations, as the users would both have to cooperate to meet in the first place, and then decide to do so again based on physical attractiveness. So the system needs a way to guarantee that users do not defect initially, and ideally to weed out users who frequently defect even upon iteration. The CBD solution is to take the relational identity established during the date and feed it back into the system.

relational identity is outsourced to the humans

CBD treats the actual date itself as a black box of data: it knows what went in and what came out, but doesn’t pretend to know what goes on inside. From a user perspective, of course, the priorities are just the opposite: we care less about the input and output and a heck of a lot about what happens on the date itself, whether that’s sharing a soda with two straws or a quickie in the janitor’s closet. Regardless of where the date falls along that spectrum, each person will emerge with some sense of who the other is and how well they were suited to each other. This is the data that CBD wants when the date is over, and the information that is usually left out of online dating sites: relational identity.

We spend most of any first encounter forming an internal model of the other person by testing and refining our assumptions about them. On a first date this is especially true because of the unfamiliarity and the fact that both people know it’s a test for compatibility. The vague and blurry picture we get from the date makes up part of that person’s relational identity, their identity as defined by how other’s view them. And a relational identity formed on a first date is immediately applied to determine how the date ends and whether there will be another. If CBD can extract a relational identity from each user after every date, they can optimize matches for good first dates.

So, after the date is completed, both users are required to answer some questions about it before they can go on another date. The questions are engineered to suss out the important parts from the black box of the date, including how compatible the users are (from a physical and a personality perspective), as well as how good a date both were in general (ie, were they on time and friendly, or would you tell a friend not to date them?). These are quantified questions, answered with numerical ratings and booleans, to describe the fuzzy social situation which happened inside that black box in a way that the software can use.

These two types of data are used in different ways: the more subjective information on how well matched the users were is used to help refine matches for those two users, and perhaps tweak the overall algorithm. CBD is attempting to aggregate relational identity about each user from each first date in order to better match them. The initial profile is needed to seed initial data, but as a user goes on more dates, I would expect that the data reported back from those dates becomes more important in the matching algorithm. Other users, after all, are who the software is trying to match the user in question with, and the aggregate relational identity of many dates must provide a decent profile against which to match other profiles.

The more objective information gathered after a date, which addresses general datability, is used to create the iterative prisoner’s dilemma in an otherwise mostly anonymous system. Users are held responsible for their actions under threat of the system, not for fear of retribution by any individual user. This elegant design allows the community standards to arise from the users, and yet also checks for abuses to the system such as lying about intentions toward sex on the first date.

real-time dating, now in your town!

CBD seems to be glancing in the direction of constant, real-time matching. Because the system is designed to use rapid face-to-face communication as a brute force attack on the relational identity matching problem of online dating, it works best when many people go on many dates. By removing the scheduling component (except, perhaps, always-off times), CBD might increase both the number of dates as well as the sense of spontaneity, but also improve the accuracy of the algorithm. Some sort of Dodgeball-esque location awareness would need to be incorporated to manage potential matches, but might be incorporated into the matching itself: “Do you want to go on a date in SoHo in 20 mins?” “No, I’m in Brooklyn today.” “Okay, we’ll text you if we find a match in Brooklyn today.” This would surely scare off the more timid users and those new to the site, and should likely be an option rather than subsume the entire service for that reason. But this always-on dating is clearly where the industry is headed, poised on the brink with many other mobile social software applications, and suggested by some of the existing affordances of nouveau-dating website like CBD and iminlikewithyou.

Conclusion

In segmenting the problem of matching potential dates in order to optimize the components toward what computers and humans are each good at, Crazy Blind Date creates what, on the surface, appears to be a non-iterative prisoner’s dilemma. By keeping users anonymous and providing no user-visible infrastructure for post-date interactions, users would seemingly be able to break the trust of the system and other users at any point. But by requiring feedback on every date, the system constructs a more cleancut case of iteration than most social software to date. Iterations are aggregated across every other user whom one goes on dates with, with the result being an increasingly accurate representational identity for each user becoming established within the system. Therefore, if the feedback questions are well constructed, matches should improve greatly over time with the increasing frequency of dates, as the system is designed to mimic the natural vetting of social situations. It’s an elegant approach on the back end that just requires a lot of data on each user to work well. As the rest of the social processes seem optimized to produce that data, the only thing left would be to increase the available data, and, therefore, to send a lot of people on a lot of dates.