Skip to main content
When implementing an A/B testing and personalization strategy across multiple websites, it is important to decide whether to use a separate project (one siteCode) for each site or adopt a single shared project for all sites. This choice affects performance, scalability, test deployment, and overall management ease. This guide compares both approaches, highlighting their pros and cons to assist you in selecting the most suitable structure based on your specific needs. Click on this link for a quick guide on locating the siteCode.

​
One project (siteCode) per site

​
Pros

  • Granular team management: Assign specific permissions for each site or project.
  • Independent configurations: Each project can have its own unique goals, experiments, and integrations. Additionally, you can easily replicate tests, goals, and segments across different projects when necessary.
  • Easier debugging and risk isolation: An issue in one site does not impact others.
  • Flexible testing: Various testing strategies can be implemented for different countries or sites.

​
Cons

  • Inefficient: There is a greater effort required for setup and maintenance. Duplicating configurations and tests across different projects involves manual work, although this process can be streamlined with the Automation API.
  • Greater complexity: Managing global test complexity can be more challenging when running tests across multiple sites, as it necessitates duplication and manual aggregation of results.
  • Maintenace: Maintaining consistency becomes more difficult, as ensuring identical configurations across sites poses challenges. Additionally, each project requires separate integrations with third-party tools, leading to increased integration effort.

​
One project (siteCode) for multiple sites (shared siteCodes)

​
Pros

  • Simplified management: Goals, segments, and third-party integrations are centralized for easier handling.
  • Easier global testing: A/B tests can be conducted smoothly across multiple regions.
  • Faster deployment: There’s no need to duplicate tests, goals, or segments for each individual site.
  • Unified data analysis: Comparing performance across different countries and sites is made easier with a single dashboard.

​
Cons

  • Increased performance impact: A single script is loaded across all sites, even if some features are not needed.
  • More complex targeting: Additional criteria, such as URL patterns, are necessary to ensure that experiments only affect relevant users.
  • Higher risk exposure: Problems in the shared script (for instance, the global custom script) can impact all sites.
  • Limited flexibility: If the sites are not identical, workarounds may be required to address the differences.

​
Recommendation

Use separate projects when sites are significantly different or when independent control over team permissions, integrations, and experiments is needed. Use a shared project if the sites are largely identical, allowing for unified data and simpler test deployment.