This is not user error, but does have an explanation. Admittedly, it's a little obtuse.  I'm probably doing a bit of disservice to the details, but the description that was most effective for me was to think about deeper navigation into Analytics as constantly narrowing your scope. So at Analytics -> Content I'm including category pages (and all lower structural elements - boards, threads). So if a category page contains content from Product Board, it is eligible to increase that page view.  Once I navigate to the Product Board itself in Analytics, I am only seeing views that happened within that board (and lower structural elements, just threads in this case), any category level view of content from Product Board is removed.    ... View more

Hey Becky! I'm 95% certain that the role is only assigned at (or near) the actual moment of new rank attainment. Meaning, any users currently in that rank will not be given that role.  There are a few ways to trick your way into resolving this. My preferred approach is create a duplicate of that rank, but place it only one placement higher in the rank tree. Have it assign the desired role. The downside here is that this will generate rank change notifications. I believe you could work with support to temporarily disable rank change notifications to try and make this seamless. Admittedly, it's tedious.  The other approach I've seen used is the one-time update you mention. You can leverage User Reports to generate a CSV of everyone currently in that rank. You can then use bulk upload to grant all of the users in that rank the new role.  ... View more

@Wendy_S wrote: Tricky question... I am not sure if it would be because you would need a parameter in order to hide something from a banned user. And I think you only have those parameters about a user once they log in.  This is exactly right if the user is banned based off of their username. The way the ban tool works makes this a slightly complicated question to answer.  In short, the ban tool provides you a series of options to base the ban on: User Name, User ID, Email Address, and IP Address. Additionally, the logic of the ban can be controlled with the check box titled "Match any of the above criteria." This allows for a few different scenarios. Imagine scenario #1, I have user who is banned based off of their User Name, IP Address, and Email Address, and I leave the Match Any Criteria box unchecked. The ban will only be in place once the system sees the specified User Name (only happens at login), the IP Address, and the Email Address. We call this an "And" ban. X and Y and Z all need to be true. If any of those items don't match the fields input during the ban, the ban doesn't hold. If User Name and Email Address are inputs in this kind of ban, it can only be assessed after sign in.  Scenario #2, however, could potentially accomplish what you're looking to do. If I have the same inputs in my ban: User Name, IP Address, and Email Address but I do check the "Match Any Criteria" box, the ban is now an "Or" ban. X or Y or Z can be true and the ban holds. In this case, if the IP address is used as an input in the ban, the user is prevented from ever seeing the community at all, much less being able to sign in. The system triggers the ban message immediately upon seeing that IP address.  I'd be remiss without mentioning that Scenario #2 should be used with a lot of caution. An IP based "Or" ban can be really powerful, but can also sometimes catch users you didn't intended to ban. Imagine that you've banned someone accessing the community from their workplace or university, one where they share their IP Address with a large number of people. If you tell the ban logic it can prevent access based solely off of an IP Address, anyone who happens to share that IP Address is also banned. This is usually an edge case, but it's worth being wary of.  ... View more