Alternative to "Bounces" Metric

[skatofiabah]

Hi Adobe Analytics Community!

I hope you are all doing great. We have been having server call issues with our "Bounces" Out-of-the-Box" Adobe Metric, which therefore impacts our bounce rate. Therefore, we can't use these as metrics to look at Bounces and Bounce Rate.

My question is to say is there an alternative way of calculating Bounce rate or something super close and similar in Adobe Analytics Workspace that can mimic it super closely? We have tried a Single Page URL Instance Segment and also a Single Page in Visit Segment as an approximation, but we think we can try to get closer.

Unfortunately, on our end, the Single Access metric is still inaccurate due to every session having at least two hits due to the presence of the page performance metrics plugin, which triggers an additional server call after the page renders. It was determined that we can never have fewer than 2 server calls for any page load. I did attempt to create a calculated metric excluding visits with a hit depth of greater than 2 to try to approximate the “bounces” where a user does nothing after the initial page load.

Let me know if you can help!

Thanks!

[MandyGeorge]

Single page visit is what we use for our bounce rate metric. It takes into account the fact that there could be more than one server call on the same page. But it's still just a single page, which we consider to be a bounce. 

You could try making a segment that counts the number of hits that aren't page performance. Since you said every visit has a page performance hit which is a second server call, I would exclude that.

So count the number of hits of everything except those with something like the logic below. Then if there is only one hit, it becomes a bounce. 

Visit

     Distinct count 'hits'

     AND

     Hit does not equal page performance

Or you could try doing hits = 2 and insisting that one of them has to be the page performance (meaning there would be only 1 that isn't, also making it a bounce). 

[skatofiabah]

Hi @MandyGeorge,

Thank you for the prompt response. We have the same page view call, it's just that the 2nd one is a page performance call to get those metrics. What would the segment look like? Do we just filter a segment on a visit level to include only 2 hits? Like hit depth > 2 exclusion or something?

[bjoern__koth]

Hi @skatofiabah 

if the second call only contains page performance information, you will want to go for a custom link tracking call (s.tl) that will not inflate the page views nor impact the single page visit metric.

Cheers

[skatofiabah]

Hi @bjoern__koth,

So you are saying that the page performance information should be a link call and not a page call and that will solve it? Don't we need it as a page call to be able to properly report on page performance metrics?

[bjoern__koth]

Hi @skatofiabah 

the page view call just increases the internal counter for the pageName you define in the the payload (the "Page" dimension in your reports).

In custom links you can send anything that is not supposed to increase the page view counter.

Just one important thing: additionally, you must make sure to capture the pageName in a separate attribute like an eVar (eVar recommended since it can capture a longer string than a prop), since custom link tracking calls will not contain the pageName! That is reserved for page views.

 
You will see the pageName in the link tracking network request (if you define it), but in Analytics you will not be able to use the Page dimension to see your performance stats.

This is a general best practice to capture the current pageName additionally for all calls in its own eVar.

Bottom line:

• get rid of the second page view call
• Capture your pageName in a dedicated eVar for every tracking call
• send the performance stats in a custom link call instead
• in Analytics, do your performance reporting with the eVar as dimension and not Page

[skatofiabah]

Hi @bjoern__koth,

Thank you. I think this makes sense to me. Is there a way to capture the initial page view and performance metrics in a single page view? And also do this for other page views? We currently have 1 page call and 1 link call with each page load and we were wondering if this can at all consolidate into 1 call?

[bjoern__koth]

Hi @skatofiabah 

that's a question for your developers or who ever is maintaining the tag manager., if you can delay the firing of the page view until the page has finished loading and your performance data is ready.

Another option would be storing the performance data on that page as soon as it is ready, including the page name which you would send as eVar (as mentioned), and send it with the following page view call.

This can be stored in e.g., the session storage until the next page loads.

obviously, the downside is that if users leave your website, the information will not be sent.

but you will still get most of the performance data in

[skatofiabah]

Hi @bjoern__koth,

So if I understand this right, we can do 1 page call that contains page performance metrics, it will just delay the call to render and if a user leaves before it loads, we can't capture that, right? We should be able to capture what they do after that page load if they stay on the visit and look at other pages and link calls though, right?

[bjoern__koth]

Not quite, if you want to send the performance metrics with the same call, you will have to delay the page view call.

if you are ok with sending it with the succeeding call, you can ask your devs to

• persist the performance metrics in session storage
• pick it up in the next page view call (make sure to store the pageName of the previous page with this data as well in a separate eVar)

[skatofiabah]

Hi @bjoern__koth,

So We can have it in a single page call and it just gets delayed? Not sure what you mean by persist and next page view call pick it up? Shouldn't all eVars, events, and page performance metrics be in the single delayed page call? Also, shouldn't it all just persist and get stored based on the admin eVar and events persistence rules for a visit?

[bjoern__koth]

Hi @skatofiabah 

yes, if you want to wait until the performance data is all there, you can also delay that call if you want.

The other approach was just to send the page view as soon as possible, and as soon as the performance data is available, persist this until the next page loads.

In that next page view you could then send the previous page performance information as payload.

This is the similar to the approach that the getPercentPageViewed plugin uses.

https://experienceleague.adobe.com/en/docs/analytics/implementation/vars/plugins/getpercentpageviewe...

Hope that makes it clearer

[skatofiabah]

Hi @bjoern__koth,

The problem with option 2 is that we need another page view to occur, right? In other words, if a bounce happens or only a single page visit, we are in trouble, right?

[skatofiabah]

Hi @MandyGeorge,

In addition to the above, could you also show this portion as an example segment?

Visit

     Distinct count 'hits'

     AND

     Hit does not equal page performance