List Variables and List Props

That covers the variables you reach for every day: props, eVars, events, and the built-ins, which is most of what any report needs. This section covers one that is different, not used often, easy to overlook, but pivotal in the narrow situations where nothing else will do. Every variable so far shares one quiet limitation: it holds a single value per hit. But real behavior is often plural, a visitor views three categories, applies four filters, matches five interests, all at once. List variables exist for exactly that. They hold many values in one hit, and here is the defining trait: each value gets full credit, not a divided share.

You have actually met this problem already. Back in the props section, the survey example, four checkboxes a visitor can tick in any combination, showed up as a reason to use a list prop. Look at the reporting side of it now. If a visitor can select any of four options at once, their raw input becomes a tangle of combinations: option 1 and 2, then option 2 and 4, then option 1 and 3 and 4. A naive report drowns in those permutations. What you actually want is dead simple, four lines: how many times was option 1 chosen, option 2, and so on. A list variable delivers exactly that, because it splits the values apart and credits each one independently.

That independent, full crediting is the whole point, and it is easiest to see against an eVar. Set one eVar to three values and Linear allocation (from eVars) splits the conversion across them. Put those same three values in a list variable and every one is credited in full:

Two kinds, and which side they sit on

The names are similar, but list variables and list props live on opposite sides of the prop/eVar divide, and the differences are exactly the constraints that decide which one you need:

That capacity and persistence row is the crux. A list prop is hit-scoped and capped at 100 bytes for the whole variable; a list variable persists like an eVar and allows 255 bytes per value with no overall cap. So the moment you need the values to survive past the hit, or you outgrow 100 bytes, the prop can no longer do the job.

List variable settings worth knowing

• Delimiter: the character separating values (commonly a comma), configured per variable. It must match exactly what your code sends, and it cannot be a space or a multi-byte character.
• Expiration: like an eVar, controls how long values stay eligible for credit.
• Allocation: Full (every value gets full credit, the usual choice) or Linear (credit divided across values).
• Max values: caps how many values are kept per visitor, up to 250; beyond that, the oldest drop off.

One helpful behavior to know: Adobe de-duplicates repeated values on the same hit, so s.list1 = "Brick,Brick" counts a single instance of "Brick," not two.

// List variable (persists, each value credited per config)
s.list1 = "running,outdoor,sale";

// List prop (hit-scoped, must be enabled in Admin first)
s.prop1 = "shoes,apparel,accessories";

The discipline: guard your three

Here is the practitioner's rule the scarcity forces. Because only three list variables exist per report suite, and reclaiming one later means losing its history, they are the one variable type you should be slow to spend. A few habits keep you out of trouble:

• Don't switch them on during your first implementation. Early on you rarely know which multi-value needs are real and lasting.
• Reach for a list prop first. If you only need multi-value capture for traffic analysis, and the values fit in 100 bytes and don't need to persist, a list prop costs you nothing scarce (props).
• Escalate only when the prop genuinely can't do it: when the values must persist to credit a later conversion, or exceed 100 bytes. That is the real dividing line.
• Activate one at a time, and only after a deliberate discussion with your team about whether the need is durable.

The failure mode is switching on all three early, then discovering a genuine list-variable need a year later with nothing left to give. At that point you are stuck: you cannot free one without abandoning the data already collected in it. Spend the last slot as if it were the last.

One last practical note. Raw list values are often codes or messy strings, a banner ID, an error code, which make for an unreadable report. The fix is the same one that helps elsewhere: classifications turn each raw list value into a friendly, reportable label, so a list of cryptic IDs becomes a clean report of names.

Every variable across this module shares one assumption: your code sets a specific, named slot directly, s.eVar5, s.list1, and so on. Context Data Variables covers a more flexible way to hand data to Adobe, one that does not commit to a slot at collection time.