Every event Segmently sends to Facebook (Pixel + Conversions API)
The complete list of the events and parameters Segmently sends to Meta — the browser Pixel events as your visitor moves through the funnel, and the server Conversions API events from Stripe payments — so you know exactly what to build ads, audiences, and conversions on.
Where this fits
This is reference material for the optional ad-tracking step of launching a funnel. It assumes you have already added the Facebook Pixel and Conversions API integrations (see the Facebook setup guide). Once both are connected, the events below start flowing automatically — you do not configure events one by one. Use this page to decide which event to optimize your Meta campaigns on and which to build Custom Audiences from. Event names are sent exactly as written here, so they appear under these same names in Meta Events Manager.
Two streams: the browser Pixel and the server Conversions API
Segmently sends to Meta in two ways. The browser Pixel fires from the visitor's device as they move through the funnel (page views, button clicks, product selection, checkout). It reports rich funnel behaviour but can be blocked by ad blockers or tracking-prevention. The server Conversions API (CAPI) fires from Segmently's servers when Stripe confirms a payment event (purchase, subscription, cancellation, failed charge). It is the reliable money signal that does not depend on the browser. The two work together and are de-duplicated, so a purchase counted by both is only counted once.
How browser Pixel events are sent
All browser events are sent to your Pixel as custom events (technically fbq('trackCustom', ...)), keeping Segmently's own event names rather than renaming them to Meta's standard set. So in Events Manager you will see names like ScreenDidAppear and StripePurchase, not 'PageView' or 'Purchase', for the browser stream. They fire only when the Facebook Pixel integration is enabled and — if you use GDPR consent — only after the visitor accepts cookies. Because they keep their original names, you build Custom Conversions and audiences in Meta by matching on these exact names.
Browser Pixel events: journey and navigation
These describe how a visitor moves through the funnel.
StartOnboarding
Parameters: projectName, projectId, onboardingName, onboardingId, versionId, and A/B test fields when present. Fires when the funnel is opened.
ScreenDidAppear
Parameters: screenID, screenName. Fires when a screen is shown.
ScreenDisappeared
Parameters: screenID, screenName, the screen's input value, nextScreenId. Fires when a screen is left.
EntryScreenRuleMatched
Parameters: screenID, screenName, paramKey, paramValue, operator, expectedValue, defaultScreenId, ruleIndex. Fires when an entry rule sends the visitor to a specific first screen based on a URL parameter.
RouteTaken
Parameters: screenID, targetScreenId, actionKey. Fires when the visitor moves from one screen to the next.
PageHidden
Parameters: screenID, timeOnScreenMs. Fires when the tab is hidden.
FunnelExited
Parameters: lastScreenId, journeyDurationMs, screensVisitedCount. Fires when the visitor leaves without finishing.
OnboardingFinished
Parameters: screenID, screenName. Fires when the funnel is completed.
Browser Pixel events: inputs, buttons, and extras
These capture interactions and answers.
UserUpdatedValue
Parameters: screenID, screenName, the value, blockType, dataKey. Fires when the visitor changes an input.
FieldInputValueError
Parameters: screenID, the value, errorMessage. Fires when an input fails validation, e.g. a malformed email.
VariableUpdated
Parameters: variableId, variableName, variableType, value. Fires when a funnel variable changes.
FirstFooterButtonPressed and SecondFooterButtonPressed
Parameters: screenID, screenName. Fire for the main and secondary footer buttons.
LeftNavbarButtonPressed, RightNavbarButtonPressed, CloseNavbarButtonPressed
Fire for the back, skip, and close buttons in the header.
AbTestLoaded
Parameters: abTestId, abTestName, abTestVariantId, abTestVariantName. Fires when the visitor is placed in an A/B variant.
AcceptCookiesPressed and DeclineCookiesPressed
Fire for the consent banner choices.
DownsaleTriggered
Parameters: screenID, cancelActionKey. Fires when a downsale offer is shown after a cancel.
Browser Pixel events: paywall and payment
These are the highest-value browser signals because they show buying intent. Note: these browser payment events can be lost to ad blockers, which is exactly why the server Conversions API events below exist.
ProductSelected
Parameters: screenID, productId, price, currency. Fires when the visitor picks a plan on the paywall.
PurchaseFooterButtonPressed
Parameters: screenID, productId, price_id, offer_type, trial_days, paywall_type, and buy_intent_status ('accepted' or 'error'). Fires when the visitor presses Buy / Continue to pay. This is your best browser-side intent signal.
StripeCheckoutSessionCreated
Parameters: sessionId, paywallProductId. Fires when a redirect Stripe Checkout session opens.
StripePaymentIntentSuccess
Parameters: paymentIntentId, mode. Fires when a card or wallet payment is confirmed in the funnel.
StripePurchase
Parameters: productId, mode ('embedded' / 'upsell_frictionless' / 'redirect'). Fires when an embedded or one-click purchase succeeds.
StripeSubscriptionCreated
Parameters: subscriptionId, mode. Fires when an embedded subscription is created.
StripeCheckoutSessionSuccess and StripeCheckoutSessionCancel
Fire when the visitor returns from hosted Checkout as paid or cancelled.
StripePaymentElementError
Parameters: error, mode. Fires when a payment error occurs.
Server Conversions API events (from Stripe)
These fire from Segmently's servers when Stripe confirms money has moved. Important: these are the names Segmently uses internally — what you see in Meta is the name after the adapter maps it. In particular, RecurringPayment is the internal name for a renewal, but the Facebook adapter remaps it to Purchase, so subscription renewals never appear under a distinct 'RecurringPayment' name in Meta — they show up as Purchase. Purchase and Subscribe pass through under their own names because they match Meta's standard set. One extra detail: when a subscription is created and is active or in trial, Segmently also sends the raw customer.subscription.created event alongside Subscribe, so analytics teams can report on both — your campaigns should still optimize on Subscribe. If the creation status is 'incomplete' (payment not yet confirmed), the raw created event is skipped and Subscribe fires later on the incomplete-to-active transition, so not every creation emits the dual raw event.
Purchase
Parameters: value, currency. A payment was completed — a one-time purchase, the first subscription charge, or a paid-trial fee. Sent under its own name in Meta.
Subscribe
A subscription was created and is active or in trial. Sent under its own name in Meta.
RecurringPayment (appears in Meta as Purchase)
A subscription renewal was charged (and the first charge after a 'fake' trial, where the original purchase was already counted). RecurringPayment is the internal name only; the Facebook adapter remaps it to Purchase, so renewals reach Meta as Purchase, not as a distinct 'RecurringPayment' event.
CancelSubscription
A subscription was cancelled. Sent under its own name in Meta.
PaymentFailed
A charge failed — a declined card or a failed renewal. Sent under its own name in Meta.
How each Stripe moment becomes an event
Segmently translates Stripe's webhooks into the events above carefully, so nothing is double-counted: • A completed hosted Checkout for a one-time product → Purchase. • A confirmed payment inside the funnel (embedded card or wallet) → Purchase. • The first subscription invoice when an amount was actually charged (a paid-trial fee, or a Checkout subscription's first payment) → Purchase; if that first invoice is a free trial charging nothing, it is skipped. • The first charge after a real trial ends → Purchase (this is when money first moves). • Any later subscription renewal → RecurringPayment internally, which the Facebook adapter remaps to Purchase, so in Meta a renewal also reports as Purchase. • A subscription becoming active or in trial → Subscribe. • A subscription cancelled → CancelSubscription. • A failed charge or failed renewal → PaymentFailed. The takeaway: Purchase marks real revenue (including renewals once they reach Meta), and Subscribe marks the subscription decision.
What customer and value data is attached
The server Conversions API events carry the data Meta uses to match a conversion to the right person and value. Personal details are securely hashed (SHA-256) before sending: em (email), ph (phone), fn (first name), ln (last name), and external_id (your Segmently visitor id). Browser-matching signals are sent as-is because Meta expects them raw: fbp and fbc (the Pixel's browser-id and click-id cookies), client_ip_address, and client_user_agent. The purchase itself carries value and currency, plus content_ids and your funnel metadata (UTM tags, fbclid, product and offer details) forwarded under meta_ names. This is why collecting the email before the paywall and mapping the ad identifiers at publish matter — they directly improve how many conversions Meta can match.
Why a purchase is not counted twice
Because both the browser Pixel and the server Conversions API can report the same sale, Segmently gives each server event a stable event_id derived from the Stripe event (in the form evt_<stripe-event-id>) and includes external_id (your visitor id). Meta uses these to recognise the browser and server reports as the same conversion and merge them. The result: better match quality from the server signal, without inflating your numbers. You do not need to configure anything for this — it is automatic once the Pixel ID matches between your Pixel and Conversions API integrations.
What makes these events fire and match
Three launch-step settings decide whether these events actually fire and how well Meta can match them: • Enable both integrations — the Facebook Pixel and Conversions API integrations must be turned on in your Analytics settings; until they are, none of the events above leave Segmently. • Collect and bind the email — add an email screen before the paywall, create a variable for it, and select that variable as the Web Placement's stripe.emailVariableId, so the visitor's email reaches Stripe and is forwarded (hashed) as the strongest match key on the server Purchase / Subscribe events. • Map the ad identifiers at publish — map fbp and fbc into Stripe metadata at publish (the dotted facebook.fbp / facebook.fbc keys via stripeMappings); without them the server events lose the browser-id and click-id signals and Meta's match quality drops. Get these three right and the events below fire reliably and match to the right person.
Which events to optimize ads on
For most paid funnels: optimize purchase-driven campaigns on Purchase (the reliable server revenue signal) and, for subscription products, on Subscribe. Because subscription renewals reach Meta as Purchase (RecurringPayment is remapped to Purchase by the adapter), your Purchase volume already includes renewals — there is no separate renewal event in Meta to optimize on. Use PurchaseFooterButtonPressed (buy intent) as an upper-funnel signal when you do not yet have enough purchases for Meta to learn from. Build Custom Audiences and retargeting from the journey events — StartOnboarding, ScreenDidAppear on your paywall screen, and ProductSelected — to re-reach people who showed interest but did not buy. Avoid optimizing on the browser StripePurchase alone, since ad blockers can suppress it; the server Purchase is the dependable choice.
Who does what
Segmently sends every event above automatically once your Pixel and Conversions API are connected — you do not wire events individually. In Meta you do the campaign work: pick the optimization event (Purchase or Subscribe), define Custom Conversions or audiences on the event names listed here, and confirm events are arriving in Events Manager (use a Test Event Code while testing). Remember the server Conversions API sends payment events only; the full funnel behaviour comes from the browser Pixel. The two complement each other.
Next
If you have not connected Meta yet, open the Facebook Pixel and Conversions API setup guide to add both integrations and the matching identifiers. Running TikTok ads too? The TikTok events catalog lists the equivalent events and the names TikTok expects.