EvlPixel

Meta pixel Sign in Get started

Meta ads for a Fanvue page

Meta permits the link and constrains the creative, which forces a funnel whose conversion happens on a domain no pixel can reach. This is what Ads Manager sees instead, and what it does with it.

What the standards actually permit

The received wisdom is that Meta bans adult content advertising outright. The written standards are narrower than that, and the shape of the carve-out decides what the funnel has to look like.

The advertising standard on adult sexual solicitation lists, among the things advertisers may run when targeting people aged 18 or older, ads that “contain usernames, links to or logos of Adult Subscription Websites”. The link is not the problem. The creative is.

The separate standard on adult nudity and sexual activity is where the creative gets decided. Ads may not depict nudity or near-nudity, including nudity covered only by a digital overlay. They may not depict sexual activity, sexually suggestive activity, or gestures signifying it. They may not depict logos, screenshots or video clips of known pornographic websites.

Those two sit awkwardly beside each other. One names the logo of an adult subscription website as permitted to an 18+ audience; the other names the logo of a known pornographic website as prohibited outright. Which bucket a particular creator’s page falls into is decided at review, and no reading of the published text settles it in advance.

There is a third group worth knowing about. Imagery focused on individual body parts — the standard names groin, buttocks and female breasts — and people in sexually suggestive poses or revealing clothing sit under content that should be targeted to people over 18, not under content that is prohibited. Read literally, that is an age gate rather than a ban.

A fourth standard applies and is almost always missed, because it has nothing to do with nudity. Meta’s standard on subscription services requires an ad for a subscription to show price and billing interval clearly — not in fine print at the foot of a page, not buried in a privacy statement, not behind a separate link — and to say how to cancel. A Fanvue page is a recurring subscription. That obligation lands on the landing page, and a landing page built only to look safe for work usually fails it.

The trap inside the compliant funnel

Compliance forces safe-for-work creative, 18+ targeting, a destination that will not embarrass a reviewer, and the actual product one more tap away.

Meta ad (SFW creative, 18+)
   → your-domain.com/lp        ← pixel fires here, you own this
      → fanvue.com/creator     ← pixel is blind from here on
         → subscribe           ← the money
            → renewals, PPV, tips for the next six months

Every part of that is required, and every part of it is why the campaign cannot report a conversion. Fanvue’s published creator settings cover tracking links, subscription pricing, profile, automated messages and API keys; there is no field for a pixel or a custom script, and nothing in the API reference exposes one either. Absence of a documented feature is weaker evidence than a documented refusal, and this is the one claim on the page worth re-checking if Fanvue ships something. On the evidence available, the only pages a creator can instrument are the ones before the money.

What Meta actually sees

What happens	What Meta records
Ad is served	Impression
Tap on the ad	Link click
Landing page loads	PageView, if the pixel is on it
Tap through to Fanvue	Nothing, unless an event fires on the outbound tap
Fan subscribes for $9.99	Nothing
Renews on day 30	Nothing
Spends $240 on unlocks over three months	Nothing

Read that column downwards and the optimiser’s problem is plain: the best signal available to it is a page view on a page that exists to be left.

Some of that traffic never had a person behind it. Meta documents facebookexternalhit as the crawler that fetches shared and advertised URLs to build the preview card, and Meta-ExternalAds as a crawler that fetches for advertising and business products. Meta says most of its crawlers respect robots.txt, with a named exception: facebookexternalhit may bypass it when performing security or integrity checks such as looking for malware. Meta also asks for up to 24 hours for a robots.txt change to take effect, because crawlers cache the file for that long. So a Disallow is a preference with a lag, not a switch. Blocking it is the wrong instinct anyway: that fetch is what builds the ad’s preview card.

The practical consequence is a discrepancy otherwise worth a week of chasing. A crawler fetching HTML for a preview card is not running a browser session. A server-side redirect counts it as a click. The redirect log and the pixel will disagree, and the redirect log is the one lying.

Fanvue’s own numbers are better than the usual complaint

The standard dismissal is that Fanvue’s Fanvue’s own tracking links only count clicks. That is not what the API returns. A tracking link object carries clicks, an engagement object with acquired and total subscribers and followers, and an earnings object with gross and net revenue — null until the link has earned anything. Fanvue can already tell a creator which link made money.

