Projects & configuration
Everything Fidero does for you happens inside a project. A project holds one configuration and one set of user profiles, and every event carries a project ID, which decides both the rules that apply to it and the profile it can join.
That makes the project the natural boundary between things that should behave the same and things that shouldn’t.
What a project holds
Section titled “What a project holds”A project scopes four things:
- The destinations that are enabled, and the credentials each one needs
- Consent settings, including any per-destination overrides
- The trusted domains that count as one property for identity
- Any custom overrides agreed for your setup
Profiles sit inside the boundary too. Two sites in one project share one view of each visitor. Two projects keep separate views, by design.
One config, both halves
Section titled “One config, both halves”The configuration lives on Fidero’s server. The browser SDK reads it by project ID when it loads, and the enrichment API reads the same record when events arrive, so there’s no second copy to fall out of step. When something changes, both halves pick it up on their next request.
The config holds the outcomes you’ve asked for and the credentials they need. Everything else about how events reach each tool is platform behaviour, not settings. The platform overview walks through the reasoning behind server-held configuration.
Changing it is a request rather than a deployment – Configuration & changes covers the day-to-day process.
One project or several
Section titled “One project or several”Split projects where behaviour should differ, and share one where it shouldn’t.
Separate projects suit separate environments: staging events shouldn’t land in
production analytics, and a staging project can point at test ad accounts instead
of live ones. Environments don’t need separate code – the same install runs
everywhere, and the project ID passed to init() picks which project it feeds.
The same split suits brands or products with their own tracking requirements, and
regions with different consent rules.
A single shared project suits domains that behave as one property: same destinations, same consent, and a visitor who moves between them stays one person. A marketing site and its checkout subdomain usually belong together for exactly that reason.
Restructuring later
Section titled “Restructuring later”Project structure isn’t permanent. Splitting or duplicating a configuration across new projects is a request like any other, and if a project ID changes, the only edit on your side is updating it in your install. Data already recorded stays in the project that recorded it.