Expand my Community achievements bar.

Join us for the next Community Q&A Coffee Break on Tuesday April 23, 2024 with Eric Matisoff, Principal Evangelist, Analytics & Data Science, who will join us to discuss all the big news and announcements from Summit 2024!
SOLVED

Context Variables and Processing Rules.

Avatar

Level 4

Hi Everyone,

I'm looking to implement some new Report Suites in Adobe Analytics, hunting around it seems that using context data variables and processing rules will be much more efficient/consistent way to populate props, eVars and success events, however before we dive, take the test and start implementing, I just wanted to check:


Are there any limitations to the number of Context Data Variables that are allowed per report suite?

Are there any limitations to the number processing rules per report suite? - If we are using these to populate our props, eVars and successes the numbers could get pretty high.

Are there any disadvantages to using context data variables over the traditional sProp and eVar + Event tags.

Thanks

Toby

1 Accepted Solution

Avatar

Correct answer by
Employee

Hi Toby,

Please see my responses in line:

Are there any limitations to the number of Context Data Variables that are allowed per report suite?

There are no limits on context data variables and you are only limited by the Admin console variable mapped allocations.

Are there any limitations to the number processing rules per report suite? - If we are using these to populate our props, eVars and successes the numbers could get pretty high.

You are limited to 100 rules (expanded from 50 rules in February 2014) with 30 conditions each for each report suite. I recommend you set any mapped variables using a single Processing Rule rule. For example: (Always)

Set prop1 to product.type
Set prop2 to product.team
set prop3 to product.color

Are there any disadvantages to using context data variables over the traditional sProp and eVar + Event tags.

It potentially adds another step to your implementation process where the Admin has to do the processing rules mapping work, but processing rules provide many benefits. I recommend reviewing the Adobe help page (linked below) and watching the Overview video 'Processing Rules Overview' on the main page (linked below):

Reference Links:

https://marketing.adobe.com/resources/help/en_US/reference/processing_rules.html

https://marketing.adobe.com/resources/help/en_US/reference/processing_rules_about.html

https://marketing.adobe.com/resources/help/en_US/reference/processing_rules_tips.html

Best,

Brian

View solution in original post

1 Reply

Avatar

Correct answer by
Employee

Hi Toby,

Please see my responses in line:

Are there any limitations to the number of Context Data Variables that are allowed per report suite?

There are no limits on context data variables and you are only limited by the Admin console variable mapped allocations.

Are there any limitations to the number processing rules per report suite? - If we are using these to populate our props, eVars and successes the numbers could get pretty high.

You are limited to 100 rules (expanded from 50 rules in February 2014) with 30 conditions each for each report suite. I recommend you set any mapped variables using a single Processing Rule rule. For example: (Always)

Set prop1 to product.type
Set prop2 to product.team
set prop3 to product.color

Are there any disadvantages to using context data variables over the traditional sProp and eVar + Event tags.

It potentially adds another step to your implementation process where the Admin has to do the processing rules mapping work, but processing rules provide many benefits. I recommend reviewing the Adobe help page (linked below) and watching the Overview video 'Processing Rules Overview' on the main page (linked below):

Reference Links:

https://marketing.adobe.com/resources/help/en_US/reference/processing_rules.html

https://marketing.adobe.com/resources/help/en_US/reference/processing_rules_about.html

https://marketing.adobe.com/resources/help/en_US/reference/processing_rules_tips.html

Best,

Brian