Classification Sets Performance When Using Multiple Report Suites | Community
Skip to main content
AbhishekDhami
Level 2
March 7, 2026
Solved

Classification Sets Performance When Using Multiple Report Suites

  • March 7, 2026
  • 3 replies
  • 71 views

Hello everyone,

With the upcoming migration from traditional classifications to Classification Sets in Adobe Analytics, I had a question regarding performance optimization.

Previously, when using classifications, we had to create them separately for each report suite, even if the same variable existed across multiple report suites.

With Classification Sets, we can now create a single classification set and apply it to multiple report suites, which simplifies governance and management.

However, the official adobe documentation mentions two important points :

• Processing time improved from ~72 hours to ~24 hours
• Performance mainly depends on the number of unique key values, especially when combining variables from multiple report suites into a single classification set.

Scenario

Suppose we have the same variable (for example an eVar) across 8 report suites.

Instead of creating one classification set covering all 8 report suites, would it be better from a performance perspective to create:

  • Two classification sets

  • Each covering 4 report suites

The idea is that the number of unique key values processed in each classification set would be smaller, which might improve rule processing performance.

My Questions

  1. Does the unique key count get aggregated across all report suites within a classification set, or does Adobe internally deduplicate keys?

  2. From a performance standpoint, is it recommended to split high-cardinality variables across multiple classification sets instead of grouping many report suites into one?

  3. Are there any best practices or thresholds for unique key counts when designing classification sets?

Would really appreciate insights from anyone who has already tested this in production.

Thanks!

 

Reference:
https://experienceleague.adobe.com/en/docs/analytics/components/classifications/sets/overview 

Best answer by manpreetkaur27

Yes, unique keys are counted at the classification-set level, across all subscribed suites. They're not tracked separately per suite for processing; dedupe only happens when the key text is literally the same.

Regarding your second query, splitting is a last‑resort optimization, not a default pattern.

 

Recommended default:

For the same dimension (e.g., eVarX) used consistently across multiple suites, 

  • Create one primary classification set for that dimension.
  • Subscribe all relevant report suites (same eVar) to that set.
  • Use Consolidation if you already have legacy per‑suite sets and you want to merge them.
     

When you might consider splitting

Only consider separate classification sets for this eVar if all of the following are true:

  1. The eVar is very high cardinality, and each subset of suites contributes mostly distinct keys (little overlap).
  2. You see classification jobs regularly pushing against or beyond the ~24h target for that set.

Then splitting can reduce keys per set, which can shorten processing time. But that's a performance tuning exception, not the default pattern.

3 replies

Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
March 9, 2026

My old classifications were always set to multiple suites…. my main QA/Dev Suite, my “isolated” QA/Dev Suite and Production (since we use a global suite setup) were always set up using one singular Classification rule per dimension…. This isn’t new, but I fully understand what a pain it would be to manage multiple versions would be.

 

Are you using Rules or Importer for these classifications? If you are using Rules, I seriously doubt you will have any impact… if you are doing an importer rule, then it will depend on how many rows and columns you are dealing with.. but I would expect any noticeable performance issue would happen will millions of rows (the number of unique matches to process) and a lot of columns (the number of unique classifications)…  

 

If I were you, I would do them all as one… and IF you see an issue, then worry about splitting it only then…

I suspect you will be fine.

AbhishekDhami
Level 2
April 19, 2026

Thank you ​@Jennifer_Dungan and apologies for the delayed response.

Currently I am using Rule builder and Single rule for all report suites.

I’ll most likely proceed with a single Classification Set as well. I don’t anticipate any major performance issues, but since Classification Sets are relatively new, I just wanted to understand the recommended approach before implementing this in production.

Really appreciate your insights on this 🙂

manpreetkaur27
Adobe Support
manpreetkaur27Adobe SupportAccepted solution
Adobe Support
April 8, 2026

Yes, unique keys are counted at the classification-set level, across all subscribed suites. They're not tracked separately per suite for processing; dedupe only happens when the key text is literally the same.

Regarding your second query, splitting is a last‑resort optimization, not a default pattern.

 

Recommended default:

For the same dimension (e.g., eVarX) used consistently across multiple suites, 

  • Create one primary classification set for that dimension.
  • Subscribe all relevant report suites (same eVar) to that set.
  • Use Consolidation if you already have legacy per‑suite sets and you want to merge them.
     

When you might consider splitting

Only consider separate classification sets for this eVar if all of the following are true:

  1. The eVar is very high cardinality, and each subset of suites contributes mostly distinct keys (little overlap).
  2. You see classification jobs regularly pushing against or beyond the ~24h target for that set.

Then splitting can reduce keys per set, which can shorten processing time. But that's a performance tuning exception, not the default pattern.

AbhishekDhami
Level 2
April 19, 2026

Thank you ​@manpreetkaur27  and apologies for the delayed response.

This clarifies it really well. The point about unique keys being counted at the classification set level across all subscribed suites is especially helpful, as that was my main concern.

I agree that keeping a single classification set as the default approach makes sense, and splitting should only be considered as a performance optimization in specific high-cardinality scenarios.

I’ll proceed with a single classification set and monitor processing times, and only consider splitting if we start seeing delays beyond expected thresholds.

Appreciate the detailed explanation 🙏

manpreetkaur27
Adobe Support
Adobe Support
April 12, 2026

Hi ​@AbhishekDhami 
I just wanted to follow up here. Did any of these responses help answer your question? If so, please consider marking a best answer to close out the thread and help anyone else with this question find the answer in the future.