Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Context Variables and Processing Rules.

tobyc49922805
Level 4
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
brian_au
Correct answer by
Level 9
Level 9

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
brian_au
Correct answer by
Level 9
Level 9

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