How this Max Frequency for a session work in Adobe Launch Rule Condition

[aguseranalytics]

Hi Team, 
There is a requirement regarding Launch implementation, It is to fire an 'eventx' after every session is complete for a visitor. The above eventx should only fire when :
a) event : userUpdate
and 
b) user is logged in
And we need to fire this event consistently after every session provided the user is logged in. It should not be the case, that a guest user has this event fire though it wont, because condition a needs to true.
I was trying for the Max frequency condition but I read in the below link,  it has certain conditions to be fulfilled regarding visitor session count and max freq session count, how basically it works?  https://experienceleague.adobe.com/en/docs/experience-platform/tags/extensions/client/core/overview
Please add in your thoughts how we can achieve the above requirement.

Thanks in Advance.

[bjoern__koth]

Hi @aguseranalytics 

there is no way to detect when a session ends in Adobe Analytics since this is calculated on the Adobe servers after 30 minutes of session inactivity. 
Launch won't help you either. The only thing I could think of could be using browser events when the user navigate away from the current tab to a different domain or closed the tab.

But this will not close the AA session. Should the user reopen another tab within 30 minutes, this will remain within the same session.

In other words it's a requirement that should be rejected or adapted at least.

[aguseranalytics]

Thank you @bjoern__koth for the reply. Yes, it seems quite undoable to exactly understand when this session would end, and we can not do it manually either. 

And another question is related to the above scenario, what would be the impact of expiring data elements on a session?
Provided, these data elements are inserting values to the eVars itself, which are set to expire on a visit. I mean can we expect some difference here with respect to both the configurations.

Please add in and Thanks in Advance.

[Jennifer_Dungan · Accepted solution]

Hi, I just want to clarify your use case...

You say "after every session" but then you also give a clear trigger event of "userUpdate
and user is logged in".  I am unsure how "after every session" comes into play, unless you just mean, you need to restrict eventx to once per session (not really deferring it to the end of the users session which is sort of implied by the wording above).

If this is really just a "restrict eventx to once per session", there are two ways to go about this.

The first, is using Max Frequency as you mentioned above... if you create a trigger for "userUpdate", you can add two conditions to the rule:

1. Check if the User is Logged In

2. Max Frequency "Return true no more than once every 1 sessions"

This should only trigger the rule once per session, on the "userUpdate" action when the User is Logged In. If the first userUpdate doesn't have the user logged in, this won't count against the Max Frequency.... all conditions should need to pass for the Max Freq to apply.

However, if you have an implementation that might cross sites / use multiple Launch Properties across your sites... the Max Frequency will only apply to the implementation for that one Launch Property.

But long before Launch was around, Adobe had a very easy way to limit events.... Right in the configuration of your events, you can set up Event Recording Behaviour:

• The default is "Always Record Event", which means the event will always trigger.

• The item you might want to look into is "Record Once Per Visit"... this means you can send eventx on every "UserUpdate" (where the user is logged in), but only the first eventx of the user's visit will be allowed in your data... all subsequent eventx in the same visit will be ignored... you will see eventx in your tracking calls, but they will be excluded during post-processing.
  
  This is a lot easier to implement technically.. you don't have to do as many rule conditions in Launch and test them for various scenarios. And if you already have other tracking on UserUpdate (where the user is logged in), you can simply add eventx on that existing tracking call.
  
  
• The last option is serializing your event... you can actually pass a unique id (that applies for life - or at least for as long as your data is retained...) that means the event will only count once against a particular ID... this can be good for tracking things like User Account Creation, passing the User's UUID as a unique identifier...
  
  Example: 
  s.events = "event1:12345"
  
  Adobe will only track the first ever instance of "12345".. whether it's part of the same session, or a year from now. The only problem is that event serialization only accepts 20 digits... which is not enough for most implementations today (a lot of UUIDs are 32-36 character GUIDs).

Now, I see that in Bjoern's response and your replies, you seem to be specifically looking for the "end of the session"... I really don't think that is possible.. and I cannot really understand a use case that would require such a specific "end of session" trigger after a particular action... 

As for your second question

impact of expiring data elements on a session

