Implementing Adobe Analytics Custom Traffic Variables (Props)

When the predefined traffic variables, page name, channel, server, and the 404 flag, do not cover a measurement need, Adobe Analytics gives you custom traffic variables, numbered s.prop1 through s.prop75. Props are blank containers. Adobe does not pre-name them because every organisation uses them differently, so you name them yourself in the Admin interface to match what you are actually capturing, and whatever you pass into a prop shows up in the report you have named for it. They are the workhorses for questions the standard variables cannot answer: how visitors use content categories, how they navigate, what they search for internally, and how traffic splits across user segments. This article covers how props behave, the use cases they fit, the two features that extend them, and the single rule that governs whether you set them once or on every page.

How props behave

A prop is coded just like the predefined traffic variables, by assigning a string to it.

s.prop2  = "internal search term";
s.prop16 = "Registered User";
s.prop17 = "German Page";

Every prop shares the same core properties. The value is capped at 100 bytes and is case sensitive. Crucially, props are non-persistent, meaning a value exists only for the current image request and does not carry to the next page, which turns out to be the most important thing to understand about them. They behave identically to page name, channel, and server in every other respect, there are up to seventy-five of them, and a prop must be enabled in Admin under Report Suites, Edit Settings, Traffic, Traffic Variables before it collects anything. Data sent to a prop that has not been enabled is permanently lost, so enabling comes first.

What props are good for

The clearest way to understand props is through the jobs they do.

Internal site search is one of the highest-value uses. A faceted search captures each dimension in its own prop, the keyword in one, the scope in another, and the result count in a third.

s.prop2 = "umbrella";   // the keyword the visitor typed
s.prop3 = "Women";      // the scope: site-wide or a section
s.prop4 = "47";         // how many results came back

Splitting these across separate props is what lets analysts cross-reference, asking what the top search terms are when the scope is a particular section, which you simply cannot do if everything is jammed into one prop. The result-count prop is quietly valuable too, because zero-result searches are high-priority content gaps. And with pathing enabled on the search-term prop, you can see how visitors refine a query, the progression from “umbrella” to “leather umbrella” to a specific brand.

Page language segmentation is another natural fit on multilingual sites, where a prop tags each page with its language.

s.prop17 = "EN";   // English pages
s.prop17 = "FR";   // French pages
// left blank on the language-selection page

Because props are non-persistent, each page is counted independently for its own language with no carry-over, so a visit that moves through three English pages and two French ones reports cleanly as sixty percent English and forty percent French. The language-choice page itself has no language yet, so the prop is correctly left empty there.

Props also add levels of page grouping that channel alone cannot express. Where the site goes deeper than a single section, you can layer subsection and sub-subsection onto the channel.

s.channel = "Women";        // top-level section
s.prop1   = "Activewear";   // subsection
s.prop2   = "Ski Apparel";  // sub-subsection

That gives three independent reports, each with its own page views, visits, and unique visitors, which you can break down one into the next in Analysis Workspace. A related but different approach groups pages by what kind of page they are rather than where they sit, tagging each as a home page, category page, subcategory page, or product page, which answers how traffic and ultimately conversion distribute across page types and informs where to invest content effort.

Finally, props segment all traffic by visitor attributes such as registration status or membership tier. Here the non-persistence rule bites hardest, because to attribute all of a visitor’s traffic you must set the segment value on every page they touch.

s.prop3  = "Registered";       // or "Unregistered"
s.prop18 = "Platinum Member";  // or "Silver Member"

The usual pattern is to hard-code the default, “Unregistered”, in the base rule that fires on all pages, then let server-side logic or a data layer value override it with the correct status once a logged-in user is identified.

List props: many values, one page view

A regular prop can hold several values at once, but it records the entire string as a single line item, so three visitors with different combinations produce three unique, unreadable rows and you cannot tell how many own any single item. A list prop fixes this by splitting a delimited string into separate countable values.

// List prop with a pipe delimiter
s.prop11 = "Tents|Backpacks|Boots";
// or with a comma delimiter
s.prop11 = "Tents,Backpacks,Boots";

With list support enabled, one page view can credit every value simultaneously, so “Boots” appearing across three visitors counts as three rather than hiding inside three different combination strings. You enable it in the same Traffic Variables admin screen by turning on List Support and choosing the delimiter, pipe or comma, though note that list props must be switched on by Adobe Customer Care rather than fully self-serve. The one rule that matters is consistency: if you configure pipe as the delimiter and then pass comma-separated values, Analytics will not split them and you are back to a single useless string.

Pathing: the order values appear in

Pathing records the sequence in which a prop’s value changes across a visit, and it powers the flow visualisations and path reports. The key detail is that pathing is triggered by a change in value, not by every page view, so a visitor who stays in the Women’s section for five pages and then moves to Electronics records the single transition Women to Electronics. Enabled on a search-term prop, it reveals how queries are refined; enabled on the channel, it reveals how visitors move between sections. You turn it on per prop by setting Path Reports to Enabled in the same admin screen, and the resulting flow view shows where visitors came from, where they went next, and where they abandoned.

Naming props so reports make sense

By default props appear as “Custom Insight 1”, “Custom Insight 2”, and so on, which means nothing to a business user, so you always rename them in Admin under Traffic Variables. Each prop carries a friendly name that shows in reports, an enabled toggle, the list-support and delimiter settings, and the path-reports toggle. A useful naming habit is to prefix the friendly name with a code matching the prop number, like c01 Department, c02 Category, c03 Subcategory, so the list stays ordered and easy to scan.

The one rule that matters most: once or every page

This is the most operationally important concept in prop implementation, and it follows directly from non-persistence. Whatever you pass in is counted and recorded exactly as populated, and whatever you omit simply does not pass in. So the question is always whether you are measuring an event or a segment. If you are measuring an event, a search, a click, a detected browser version, you populate the prop once at the moment of that event, because setting a search term on every subsequent product page would inflate the search count with searches that never happened. If you are measuring a segment, registration status, membership tier, page language, or page type, you populate it on every page, because attributing all of a visitor’s traffic to their segment requires every page view to carry the value. Getting this distinction right is the difference between accurate data and a quietly broken report.

Deciding whether you even need a prop

Before reaching for a prop, check whether a predefined variable already captures the data, and if so, use that. If not, ask whether the data is a page attribute or user segment, in which case a prop is right. From there, two follow-up questions point to the extensions: if a visitor can hold multiple values at once, enable list support on that prop, and if you need to see the order values appear in, enable pathing. There is one more branch worth flagging, which is persistence. If the value needs to survive across pages and link to a later conversion, a prop is the wrong tool, because props are non-persistent by design, and you want a conversion variable, an eVar, instead.

Mistakes can happen

A handful of mistakes recur. Populating a segment prop only on the first page, such as setting registration status on the login page and never again, leaves all subsequent browsing unattributed, so segment props must fire everywhere. The opposite error is setting a search-term prop on every page after the search, which inflates the search count with views that were not searches, so event props are set once. Using a regular prop for multi-select data produces a mess of unique combination rows, so anything that naturally holds several values at once needs list support. Forgetting to enable a prop in Admin means the data collected before enabling is gone for good, so enable before you implement. An inconsistent delimiter between the Admin configuration and the code stops list values splitting at all. And leaving props named “Custom Insight 14” hands business users a report they cannot interpret, so always rename before going to production. Respect the once-versus-every-page rule and these conventions, document each prop and its population logic in the SDR, and your custom traffic variables will give analysts exactly the slices they need without quietly corrupting the numbers.

See you soon.