Can I keep track of user tab/visual habits?

Q&A
, ,
1

I was wondering is Quick has the capability of keeping track of viewer habits. When someone is viewing a dashboard, is it possible to see what tabs or visuals they spend more time looking at?

2

Hi @ineedqshelp and its good to see you back in the community!

The short answer is that Quick Sight can tell you how much your dashboards are being used, but not how long a viewer stays on a specific tab or which individual visuals they focus on. What you can track is usage at a higher level. Through CloudWatch, quick sight exposes metrics like DashboardViewCount, DashboardViewLoadTime, and VisualLoadTime, which are useful for adoption and performance monitoring.

If interested, I’ve gone ahead and attached the official AWS documentation about this:

Hope this helps!

3

How would you recommend getting those metrics from cloudwatch into quicksight?

4

Hi @ineedqshelp - want to add some detail here that I think is relevant to your use case.

CloudWatch is the ideal solution for high-level account/asset view monitoring. It gives you aggregate metrics about dashboards (e.g. “how many times was dashboard ABC opened last week”), but doesn’t have information about who opened the dashboards.

Note: these metrics aren’t only account-wide - DashboardViewCount and DashboardViewLoadTime both support a DashboardId dimension, so you can pull view counts and load times per individual dashboard, not just totals across your whole account.

CloudTrail goes a level deeper by tracking these actions by user. It logs the underlying API calls (GetDashboard, UpdateDashboard, UpdateDashboardAccess, etc.) tied to a specific IAM identity, timestamp, and source IP. So if you need to know who opened a given dashboard and when, that’s where you’d look.

One caveat applies to both: neither CloudWatch nor CloudTrail can get you below the dashboard level. Since both only capture QuickSight API calls, there’s no event for tab switches or time spent on a specific visual - that kind of interaction happens client-side and never generates an API call, so it’s outside what either service can see. If per-tab/per-visual engagement is a hard requirement, the only path is a custom solution - embedding your dashboards via the QuickSight JS SDK and capturing navigation/state-change events client-side yourself (though this might be overkill).

To answer your CloudWatch → QuickSight question:

  • CloudWatch metrics aren’t a native QuickSight data source, so you need something in between
  • The most common approach is the Athena CloudWatch Metrics connector - it lets Athena query CloudWatch metrics via federated query, and QuickSight can then connect to Athena like a normal data source
  • One limitation: that connector only returns the trailing 15 days of metric data
  • If you need longer retention: a simple scheduled Lambda that calls GetMetricData on a schedule and writes results to S3 (then pointed at by Athena/QuickSight) is usually the lightest-weight way to get there (though that requires provisioning additional infrastructure)

Relevant article here:

Hope this helps close the loop!

5

Do I need to create a log group for QuickSight? I currently have a glue database of all the cloudtrail logs, and when I query it looking for “VisualLoadTime” metric, I don’t see it. Or is there a way to directly access cloudwatch metrics so I can look at the QuickSight metrics without dealing with CloudWatch logs.