When you think of a CMS, understandably, you think of content. In Brightspot, we treat each asset and each piece of content as a unique object — meaning that each one can have a unique title, a unique URL, unique SEO properties, and so on.
For sites where login and authentication are part of the business model—meaning a site visitor registers to become a user of the site — Brightspot also treats those users has objects. There are plenty of reasons why customers using Brightspot to publish content might want to allow site visitors to become users, here are just a few:
- For media publishers, a site visitor may be required to register as a user in order to gain access to premium content and features.
- For corporate publishers, a site visitor may be required to register in order to use commenting features (i.e., if I personally identify myself, I am much more likely to be pleasant in my exchanges in the comments section).
- For intranet publishers, site visitors are going to be employees—and they’ll likely need to pass through additional registration and authentication gates in order to access content and other features.
So, when it comes to Brightspot, what information is stored in the CMS—and why?
Let’s Start With the Basics
It’s worth noting that Brightspot never handles PII—personally identifiable information—that might identify a single individual. Our object records of users generally include:
- Email Address
- User Status
- Registration Date
- Last Login Date
Basically: The information available in Brightspot is only the data that Brightspot ever needs to touch. For example, Brightspot may need to pass username and avatar on to the front end user profile; registration date and last login date are often needed in order to calculate triggers on content (how long since you last looked at X page). User status lets the CMS admin determine if a user is verified, or approved to use the site, or blocked for misuse.
For users who have registered as users on a Brightspot site via a social authentication method such as Google, Facebook, or Twitter, similar details are also displayed. All this information in Brightspot is read only, so it can be viewed by an Admin, but can only be changed or updated by a user via their profile on the front end of the site.
Brightspot also offers a “Force Password Reset” option from the CMS on individual users. This can be helpful if you have a frustrated site user who cannot access a Forgot Password flow — think of it as a handy, built-in exit strategy.
Treating Users as Content
Because Brightspot treats all assets as content, the same powerful search features that are available on content are also available on users.
For example, CMS admins can search for specific users based on username, as well as narrow by user status. Using search, CMS admins can run reports on active users based on last login date, number of new users based on registration date.
Last but not least, CMS admins can use the many Brightspot widgets to manage users as content. Recent Activity filtered to Users lets CMS admins see how many users have registered recently; Workstreams can be set up to facilitate the user approval process.
And Then, There’s Third-Party Data
That’s the default set of information that is stored on a single user in Brightspot. When it comes to implementations of Brightspot, there are many variations and unique business requirements that can be added and appended to this data.
Here’s a few examples of ways we have seen our customers extend the user object to meet their needs:
- A “Community” area that includes a user's comments, favorites, and followed topics
- A “Subscriptions” area that includes a user’s access to content—including purchased content and yearly subscriptions (in this case, this data is passed back into Brightspot from a third-party payments processor)
- A “Mailing” area that includes a user’s contact information for receipt of physical copies of magazines
The possibilities are limitless.