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.
