Default and Reserved Variables

Props, eVars, and events cover an enormous amount of ground, and you might reasonably think they are all you need. For a while, they are. But like any mature platform, Adobe Analytics ships with a set of built-ins: variables and dimensions its creators knew almost every customer would need, so rather than make you configure them from scratch, Adobe provides them ready to use. The logic is simple. This tool exists to measure behavior on websites and apps, and a website is a collection of pages, so it is a near-certainty you will want to know which pages were viewed. Page identity is not optional; Adobe bakes it in. The same reasoning extends outward: page details, commerce, campaigns, and the visitor's own environment are things almost everyone measures, so almost all of them come built-in.

These built-ins fall into two families, and telling them apart is the key to this section. Some are reserved variables you still populate: Adobe fixes what they mean, but you set the value. Others are dimensions Adobe collects automatically, derived from the hit itself with no tagging at all.

Family one: reserved variables you populate

With a prop or eVar, the slot is blank until you decide what it holds. A reserved variable is the opposite: Adobe already knows what it means and will treat its contents in specific, built-in ways no matter what you intend. Your job is not to define it, but to populate it correctly.

pageName: small variable, big consequences

It looks trivial, but pageName is the identity of every page in your reports. Adobe groups page views by this value, so two pages sharing a pageName merge into one line, and one page sent with three slightly different names fragments into three. A consistent, deliberate pageName strategy is the difference between clean page reporting and a Pages report no one trusts.

Two IDs people mix up

purchaseID and transactionID sound alike and do completely different jobs. purchaseID de-duplicates a whole order: set it on the purchase, and a refresh cannot double-count the sale (the cleaner alternative to serializing the purchase event, from events). transactionID is for Data Sources: it tags a hit so you can later stitch offline outcomes (a call-center sale, a returned order) back to the original online visit. One prevents duplicates; the other links worlds.

campaign: a reserved slot for marketing

One reserved variable deserves its own note. Marketing has always run on campaigns, and the internet only changed their form: instead of billboards and print, modern campaigns run through display ads, paid search, and affiliate links. Knowing which campaign drove traction is how a marketing team optimizes spend and lifts conversion, so Adobe reserves a dedicated variable for it. You capture the campaign's tracking code, usually pulled from the landing URL, into campaign, and it feeds the Tracking Code dimension and the Marketing Channels reports. Because it is really a reserved eVar under the hood, it persists and can be given an expiration, exactly the attribution behavior from the eVar section.

Reserved names are not limited to variables. Adobe's commerce events, the ones covered in Events (Success Events), also carry fixed meanings you simply use rather than define:

Reserved commerce events, with fixed meanings you do not define.

Because Adobe knows what these mean, an entire commerce funnel, product views to cart to checkout to order, reports consistently across every Adobe Analytics implementation in the world. You populate them, usually alongside the products variable, and the standard commerce reports appear without any custom setup.

Family two: dimensions Adobe collects automatically

The second family costs you nothing to collect. Every hit already carries clues about the visitor's environment, and Adobe reads them for you. You do not tag any of this; it simply appears in your reports.

Two modern caveats are worth knowing. First, only the broad signals come free: browser type, OS type, and desktop-versus-mobile are automatic, but precise versions (the exact browser build, device model, or OS version) now require configuring client hints, because browsers have tightened what they reveal by default. Second, on a Web SDK implementation these device, browser, and OS dimensions are not automatic the way they were in classic AppMeasurement; you must enable Device Lookup on the datastream to populate them. Geolocation precision is also yours to control: the same IP obfuscation setting from report suites decides how precise the country, region, and city data is allowed to be.