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
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:
The crucial bit is the condition, specifically the operator — “Does Not Start With”.
Page on http://my.site.com/landing.php?cid=abc 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 http://my.site.com/landing.php?cid=je_123 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 http://my.site.com/home.php is viewed by someone?
There is no “cid” URL parameter here.
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.
Here we go:
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:
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:
And the resulting data is good:
Nice little gotcha, isn’t it?
So when you use Processing Rules, be positive or be negative, up to you. But always be precise!