EvlPixel

Meta pixel Sign in Get started

Fanvue attribution for agencies

Attribution that works for a single creator can mis-credit a roster of six without ever producing a number that looks wrong. This is where it breaks, why the totals hide it, and what a per-creator key has to carry.

Why a roster breaks a join that worked fine for one creator

Attribution is a join. A click on one side, a conversion that happened on fanvue.com hours or days later on the other. Every tool has to decide which click a conversion belongs to, and every tool has cases where it is not certain.

With one creator, uncertainty is harmless. There is only one creator, so any conversion that arrives belongs to them. Every ambiguous case resolves correctly by accident, and a tool can be sloppy about the join without ever showing it.

Put six creators behind the same workspace and each ambiguous case becomes a choice between six answers. The tool still returns one. It is simply wrong some of the time now, and wrong in a direction nobody audits.

The failure is invisible because the totals are right

Mis-crediting conserves the total. One conversion, one click, one credit — assigned to the wrong creator. The roster-level numbers stay exactly correct while every per-client number rots.

A worked example. Six creators, one month, $18,400 spent, 512 subscriptions. Assume eight per cent of conversions arrive without a click identifier and fall through to a weaker tier that picks the most recent unmatched click in the workspace. That eight per cent is a stated assumption for the example, not a measured rate. Misdirected credit flows towards whoever has the most recent click volume, which is the creator with the cheapest traffic.

Creator	Spend	Subs (true)	Subs (reported)	CPA (true)	CPA (reported)
A	$2,100	214	238	$9.81	$8.82
B	$3,200	96	107	$33.33	$29.91
C	$2,800	71	77	$39.44	$36.36
D	$4,100	63	55	$65.08	$74.55
E	$3,400	41	27	$82.93	$125.93
F	$2,800	27	8	$103.70	$350.00
Total	$18,400	512	512	$35.94	$35.94

Total spend, total subscriptions and the $35.94 blended acquisition cost are all correct. Every per-client figure is wrong, and two are wrong enough to change a decision. F reads as a $350 acquisition against a real $104, and gets cut. E reads as $126 against a real $83, and gets its budget trimmed. A reads as the star and receives money it cannot absorb.

Note what these numbers are not. At an average first charge of around $12, a $35.94 acquisition cost is not a loss — it is a subscription business recovering over renewals, unlocks and tips. That is the whole reason per-client accuracy matters here: the decision to cut a creator is being taken on a first-month figure that only makes sense in the context of what their fans go on to spend.

What one shared pixel does

The second failure is cruder and easier to spot once you know to look for it. If conversions go to every pixel configured in the workspace rather than only the pixel belonging to the creator who earned them, every client’s dataset receives every other client’s conversions.

Meta’s asset model makes this worse than a reporting nuisance. A pixel is owned by a business, and that business shares it with an agency by granting named tasks. Meta documents UPLOAD as uploading website conversion data to the dataset and ADVERTISE as connecting ad accounts to it. The grammar of that model is unambiguous: the dataset is the client’s property and the agency is a guest in it. Writing another creator’s subscription values into it puts one client’s revenue inside another client’s asset.

What makes the leak survive is that nothing looks broken. The events carry an fbc rebuilt from a click on a different ad account’s ad, so the receiving account has nothing of its own to credit them against, and they tend not to surface there as attributed conversions. That last part is reasoning from how attribution works rather than something Meta documents — but the dataset is polluted either way. Value-based lookalikes and any audience built from purchasers now include a stranger’s buyers, and the external_id sent with each event — the Fanvue user uuid, which is the only stable person-level key on offer, because Fanvue’s webhook payload carries the purchaser email as null — identifies another creator’s fans.

The per-creator key

A filter added to the report cannot fix this, because a filter cannot recover information the join already discarded. The creator has to be part of the key from the click onwards.

On Fanvue the raw material is already there, because of how the links are minted. Each creator authorises separately, and the connection holds that creator’s own access token. Fanvue documents six write: scopes; the only one this integration was granted is write:tracking_links, and it arrives alongside openid, offline_access and a third system scope, offline. A tracking link is created with one creator’s token, inside one creator’s account, so the resulting fvc code names exactly one creator.

It is worth being precise about the limit of that argument. Fanvue does publish agency scopes, and what they cover is the agency’s team members and invites — not a roster-wide key that mints links across creator accounts. Nothing in the public scope list describes one. Whether something equivalent exists internally is not visible from outside, which is the actual reason to carry creator identity in the tool rather than infer it: not that Fanvue cannot disambiguate, but that an integrator cannot verify that it does.

So creator identity is carried at every hop, and never has to be guessed:

ad click   ->  /r/spring-a          slug belongs to one link
                                 link belongs to one Fanvue connection
                                 connection belongs to one creator

           ->  fanvue.com/handle?fvc=fv-123456&metadata[fvp_cid]=c8k2m9x

webhook    ->  tracking.metadata.fvp_cid = c8k2m9x     the exact click
               tracking.link_url ...?fvc=fv-123456     the creator's link

dispatch   ->  SELECT * FROM destinations
                WHERE tenant_id = ? AND status = 'active'
                  AND (connection_id IS NULL OR connection_id = ?)

The bracketed metadata[...] spelling is Fanvue’s documented form, and it is worth matching exactly rather than trusting a parser to normalise a percent-encoded version of it. That one parameter is the entire join.

