How this Max Frequency for a session work in Adobe Launch Rule Condition | Community
Skip to main content
A
aguseranalytics
Level 3
June 8, 2025
Solved

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

  • June 8, 2025
  • 2 replies
  • 1104 views

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.

Best answer by Jennifer_Dungan

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.

2 replies

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 9, 2025

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.

Cheers from Switzerland!
    A
    aguseranalyticsAuthor
    Level 3
    June 9, 2025

    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
    Community Advisor and Adobe Champion
    Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
    Community Advisor and Adobe Champion
    June 9, 2025

    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.

      A
      aguseranalyticsAuthor
      Level 3
      June 10, 2025

      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-a-value/m-p/708209 


      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
        Community Advisor and Adobe Champion
        Jennifer_DunganCommunity Advisor and Adobe Champion
        Community Advisor and Adobe Champion
        June 10, 2025

        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.

          Terms & ConditionsAccessibility statement

          Loading footer...