EvlPixel

Meta pixel Sign in Get started

Fanvue tracking links: what they measure and what they do not

Fanvue’s native tracking links are better than their reputation and more limited than their name suggests. This is where the ceiling sits, field by field, and what the per-impression metadata channel is actually for.

What the feature actually is

A Fanvue tracking link is a small object with a name, a channel label and a short code. Creating one takes two required fields: name and externalSocialPlatform. The platform must be one of eight enum values — facebook, instagram, other, reddit, snapchat, tiktok, twitter, youtube. Everything else is computed by Fanvue and read back.

What comes back is more than most people realise, which is why the ceiling catches them out later. One thing worth knowing before building against it: the field named linkUrl is documented as “Tracking link URL”, and the example value the reference gives for it is fv-123. It holds a short code, not a URL. It is the kind of naming that costs an afternoon if you assume otherwise.

Three attribution models sitting in one feature

This is the part nobody mentions. Fanvue’s tracking surface does not use one attribution model. It uses three, and they disagree with each other by design.

acquiredSubscribers is documented as first-click attribution, with the parenthetical that users are only counted for the first link they clicked. totalSubscribers is a current-state count of everyone who clicked this link and is an active subscriber right now, regardless of who acquired them. On the webhook, tracking.metadata is documented as the latest tracking-link impression metadata for this creator, which is last-touch.

Then there is the field that will bite you.

{
  "type": "creator.subscription.activated",
  "data": {
    "price": 999,
    "purchaser": { "uuid": "fan-uuid", "email": null },
    "tracking": {
      "link_url": "https://fanvue.com/creator-handle?fvc=spring-promo",
      "metadata": { "campaign": "spring-promo", "source": "x" }
    }
  }
}

Note the shape before the semantics. On the API object, linkUrl is a bare code. On the webhook, link_url is a full destination URL carrying the code in an fvc query parameter. Two fields, near-identical names, different shapes — so joining a webhook back to a link means parsing the query string, and defending against the bare code arriving instead.

Fanvue documents this plainly rather than hiding it, which is to their credit. It is still the single most common way a home-built attribution script goes quietly wrong.

Which events carry any of it is worth checking before you build. tracking is an object | null on creator.payment.succeeded, on creator.subscription.activated and on creator.follow.created. The post-liked and post-commented events carry no tracking block at all. Checkout-link events do not carry one either — those attribute through client_reference_id and their own passthrough metadata instead, which is a separate mechanism with a separate shape.

The renewal case matters more than it looks. The documented example for creator.subscription.renewed shows tracking: null. Attribution is present at inception and absent on every billing cycle after it, so anything that wants to credit renewal revenue to a source has to store the first-touch result itself and carry it forward. Nothing on the platform will re-state it for you.

The first-click rule has a consequence worth planning around too. Because a fan is only counted against the first link they clicked, a retargeting link will under-report against your prospecting link permanently. That is not a bug. It is correct behaviour for a first-click model, and it is the wrong number to judge retargeting on.

The money question, answered fairly

Tracking links do report revenue. Anyone saying otherwise has not read the schema. The earnings object carries totalGross, documented as total gross earnings from the link before fees, and totalNet, after fees. On a freshly created link the whole object is null, which the reference states explicitly.

The honest version of the limitation is narrower and more interesting than “no revenue data”. The number is a lifetime running scalar with no timestamp attached. There is no time series. The createdAfter and createdBefore filters on the list endpoint are documented as filtering links created on or after, and before, an ISO datetime — the link, not the money. There is no per-event breakdown, so a subscription and a tip are the same pound in the same total.

The earnings fields also carry no currency field and state no units. Webhook payloads are explicit on both counts: amounts are integers in the currency’s minor units, and resources carry an ISO 4217 currency. The tracking-link schema says neither. Fanvue settles creator earnings in USD cents, so USD cents is the reasonable inference — but it is an inference, and it is worth confirming against your own numbers rather than trusting it.

