Attribution for agencies running ten brands at once

An account manager exports a performance report on a Friday and sends it to a client. Row 40 of the spreadsheet, well below where anyone scrolled, contains a campaign belonging to a different brand in the same category.

Nobody notices for eleven days. Then somebody does. (Composite, drawn from incidents agencies have described to us afterwards.)

The failure nobody sees until it happens

Agency attribution has a requirement that in-house attribution does not: the data has to stay separated by client, permanently, under conditions nobody anticipated.

That requirement is invisible during evaluation. Every tool demos beautifully with one brand loaded, and the isolation problems surface months later, in an export, a shared login, or a creator working with two of your clients at once.

The distinction that matters is where separation happens. Storage-layer isolation means each client’s data lives in its own scope and a bug produces an error. Report-layer filtering means everything lives together and a bug produces a leak.

Storage isolation, not report filtering

Ask any vendor one question: if the client filter were removed from the query, what would the report show?

If the answer is everything, the tool is single-tenant with a dropdown. That is a perfectly reasonable architecture for a brand and an unacceptable one for an agency, because every safeguard depends on a filter being applied correctly on every code path forever.

Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients.

Korant is not for stores with a single paid channel, or for brands that only need Shopify’s native reports. A single-brand client running one channel does not need any of this, and an agency should be able to say so rather than putting every account on the same tooling by default.

The tenant-isolation test

Seven checks. Run them during evaluation, not after signing.

Check	What to test	Pass condition
Identifier namespace	Create the same slug for two clients	Both succeed, independently, with no collision
Cookie scope	Inspect the cookie domain set at redirect	Scoped to the client’s own domain, not the agency’s
Export boundary	Export a report and read every row	No row references any other tenant
Role separation	Give a user access to one client	That user cannot enumerate other clients at all
Token scope	Use a client’s API token against another client’s data	Rejected, not filtered
Deletion	Offboard a test client	Data exportable to the client and removable from your systems
Aggregation	Open the portfolio view	Aggregates only, with no path to per-client drill-down for unauthorised users

The namespace check is the one most likely to fail in practice. Two clients in the same category eventually work with the same creator, and slugs derived from creator names collide immediately. A tool that responds by silently reusing an existing slug has just attributed one client’s sales to another’s report.

The cookie scope check is the subtlest. A single agency-wide cookie domain means one browser carries identifiers set by every brand you run, which is a customer’s presence at one client becoming visible to another.

Per-client rules, agency-wide standards

Resist the urge to impose one attribution rule across the portfolio.

Buying cycles differ, so windows differ. Channel mixes differ, so priority orders differ. A skincare refill brand and a furniture brand forced onto the same 7-day window produce two reports, one of which is approximately right and one of which is badly wrong.

The agency standard should be procedural rather than numeric: every client has a documented rule, the rule is stored with the client, and it changes only at quarter boundaries. The reasoning behind that structure is in building a single source of truth for marketing spend, and it applies per tenant rather than per agency.

Keep a register of which client uses which rule. New account managers inherit accounts without inheriting context, and an undocumented window becomes an unexplained number three months later.

The portfolio view that does not leak

Agencies need a cross-client view for real reasons: staffing, spotting a platform-wide anomaly, knowing which accounts need attention this week.

Build it from aggregates only. Category medians, portfolio totals, count of accounts outside a normal range. None of those identify a client to anyone reading them.

The moment a portfolio view contains a named per-client column, it is client data outside its tenant, and internal-only is not a durable property of a spreadsheet. It gets pasted into a deck, and the deck gets sent.

Benchmarking is worth doing and worth constraining. A median CAC across ten clients in a category is genuinely useful to every one of them and reveals nothing about any of them. A ranked list of ten named brands is the same information arranged to cause a problem.

Check the client agreements before building either. Some contracts prohibit aggregate use of client data outright, and finding that out after building the benchmark is expensive.

Onboarding and offboarding as data events

Onboarding is where isolation is either established or quietly skipped. New tenant, new namespace, new tokens, new cookie scope, documented rule. Skipping any of those under time pressure creates a problem that surfaces months later with no obvious cause.

Offboarding is the step almost nobody has a process for. When a client leaves, their attribution history should be exported to them and removed from your systems on a stated schedule.

Tools with no deletion path accumulate former clients indefinitely. That is a growing liability, it is invisible until somebody asks, and the question usually arrives from a lawyer rather than from a marketer.

What clients will eventually ask you

Three questions, and having answers ready is most of the value of doing this properly.

Where does my data live and who can see it. Answerable in a sentence if isolation is at the storage layer, and answerable only with hedging if it is not.

What rule assigns my orders to channels. Answerable from the register, with the date it was last changed.

What happens to all of this if we leave. Answerable with an export format and a deletion timeline.

The honest limitation is that none of this makes the attribution itself better. Ten perfectly isolated tenants still each face the same problems any single brand faces: view-through inflation, unclaimed orders, and no causal answer without a holdout. Isolation prevents a category of incident and improves no client’s numbers, which is worth saying out loud when somebody asks why the tooling costs what it does.