One thing I sometimes see is using a given Liferay feature the wrong way in order to do something.

Take delivering content to the right users. Liferay actually has a bunch of ways to accomplish this kind of thing.

First we have taxonomy. Using vocabularies, categories and tags, you can apply taxonomy to your assets and then, through an asset publisher or search filter, for example, you can limit results to match a taxonomy. Through the use of taxonomy, you can target a given group of assets and present them in a focused way.

Next we have permissions. Using permissions and roles, you can apply view rights to assets and the portal will enforce that the current user has the necessary rights in order to view the assets. Using permissions and roles, you can prevent or allow users to view assets.

We also have User Segmentation (AKA Audience Targeting). Segmentation is a souped up way to select the best content to show to a specific user, typically in order to put something in front of them that they will be more likely to interact with.

Since these three things can all show content to specific users and hide content from others, it can often be tempting to use one technique all the time, even though there is no single solution that is best for all use cases.

So let's do a deep dive into these options and identify the use cases that each are designed to solve.

Permissions

Permissions are probably the easiest to understand, but I also feel like it is the most abused.

Each asset has the Permissions configuration panel available and you can choose the roles that are given the View permission:

Given that a user must have one of the roles to be able to view the asset, this often becomes the "go to" method to hide content from users.

For example, say you are a college admin and you want students that live in Dorm A to see a message about a bathroom in Dorm A being out of order. It is easy to fall into a trap thinking that Dorm A should be a role, the bathroom article should be permissioned such that the Dorm A role can view the article, and that students that reside in the dorm will somehow be given the Dorm A role.

The problem with this approach is that the bathroom article should not be restricted to Dorm A residents. A student from Dorm B might be going to visit a friend in Dorm A and might like to know they should use a bathroom before going to visit. A parent of a student in Dorm A might want to track the closure and know when it is open again. A grad student doing a research project analyzing the university's facilities team response times might need access to this and other dorms reports for data.

There's nothing privileged about the bathroom article, but there is the understanding that Dorm A residents are the ones most likely to want to get this message.

Or consider a course syllabus; it can be easy to think the only folks that need access are students that are enrolled in the course. But a student who has taken the course in the past may want to review the syllabus to remember what was covered. A potential student might want to review the syllabus to see if it is a class they want to attend. A parent might want to review the syllabus for the class their child is taking. A person from outside of the university might be reviewing the course catalog to see if it has the major or specialization degree.

Again, there is nothing privileged about the syllabus. Students taking the course are most likely to be interested in it, but that doesn't mean it should be restricted from other types of users.

A permissions-based view control is appropriate when a set of users should be restricted from seeing an asset, when access is strictly controlled to an approved set of users. Roles and permissions are that strict, determining a simple yes/no response to the question, "can I see this asset".

If the rules for view access are not that black and white, then I would argue that a permissions-based view policy is not the right fit for managing view access.

With respect to search, search results will typically never include assets the searcher does not have view permission for. This can be an important factor when considering permission-based view control as it prevents all access to an asset, either directly or indirectly from search or related assets or asset publishers, etc.

User Segmentation

User Segmentation, previously called Audience Targeting, is usually not used in a yes/no sort of choice, typically it is choosing the best from a set of assets. User Segmentation and Personalization is a core feature of Liferay 7.2+ and learning how to create segments is covered in our documentation, and there can be obvious cases where User Segmentation is a perfect solution but may not be the best option every time.

For example, my daughter Susan is graduating from college in May this year.

I recently attended a graduation webinar for parents and found that the different colleges (business, arts, technology, etc) actually have ceremonies at different times during graduation weekend.

So if Susan and other graduates all go to the university's graduation planning page, well this would be a perfect place for User Segmentation.

Since the system would know Susan is logged in and what college she is in, User Segmentation rules can show her the graduation ceremony for the college of technology, while other students from other colleges would show the graduation ceremony for their particular college.

We see the same kind of need for user segmentation often in sales and marketing scenarios, where we want to show an asset that a particular user is more likely to interact with. I'm an Apple FanBoy, so if I'm shown a card on a website for a great new Android game or app, I'm not going to interact with that. But if you show me a card for the iPhone version, I'm more likely to interact with that card.

And that's the goal of segmentation - show the content that most aligns with the user that is more likely to garner some kind of interaction.

