Is the 'Reloads' metric commonly used?

[HyunjiLee]

I found the definition of "Reloads" a bit confusing.
From what I understand, it seems to be an automatically collected event that's counted as '1' when the current page view is based on the same page as the immediately previous page view. Is that correct..?

If so, aside from refreshing the browser, are there any other cases where this could happen? 
I would really appreciate it if you could kindly let me know

[EurosIMS]

Reloads, like Bounces or pageType, I think is one of the things that is more a relic of historical analytics than anything else.

However, as with the others, it still has uses. Consider how often you visit a website to login, but the back end errors & for some reason it fails. There might not be an error on page, or a new page, or any tracking that can pick this up: However, Reloads would tell you that there's been a spike on that page, which could help indicate there's a back-end problem no-one is yet aware of. 

Similarly on other pages where something should happen, but doesn't in the way a user expects- without certain kinds of tracking, the only indication might be that Reloads on that page increased, which could help lead to QA-ing the issue. 

[Jennifer_Dungan]

You are correct, it's basically triggered when Adobe believes the same page has been reloaded... This could be fooled say on a search result page; assuming you aren't passing something like a page number into your page name when the user paginates... It could be even worse if you only pass a pageName like "search result" (with no context to the search term, page the user is on, filters, etc). This really depends on your implementation and how detailed your page names are....

I use Reloads frequently, for various reasons...

1. I work on news sites, so understanding if people are refreshing our articles could be an indication of people trying to bypass our subscription walls (if they aren't entitled), or it could indicate more engagement with our commenting section, or it might be a developing story with updates and seeing people trying to get additional information
2. I have used this in the past to "right size" traffic after bad deployments causing inflated page views... one that comes to mind immediately is years ago, we had an adaptive / responsive site, and someone on the team decided it was a good idea to force a refresh when the breakpoint changed... ok, I could deal with that... the problem is that the developers made a mistake, and had a 1px overlap on the iPad screen size... so everyone who attempted to come to the site on an iPad (or anything with the same screen width) got stuck in an infinite reload loop...  and since it was deployed on a Friday, it wasn't fixed until Monday...   I used reloads paired with that screen size to create a segment to exclude reloads for the weekend so that our traffic numbers weren't massively inflated...

[GrahamKr]

Actually Reloads metric measures the number of times a dimension item, typically a page, is loaded consecutively, most commonly when a visitor refreshes their browser.

It counts instances where the Page dimension has the same value as the previous hit within a visit. Importantly, it does NOT count non-consecutive visits to the same page unless they occur sequentially. For example, navigating from Page A to Page B and back to Page A does not count as a reload unless Page A is immediately reloaded after itself. We set up an Adobe connected EC2 instance on a HostJane managed VPS and this metric helps identify user behavior related to page refreshes, which can indicate issues like poor page performance, user confusion, or intentional refresh actions (e.g., checking for updates on dynamic content).

Analytics checks the Page dimension (e.g., post_pagename) for consecutive hits with the same value. A visitor refreshing their browser or triggering another page view call (e.g., s.t()) on the same page increments the Reloads metric. We were using a virtual machine running laravel btw for our checks and combining our HostJane Reload metrics with other Metrics: Pair Reloads with Page Views, Time Spent, or Bounce Rate to contextualize user behavior.

The Reloads metric is used in Analysis Workspace, Report Builder, or other Adobe Analytics tools to analyze user behavior, troubleshoot website issues, or optimize content. It’s particularly useful for:

1. Identifying problematic pages: High reload rates may suggest technical issues (e.g., slow loading, broken functionality) or user frustration.
2. Monitoring dynamic content: For sites with frequently updated content (e.g., news or e-commerce), reloads can indicate users checking for updates.
3. Comparing engagement: Reloads can help differentiate intentional refreshes from navigation errors or poor user experience.
4. Custom reporting: Combine Reloads with dimensions like Page, Entry Page, or Device Type to gain deeper insights.

[gautham_madala]

Not very commonly used in high-level dashboards or standard analysis.

However, it can be useful in troubleshooting:

Identifying technical issues, such as loops or bad redirects.

Spotting unintended user behavior (e.g., users stuck on the same page).

Auditing page view tracking logic — especially in SPAs or custom implementations.

I had a problem once reloads was a key KPI for validating the analysis. The page had almost 10 reloads per visit per user and usually it was 1, so we detected the error and validated it against this metric