Processing Rules: difference between put condition in "All the following are true" and put it in "Then do the following"?

[OscarMM]

Hi all, 

I'm confused about when put Processing Rules condition in "All the following are true" and put it in "Then do the following"?We have an issue because we should assigned eVarY only when value in eVarX does not equal 0. But it looks rule is not working. Currently condition is in "Then do the following" area. Is that correct? Is the issue because of that? Or it doesn't matter where to put condition on this case?

Thanks, 

[yuhuisg]

In general, there are 2 parts to a Processing Rule: the conditions and the actions.

The "If All/Any of the following are true" section lets you specify the conditions that your Rule must match to.

The "Then do the following" section lets you specify what the Rule should do after the conditions are met.

So in your case, you want to put your eVarX condition under the "If All of the following are true" section. Then put your eVarY action under the "Then do the following" section.

To allow for more complicated actions, you can also add conditions to an action. But in your case, I don't think you need that level of complexity.

Here's an example of when you would add an action that has its own condition (in bold):

• If All of the following are true:
  • Query String Parameter "token" is set
• Then do the following:
  • Overwrite value of eVar10 With Query String Parameter "token"
  • Overwrite value of eVar11 With Query String Parameter "token" If Query String Parameter "secret" Equals "foobar".

What happens here is that when the Rule processes a hit where the URL contains the query "token", then eVar10 will always be set with that "token" value, but eVar11 will only be set when there is another query in the URL with "secret=foobar".

[OscarMM]

Thanks for you response. This is the thing.

Someone in the company, before me, implemented a Processing Rule setting up the condition in "Then do the following" section. I don't really know the reason why.

But we have an issue because we the idea is to setup eVarY only when eVarX=0. When checking the data in a Workspace Dashboard we find eVarX=0, eVarY=abcd. So, eVarY is assigned even when rule should filter it.

Could be possible issue is because condition it's in "Then do the following" section instead of first one? In any case, we already changed location of condition to see what happens.

[yuhuisg · Accepted solution]

I think the Processing Rule is working as expected, in a manner that is similar to the one that I had described in my example.

So in your case, eVarX is always getting set. But when eVarX = 0, then eVarY also gets set with the value "abcd". But for all other values of eVarX, eVarY should be "Unspecified". Read that again: only when eVarX is 0, then set eVarY. It's not checking eVarY first before setting eVarX.

So your statement "So, eVarY is assigned even when rule should filter it." is invalid. No filtering occurs here (assuming I'm reading your problem correctly).

It might also help to show a screenshot of your original Processing Rule.

[OscarMM]

Sorry, I mean we want to populate eVarY only when eVarX != 0 (not equal).

To validate if condition position was the issue, we moved it last Friday to first section. But issue still there.

Please take a look to this screenshot:

 This is last Friday implementation:

I know, it's a small %. But we still think it shouldn't happen.

[yuhuisg]

In your Rule, your first condition is that eVar24 is not set. So could it be that eVar24 is already being set in the implementation tracking code? In that case, since it has a value when the Rule runs, then the Rule gets ignored and AA dutifully reports that eVar24 value.

[OscarMM]

Hi @yuhuisg. In client side eVar24 is not assigned. But to be sure I did some changes to rule to remove explicitly eVar24 value when Flag=0. No result, issue still there.

[yuhuisg]

Then I wonder whether the "0" is the culprit? From experience, sometimes AA doesn't "play nicely" with 0s.

Can you change your rule to make a test? Instead of "0", use another number, like "1". Then see if you still encounter the same problem.

[OscarMM]

Hi @yuhuisg 

Changing that value is not possible in an easy way. We have several websites and apps and also several development teams. Changing that value would be difficult. By the moment for testing is not possible.

Yesterday, again I did a new testing. I'm sure something wrong with Rule. Look at this:

[yuhuisg]

When you ran your report, was it for the duration after you had made your latest Processing Rule change (the new testing one)?

If it is, then I suspect the "0" could be the culprit.

Can you try switching your rule conditions to test for eVar145 = 1 instead? I.e.

Rule 1: If eVar24 is set, delete eVar24

Rule 2: If IP Address is set and eVar145 = 1, set eVar24 with the IP address.

In the above, Rule 1 ensures that eVar24 is absolutely blank before Rule 2 runs. In that way, you can be sure that eVar24 has a value only when Rule 2 succeeds.