Limitations and Best Practices

Use Cases and Examples got you onto the pitch, building real rules against real data. Playing a match once is not the same as playing well across a season, and the difference is rarely a flashier move. It is discipline: knowing the fouls, knowing which plays not to attempt, and not giving away penalties through avoidable mistakes. A processing rule is powerful for one reason, it acts directly on your data as it is collected, and that same directness is exactly why a careless one does real harm. This closing section is about playing well: the limits the tool genuinely has, the habits that keep those limits from becoming damage, and the single most important judgment call, whether a rule is even the right instrument for the job.

The limits are the shape of the tool

Every limitation of processing rules traces back to where they sit. A rule runs on every hit, server-side, as data streams in at collection scale, and it has to do that quickly and predictably. That one constraint rules out anything slow or open-ended: no reaching out to an external file in the middle of a hit, no arbitrary computation, nothing that has to remember earlier hits. The limits below are not an unfinished feature set. They are the price of running safely at that volume and speed, and knowing them is what stops you from asking a rule to do something it was never built to do.

Two limits are worth naming precisely because they are widely believed and simply untrue. A rule is not restricted to a single action; it can carry many. And a rule is not stuck at "if this, then that"; the Otherwise branch from the Conditions and Actions section is a genuine else. Older guides still repeat both myths, so do not let them talk you out of a rule that would have worked perfectly.

The mistakes those limits invite

Most processing-rule disasters are not exotic. They are a handful of predictable mistakes, and each best practice below is simply the antidote to one of them.

Because there is no undo, never learn a rule on production. Build and prove it in a non-production report suite first, watch the data it produces, and only then copy the proven rule across. Because an overwrite does not check whether its source has a value, guard it: add an "is set" condition so the rule can never blank out good data with an empty one. Because rules run top to bottom with no early exit, sequence them on purpose, any rule that reads a value must sit above the rule that overwrites it, or it will read the wrong thing. And because rules are permanent and tend to outlive the person who wrote them, write the Reason on every rule, give it a name a stranger could understand, and audit the set now and then to retire the ones no longer earning their place.

Processing rules or Launch? The call that matters most

Look honestly at what these rules do, copy a value, correct a value, pull something from the URL, and a fair question follows: should this have been a processing rule at all? Very often the better home is your tag manager. A Launch data element can run custom JavaScript, use regular expressions, read almost anything available on the page, and chain logic together. Next to overwrite, delete, and set event, that is close to unlimited. So the honest default is this: if you can shape the data correctly at the source, in the implementation or in Launch, do it there. Work done at the source is visible, versioned, testable, and changeable in a way a processing rule never is.

That default is not the whole story, though, because Launch is not always available or sufficient. Three situations put a processing rule firmly in the right:

• There is no tag manager to run. A mobile app has no Launch executing inside it, and server-side or API-collected data has no page for a tag to run on. A processing rule acts after collection, so it works no matter where the data came from.
• You cannot wait. A code or tag change rides the next release, and for a mobile app that release can be weeks out and outside your control. A processing rule is live the moment you save.
• The value only exists after collection. Context data is meaningless until a rule maps it, and in a context data or Web SDK setup, processing rules are how those incoming fields become props and eVars.

The deeper point is that these two are not rivals fighting over the same ground. They sit in different layers. Launch shapes data on the way out, in the browser or app, before the hit is ever sent. A processing rule acts inside collection, on the raw hit, on Adobe's servers, before storage. Neither is superior; they are different moments in the same journey, and the skilled choice weighs your platform, your urgency, and whether the fix belongs at the source or after it.

A checklist to carry into production

Before you enable any rule in a live report suite, walk this list. It is the whole module compressed into nine questions.

• Could this be fixed at the source, in the implementation or Launch, instead? If yes, prefer that.
• Are you building and testing in a non-production report suite first?
• Have you sent the hits the rule should ignore, as well as the ones it should catch? A condition that has never met a hit it must skip has not been tested.
• Is any variable written by both the tag and a rule? Reduce it to one owner.
• Does every overwrite have an "is set" guard on its source, so it cannot blank good data?
• Is the rule order correct, with reads placed above the overwrites they depend on?
• Have you written a clear Reason (who asked, and why) and given the rule an understandable name?
• Once proven, have you copied it to the right suites and kept them in sync?
• Is this genuinely a processing-rules job, or does it belong to Classifications, Marketing Channels, or VISTA?

That closes the first tool in the shaping layer. Processing rules are immediate, server-side, and deliberately narrow, and used with discipline they turn raw collection into data you can trust, while used carelessly they quietly corrupt it. The heavier instrument begins exactly where this one ends. When a requirement outgrows conditions and actions, when you need visitor-level logic or a transformation these three actions cannot express, that is the territory of VISTA Rules, the Adobe-managed layer that sits just past processing rules.