Processing Rules – Positive or Precise

I came across an interesting gotcha last week when I was helping a German company troubleshoot their tracking.

They were sending in a prop and an eVar along with an event as payload on a custom link. The numbers for that custom link were a lot higher than the event and the instances on both the prop and the eVar.


I like a puzzle.

So I looked at the debug logs and found the same thing: I could see the hits carrying the information, but I could also see that it “didn’t make it”.

There are a couple of culprits in a situation like this (we mentioned them before):

I checked the settings, they looked good. I checked for VISTA Rules on the Report Suite and found one, but it didn’t modify this prop or eVar. Then I looked at the Processing Rules (it’s always the last thing you check, isn’t it?) and found a ton.

One rule actually did modify the “variables”, but it had a condition which had nothing to do with this case… but it was a “negative condition”. I’ll explain below.

Testing Processing Rules

Usually, troubleshooting web analytics is relatively easy. Because it all happens in broad daylight, you can check what a site is tracking using a debugger. Just look at the URL.

But Processing Rules (and VISTA Rules) are applied on Adobe servers. You cannot see the effects of these rules on your data. All you can see is the resulting reports.

When I put my developer hat on, I find that frustrating. I need instant feedback! How am I going to debug when I have to wait a couple of minutes, or when I’m not 100% sure what the data in the reports should look like?

Maybe I won’t even have access to the reports! How do I explain to my friendly marketer that I am sending specific values and how can I trust their judgement on whether the reports reflect what I sent?

Only one way that I know of: run end-to-end tests. Sit down with the marketer and plan exactly what we’re going to send in and what we expect to see.

You must define the expected results upfront! Failure to do so means you’ll see data and you’ll likely find a way to explain it. Don’t walk into that trap!


I decided to replicate the rule this customer had, but make it simpler.

My hunch was that the “negative condition” was the culprit. Let me explain, using the rule I made. Here it is:

Processing Rule with Negative Condition
The crucial bit is the condition, specifically the operator — “Does Not Start With”.

Two examples

Page on is viewed. The “cid” URL parameter does clearly not start with “je_”, so we would expect the rule to fire and therefore event6 should be set on this hit.

Page on is viewed. In this case, the “cid” parameter on the URL does start with “je_”, so we would expect the rule to not fire. The event should therefore not be set on this hit.

So far so good.

Unfortunately there is a third case.

What about when the page on is viewed by someone?

There is no “cid” URL parameter here.

Easy, right?

Yup, easy. The rule does fire.

It turns out the “Does not” rules are literally a negation of their “Does” counterparts.

The system tests whether “cid” starts with “je_” and since it clearly doesn’t, the condition is met and the rule fires.

Need proof?

Here we go:

Test Hits in Charles
I sent 8 hits in total, 2 with “cid=abc”, 2 with “cid=je_123” and 4 without a “cid” parameter.

This is what I got:

Test Results (event5)
If you expected a “2” here, you’re not alone. But the hits without a “cid” are clearly being counted, hence the “6”.

So how do we fix that?


Rules can have more than one condition. All you need to do is make it more explicit.

And let’s be honest, when you used “URL parameter cid does not start with je_”, you actually meant “if there is a URL parameter cid, it must not start with je_”.

This is exactly how you fix this:

Better Processing Rule
And the resulting data is good:

Test Results (event7)
Nice little gotcha, isn’t it?

So when you use Processing Rules, be positive or be negative, up to you. But always be precise!

4 thoughts on “Processing Rules – Positive or Precise

  1. Ah, bitter experience. It teaches the most memorable lessons 🙂
    These processing rules are really helpful but the constraints and disadvantages (the debugging one you mention, longer-term maintenance and config mgmt..) have lead me to use them as only as interim solutions for measuring web applications. I can get these badboys live while I queue-up a JS-based solution.


    1. I wonder how long-term maintenance will pan out, but I would point out that the days of doing everything in one place (the s_code.js file) are over and have been for some time now.

      Report settings, plugins, VISTA rules, Marketing Channels, Processing Rules, Tag Management, all these are moving parts and they all play together.

      I fully agree that you should keep complexity down, but there are some really good use cases for Processing Rules, see post from last week.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.