On the client side, the main object provided by the Adobe Analytics JS library (AppMeasurement.js) is _typically_ "s". People refer to this as the "s Object" or just as "s". It may also be referred to as the "tracker" object. Technically, it may have a different name and it may or may not be exposed at global scope. Anyway, I'm going to just call it "s".
"s" is created when the Adobe Analytics library loads (and when a call to s_gi is made. BTW, s_gi is the function that gets an instance of the "s" object ( tip: remember "get instance" for s_gi ). On a traditional web page, we load the page into the browser, which loads the TMS (DTM or Launch or other). The TMS loads AppMeasurement.js, calls `s=s_gi('<report_suite_id>')` and we have the s object established. At this point, "s" is clean and has no settings for props, eVars, events, products, or any other variable.
Variables are subsequently set on "s" either directly (like s.eVar4="stew", or s.prop3="cat") or via some UI in the TMS. These variables mean nothing unless a beacon is sent (calling s.t or s.tl directly or indirectly via TMS actions). These values will persist on the "s" object until they are :
1) Overwitten by some other value
2) Cleared by calling s.clearVars()
3) "s" is destroyed or overwritten (not typical)
4) The page is replaced in the browser.
Typically, we think "new page" - "new s object".
In a SPA, the "s" object is (typically) created when the application loads and it will stick around until the application unloads. Because of this, view changes on the SPA don't get a fresh, clean "s" object (unless you make it so). This is why it becomes important to implement some hygiene that clears (or partially clears) variable settings on "s".
On the server side, persistence is done within the AA database based upon rules that you set in the AA admin console. For every hit that gets sent in, there is a column for each variable (say eVar5), and another that represents the post-processed value, post_eVar5. Variable persistence is not the only thing that can affect a difference between the two, but it's a common reason for the difference. Anyway, in the admin console for a report suite, you could say the eVar5 has an expiration of 30 days and an allocation of "original". This means the first value set to that eVar will be persisted for 30 days from the time it was set.
There are tons of resources on this topic, so use the Google if you want to learn more.
Increasingly, server-side persistence and pre-specified expiration and allocation settings are becoming irrelevant. As systems advance and processing becomes cheaper, these models are simply constructed atop the base data giving the analyst many more options (and interpretations) when reporting on the data.