Two things still break, and neither is an accuracy problem.

Acquisition is first-click by definition. The documentation is explicit that acquired subscribers and followers use first-click attribution and a user is only counted for the first link they clicked. A fan who arrives twice belongs to the earlier link permanently, so no retargeting link can ever be credited with the fan it converted.

And the number lives inside Fanvue. There is no path from that dashboard to a pixel, so however accurate it is, it trains nothing. The the webhook side has the same shape: renewals and later purchases arrive with tracking null, so a fan’s later spending is detached from the link that brought them unless something on your side stores the join on the fan record and re-applies it to every event that follows.

Two weeks of optimising on clicks

Delivery buys whatever event it is told to buy, as cheaply as it can. Point it at landing page views and it becomes very good at finding people who open a page. Cheap taps and buying intent are close to uncorrelated, which is why the outcome is worse than neutral.

Window	What is happening
Days 1–3	Delivery explores. The cheapest source of a landing page view is an idle tap, so that is the population it starts buying.
Days 4–7	Meta documents the learning phase as ending once an ad set reaches roughly 50 optimisation events in a rolling seven-day window since the last significant edit. Landing page views reach 50 far sooner than subscriptions would, so the ad set stabilises — on the wrong objective.
Days 8–11	Cost per click and cost per landing page view fall. The dashboard improves. Subscriber count does not move.
Days 12–14	Budget consolidates onto whichever creative harvests taps most cheaply. The creative bringing actual buyers has the worse cost per result and gets switched off.

The damage is not the missing conversion report; that was missing on day one. The damage is that two weeks of delivery data now describe a population selected for not buying, and the one creative that worked has been eliminated on the evidence of a metric unrelated to it. Turning conversion reporting on in week three undoes neither.

What can honestly be sent instead

The conversion has to be reported from a server, because there is no browser on the page where it happens. That is what the Conversions API is for. The hard part is not the request; it is having something truthful to put in it.

The join runs through Fanvue itself. The click is recorded on a domain the creator controls, where fbclid, fbp, IP and user-agent are still readable. A click id is minted and written into the metadata of Fanvue’s own native tracking link, so when that fan subscribes or tips, Fanvue’s webhook carries the click id back — a deterministic join through a third party, rather than guessing by IP and timestamp, which on mobile traffic behind carrier-grade NAT is not attribution at all.

That join either lands or it does not, and the honest thing is to record which. When the click id comes back on the webhook, the match is deterministic. When it does not, what remains is the Fanvue link the fan arrived on, then an IP and user-agent match inside a short window, then nothing. The last tier is the one that matters: an event with no click behind it is sent unattributed rather than guessed at, and it is labelled that way in the log.

Matching is where Fanvue’s API imposes a real limit. The webhook gives purchaser email as null, so there is no email to hash and no em parameter to send. What is left is external_id, fbc, fbp, client_ip_address and client_user_agent. Meta publishes the parameter combinations it treats as invalid on their own — city, country, state, postcode, gender and user-agent together; date of birth plus user-agent; first name plus gender; last name plus gender — and this set is not among them. It is a valid event. It is also weaker than an email-matched one, and Meta is explicit that only matched events can be used for ads attribution and delivery optimisation, with unmatched events remaining useful for basic measurement only.

{
  "event_name": "Subscribe",
  "event_time": 1755000000,
  "event_id": "conv_01J9...",
  "action_source": "website",
  "event_source_url": "https://your-domain.com/lp",
  "user_data": {
    "external_id": ["<sha256 of the Fanvue fan uuid>"],
    "fbc": "fb.1.1754900000000.IwAR...",
    "fbp": "fb.1.1754899000000.1116446470",
    "client_ip_address": "...",
    "client_user_agent": "..."
  },
  "custom_data": {
    "currency": "USD",
    "value": 9.99,
    "predicted_ltv": 62.40
  }
}

Five fields there are decisions rather than defaults.

action_source. “website” tells Meta a browser touchpoint existed. With a stored click behind the conversion that is true. Without one — a fan who subscribed having never passed through a tracking link — it is not, and system_generated is the honest label; Meta’s own worked example for that value is a subscription set to auto-pay monthly. The cost of the honest label is real but only half documented. Meta states that Event Match Quality is currently available only for web events, and names offline, physical store, app and conversion-leads events as the exclusions. system_generated is not named either way. The safe reading is that anything not reported as a website event should not be expected to carry a match-quality score in Events Manager.

