Excluding non-interaction events from the bounce rate calculation


In Google analytics we can define any event as interactive or non interactive in event. Can we do the same in Snowplow as well? Actually we have implemented Scroll Event as Structured Event. So now while calculating the bounce rate I cannot directly count all those userid where event count =1 as scroll event will add to the event count.

Shilpi Singh

1 Like

Hi @ssingh195,

That can easily be done by either including or excluding events from the count you’re using to determine whether a user bounced or not.

I hope this answers your question,


Hi @ssingh195,

we’re having a similar wish here. Did you find an elegant way to make the distinction between user-generated (page views, clicks etc) and server-side events (app install, push notification, page load) ?

@christophe is there a way to attach some form of labels to structured event categories, to sort of facilitate the queries?

we thought about keeping a reference table of events with a certain “event_source” : ‘user_action’, ‘load’, ‘push’ … However it sounds already hard to maintain.

any hint?



Hey @SixtineVervial,

Would app ID or tracker version work? Tracker version is a little harder to use because the string combines both the SDK (e.g. Ruby) and the version (e.g. 0.3.0).

I’m not sure I fully understand the question. Are you looking to send an extra field with each event category? What would be an example of a label that would be sent with a category?

Hope this already helps.

Hi @christophe,

we looked into several ways of tackling this. Unfortunately the app_id field is used in our company to track the webapp / ios / android / service version that fires the event, and is therefore not usable for that purpose.

I guess what we are looking for would be a way to attach labels to events like “passive / active” or “on-site / offsite” or “engagement” etc. We could add this “meta” information into contexts or any se_* field, but managing those labels (applying them on historical data for instance) can be a touchy operation.

For now we are thinking of simply building a reference table with the labels we need. But maybe this could be part of a more global feature where we document each event we fire (with versioning, historical compatibility, labels etc). We’ll test some stuff internally and will let you know if we find a scalable / easy-to-maintain (for both analysts and frontend devs) method.


1 Like