Course 5: AQS Recommendations

Learn how AQS Recommendations work.

AQS Recommendations

The goal of the AQS Recommendations feature is to help you to identify issues from the data and ways to handle them. It is available in the Activity Dashboard of the Applause platform.

Users will be notified of unusual trends as identified by a recommendation engine and offered next-step suggestions as well as a detailed description of types of the notifications and the ways you will interact with them.

Components of the AQS Recommendations
  • The Recommendation Engine that runs in the background, calculates a series of metrics and compares them to predefined thresholds

  • On-screen notifications displayed to the Activity Dashboard user

How the AQS Recommendations Work

Once the recommendation engine triggers a recommendation, an on-screen notification is displayed in the Activity Dashboard.

Each notification describes the found issue, provides a graphical trend to visually demonstrate the identified outlier and offers a link to a corresponding resource on https://help.applause.com with suggested root causes and proposed next steps.

Users may dismiss the notifications as they appear in the notification panel of each build, effectively hiding them from the screen. All recent notifications - whether dismissed or not - are still available in the notification list.

Recommendation Types and Triggers

The recommendation engine is set to identify the following recommendation types:

  • Bugs
  • Triage (only if Reporting Configuration has “Customer Responsible for Triage” checked)
Recommendation on Bugs

Identified issue

Metric

Threshold

Compared Metric

Increase in the number of issues

Number of bugs in status "New", "Info Requested" "Under Review", "Pending Approval", "Pending Rejection", "Approved" and NOT marked as "Won't Fix" for the build

=> 150%

The product’s average number of bugs per build

Decrease in the number of issues

Number of bugs in status "New", "Info Requested" "Under Review", "Pending Approval", "Pending Rejection", "Approved" and NOT marked as "Won't Fix" for the build

<= 50%

The product’s average number of bugs per build

Increase in the severity of issues

Base Severity Score

=> 150%

The product’s average Base Severity Score per build

Increase in the priority of issues

Base Priority Score

=> 150%

The product’s average Base Priority Score per build

Decrease in the value of issues

Base Value Score

<= 50%

The product’s average Base Value Score per build

Specific component has a lot more bugs

% of bugs in status "New", "Info Requested" "Under Review", "Pending Approval", "Pending Rejection", "Approved" and NOT marked as "Won't Fix" reported for the component for the build

=> 200%

The product’s average % of bugs for the component per build





Recommendation on Triage (Only if the Reporting Configuration Has “Customer Responsible for Triage” Checked)

Identified issue

Metric

Threshold

Compared Metric

Increase in approval rate

Bug approval rate for the build

<= 70%

Product’s bug approval rate per build

Many issues awaiting triage

Number of bugs in status "New", "Info Requested" "Under Review", "Pending Approval", "Pending Rejection" for the build

=> 10

---

Triage takes too long

Average time of

  • For triaged bugs - from createDate to triageDate

  • For pre-triage bugs - from createDate to now() For the build

=> 150%

Product's Average time-to-triage per build

Average time between TTL recommendation ("Pending Approval", "Pending Rejection") to triageDate

=> 150%

Product’s average time-from recommendation per build

Many TTL recommendations are rejected

Number of bugs moving from:

  • Pending Approval to Rejected

  • Pending Rejection to Approved

=> 3

---