event_source_url. Required for website events — alongside client_user_agent, which is required for the same reason — and Meta’s documentation says the URL should match the verified domain. fanvue.com cannot be verified by a creator, so the URL reported is the landing page or redirect on the domain they own. Putting a fanvue.com URL there would be inventing a page nobody controls.

fbc. Not an opaque token. Meta documents it as version, subdomain index, creation time in milliseconds and the fbclid, joined by dots. Rebuilding it from a stored click therefore needs the click time in milliseconds, not seconds, and the right subdomain index — the second component encodes which level of the domain set the cookie, and getting it wrong is silent. Meta suggests a 90-day expiry for the _fbc cookie, which is worth holding next to the seven-day event window below; the click identifier outlives by a wide margin the period in which an event carrying it may be sent.

value and currency. Fanvue settles creator earnings in USD cents regardless of what the fan paid in, so USD is the figure that reconciles against a payout. Reporting the fan’s display currency produces a number matching nothing.

predicted_ltv. A $9.99 signup that becomes $300 over six months is not a $9.99 conversion, but Meta accepts events only up to seven days old, and the wording is unforgiving: if any event_time in the request is more than seven days in the past, Meta returns an error for the entire request and processes no events. A renewal on day 40 cannot be sent as a fresh acquisition. It can still be sent as its own event, and Meta’s original_event_data block — event_name, event_time, order_id and event_id, all optional — can carry the original event’s identity alongside it. Read that documentation carefully before leaning on it: the use case Meta describes for the block is deduplication, and nothing published says an event named this way gets credited back to a click outside the attribution window. Which leaves predicted_ltv, defined by Meta as the predicted lifetime value of a conversion event, to carry the expected future in the first event. Whatever goes in that field is a model output, and it is worth saying out loud that the optimiser will treat it as fact.

One operational detail that otherwise costs an afternoon: Meta reports throttling as an HTTP 400 with an error code in the body — 4, 17, 32, 613 or 80004 — rather than as a 429. A client that retries only on 429 treats a rate limit as a permanent failure and drops the conversion.

The ad account structure question

Two decisions get made once and are unpleasant to reverse. Both are usually explained using a rule Meta has since withdrawn.

The eight-event rule is gone. Aggregated Event Measurement used to cap a verified domain at eight prioritised conversion events, and a great deal of still-published advice is built on choosing them. During 2025 Meta removed the cap and the manual prioritisation and took the configuration tab out of Events Manager; eligible web events are aggregated without a ranking. Anyone planning a Fanvue funnel around which eight slots to spend is planning around a control that no longer exists. Check the current state of Events Manager before believing any guide on this, including this paragraph.

Which domain gets verified. Verification still matters, for narrower reasons. Meta verifies at the registrable domain — effective top level domain plus one — and subdomains, eTLD+2, are not separately verifiable. Ten creators on ten subdomains of one landing domain are one domain as far as Meta is concerned; separate registrable domains are what actually separate them. What verification now buys is that the Conversions API documentation wants event_source_url to match a verified domain, and that verification controls which business portfolio may point ads at a domain you own.

How many creators share a dataset. Events Manager calls the pixel a dataset now, with the same ID underneath. Either way it is a population. Pooling several creators trains one model on audiences that may have little in common. Splitting them keeps each model clean but divides conversion volume, and the learning-phase arithmetic decides this more often than any argument about audience purity: a creator producing a handful of subscriptions a week is not going to reach fifty events in seven days on their own. The split should follow whether the audiences are genuinely different, not whether the accounts are.

Cloaking

It comes up eventually in every conversation about this. Serving review one page and visitors another is not a policy breach inside the review process; it is an attempt to circumvent the process, which Meta prohibits separately. The asymmetry is the argument. A rejected ad can be edited and resubmitted. A restricted ad account, Page or business portfolio can be put up for review in Account Quality, and a denied appeal can be escalated for a further review. Enforcement for circumvention reaches past the individual ad to the accounts and business assets attached to it, and Meta states that an account disabled for 180 days cannot be reinstated at all. The published policy does not promise every cloaking case ends there. It does not have to: the recoverable failure is cheap and the unrecoverable one is total.

Common questions