Hmm interesting. A bit odd? Maybe that is just me. Do you feel it is best to pull metrics from the Product board itself in Analytics vs Analytics > Content? Thanks!
I definitely agree that it's not intuitive. The upside is that it is handy to have that extra layer of data.
Most of the time, I think the Analytics -> Content is the right level. I think it aligns better with what we generally try to measure. For posterity, here's how I would frame making the choice between the two
Product Level - If you really want to get a sense of how people are consuming and posting within a specific board, and you want certainty that they're looking at just that content.
Content Level - If your intent is broader, and you want to gauge how content from a particular board is being consumed/interacted with, and you don't mind if it's being viewed at category pages.
... View more
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
One thing I have seen useful in making the case for archival and against deletion is stressing that deletion is final. That content is gone. If a user does ever reach back out asking about that content, it's irretrievable.
With archival, you get the facade of deletion (it's not findable by anyone other than you and your staff), but the safety net of being able to move it back into public view, if needed.
There are some additional pieces of functionality coming to the archival tool that will allow for bulk action based on some of the criteria you've described as well. CC: @RahulHa
... 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
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