Recommended library capacity in launch | Community
Skip to main content
Level 4
May 15, 2025
Solved

Recommended library capacity in launch

  • May 15, 2025
  • 3 replies
  • 632 views

Is there any recommendations or best practice on how many rules we can push to production in a single library? 

 

 

 

 

 

 

Best answer by Harveer_SinghGi1

Hi @aepaa ,

There is no specific or fixed recommended library size but definitely it is a good practice to monitor the overall size of the production environment and keep it as light as possible as that impacts your page performance.

Cheers!

3 replies

Harveer_SinghGi1
Community Advisor
Harveer_SinghGi1Community AdvisorAccepted solution
Community Advisor
May 16, 2025

Hi @aepaa ,

There is no specific or fixed recommended library size but definitely it is a good practice to monitor the overall size of the production environment and keep it as light as possible as that impacts your page performance.

Cheers!

Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
May 16, 2025

Yes, there is no specific recommendation, but even for your own sake, building your rules in a "smart" manner to avoid a lot of duplication is in your best interest...

 

For instance, I have one "Fundamental Tracking" rule, this rule triggers not only my Adobe Analytics, but other trackers, including all our various pixel trackers all from the same trigger... rather than having 10 different rules for each item that loads on a page view....

 

I also combine logic for different actions.

 

If I need to modify the triggers or conditions, I only have to do so once... not for every rule.

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
May 18, 2025

Fully agree to what has been said. Even if there is no official recommended maximum number of rules and data elements, the larger the number the slower your build time and potentially also execution time of tags due to an increased library size.

 

i typically aim for a generic approach where I try to boil it down to three essential rules.

  • one rule that sets commonly used analytics attributes and listens to ten same events as the two others
  • one "page_view" rule that sets additional properties that are only supposed to be sent in a page view like a campaign value and sets the specific event type if you are using web sdk or sends the AppMeasurement page view 
  • One "interaction" event rule that sets everything event-related. To identify which kind of interaction took place, I typically have an "action" attribute in the data layer that contains for instance a "click", or "submit". Plus, a "component" object that gives you the context of what component actually triggered the event. This typically covers most of my use cases.

So basically the underlying data layer has to make sure to only send these two events, so we are talking about an Event Driven Data Layer, and there are a few extensions you can use to react to these events like the recommended Adobe Client Data Layer or the Google Data Layer. 
I'm a big fan of EDDLs, since you don't have to set up additional rules to capture events and the page is ok charge of telling you what is happening when it's happening.

Cheers from Switzerland!