Answers: <p>There is a crossover here with some analytics tools as you are probably interested in:</p>
  <ul>
  <li>Front end errors</li>
  <li>Rage clicks / dead clicks</li>
  <li>Time from interaction to delivery (i.e. how long to do something after a user clicks)</li>
  </ul>
  <p>If you monitor these, you can set up automatic alerts when there's an anomaly, such as a sudden increase in front-end errors that may have been caused by a change in the latest version of your app.</p>
  <p>Rage clicks and dead clicks indicate usability problems.</p>
  <p>You'd expect the timings to be super-fast if the whole app runs in the front-end without communicating with back end services, but this will certainly offer surprises if there's an operation that takes longer than a few milliseconds!</p>
  <h2>Business metrics</h2>
  <p>Additional to this would be tracking the business metrics that relate to the app. Are you hoping people will do something as a result of the app? How many / what proportion of users do the thing you wanted?</p>
  <p>A new version of the app might be technically brilliant, but if users stop doing the business thing you hoped for, it might need to roll back to keep your business operating.</p>
  <p>As an example, if you ran a hotel bookings site and released a change to the sorting of the results, it could reduce the number or value of hotel bookings, which could put you out of business if you don't go back to the old sorting.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-03-15T18:15:03.503Z
Answers: 2023-03-15T18:15:03.503Z
Answers: Fenton
Body: <p>Context:
  We have some features that rarely calls any backend service and the logic stays in the frontend.</p>
  <p>Most of the tools we have can calculate SLI/SLO status based on latency and error code return from the server side, but right now since the applications is frontend-heavy, we're mostly tracking bugs based on user reports, manually.</p>
  <p>We're trying to add some services to track the end user interaction and hope that we can collect some metrics like number of clicks for example.</p>
  <p>The main question is: what are the good metrics to collect for a frontend application?</p>
  <p>I think analyzing bug tickets, user feedback, and surveys are good methods also but I'm looking for some &quot;black box&quot; metrics so based on that we can set up some kind of alerts to notify our team to send someone to investigate before bug tickets arrive.</p>
  
Comments: CC BY-SA 4.0
Comments: 2022-05-24T18:42:32.390Z
Comments: https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals
Comments: chicks
Tags: <monitoring><sre><metrics>
Title: What are the good metrics to collect for frontend application?
UserDisplayName: nvcnvn
ThreadText: # What are the good metrics to collect for frontend application?
  
  (Asked by: username_0 on 2022-05-22)
  
  Context:
  We have some features that rarely calls any backend service and the logic stays in the frontend.
  
  Most of the tools we have can calculate SLI/SLO status based on latency and error code return from the server side, but right now since the applications is frontend-heavy, we're mostly tracking bugs based on user reports, manually.
  
  We're trying to add some services to track the end user interaction and hope that we can collect some metrics like number of clicks for example.
  
  The main question is: what are the good metrics to collect for a frontend application?
  
  I think analyzing bug tickets, user feedback, and surveys are good methods also but I'm looking for some "black box" metrics so based on that we can set up some kind of alerts to notify our team to send someone to investigate before bug tickets arrive.
  
  **Tags:** monitoring, sre, metrics
  
  > **Comments:**
  > **username_1**: https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2023-03-15. Score: 0 | Accepted answer
  
  There is a crossover here with some analytics tools as you are probably interested in:
  
  * Front end errors
  * Rage clicks / dead clicks
  * Time from interaction to delivery (i.e. how long to do something after a user clicks)
  
  If you monitor these, you can set up automatic alerts when there's an anomaly, such as a sudden increase in front-end errors that may have been caused by a change in the latest version of your app.
  
  Rage clicks and dead clicks indicate usability problems.
  
  You'd expect the timings to be super-fast if the whole app runs in the front-end without communicating with back end services, but this will certainly offer surprises if there's an operation that takes longer than a few milliseconds!
  
  ## Business metrics
  
  Additional to this would be tracking the business metrics that relate to the app. Are you hoping people will do something as a result of the app? How many / what proportion of users do the thing you wanted?
  
  A new version of the app might be technically brilliant, but if users stop doing the business thing you hoped for, it might need to roll back to keep your business operating.
  
  As an example, if you ran a hotel bookings site and released a change to the sorting of the results, it could reduce the number or value of hotel bookings, which could put you out of business if you don't go back to the old sorting.
  
  
  ---
  
  