About Aurora badge rules and supported criteria
For each community badge you want to create, you must define the rule that determines how a member achieves or receives the badge. For simpler rules, you can use the built-in tool that enables you to select a criterion and additional qualifiers. However, if you want a more complex rule for a badge, you can use the Advanced Editor to enter badge formulas. Badge formulas include a combination of a formula clause type, a keyword, an operator, and a value. When the calculation of a value in a formula returns a true result, the member achieves the badge. The badge achievement is then reflected in their profile and badges page. To create more complex badge rule expressions that require multiple rules be met before awarding a badge, you can use the “AND” operator. Common use cases for badges with multiple rule criteria include profile completion tasks and more complex engagement options. For example, you may want to award a “VIP Contributor” badge to members who: Have received at least 100 likes Have had at least 25 answers marked as Accepted Solutions Have posted at least 10 blog articles Tip: You can also use community roles as an additional requirement for any badges based on activity. By taking advantage of the “unlocking” game dynamic, you can set certain badges to be earnable only after a community member has reached a rank that grants them the required role. Create a complex badge rule Go to Settings > Users > Badges. To add a rule to a badge in an existing badge set, click the name of the badge set that contains the desired badge and then click Add Badge. Otherwise, create a new badge set where you want the badge with complex rules to live (see Create badge sets and badges). After entering the badge Name, Description, and Icon, in the Criteria drop-down menu, select Advanced Editor. In the Advanced Editor field, enter your custom badge rules. Enter each rule you want met (making sure that each rule has an identifier, operator, and value). Enter AND between each rule. Select the Hide from member profile until earned checkbox to ensure that the badge is displayed on member profiles only when the rules are met. Click Add Badge. Let’s say you want to create a badge for new members to encourage them to begin participating in the community. You might create a rule like this: metric.net_overall_threads >= 5 AND metric.net_kudos_weight_received >= 20 AND metric.net_accepted_solutions >= 3 This complex rule may be great for a badge that rewards users for creating new content with great quality. Feel free to use this example for your own community! Note: You cannot create complex rules with OR or NOT. Supported badge clauses and badge criteria A badge formula can include one of five types of clauses depending on the type of behavior you want to reward. You can chain rules together to create complex criteria using these clause types: Metric: Assigns a badge based on the value of a specific community activity recorded for each member. Member in role: Assigns a badge to a set of members based on community-level roles. User ID in set: Assigns a badge to a manually specified set of members based on their numeric user ID. This should be reserved for awarding rare badges to a small group of members. Non-Default profile setting value: Assigns badges based on members changing the default state of a specific setting or profile field on their member profiles. Specific profile setting value: Assigns badges based on the member changing a setting in their profile to a specific value. (For example, you could award a badge when a member sets their profile language to French.) Clause Type Clause Format (variables in bold) Metric metric.name_of_metric >= number Example: metric.net_accepted_solutions >= 1 Roles user.role.name in ['role'] Example: user.role.name in ['Administrator', 'Khoros'] User ID user.id in [id] Example: user.id in [10, 2, 5] Non-default profile setting setting.setting_key != 'default' Example: setting.profile.location != 'default' Profile setting value setting.setting_key = '[value]' Example: setting.profile.location = 'Argentina' Rewarding user activity using metrics For definitions of exactly what these metrics are, refer to these Aurora Analytics Metrics Definitions. The following member activity metrics are supported for use in a badge formula using the format: metric.name_of_metric >= [number] Accepted Solutions metric.net_accepted_solutions All Content Types metric.net_overall_posts metric.net_overall_replies metric.net_overall_threads Blogs metric.net_blog_articles metric.net_blog_comments metric.net_blog_posts Forums metric.net_posts metric.net_threads metric.net_replies Ideas metric.net_idea_threads metric.net_idea_comments metric.net_idea_posts Images and video metric.image_upload_count metric.video_upload_complete_count Likes metric.net_kudos_weight_given metric.net_kudos_weight_received Message views metric.message_views Sign-ins metric.logins KBs metric.net_published_tkb_articles metric.net_tkb_comments Rewarding specific members You can award badges to a specific group of members based on their role or user ID. Since you can’t edit a rule after you create the badge, we recommend using roles as the basis of your rule criteria. That way, if you need to add or remove members later, you can modify the member list for the role independent of the badge rule criteria. Important: If you want members to be notified (via email or real-time notifications) of a role-based badge, you must roll out the badge first and then add the role for that member. If the member already has the role before the badge is published, the member will not be notified. Keep in mind: Newly created badges are automatically applied to all members who already match the criteria, resulting in email notifications being sent out to community members depending on your badge notification settings. You need to coordinate such badge releases with Khoros to avoid a surge of emails being sent out to the community members, which can impact your community performance. Use single quotes around the role name. Use commas if you enter more than one. For example, to award a badge to all members with the “Admin” or “Moderator” role, enter this rule criterion: user.role.name in [‘Admin’, ‘Moderator’] You should use "user ID in set" in badge criteria only if you have a static, unchanging list of specific members. This clause type should be used only in special cases to award badges for one-time achievements. Otherwise, you’ll need to delete and recreate the badge each time you want to add another member’s user ID to the rule. Use commas if you enter more than one. For this case, use this format: user.id in [10,2,5] Rewarding profile completion You can use the profile setting below to create badges that reward members for filling out more information about themselves in their profile. These settings can all be used with the "Non-default profile settings" clause. Profile setting identifier Setting name Setting location setting.profile.name_first First Name My Settings > Personal setting.profile.name_last Last Name My Settings > Personal setting.profile.location Location My Settings > Personal setting.profile.biography Bio My Settings > Personal > Bio setting.profile.url_homepage Personal Site My Settings > Personal avatar_changed Note: To award a badge when a member changes their default avatar image, use this syntax: avatar_changed = true Avatar My Settings > Personal > Edit Rewarding date-based activity You can award badges based on date-based activities. Setting identifier Setting options Examples consecutive sign-ins number setting.user.max_consecutive_logins >= 2 registration_date date registration_date > "2015-01-01" (see supported syntax options below) time_since_registration time value in days, months, or years time_since_registration >= "1 years" signin_date date signin_date > "2015-01-01" (see supported syntax options below) About sign-in related activity We store a counter of the number of days in a row and the last sign-in time. When someone signs in, we get the date of the last increment and the date of today, and we count the days between. If < 1, we ignore it (so no gaming the system). If == 1, we increment the day counter. If > 1, we set the day counter to 0. About entering dates You can enter dates (which must be in quotes) in all formats supported by ISO 8061: Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) where: YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm) Note: When an ISO 8601 date doesn't specify a time zone, it is considered to represent local time. We do not override the local time zone for this purpose, so the date is parsed from the badge clause based on the server's local time zone. So that will differ depending on the AWS region: US-West-2 (PST) EU-West-1 (CET) To prevent confusion on the Internet, date strings (for example, in badge clauses) may specify a time zone. Related topics: About Badges and Badge sets Create badge sets and badges Feature badge sets on the member profile Delete badge sets and badges Example badge sets and badges View badges from the member profileAurora: Enable read-only mode for community places
From time to time, you may need to lock down areas of your community for standard maintenance or updates. Or, you may want to temporarily restrict people from creating new content in specific categories, boards, or the entire community. By putting community places in read-only mode, you can enable members access to still view community content but restrict them on making any changes to this content. You can enable read-only mode at the community, category, or board level to restrict members from posting new content or editing existing content. Read-only mode does not apply to admins and moderators; they can perform their respective actions as normal. Read-only mode is commonly used for these reasons: Community:Standard site maintenance where site activity could interfere with the site updates or when a community is under a security threat. Category:For categories dedicated to broadcasting information and does not require members to post any content. It can also be used to temporarily or permanently make a category read-only. Board:For boards that are dedicated to broadcasting information and does not require members to post any content. It can also be used to temporarily or permanently make a board read-only In addition to the above scenarios, admins and moderators can enable read-only mode on a case-by-case basis based on their specific needs. Note: We recommend this setting only for specific cases as it highly impacts the member site engagement. You should also let your members know why a community place has been temporarily placed in read-only mode. What to expect in read-only mode In read-only mode, members can: View, like, or report inappropriate content Tag their own content (When set at places below community level) Send private messages to other members In read-only mode, members cannot: Create new content Edit or delete existing content Add comments or replies to content Tag others’ content Move content to another location (When set at community level) Send private messages to other members Note: Members are blocked from performing the above actions even if they have appropriate permissions. Enable read-only mode at the community level Open the Account menu and go to Settings > Content Features. In the General section, toggle on the Read-only mode option. Configure read-only mode at the category, group, or board level When read-only mode is enabled at community level, it is inherited at the category, group, and board levels. You can override the setting at lower levels as needed. Let’s look at an example where read-only mode is turned off at the community level and you want to enable it in a specific category. To enable read-only mode for a specific category: Open the Account menu and go to Settings > Community Structure. In theCommunity Structure, click the category where you want to enable read-only mode. Below Content Features, toggle on the Read-only mode option. Similarly, you can configure read-only mode at group and board levels.Aurora: Escalate discussions to Salesforce
Forum discussions can be escalated either manually or automatically You can also escalate replies to forum discussions. Members with the View escalations permission can see the details about the escalation. Manually escalate forum discussions to Salesforce Members with either the Escalate a discussion to the CRM systemand the Escalate one's own discussion to a CRM system permission can escalate discussions to Salesforce. Those with theManage escalation settings and providers permission can also set the Escalate discussions settings for the forum board. To manually escalate a discussion: Open the Options menu for the discussion. Click Escalate to Salesforce. A window opens where you can enter the details for the escalation. Enter the Reason and Comments for the escalation. Click Escalate. You receive confirmation that the discussion has escalated successfully. On the discussion page, you can see that the discussion was escalated along with details on who escalated it and when. Escalate discussion replies Members with either the Escalate a discussion to the CRM system or the Escalate one's own discussion to a CRM system permission can escalate discussions to Salesforce. Automatically escalate discussions to Salesforce You may want to automatically escalate discussions or replies within your community. This urgency could be due to issues raised by members with elevated roles or the need to promptly address and resolve cases within the community. To address this, you can designate a board specifically for discussions and/or their replies to be escalated automatically. You can also set a waiting period for a response (either a reply or a solution), after which the discussion is escalated automatically. Let’s understand these settings: Scenario 1: If you want to automatically escalate a discussion based on the author’s role, set the Automatic escalation by role settings as shown below. In certain cases, you may not want to regulate escalations from specific members within the community. For instance, admins and moderators might post discussions solely for informational purposes rather than issues or cases requiring escalation. Follow the steps below to implement this control: Click Edit next to the Automatic escalation by role setting. A window where you can set the roles opens. You can do one of the following: Select Exclude escalation of posts from the roles below. In the following example, the roles Administrator and Moderator are selected. This ensures that discussions authored by members with these roles are not automatically escalated. Select Only escalate the posts from the roles below. In the following example, a “CategoryExpert” role is selected. This ensures that only those discussions authored by members with these roles are automatically escalated. Click Save. Scenario 2: To prevent discussions from remaining unattended for extended periods and potentially leading to unresolved issues, you can turn on the Automatic escalations for unanswered discussions option. Configure the Wait time before escalating unanswered discussions settings to ensure timely escalation. Click Edit to set the time in minutes to wait until the discussion is escalated, and click Save. In the example below, discussions in this board are escalated to Salesforce if they remain unanswered for 2 days. Scenario 3: To prevent discussions from remaining unresolved (Mark as Solution) for extended periods, you can turn on the Automatic escalations for unsolved discussions option. Configure the Wait time before escalating discussions with no solutions settings to ensure timely escalation. Click Edit to set the time in minutes to wait until the discussion is escalated and click Save. In the example below, discussions in this board are escalated to Salesforce if they remain unresolved for 2 days. View escalation details On the discussion page, members with the View Escalations permission can see the details about the escalation. Click View Details to view case details such as case number, when and by whom the discussion was escalated, the status of the case, and the last update date.Aurora: Top Contributors widget configuration
The Top Contributors widget displays a series of contributors with the highest ratings based on popularity metrics including Likes/Votes Received, Posts (Topics and Replies Created), Topics Created, and Solutions Authored. It is available on the Community Home Page, the Category Dashboard, the Group Dashboard, the Forum Dashboard, the Blog Dashboard, the Knowledge Base Dashboard, and the Ideas Dashboard. Layouts The Layouts sectionfeatures theList, Grid, and Cardlayouts. The information that can be displayed for each contributor depends on the Layout and its unique set of available elements. List Grid Card Configuration Options The configuration options available depend on the layout selected. For example, the List layout style has a List Style setting, while the Grid layout includes an Avatar Size option. List Style The List Style is unique to the List layout and determines how items in the list are separated from each other. You can choose to have whitespace (Space) between items, a horizontal line (Divide), or a defined Border that separates items in the list into individual visual blocks. Avatar Size Unique to the Grid layout, the Avatar Size setting changes the size of the avatar images as they appear in the grid. You can choose between a MediumorLarge avatar size. Widget Title The Title appears at the top of the widget. If the Visible Only to Screen Readers toggle is active, the title remains hidden from most visitors; however, the title information is still relayed to visitors using screen readers. Number of Items You can designate the number of contributors featured in the widget using the Number of Items slider (maximum 20). Sort You can sort contributors by several different categories using the Sort By drop-down menu. Available options include: Likes/Votes Received Posts (Topics and Replies Created) Topics Created Solutions Authored Sort By gives you the power to create a widget dedicated to the top solvers in your community and another for members with the most likes on their content. The Time Period defines the length of time popularity metrics are calculated. This enables you to create a widget featuring a single top contributor for the week/month/year, your top five of all time, or any variation in between. List Item/Card Elements The List and Card layouts include elements that can refine the information about each member that appears in the widget. These elements include: Avatar Rank Count Roles to exclude You can exclude specific roles from being displayed in the Top Contributors widget. This is helpful when your administrators or other staff create a large amount of content but you want to highlight only your other members’ contributions to the community. To exclude roles, select the field and then choose the roles you want to exclude. Members assigned to the roles you select are not displayed on the Top Contributors widget. More Options Additional options for the widget appear in the More Options section of the Edit Widget panel: The Hide if Empty option hides the widget in the event that nothing meets the criteria to be displayed (for example, if no contributors have authored any accepted solutions and Solutions Authored is the Sort By criteria). Optimize page-load time uses lazy loading to load images as the member scrolls down the page.About default Aurora community ranks
Aurora communities include a set of pre-defined, default ranks. Review these out-of-the-box ranks and their associated ranking formulas and decide which ones you want to include in your community rank structure. The default ranks we’ve provided have the following names and ranking formulas: Rank Formula Khoros hasRole("Khoros") Community Manager hasRole("Administrator") Moderator hasRole("Moderator") Honored Contributor (registrationAge >= 300000) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (net_kudos_weight_received*4) >= 222500) Esteemed Contributor (registrationAge >= 250000) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 100000) Respected Contributor (registrationAge >= 200000) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 50000) Trusted Contributor (registrationAge >= 175000) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 30000) Valued Contributor (registrationAge >= 150000) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 20000) Super Contributor (registrationAge >= 120000) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 5000) Regular Contributor (registrationAge >= 86400) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 2000) Frequent Contributor (registrationAge >= 43200) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 750) Contributor (registrationAge >= 10080) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 200) Occasional Contributor (registrationAge >= 5670) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >= 50) New Contributor (registrationAge >= 2880) && ((net_threads) + (net_replies*2) + (net_blog_articles*10) + (net_blog_comments*1) + (net_idea_threads*5) + (net_idea_comments) + (net_published_tkb_articles*10) + (net_tkb_comments) + (net_accepted_solutions*15) + (net_kudos_weight_given*2) + (kudos_weight_received*4) >=1) Senior Member (registrationAge >= 43200) && (overall_posts==0) && ((message_views*.25)+(net_kudos_weight_given*2) >= 10000) Established Member (registrationAge >= 43200) && (overall_posts==0) && ((message_views*.25)+(net_kudos_weight_given*2) >= 5000) Regular Visitor (registrationAge >= 43200) && (overall_posts==0) && ((message_views*.25)+(net_kudos_weight_given*2) >= 2500) Frequent Visitor (registrationAge >= 11520) && (overall_posts==0) &&((message_views*.25)+(net_kudos_weight_given*2) >= 500) Visitor (registrationAge >= 11520) && (overall_posts==0) &&((message_views*.25)+(net_kudos_weight_given*2) >= 150) Occasional Visitor ((message_views*.25) && (overall_posts==0) >= 25) New Member (logins >= 1) For each of the provided ranks you intend to use, you should change the name to reflect the personality of your community. For example, if your brand is focused on music, you might want to reflect that theme in your ranks ("Beginner,""Rock Star,""Conductor"). Or, you might want to use more general rank names like"New Member,""Top Contributor,""Expert," or"Esteemed Contributor" that reflect a member’s status, contributions, and influence level in your community. Rename, edit, or delete any of these ranks to meet your specific needs before launching your site. Additionally, you can create new ranks before or after you launch your site. Related topics: About member Ranks and ranking formulas Create a rank Create a ranking formulaAurora Analytics Metric Definitions
This article provides definitions for all the metrics available in Aurora Analytics. Aurora Analytics approximates user behavior and therefore these metrics exclude almost all nonhuman requests (Web crawlers, robots, RSS feeds, REST API calls). About how Community visit metrics are calculated When viewing visits metrics, you might see small variants in the reported numbers. This is expected when you compare visits metric for a period within a month versus a sum of months in that period. The main reasons for these differences include: Overlapping visits across months "Visits" are defined as the number of unique user sessions. A session is defined as a group of interactions one user takes within a given time frame. Sessions time out in the case of 30-minute inactivity. Assume someone browsed through a community during the last hour of a month (Month-1) and continued browsing through the first hour of next month (Month-2). In this scenario: When we measure visits for Month 1, this session is counted as 1 visit. When we measure visits for Month 2, this session is counted as 1 visit. So, when you sum up visits for Month 1 and Month 2, you see 2 total visits, whereas, if you measure visits over the 2-month period, this session is counted as a single visit. Algorithm approximation "Visits" and "visitors" metrics are an approximation algorithm in their calculations. As such, there might be a 1-2% variance in the calculations. Elastic search documentation mentions that sometimes the variance could be up to 6%. Aurora Analytics metrics and definitions Widget/Metrics Definition Page Views A page view is counted each time a browser requests a page regardless of the device type or whether the page is cached. Page Views approximate user behavior and therefore exclude non-human requests (web crawlers, bots, RSS feeds, REST API calls). Page Views (Trend graph) Page Views trend graph is a line graph that shows how the Page Views are trending for the selected time frame. Visits A visit is one or more page views over time by a uniquely identified visitor. A cookie set in the browser identifies visitors (anonymous or registered), so if a visitor has cookies turned off, each page view counts as a new visit. The visit counter increments as soon as the visitor views any community page; the visit ends after 30 minutes of inactivity. After the 30-minute timeout, the next page view counts as a new visit. The Mobile Visits metric is a subset of the Visits metric and includes requests from mobile web browsers only. Unique Visitors The number of unique visitors over the specified time interval. When a visitor (registered or anonymous) views a page, the application looks for a visitor cookie. If no cookie is found, a new cookie is created, and the visitor counts as a new unique visitor. If a visitor cookie is found, the Unique Visitor counter is not incremented. If cookies are cleared after a visit, the next visit sets a new cookie and counts a new unique visitor. Since cookies are browser dependent, so are unique visitors. Users who access the community from different browsers count as a unique visitor. The Mobile Unique Visitors metric is a subset of the Unique Visitors metric and includes visitors who used mobile web browsers only over the specified time interval. Page Views /Visit The average number of Page Views per Visit for the time frame selected. Visits vs. Unique Visitors The trend of the number of visits to the community site against the number of unique visitors for the selected time frame. Visits by User Type The number of visits made by anonymous users and signed-in users. Anonymous users also refer to community members who have not logged in. Learn more about Visits by User Type. Visit Referrals The number of community visits that originated from specific URL domains. This metric helps you understand how much traffic is coming in from different search engines, social networks, or links on your company website. Completed Registrations The number of member registrations completed during the selected time period (excludes partial/abandoned registrations). A registration is considered complete when the visitor finishes the sign-up flow and is given a unique user ID. If the visitor leaves the sign-up flow before being granted their unique user ID, the registration is considered to be abandoned, and the completed registration counter is not incremented. If the community uses Single Sign On (SSO), Khoros increments the completed registration count the first time it receives an authentication token that contains a unique User ID. Partial Registrations The number of user registrations abandoned during the selected time period. Completed and Partial Registrations The line graph shows how the completed and partial registrations are trending over the selected time frame. DAU/MAU DAU (Daily Active Users) is the number of unique members who engage with the community in a one-day window. MAU (Monthly Active Users) is the number of unique members who engage with the community over a month or 30-day window. The ratio of DAU to MAU is the proportion of monthly active members who engage with the community in a single day window. Member Time on Site The Member Time metric indicates the total number of minutes from first page request to last page request for each visit of all registered members in your community during the date range of the report. Member time does not capture the time of actions, such as likes, unless the member requests a new page after the action. Nor does it include the last 30 minutes after the last page request before the session times out. Member time is calculated from the time of the first page request, such that a session that started at 11:50pm on day 1 and ending at 12:15am on day 2 is counted as member time for day 1. New vs. Returning Members New members are members who have never visited the community and are visiting for the first time. Returning members are members who have visited the community before. This line graph shows the trend of new and returning members over the selected time frame. Note that this widget will show data for the last 30 days only, irrespective of the selected date range. Depending on the time range you choose in the dashboard settings, you may get partial data or no data. New vs. Returning Anonymous Users When a user views the community without signing in, the community looks for cookies saved on their device. If there is no cookie present, then the user is treated as a New Anonymous User. If cookies are present, then the user is treated as a Returning Anonymous User. Since members can also view the community without signing in, they are also considered Anonymous. Note that this widget will show data for the last 30 days only, irrespective of the selected date range. Depending on the time range you choose in the dashboard settings, you may get partial data or no data. Forum This widget shows the engagement on the selected Place for the date range selected. Shows the number and trend line of the number of discussions created, number of likes received, number of replies for the time frame and selected Place. Click View Detailsfor further insights. Blog This widget shows the engagement on the selected Blog for the date range selected. Shows the number and trend line of the number of posts created, number of likes received, and the number of comments for the time frame and selected Place. Click View Detailsfor further insights. Knowledge Base This widget shows the engagement on the selected Knowledge Base for the date range selected. Shows the number and trend line of the number of articles created, number of likes received, and the number of comments for the time frame and selected Place. Click View Details for further insights. Places - Follows The total number of followers for the selected Place. Topics - Follows The total number of followers for the selected Content. Observing vs. Participating vs. Contributing This widget shows the engagement between members who are observing, participating and contributing in the community for the place and time frame selected. Observing members are those who have signed into the community and their engagement is limited only to viewing the contents. Participating members are those who reply or like posts in the community. Contributing members are those who create content or provide solutions in the community. Private Messages This widget shows the number of private messages sent, its trend line and the messages per conversation in the community for the time frame selected. Messages sent The number of private messages sent from the inbox by all the community members during the selected time frame. Messages sent (trend graph) The trend line graph showing the number of private messages sent from the inbox by all the community members during the selected time period. Discussions The number of Discussions in the selected Place during the selected time frame. Likes The number of likes received for the Discussions and replies in the selected Place during the selected time frame. Replies The number of replies received for the Discussions in the selected Place during the selected time frame. Engagement Shows the trend line for number of Discussions, likes, and replies in the Place during the selected time period in Forums Details. Shows the trend line for number of Blog posts, likes, and comments in the Place during the selected time period in Blogs Details. Shows the trend line for number of articles, likes, and replies in the Place during the selected time period in Knowledge Base Details. Shows the trend line for number of ideas, votes, and comments in the Place during the selected time period in Ideas Board Details. Time to First Reply The time taken (average) for Discussions in the selected Place to receive its first reply after it has been initially submitted. It is typically measured from the moment the Discussion is published to the moment someone replies to it. First Replies The total number of first comments on all the Discussions in the selected Place during the selected time frame. If for the selected time frame there are 10 Discussions in the selected Place, and only 4 have received a reply, then the total number of first replies is 4. If for the selected time frame there are 10 Discussions in the selected Place and only 1 Discussion has replies, even if that one Discussion has 5 total replies, the First Replies is 1. Marked As Solved The number of Discussion replies that are marked as an accepted solution for the selected Place and for the selected time frame. There is only 1 solution per Discussion. Marked As Solved Trend Shows the trend line for the number of replies that are marked as an accepted solution for the forums in the selected Place and for the selected time frame. Solutions Authored The number of solutions the member provided for a discussion Time to Solution The average time taken for the replies in Discussions for the selected Place to be marked as an accepted solution. It is measured from the moment the Discussion is posted until one of its replies is marked as an accepted solution. Solution Views A count of page views of Discussions with an accepted solution after the Discussion has had a reply marked as an accepted solution. Forum - Follows The total number of followers for the selected Forum during the time frame selected. Discussions - Follows The total number of followers for the Discussions in the selected Place during the time frame selected. New and Trending Discussions The total number of new Discussions and trending Discussions in the Forum selected during the selected time frame. The metric values for Trending Discussions depends on the minimum number of views set in the Engagement dashboard settings. Posts The number of blog posts in the selected Place during the selected time frame. Comments (for Blogs and Ideas) The number of comments the blog posts or Ideas in the selected Place received during the selected time frame. Articles The number of Knowledge Base articles in the selected Place during the selected time frame. Blog - Follows The total number of followers for the Blog in the selected Place during the time frame selected. Posts - Follows The total number of followers for the Blog posts in the selected Place during the time frame selected. Knowledge Base - Follows The total number of followers for the Knowledge Bases in the selected Place during the time frame selected. Article - Follows The total number of followers for the Knowledge Bases articles in the selected Place during the time frame selected. TTFR Time to First Reply TTFS Time to First Solution Helpful Votes The number of votes the Knowledge Base board or article received stating that they were helpful. Unhelpful Votes The number of votes the Knowledge Base board or article received stating that they were unhelpful. Members Joined The number of members who joined the Group. Members Left The number of members who left the Group. Invitations Sent The number of invitations sent to members to join the Group. Invitations Accepted The number of invitations that were accepted by members to join the Group. Ideas Snapshot (widget) This widget contains the metrics related to Ideas Board. The metrics are number of ideas, number of comments received, number of votes received during the selected time period for the Place selected. Ideas (Groups, Events and Members reports) Total number of ideas created during the selected time period for the selected Place. Votes Total number of votes received during the selected time period for the selected Place. Idea Votes (Members report) Total number of votes given by members during the selected time period for the selected Place. Idea Votes Given(Members report) Total number of votes given by members during the selected time period for the selected Place. Idea Votes Received (Members report) Total number of votes given to the member's ideas during the selected time period for the selected Place. Closed Total number of ideas closed during the selected time period for the selected Place. Completed Total number of ideas completed during the selected time period for the selected Place. Events (Groups, Events, and Members reports) The number of events in the selected Place during the selected time frame. RSVP-Attending (Groups, Events and Members reports) The number of members who RSVP'd 'yes' to the events in the selected Place during the selected time frame. RSVP-Interested(Groups, Events, and Members reports) The number of members who RSVP'd 'Interested' to the events in the selected Place during the selected time frame. Attended The number of members who attended the events in the selected Place during the selected time frame. Events Attendance(Members report) The number of members who attended the events in Groups for selected Place during the selected time frame. Events Attended(Members report) The number of events the member attended during the selected time frame. Events by type (widget) This widget shows engagement on events based on the event type (In-person, Online, and Hybrid). Lead-up to the Event (widget) This widget shows metrics on all the activities that occurred on the event before it started. Note: In Classic Analytics, a summation of all posts in the community (root topics and replies across discussion styles) is presented as the 'Posts' metric in the Categories report. However, in Aurora Analytics, the root topics and replies across content types (Forums, KB, Blog, Idea and Events) are presented as specific/independent metrics, instead of adding them together and presenting as 'Posts' metric. Related topics: About Aurora Analytics Dashboard Settings Aurora Analytics ReportsKhoros Communities: Aurora 24.12 Release Notes
This release brings enhancements for both community admins and members! Trusted members can now bypass content filters, spam rejection, and flood control limits, while admins can streamline event invites, manage SSO profiles, and maintain data integrity. Offline mode and role exclusions in Top Contributors offer more control over your community experience. Developers can enjoy a more efficient Branch Switcher with customizable branch availability. We have also fixed several bugs.Aurora: Configure SSO settings for the community
Before you can use SSO with your community, you need to configure settings and enable the option. Note: As soon as you turn on the Use Khoros single sign-on (SSO) option, all the settings in the Single Sign-On area become active in the community. To configure SSO settings and enable SSO: Go to System > Account & Privacy. Scroll down to the Single Sign-On (SSO) section. Manage the following options: Allow member to change their SSO email address:Enable members using SSO to change the email associated with their account. This should be enabled only if the email address is collected on the Community SSO Registration screen. Allow member to change their first name and last name: Enable SSO users to update their first and last names under My Preferences > Personal. Use auto sign-in for fallback SSO:When Khoros SSO token-based sign-in fails, auto sign-in is used instead. Enter the following SSO URLs: Registration page:Direct users to this URL when they register. Sign-in page:Direct members to this URL when they sign in. Sign-out page:Direct members to this URL when they sign out. Bounce URL:(Optional) URL where the first request of a session is redirected. Can help to enable seamless Community authentication or "Bounce SSO". Leave blank to disable. Enter the Return value parameter name. By default, the Aurora Community application appends a query string parameter named referer (spelled as shown) and a value corresponding to the URL of the page the member was browsing prior to being redirected to the login or registration page. If your authentication system is already configured to use a parameter like “referer,” you can change “referer” to the name of that parameter. Otherwise, leave the parameter name as “referer.” Turn on Use Khoros single sign-on (SSO) to make these settings active in the community. URL formats SAML (REDIRECT BINDING) Sign-in URL: <Aurora url>/t5/s/<communityID>/auth/saml/doauth/redirect Sign-out URL: <Aurora url>/t5/s/<communityID>/auth/saml/dologout/redirect SAML (POST BINDING) Sign-in URL: <Aurora url>/t5/s/<communityID>/auth/saml/doauth/post Sign-out URL: <Aurora url>/t5/s/<communityID>/auth/saml/dologout/post OIDC SSO Sign-in URL: <Aurora url>/t5/s/<communityID>/v1/auth/oidcss/sso_login_redirect/provider/<providerID> Sign-out URL: <Aurora url>/t5/s/<communityID>/v1/auth/oidcss/sso_logout_redirect/provider/<providerID> Related topics: About Khoros Aurora Single Sign-On (SSO) Khoros Aurora SSO auto-sign in MultiAuth SSOAurora: Overview of Content Workflow and Approval feature for Knowledge Base articles and Blog posts
To enable people to create high-quality and engaging content quickly, you need a simple process for authors, editors, and publishers to follow. Different people have different responsibilities in the content creation workflow, and it’s important for teams to be able to collaborate on new and existing articles at scale and not get in each other’s way. Granular control over author, editor, and publisher permissions, enables you to clearly define who can perform each task in the publishing workflow. Each blog post or KB article moves through different states, and members can view the latest state of articles and blog posts via Manage Content Dashboard. This flowchart shows how an article moves through the publishing workflow and the tasks members with specific roles can perform. Feature Enablement Admins can enable content workflow in your community. To enable it, goto Account menu > Settings > Features > General and enable Content Workflow. Learn more on how to enable Content workflow in the community. Key features The default roles for content workflow include: BlogAuthor:Can start and edit blog articles BlogEditor:Can edit on articles that are in the Awaiting Review state. BlogEditors can send articles back to the BlogAuthor if there are changes required or can forward the article to the BlogPublisher for publication BlogPublisher:Can approve and publish articles that are in the Awaiting Publicationstate or send the article back to the BlogEditor if additional changes are needed. KBAuthor: Can start and edit KB articles KBEditor: Can edit articles that are in the Awaiting Review state. KBEditors can send articles back to the KBAuthor if there are changes required or can forward the article to the KBPublisher for publication KBPublisher: Can approve and publish articles that are in the Awaiting Publicationstate or send the article back to the KBEditor if additional changes are needed. You can find these roles when you go to Settings > Users > Community Permission Defaults. Learn more about enabling this feature and assigning roles to members 3-step workflow: Once you assign the above roles members, every draft will go through the process of publishing articles with a 3-step workflow that provides for authoring, editing and publishing. Below is an example of a blog post’s draft page that was written by a member with a BlogAuthor role and submitted for review. You can see the status of the draft, version number, and perform further actions depending on your role in the workflow process. When the drafts are in the 3-step workflow and yet to be published, you can Manage Content:Trackan article’s or blog post's journey in the publishing workflow and make it easier to take relevant actions using thecontent managementdashboard. Compare two revisions of a draft:Compareany two versions when the article or blog post is in the workflow process. The differences between the two versions are highlighted View Draft History:Track every action each member performs on an article or blog post until it is published. Note: As of today, email notifications are not sent to members with these roles. This feature will be available in a future release. Knowledge Base article and blog post states In this publishing workflow, knowledge base articles and blog posts can be in one of four states: Draft:Articles or blog post has been created or edited but isn't ready to be reviewed or published Awaiting Review:Article or blog post draft is ready for review Awaiting Publication:Article or blog post has been reviewed and is ready for approval and publication Published:Article or blog post has been published. If this article or blog post was a revision for an already-published article or blog post, respectively, this new version replaces the previous version in the community Related topics: 3-step workflow for Knowledge base articles and blog posts Return a Knowledge base article or blog post back to draft state Send a Knowledge Base article or blog post back for review