The weaker tier matters as much as the strong one. When a conversion names a link but carries no click id, the fallback has to be scoped to that link — newest unmatched click on fv-123456, not newest unmatched click anywhere in the workspace. It is one extra join, and it is the entire difference between the true and reported columns above.

Note the connection_id IS NULL branch. That is the single-creator default, and it means every creator here. It is correct for a workspace with one creator and wrong the moment a second is added. Any tool that grew up serving solo creators has that default somewhere.

One pixel per client, and the volume objection

Splitting a roster into one dataset per client is the right answer, and the objection to it deserves a straight hearing rather than a dismissal. The objection is the learning phase. Meta marks an ad set learning limited when it is unlikely to receive around fifty optimisation events in a week, and among Meta’s own suggested remedies is combining ad sets and campaigns. Six datasets each carrying a sixth of the events sounds like six times that problem.

The argument is weaker than it sounds, and the reason is in the definition. Those fifty events are counted per ad set, against that ad set’s own optimisation events. Another creator’s subscription is not one of them, whichever dataset it lands in. Pooling six creators into one pixel does not lift any client’s ad set out of learning limited; it puts five other creators’ conversions somewhere this client’s ad set will not count them. The consolidation buys less than the agency thinks it is buying.

What pooling genuinely feeds is the dataset-level machinery — audiences, value-based lookalikes, anything fitted on the set of people who converted. That is also precisely the machinery the contamination corrupts. A model fitted on a blended roster fits the blend, and where the creators’ audiences differ, the blend describes none of them accurately.

Ownership settles what is left. The dataset outlives the engagement: a client who leaves takes a pixel with a clean history, while a client whose pixel is full of six other creators’ buyers takes a liability. Where volume genuinely binds, the honest lever is fewer and larger ad sets inside one client, which is the unit the learning phase actually measures — not fewer datasets across clients.

What to demand of a tool

These are things to verify, not questions for a sales call.

• Prove the isolation. Connect two creators. Put a test event code on client B’s destination only. Convert on creator A. B’s Test Events tab should stay empty. Ten minutes, and it settles the largest question on this page.
• Ask what happens when the click id is missing, and whether that query is scoped by link. If the answer involves IP address, walk away: the conversion arrives as a server-to-server webhook from Fanvue, so the IP on it belongs to Fanvue’s own infrastructure rather than to the fan. There is no fan IP at conversion time to compare the stored click’s IP against, so an IP tier can only hand whichever click was newest to whichever fan converted next.
• Ask what adding a second creator does to an existing pixel. If it silently starts receiving the new creator’s conversions, that is fan-out with the safety off.
• Ask whether every conversion records how it was matched — deterministic, named-link guess, or unattributed — and whether the client can see that field rather than only the agency.
• Ask what onboarding does with history. Fanvue’s earnings insights return earnings, not ad spend, from before the tool existed — settled in USD cents whatever the fan paid in, newest-first, cursor-paginated and capped at 50 records a page, with anything larger refused as a validation error. Backfill belongs in the dashboard as a baseline. Reported into the pixel as though the ads caused it, it is fabrication — and Meta limits the damage by design: if any event in a request is more than seven days old, it returns an error for the entire request and processes none of it.
• Ask how webhooks are registered per creator. Creating a subscription through POST /webhooks/subscriptions can fail with a 400 and an empty error body for some apps, so a working integration needs the app-level endpoint as a fallback. The two are not equivalent. Meta aside, Fanvue documents a per-subscription secret for API-registered webhooks and a single signing secret for the app-level one — so on a roster that one URL receives every creator’s events under one shared secret, and the creator has to be resolved from the delivery rather than assumed from the route.

Attribution as a contract term

The technical fix stops the mis-crediting. It does not settle the argument, because the agency and the client are reading two systems that will never agree.

Meta’s attribution settings offer click windows of one day or seven days, so seven is the longest credit a click can be given. A fan who subscribes on day two and spends for eight months produces revenue the agency can see and Ads Manager will not credit. The agency’s dashboard therefore shows a better return than the client’s Ads Manager, permanently, in the agency’s favour. That is a genuine effect and also precisely what a dishonest agency would claim, which is why it has to be written down before the first invoice rather than explained after a bad month.

Three things belong in the contract:

• Which system the invoice is calculated from. Pick one. If it is the agency’s, the client gets read access to it.
• What counts as attributed. A deterministic match, a named-link guess and an unattributed conversion are three different things, and a commission agreement should say which are billable. An unattributed conversion is not automatically a failed match — a fan who arrived without ever touching an ad has no click to find, and reporting that honestly is different from guessing them onto the nearest campaign.
• Who owns the dataset. The client’s business should own the pixel and grant the agency partner access with the tasks it needs. An agency that creates the pixel inside its own business ends up holding the client’s conversion history by accident, and the accident becomes an accusation the day the relationship ends.

One case has no clean answer. The same fan subscribes to two creators on the roster, through two paid clicks. Both clicks are real, both clients paid, and both conversions are correctly attributed. Fans are stored per connection, so that person is two records with two separate histories — which is right for each client’s pixel and wrong for the roster roll-up, where one person counts twice. Whether Fanvue’s user uuid is even the same value on both sides is not something one creator’s connection can see. That is a modelling decision rather than a bug, and it should be stated in the report rather than quietly resolved in whichever direction flatters the agency.

Common questions