We're looking into revamping our community ranking structure and am curious if any one has any tips, best practices, etc.. to share around how their community ranking is setup? I'm particularly interested in systems outside of the standard ladder structure, which offers multiple paths to success for the various community user types.
I stumbled upon what I thought was a great public facing FAQ on the AT&T community a couple months back that I had bookmarked and wanted to reference but looks like it is no more following their redesign (which looks great by the way).
Any and all feedback is appreciated.
Solved! Go to Solution.
Creating a rank structure which recognises the wide variety of member behaviours can be a challenge… particularly as a rank structure by its nature is – unlike badges - a singular path the member will travel during their time registered in the community.
This challenge has become more present as many communities who in the past focused on support, now see the value in recognising a range of valuable contributions to the community which are not dependent upon the support objectives they once had.
One way to address this is to take the approach to recognise all the possible behaviours within the formula, and by assigning a value to each of those behaviours. For example as a quality marker on members contributions you might recognise kudos given, received and accepted solutions but these do not all hold the same value to your business and community, so you could say a kudo given = 1, a kudo received is *2, and accepted solution *10.
You would then decide what total value each rank should require. This approach to the quality portion of the formula would allow you to measure all behaviours without an explicit requirement for them all, and as such ensure a situation where for example one user who holds a lot of solutions but no kudos (or via versa) is still being appropriately recognised for their contribution to the community, based on the values you defined and not held back.
You can also take this approach to the contribution portion of the rank structure, for example rather than recognising posts, you could recognise blog articles, TKB, ideas etc. all with their appropriate assigned value.
I hope that helps but let me know if you have any questions.
Absolutely agree w/ Lisa.
As Autodesk is a large well established community thinking through any modification of Rank Structure is critical, glad to see you reaching out for best practices.
As far as how to go about it? I'll list a few things we go over in much detail during our Gamification workshops w/ clients here and look for the community to chime in.
Apologies for the late reply but thank you very much everyone for the info!
@LisaB the point system that you described is an extremely interesting approach which would simplify the different user typed tiers (explore, participate, contribute) that I've already mapped out. From an implementation standpoint however, I'm struggling to see how the point values can be mapped into the actual rank formulas. Are you able to provide an example of what this could look like on the platform?
To be clear, although I often refer to them as ‘points’ they’re technically not points, they are in fact a value of, for example each behaviour has a value, which may have a multiplier of X which then contributes to a total value of Y.
Here is a sample formula…
(logins >10) && (registrationAge >= 129600) && (((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments) + (net_idea_threads*5) + (net_idea_comments)) >=100) && (((net_kudos_events_given) + (net_kudos_events_received*2) + (net_accepted_solutions*10) + (tagging_tag_count)) >=20)
Login & registration are both required, in addition…
A combination of threads, replies, blog articles, comments, idea threads & comments are also all required but as a combination, as such the member could potentially only ever post replies and never post in a blog or idea exchange. As long as the total value equals 100 or more they will achieve this required behaviour value. The value is based on the community relevant assigned value, for example in this case it was determined a member posting a reply held more value than posting an initial thread, and as such a reply has a multiplier value of 2.
The above provides a good outline of the multiplier values we often see; however these values can be determined to your own chosen values within your formula. I would caution any unusual extremes in these values, consider carefully why you’re giving the value, and what its impact would be to the rank structure and member’s progression, for example in a strictly support oriented community giving higher value to replies makes sense, but when this is not the case it could unfairly fail to acknowledge valuable conversation starting content within the community, in which case you might prefer to have all threads & replies hold the same value. This however would not apply with blogs, where the initial article creation would rightly hold more value than any subsequent comment.
The same principle applies for the next requirement, kudos (given/ received), accepted solutions and tags.
Note: where there is no assigned multiplier the value is = 1
Hi can someone send me the document where all these ranking structure rules are explained?
For example: what is the difference between && and II ?
Thanks a lot!
these links might help you to answer a few questions:
Explanation of Formula components: http://community.lithium.com/t5/Rankings/Create-a-ranking-formula/ta-p/108837
Explanation of the Ranking System incl. Documentatnion: http://community.lithium.com/t5/Rankings/Default-ranks-provided-for-new-communities/ta-p/227059?atta...
To specifically address your question, && is a Boolean And, while || is a Boolean Or. You can access very good inline help if you click the question mark to the right of the text "Ranking Formula" just before the formula entry box. That will bring up information on the Operators, Function Description, and Variables. Here is a partial screen capture of the information that is available.