---

Data Element expiries are just a way of trying to minimize processing of getting a value into your Data Element... So there is:

• "None" (which means the value will process each time it's called... this is also pretty much required for page level values in SPAs, since there is no "pageview" to force a clear in SPAs)
• "PageView" which means the value will be processed only once per page (the page loads, the value is pulled, all subsequent uses of that Data Element will use the initially pulled value)
• "Session" which means the value will be processed only once per session (the first time this value is set in the session, this is the value that will be used every time the Data Element is called)
• "Visitor" which means the value will be processed once per visitor, maintaining the value across sessions.

I use "Session" sparingly, as many values can change over the course of a session... and I never use Visitor...  I know some people like to use "Visitor" duration for things like User IDs... but we treat people that sign out as an explicit "clearing of data"... as they could be using a shared machine... we don't want to continue tracking them beyond their explicit log in session.

[aguseranalytics]

Thank you @Jennifer_Dungan for explaining it clearly. 
I am trying the above solution of : 
Using Max Frequency, if you create a trigger for "userUpdate", you can add two conditions to the rule:

1. Check if the User is Logged In

2. Max Frequency "Return true no more than once every 1 sessions". 
It seems to be working but still monitorig the data on lower environments first.

Another question I had, I have also read in one of your solved blogs https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/how-evar-able-to-persist-... 

If we say ,we have set the expiration of the eVar on a Quarter, that is totally saved on adobe servers right!
It would be wrong if we try to check the value of an eVar (assuming that is persisting) and using it as a condition for our Launch rules or either in processing rules for that matter?

As I believe, those values are working on server level, eg : guid kind of values.

[Jennifer_Dungan]

Yes, you can add as many conditions as you need to a Rule, all conditions must pass for the rule to run. So, your scenario of "User Logged In" AND "Max Frequency" is a perfect use case.

And yes, for your second question, the value of the eVar is stored in Adobe for that identified user...  so, something like Quarter should work, so long as the user doesn't kill all their cookies in that time span preventing Adobe from associating the value to them... but then, if this happens they will be treated as a new UV.

However, you cannot read the value of the stored eVar from the front end to use as part of your Launch Rules. You also can not use a persisted value to drive logic in Processing Rules... 

Persisted Values are added to the row of data as part of Adobe's processing, which happens after the user driven Processing Rules... there is no way to see this value to use in your rules unfortunately.

[aguseranalytics]

Thank you @Jennifer_Dungan for your response. It really helped a lot to get along with multiple complex scenarios like above.

[Jennifer_Dungan]

You're very welcome. If you have any other questions, please feel free to ask, but also, don't be afraid to experiment in your Dev/QA builds (this is how I approach new complex needs)

[aguseranalytics]

Hi @Jennifer_Dungan, 
Regarding the above scenario, as I have used it as : 

1. Check if the User is LoggedIn(eventkey = userUpdate)

2. Max Frequency "Return true no more than once every 1 sessions". So now while looking at the reports, it seems "Max frequency for a session" is creating multiple events.
For instance :  Visit count is 1 , but it shows 5 separate times eventx are fired in the same visit which is creating huge hike in eventx numbers. 
What I am understanding is Launch in the UI is creating every tab opened a separate session which qualifies the rule condition but Analytics in the reports is considering it as 1 analytics session(Visit). Therefore, Visits is 1 and the eventx count is 5.
So to restrict and control this extra counting of eventx, shall we set this eventx configuration to "Record event once per visit" condition.
Will that be useful here?

[Jennifer_Dungan]

Ok, I am not sure the logic that Launch uses in the Max Frequency, but it sounds like something that doesn't transpose tabs... but even if it did, if someone closed their browser and came back within 30 mins... the browser session would have expired, but the Adobe session would not...

So if you are primarily concerned about the custom event, then yes, you can restrict that on the event settings... it's a lot safer to restrict in the event to "Record event once per visit"... you will still get the tracking call request, only the event will be restricted... if this is enough for you, then yes, this solution will work....

If you need to actually restrict the whole tracking request, you might need to do a custom code solution, something that would work across tabs....