If you have multiple websites or apps, you can create a Dynamic Yield section for each one, or manage all of them in one Dynamic Yield section entity. This can have a tremendous impact on your work and how you view reports. There is no one correct answer for all cases, so use this article to help you decide what's best for you.
Do you have a single user base for all websites and apps?
If users must create a separate account on each site, you should create separate sections in Dynamic Yield.
Do you have a single team or multiple teams working on your sites and apps?
In Dynamic Yield, permissions are defined for each individual section. If you use a single section, all your editors can edit in all domains. Separating them enables you to set one team as editors for section A and another team as editors for section B.
Do you use the same product catalog for your websites and apps?
If you have websites that are basically the same but set for different locales (say, one for EN and another for DE), you can set them up under one section and add an attribute for each product, stating different properties for each locale (for example, different name, price, availability in stock). Locale is determined in the <head> of the account. Learn more about multi-language support.
Do you run the same campaigns across your websites and apps?
If most of the campaigns are similar, consider using only one section. You can then target different websites as needed for each experience or campaign. When campaigns run across all websites, reports aren't broken down according to website. The same applies to the Audience Explorer.
Alternatively, you can maintain separate sections and, when needed, copy over templates, campaigns (for most of the campaign types), and evaluators. Some entities can't be copied and must be manually recreated for each site (including multi-touch campaigns, audiences, goals, units, and email campaigns).
Advantages of site aggregation
- User data and history are consistent between all websites and apps.
- A larger user pool means quicker test results.
For example, this helps counteract long experiment durations in countries with little traffic.
- A larger data pool means smart algorithm logic.
For example, the recommendation strategy Viewed Together is based on the user behavior of all users, combined.
- It takes less effort to maintain campaigns.
For example, you don't need to recreate audiences, strategies, and campaigns in different sections, but rather, you can build them once, and use the experience level to tailor content to the specific needs of each website or app.
Disadvantages of section aggregation
Popularity scores are calculated across all users in a section. As a result, some local preferences might be overshadowed by those of a location with higher traffic.
For example, a trend of green pants in Spain, compared to a trend of red pants in Germany. Due to traffic share, red pants will be more highly represented in recommendation strategies based on popularity.
When possible, we recommend that you minimize the number of sections. Consider your workflow: Is it just technically a different domain, but overall the same business? In that case, it is probably worth using a single or smaller number of Dynamic Yield sections. However, if your sites or apps represent different "businesses" (for example, for different brands), with different teams, goals, campaigns, and user bases, you should probably create a different Dynamic Yield section for each one.