The structural consequence is the whole story of this page. Meta’s Conversions API wants a per-event value, a currency and an event_time, and it will not take an event older than seven days — if any event_time in a batch is further back than that, Meta rejects the entire request and processes none of it. A lifetime total has no event time and cannot be given one. You cannot derive per-event signal from an aggregate. This is not Fanvue doing analytics badly — it is an analytics number being asked to be an ad-optimisation signal, which is a different kind of object.

There is no campaign, only a channel label

externalSocialPlatform is the closest thing to a campaign concept, and it is a fixed enum of eight channel names. There is no campaign, no ad set, no ad. The enum does not map cleanly onto Meta either: Advantage+ placements is the default, and it delivers one ad set across Facebook, Instagram, Messenger and Audience Network at once. Being made to pick a single platform describes something the ad platform is actively trying not to distinguish.

The API reference lists create, list, delete, list users and get metadata, plus the agency-side equivalents of each. There is no update endpoint documented. A link’s name and platform are therefore effectively fixed — changing them means delete and recreate, and a new link starts with clicks at zero and earnings null. What becomes of the deleted link’s history is not documented at all; the delete endpoint says only that it returns 204. Whatever you encode in name at creation, you live with. Name them so they sort, and so a stranger could read the name in six months.

The per-impression metadata field is the interesting part

Among the tracking-link endpoints is the only field on the whole surface that belongs to you rather than to Fanvue.

The metadata endpoint returns custom metadata from the user’s most recent impression on the link: an object of arbitrary keys with string values, or null. The same data arrives pushed to you as tracking.metadata on the events listed above, scoped to your creator account.

That is a per-fan, per-impression, creator-scoped free-text channel that survives from click through to conversion. Every other field is an aggregate Fanvue computed for you. This one carries whatever you put in it.

Do not confuse it with its neighbours. On creator.payment.succeeded, the top-level client_reference_id, transaction_id and metadata are documented as always null, present so the payload keeps the same shape as the checkout events. The nested tracking.metadata is the one that carries anything.

Two things govern its use. The semantics are most-recent-impression, so a second click overwrites the first — whatever you store must resolve on its own, not depend on being the first touch. And the pull endpoint is keyed by both link uuid and user uuid, so you must already know which fan you are asking about. It is a reconciliation tool, not a discovery tool. Discovery comes from the users endpoint.

What to do with the links alone

You can get a long way before needing anything else, and most creators never exploit half of this.

• Make one link per creative, not per channel. The platform value is only a label; nothing stops eight links all marked facebook. Fanvue’s help centre states you can create unlimited tracking links. Cardinality is free, so spend it.
• Measure the lag with the right timestamp. The users endpoint returns four, and they are not interchangeable. clickedAt is when the fan first clicked this link. registeredAt is when the fan converted via this link. subscribedAt is when they subscribed to the creator at all, attributed to this link or not. The distribution you want is clickedAt to registeredAt; reaching for subscribedAt because the name reads better quietly mixes in fans this link never converted.
• Compute retention per link yourself. status is subscriber, follower, expired, deleted — or null. Expired is documented as a subscription that ended, so expired against still-active, per link, is a usable churn proxy. Traffic sources vary enormously here and no aggregate counter will show it.
• Compare totalSubscribers against acquiredSubscribers. A wide gap means the link is mostly clicked by people who were already yours. That is a re-engagement link, and judging it by acquisitions alone gets it switched off for the wrong reason.
• Page properly. The list endpoints default to a limit of 20 and paginate by cursor. Read only the first page and you will draw conclusions from your twenty newest links. No maximum limit is documented for these endpoints, which is not the same as there being none — /insights/earnings, for comparison, caps at 50 and answers a larger request with a too_big validation error.

Where the ceiling actually is

Fanvue’s tracking links tell you how many people clicked, who those people are, what happened to them, and how much money the link has produced in total since it was made. That is a well-built feature and it answers the question it was designed to answer: which channel is working.

It does not tell you which of your ads it was, because there is nowhere to put an ad id. It does not tell you when the money arrived, because the earnings total has no time dimension. And it does not push anything outwards, because it is a reporting surface inside Fanvue, not an attribution pipeline.

Common questions