Tracking Logged In or Off and User Membership Level Status, When to Set | Community
Skip to main content
R
Rafael_Sahagun
Level 3
May 19, 2025
Solved

Tracking Logged In or Off and User Membership Level Status, When to Set

  • May 19, 2025
  • 1 reply
  • 580 views

Hello all.

 

Logged in/off Status Question
eVar expires at hit, so it doesn't matter the allocation (first, linear, last) and has to be set on each hit page load or web action.

 

Wondering of the implications to set either logged off or logged on every hit, comparing e.g. not having the value even present or populated in the data layer prior login, whats best for segmenting and overall usage?

 

I'm trying to visualize how it would be:

  • Visitor arrives to site, set to 'logged off' default status in the data layer when landing on the page.
  • Visitor authenticates, value changes to 'logged in'
  • Visitor x's out and comes back after 40 mins or the next day, will it be set to logged in or off?
    • Would devs read the ECID and automatically log the user in and keep the value for an arbitrary amount of time?
    • How does the authentication status remains or changes?

 

User Membership Level Question
eVar expires at visit, most recent allocation, values: gold, silver, bronze.
As of now on the first page load is set as null in the data layer leading to Unspecified (I believe) or what value does null populates?

 

I'm thinking setting a value such as 'prospect' on first page load when the membership level is unknown, and then upon login set gold, silver or bronze accordingly.

 

Same as with login I'm trying to understand pros and cons between not setting/getting a value in/from the data layer until known, or set it as null versus requiring a value since the first hit such as 'prospect', what are the implications when analyzing such vars, values and creating segments, is it better to have all the hits 'required' for such use cases?

 

Thanks,

R

    Best answer by Jennifer_Dungan

    FYI, I track a logged in/out status on each hit. Since there is no real way to determine if a user has an account and is logged out, or don't have an account at all, we track all of these as logged out. (The user may have had an account at one time and also deleted that account). You cannot really do lookups on an ECID on the fly to check if those users have ever logged in to be able to apply logic on the fly, and most systems once a user is logged out, all the cookies / storage items / etc are deleted... so there's not much you can go by.... also, the user may be on a new device that has an all new ECID and no history)

     

    For us, the state is the same... the user is not logged in, they are getting the logged out experience.

     

    If I need to, I can always look for users with both a "logged in" and "logged out" status over their lifetime, or within the date range.

     

     

     

    We also track our entitlement status on each hit, similar to your bronze, silver, gold... so users could start with no value, then log in and have a value... they could then later log out (or have a cookie corruption that kicks them out) and those subsequent hits would be back to no entitlement / membership status.

     

     

    However, it really depends on your needs, but no, I see nothing wrong with bucketing logged out people with accounts with people who have no account at all...  but if this is really important to you, you might need your developers to create something of a server side cookie to attribute a value of "has membership" to users even when they aren't logged in... and you could have them surface this value in your data layer to add to tracking... however, this could also have impacts on shared computers... like libraries and school labs, etc... and you might end up tracking incorrect data.

    1 reply

    Imbalakumar
    Imbalakumar
    May 20, 2025

    Hi @rafael_sahagun 

     

    FYI, The ECID will remain same even after user logged in. So adobe will able to stitch all the event pre and post login status in Experience Platform.

     

    My recommendation would be as below,

     

    Store the log in status in an eVarX, member status in an eVarY along with an event as below, use the dataLayer approach

    1. Prospect/Anonymous User, fire one event(may be event1)
    2. Member/Loyalty User. fire one event(may be event2), fire one more eVarY to store the member types(gold, silver, platinum) on the successful authentication

    You can track the login status additionally in a Prop as well. You can breakdown these eVarX, eVarY, PropX and PropY with ECID or any other dimension.

     

    Two eVar, Two Props, Two events will solve the both login and logout tracking.

     

    I hope this will solve you issue. let me know your thought.

     

    Regards,

    Bala

      R
      Rafael_SahagunAuthor
      Level 3
      May 22, 2025

      Thanks @imbalakumar 

       

      Login, the eVar (hit) exist and is tracking, login either logged in or off, required, is that a good practice? that would assume the visitor has an account to be able to login/out, what if the person doesn't have an account, would that be ok to include them as logged off? Now, if the visitor was logged in and leaves the page by xing out, would ECID hold the value of 'logged in' for 2 days and then when the visitor comes back would be logged in? (seems like a biz and or developer implemented decision), would ECID pass the value when it is a hit based eVar? (looks like yes as ECID is also hit based, and if it did, is it correct to set it as logged in? would it be better to after a determined amount of time to set it as 'logged off'?

       

      Membership status eVar exists (session based) and is tracking, on the first few hits when not logged in is undefined, so I guess the issue is only then but after login IDs and from then on ECID can share the value (gold, silver, bronze) and pass it back if login happens in the session? what if the user doesn't have an account, is it undefined better than a placeholder 'prospect' or so?

      Best,

      R

        Jennifer_Dungan
        Community Advisor and Adobe Champion
        Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
        Community Advisor and Adobe Champion
        May 24, 2025

        FYI, I track a logged in/out status on each hit. Since there is no real way to determine if a user has an account and is logged out, or don't have an account at all, we track all of these as logged out. (The user may have had an account at one time and also deleted that account). You cannot really do lookups on an ECID on the fly to check if those users have ever logged in to be able to apply logic on the fly, and most systems once a user is logged out, all the cookies / storage items / etc are deleted... so there's not much you can go by.... also, the user may be on a new device that has an all new ECID and no history)

         

        For us, the state is the same... the user is not logged in, they are getting the logged out experience.

         

        If I need to, I can always look for users with both a "logged in" and "logged out" status over their lifetime, or within the date range.

         

         

         

        We also track our entitlement status on each hit, similar to your bronze, silver, gold... so users could start with no value, then log in and have a value... they could then later log out (or have a cookie corruption that kicks them out) and those subsequent hits would be back to no entitlement / membership status.

         

         

        However, it really depends on your needs, but no, I see nothing wrong with bucketing logged out people with accounts with people who have no account at all...  but if this is really important to you, you might need your developers to create something of a server side cookie to attribute a value of "has membership" to users even when they aren't logged in... and you could have them surface this value in your data layer to add to tracking... however, this could also have impacts on shared computers... like libraries and school labs, etc... and you might end up tracking incorrect data.

          Terms & ConditionsAccessibility statement

          Loading footer...