How Evar able to persist a value

[Rishank_Tyagi]

Hi Community ,
How an Evar able to persist any value ,
does it use the cookie value? to hold the value until expiration.
What is the backend scenario to hold the value in Evar?

Thanks,

Rishank

[bjoern__koth]

Hi @Rishank_Tyagi 

eVars values are persisted on the Adobe servers, you will not find them on the client.

You send them in a tracking call and Adobe takes care of the rest for you.

What exactly do you mean with backend scenario?

[Rishank_Tyagi]

Hi @bjoern__koth ,
For Backend scenario I am trying to ask how it able to persist any value in a cookie or adobe takes care of it. that's what i am asking,
but .Thanks for the answer ,you can close this thread.

Thanks 
phew**

[bjoern__koth]

Hi @Rishank_Tyagi 

the frontend works the same way. Adobe places one or more cookies with user identifiers which get sent automatically with any outgoing tracking call.

This user identifier is linked to all additional information like eVars you are sending with the tracking request. And this happens on the Adobe servers.

On the backend side, do you mean APIs? For that, you would obviously have to provide this user information separately since (meaning, the user identifier is coming from your backend) since, as you've already figured, that approach will not contain any cookies.

https://developer.adobe.com/analytics-apis/docs/2.0/guides/endpoints/bulk-data-insertion/file-format...

does that answer your question?

[Rishank_Tyagi]

Hi @bjoern__koth ,
Thanks for the answer,
now you can close the thread.

Thanks

[bjoern__koth]

Hi @Rishank_Tyagi 
unfortunately, you will have to pick a correct answer since I do not have the rights to select my own answers as correct xD

[Jennifer_Dungan · Accepted solution]

I am just going to add some additional context to this response.

Adobe has a user identifier in their database, this is normally tied to a front end cookie like the ECID or s_vid, or it can even be tied to a passed vid (think of AMP pages where Adobe can't set cookies, but we can pass the AMP user id to Adobe so that we can re-identify the same user).

When you have a persisted eVar (Visit, Month, Year, etc) that value, once send to Adobe for a user (let's call the user id "X" for now), every subsequent hit that user X makes, if no new value is sent to Adobe, will maintain that initial value until it expires.

For other people who might come across this post, if you look at the Raw Data feeds, there are two fields for each eVar.... "eVar1" and "Post_eVar1".

On the initial hit, both of these fields will have a value. On subsequence hits, where no value was explicitly set, only the "Post" version of the eVar will have a value. Because the Adobe servers are processing that user's hit and applying the stored eVar onto the hit.

This does not mean that you always have to have the initial "eVar" field set, values set by the Admin Processing Rules will follow the same eVar behaviours... but in that scenario, only the "Post" field will be set (as is the case in old Mobile App tracking, or likely the WebSDK where the schema values are mapped to the dimensions).

We don't have access to where Adobe is storing all of the eVar behaviour data, but the system is design to create these complex attribution mappings. This is part of why there is about an hour's latency for our data.. there's a lot to process.