Skip to main content
When implementing an A/B testing and personalization strategy across multiple websites, it’s 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. For a quick guide on locating the siteCode, see Find 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 doesn’t impact others.
  • Flexible testing: You can implement various testing strategies for different countries or sites.

​
Cons

  • Inefficient: Setup and maintenance require greater effort. Duplicating configurations and tests across different projects involves manual work, although the Automation API can streamline this process.
  • 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 live in one place for easier handling.
  • Easier global testing: You can conduct A/B tests smoothly across multiple regions.
  • Faster deployment: There’s no need to duplicate tests, goals, or segments for each individual site.
  • Unified data analysis: A single dashboard makes comparing performance across different countries and sites easier.

​
Cons

  • Increased performance impact: Every site loads a single script, even if the site doesn’t need some of its features.
  • 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 aren’t identical, you may need workarounds to address the differences.

​
Recommendation

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