A Brief Primer on Database Schemas for Digital Communities
There are plenty of articles out there about the marketing and engagement side of standing up a new community online. You can get tons of advice about choosing the right platform, the right name, the right structure, the right advertising mix, or the right brand identity. You can find hundreds of posts about engagement strategies, event ideas, and member recognition programs. While those are all important considerations for the success of most community programs, this is not one of those articles.
Today, I'm going to assume the position of the old wise woman at the top of the mountain and share with you my hard-won wisdom on a concept called the "universal ID" or "unique ID" - and why you should understand them before you implement a new community platform.
Now, before the data nerds call me out - there are a variety of different usages of the terms universal ID, unique ID, universally unique identifier, and globally unique identifier. Some are used in marketing - particularly for ad-tracking - and some are used for identifying individual assets, like documents. For the sake of this primer, let's assume we're talking about individual account identifiers that allow interconnected systems to authenticate and give the user appropriate access to various systems within an ecosystem, i.e. single sign-on.
But first...
Okay, moving on.
When you create anything that will ingest data - say, a member registration form - that data has to live somewhere: a database (a structured arrangement of multiple datasets). And, when creating a new database, it's important to think about how you will structure that data. That structure is called a "schema." There are quite a few different database types out there, but for our purposes, we will use a relational database. Relational databases are represented by the data structure that you are likely most familiar with (think: rows and columns, like a spreadsheet). In a relational database, the unique identifier is the column that represents the dataset that all the other datasets are aligned to. An easy way to visualize this is to check out Airtable, where the unique identifier is called the Primary Field. In this example, the Primary Field or unique identifier (UID) is the email address:
As humans, we typically assign a person's name as their unique identifier in our brains. But, we also assign other characteristics or data points (e.g. distinguishing physical characteristics, such as facial features, height, weight, hair color, eye color, etc.) to that person so that we can distinguish them from someone else who might share the same name. We can also assign contextual data to that person's record in our minds, such as location or time, to help us further make the distinction. (This is also why it's so jarring to see a work colleague in a non-work setting or to run into a former college roommate twenty years post-grad.)
Without these additional datapoints, it would be impossible for a computer to distinguish multiple records for users who share the same first and last names. Look at lines 2 and 3 in the example above. Without the email addresses, we couldn't tell those two Sam Winchesters apart.
How does this impact the community?
Just about everything we do in the community depends on our ability to accurately authenticate a user; to give them access to the appropriate functions, spaces, and information; and to assign activities (like comments, likes, or posts) and achievements (like badges and ranks) to the appropriate individual. So, despite the fact that infrastructure and data management are the less shiny parts of managing a digital community, some level of understanding is required to effectively advocate for the right schema for managing your members' data.
As in the example above, many of the folks who are saddled with setting up a company's original account management schema choose to assign email addresses as the UID. This does technically solve the problem of differentiating between individuals who share the same name - after all, an email address is a unique identifier.
I thought you said not to use email addresses...
This solution works fine for other parts of the business because when a customer contact, for example, leaves their employer, they should no longer have access to that company's private data. From a simplicity and security perspective, this is an easy solution. However, this creates a new problem for the community manager.
In community, we don't think about members solely as representatives of their companies. Our focus is on the individuals, their personal and professional goals, and our relationships with them - built over time, based on trust and mutual investment in each others' success. This means that when the community member leaves their organization (and loses access to their work email account), we have a responsibility to preserve any achievements, contributions, and history that a user has earned or created in their time in the community. But, if the member loses access to their account in the process, there is rarely a clean or user-friendly way to preserve those accomplishments and the member is often left with either an ugly workaround or a depressingly clean slate.
That's a pretty discouraging barrier to their continued participation in the community. We've now set fire to that long-built bridge in spectacular fashion. There's nothing stopping that member from going to your competitor's community, where maybe they can build a career without the risk of losing progress every time they change jobs.
Yikes.
Indeed.
So, now what?
Tackle this problem as soon as possible - ideally before you launch your new community platform and start building your member database. As a part of your launch requirements, you'll need to consider how you'll tie into existing customer-facing systems, like support portals, partner portals, product user accounts, LMSs, and any other gated resources.
If your company already has a fairly robust user ecosystem, it is worthwhile to have a conversation with the owner of the IAM solution in your company to discover what the current UID configuration looks like. Then, you'll start the difficult work of convincing them to change the UID from what is inevitably email addresses to a more generic sequence of numbers and letters. This will allow users to move freely through their careers, owning management of their own email addresses in their user accounts, knowing your company has their back and is rooting for them to keep accelerating, and never worrying about losing their hard-earned progress due to one bad data decision.