Props — traffic variables

What they are

prop1 through prop75. Called "traffic variables" or "sProps" (from the legacy syntax s.prop1 = "value").

The defining characteristic: a prop only exists on the hit where you set it. No memory. No persistence. It describes *this hit and only this hit*.

Hit 1: prop5 = "Search Results"     → prop5 for this hit is "Search Results"
Hit 2: prop5 not set                → prop5 for this hit is NOTHING
Hit 3: prop5 = "Contact"            → prop5 for this hit is "Contact"

What props are good at

• Pathing. Props (and only props) can be enabled for pathing reports — Next Page Flow, Previous Page Flow, Page Path. If you want to know "what page did people go to after search results?", that requires a pathing-enabled prop.
• Hit-level detail you never want attributed. Page name, page template, site section, breadcrumb position, error message text.
• List props. A prop can be configured as a *list prop* with a delimiter, letting you push multiple values in one hit (e.g. all tags on an article) and report them as separate rows.
• Correlations across a single hit. "On the hits where the site section was X, what was the page template?"

Constraints

• 100 bytes per value (values are truncated beyond this)
• Case-sensitive by default
• 75 slots total

Modern context

Props are a legacy concept. In CJA, the prop/eVar distinction *does not exist* — every dimension is just a field, and persistence is configured in the Data View at report time. Props still matter today (pathing, cheap hit-level detail), but do not agonise over prop design the way teams did in 2015.

For props to be useful, they must be enabled for pathing in Admin. Without pathing enabled, a prop is just a dimension that only exists on one hit — limit yourself to eVar with one-hit expiry instead.

Rule of thumb: If you need it for flow analysis, use a prop. Otherwise, use an eVar with hit-level expiry or just don't collect it.