Again this is not a see one thing or see nothing kind of option, it is picking the best one from a set to show.

If you have a yes/no sort of view option, then user segmentation may not be the best fit.

In order for User Segmenting to work, the system has to be able to identify what segment the current user is in. So in the examples I covered, the system has to know what college Susan is in or that I have or use an Apple device. If you are trying to define a user segment on something the system doesn't know, then the system will not be able to put users into segments and show targeted content.

Although I have nothing to back this up, I do have an impression that if you have 3 or more user segment display areas set on a page, I feel like this is misusing the targeting aspects. The goal for segmentation is to present the best asset to get the user to interact with it. But doing that 3 or more times on a page? Is it realistic to think a user will interact with all three (or more) of the suggestions? I don't know, but I just feel like that is wishful thinking and will leave the user wondering which one of the options is best and they might end up not interacting with any of them.

With User Segmentation, it is not a goal to not show one of the other options to the user. For example, Susan is graduating from one college, but she has a good friend and roommate graduating from a different college and she may want to attend that ceremony. And while I am an Apple FanBoy, my mother has an Android phone so I may want to find and see the article on the Android app to see if it is something she could use.

So Liferay search, asset publishers, etc. are all free to show all of these things to the user because User Segmentation is not a permissions-based view.

Taxonomy

So I saved Taxonomy for last. Not because it is the best option, but more because I guess I'm not sure that it is seen as a way to share targeted content for users. Categories and tags have been around in Liferay for a long time, their creation is covered in our documentation.

Using Taxonomy correctly can be a powerful way to target content to an interested audience, especially when the system cannot determine how to segment the users.

Take our Dorm A bathroom issue we started with... If we create the bathroom article and then add the "Dorm A" option from the "Residence Hall" category, we have used a simple OOTB Liferay mechanism which opens doors for targeting content.

Now we can drop an asset publisher on the page for Dorm A and configure it to only display articles with the "Dorm A" category. Our bathroom article will appear automagically.

There are no permissions controlling it, so anyone searching for "bathroom" can filter on the Dorm A category and they'll be able to see the article too.

And picture a page with a bunch of checkboxes, one for each "Residence Hall" category. As they are checked, an asset publisher on the same page is updated to include or exclude those results. So even though I'm in Dorm C, I could use this to check "Dorm A" and see what is going on over there before I get there.

The same concept can apply to the syllabus issue. If each syllabus has the correct categories and tags applied, asset publishers and search filters can be used to show relevant articles and exclude irrelevant ones.

With User Segmentation, the system must have enough info to identify a segment for the user. With taxonomy, the system doesn't need this info, it can be left to the user to choose what category or categories are relevant for them. For the college ceremony example, if each notice has the right category, a search can show all or the category filter can exclude ones the user doesn't care to see.

Taxonomies don't really target content, they are primarily used to organize, categorize, and add meta information to assets. The targeting is handled by the asset publisher configurations, search configuration, etc., and the targeting is more in line with filtering out noise than anything else.

Blending Methods

Typically you will not use only one of these techniques.

You'll need to use permissions to have view access control on protected assets. That is what it is.

I always recommend using categories and tags on your assets from day 1 of your journey with Liferay. I can't tell you how many times I've helped clients realize that they could really benefit from having a taxonomy in place for their assets, but they didn't start out doing either categories or tags. It is such a pain to walk back through your assets applying a taxonomy after the fact. Even if you have no immediate plan to take advantage of categories or tags on your assets, as a rule I would suggest you require your content creators apply them anyway. Later on if you need them, they'll be there ready to go.

User segmentation is a great option when you need to choose between multiple assets and you want to present the best one, the one most likely that the user will interact with it. User segmentation does not preclude using permissions and/or taxonomies, so your assets should still have permissions and taxonomies applied.

Conclusion

In closing, I would encourage not trying to see every targeting need as a permission check. Save the permissions for assets whose basic access must be controlled.

Use user segmentation when the system can determine what segment a user falls in and when there is a need to show the best choice from a set of options, best being the one that the user is most likely to want to interact with.

And, whether you leverage them initially or not, apply taxonomy to your assets from day one. The search filters your users can leverage right away, and targeting asset publishers can be added later to facilitate targeted content delivery.