I'm wondering why you wouldn't want to constantly extend the expiration of the ahoy_visitor cookie with each page request by Ahoy.visitor_duration.
It seems wrong that if you have a user who visits your website once a week every week for Ahoy.visitor_duration, that on their next visit they'd be assigned a new visitor_token. I can't think of why it would make sense to break the continuity of that visitor token because they passed an arbitrary point in time.
Conversely, it seems to make sense that if a person lapses Ahoy.visitor_durationwithout a visit, that you'd roll their token.
I'm thinking of writing a PR for these changes, but I always assume I know less than the authors here, so what am I missing? Is this desirable functionality as a default or perhaps something that can be opted into?
--
As an aside, looking at other services setting IDs on our website (FB, Google Analytics, Stripe), they're all extending the expiry of their ID cookies per request.
Hi there,
I'm wondering why you wouldn't want to constantly extend the expiration of the
ahoy_visitorcookie with each page request byAhoy.visitor_duration.It seems wrong that if you have a user who visits your website once a week every week for
Ahoy.visitor_duration, that on their next visit they'd be assigned a newvisitor_token. I can't think of why it would make sense to break the continuity of that visitor token because they passed an arbitrary point in time.Conversely, it seems to make sense that if a person lapses
Ahoy.visitor_durationwithout a visit, that you'd roll their token.I'm thinking of writing a PR for these changes, but I always assume I know less than the authors here, so what am I missing? Is this desirable functionality as a default or perhaps something that can be opted into?
--
As an aside, looking at other services setting IDs on our website (FB, Google Analytics, Stripe), they're all extending the expiry of their ID cookies per request.