Use Cases and Examples

Conditions and Actions handed you the grammar of processing rules: conditions for when, actions for what, read top to bottom, order is logic. Grammar is theory, and here is the honest limit of theory. Imagine you have studied everything about football. The rules, the techniques, the strength and flexibility a player needs, the plain fact that the goal is to put the ball into the opponent's net. You know all of it. Now you walk onto the pitch for your first match. Will you win? Set winning aside: will you even be able to play? Almost certainly not, not well. A game is not what you know, it is what you have played, and every match makes the next one easier. Processing rules are the same. You can recite every condition and action and still fumble the first real one.

So this section does two things at once. It walks through the situations you will actually meet, each told the same way, the problem that creates the need, the decision the rule expresses, and the trade-off or mistake waiting on the other side. And it asks you to build them as you read, because reading about a rule and creating one are different kinds of knowing.

Get on the ground and play along

Open the interface now and follow the same path each time:

1. Sign in to the Adobe Experience Cloud and open Adobe Analytics.
2. Go to Admin → Report Suites and select a report suite. Choose a non-production suite on purpose, so a clumsy first rule costs you nothing real.
3. Open Edit Settings → General → Processing Rules and start a new rule.

Not every example below can be built this minute. The ones that map context data need that context data to be arriving in the suite first, and you may not have it yet. But several can be built right now with data you already have: anything keyed off an existing variable, or the query string example. Build those as you go and let the rest wait.

Example 1: Give context data a home

Your developers send a value on every hit as a context data variable, say user.loginStatus. Here is the part that surprises people the first time: on its own, that value populates nothing. A context data variable that is never mapped is invisible in every report, and if you never map it, its value is discarded for good. Context data is deliberately inert until a processing rule gives it a home.

That inertness is the design intent, not a limitation. It lets developers send clean, well-named keys without knowing or caring which eVar or prop each one belongs in, and it lets the analyst own that mapping decision where it belongs. The rule is the seam between the two roles.

Example 2: Pull a value out of the query string

Your site's internal search puts the search term in the page URL as ?q=, and reporting needs it in an eVar. The clean fix is to capture it in your implementation, but suppose a release is weeks away and you need the data now. A processing rule can read the query string parameter directly and route it into the eVar you keep for internal search terms.

Two things to hold onto here. First, the value must be UTF-8 or Unicode encoded for the rule to read it, so an oddly encoded parameter will silently fail. Second, this is a patch, not a home. Adobe's own guidance is to capture query string values in the implementation when you reasonably can, because a URL parameter is exposed, easily changed by marketing links, and outside your governance. Reach for the rule when the timeline forces your hand, then plan the proper capture.

Example 3: Manufacture an event from data you already have

You need to count form completions, but the confirmation page's template is locked behind a release you cannot influence today. The page already sends its page type, and it arrives in eVar1 as confirmation. That is enough. A rule can watch for that value and set the success event itself, with no page code at all.

This is where the sequencing lesson from Conditions and Actions stops being abstract. The rule can only test eVar1 if eVar1 already holds its value by the time this rule runs. If page type is itself set by a later processing rule, this one reads an empty value and quietly does nothing. Two more things worth knowing: the same action set to a custom value of 0 instead of 1 will discard an event, which is the clean way to drop a mistakenly fired metric, and this mechanism cannot set product-specific (merchandising) events or the products variable, so purchase-level events still belong in your implementation.

Example 4: Copy an eVar into a prop to see paths

A value lives in an eVar, and you want to see the sequence, the flow from one value to the next across a visit. You open the pathing reports and the eVar is not available in them. That is not a bug. Pathing lives on traffic variables (props), and eVars do not support it. Rather than re-implement the value a second time as a prop, a rule can copy it across.

The trade-off is that you now maintain the same fact in two places. They will stay in sync only as long as this rule does, and the prop and the eVar carry different expiration and allocation behavior, so the pathing view and the eVar view answer subtly different questions. Copy for a reason you can name, not reflexively.

Example 5: When a processing rule is the wrong tool

The most useful example in this section is the one you should not build. Campaign codes are arriving messy, email_spring, email_q3, social_reels, and someone suggests a rule that buckets them into tidy labels.

A single typo fix, correcting a misspelled site section as it arrives, is a fair use of a rule. But systematic bucketing is a different task wearing the same clothes, and a processing rule is the wrong tool for it for two reasons you already know. It only acts going forward, so every campaign code collected before today stays messy. And it needs a rule or condition per bucket, which grows without end. The tools built for this job are Classifications, which relabel values through a lookup and apply backward across data already collected, and for traffic categorization specifically, Marketing Channels. Recognizing which tool a problem belongs to is the real skill; the rule is just one instrument in a set.

Choosing the right instrument

Pulling the examples together, the question is rarely "how do you write this rule" and more often "does this belong in a rule at all." This is the map.

You now have the grammar, a working sense of where it applies, and a first feel for when a rule is the right layer at all. The final section of this module, Limitations and Best Practices, gathers the cautions that have surfaced across these examples, the empty-source overwrite, the no-undo reality, the order traps, and sets them beside the Launch-versus-rule decision, into one disciplined checklist you can carry into a real report suite.