FTD Custom Event: Deposits as Optimization Signals

An FTD custom event - first-time deposit as a named conversion event - is how finance, crypto, and betting buyers teach the ad platform the difference between someone who registered and someone who paid. The platform cannot see inside the offer; it only knows the events you send. Send registrations and it optimizes for signups; send deposits with their value and it starts hunting for people who actually fund accounts. This guide wires the deposit signal end to end: what a deposit looks like on the tracker side, when to send it as a custom event versus a standard one, how custom conversions make it optimization-eligible, and the value and timing rules that decide whether a late deposit counts at all.

The general mechanics of the delivery chain live in the network postback to CAPI guide; this page stays on the deposit-specific wiring.

What Counts as an FTD - and Why Registration Is Not It

Verticals that run on deposits care about two distinct moments: the first deposit (FTD), which proves a real paying user, and repeat deposits, which prove retention. Platforms have no concept of "first" - they count events. The distinction is business logic, and the only system holding enough history to apply it is your tracker: it stored the click, and it sees every conversion the network reports for that user.

So the wiring is a two-step decision. First, the tracker must receive deposits as a distinct status - which its postback contract already supports: Keitaro's documented status list for postbacks includes deposit alongside lead, sale, and rejected (Keitaro postback documentation). Second, "first" must be computed on the tracker side, by user - the usual markers being the user ID the network echoes back in sub ID fields, or per-account logic on the tracker's conversion rows. Whatever the marker, compute it once, in the tracker, and let the delivery layer read the answer.

The Event Choice: Standard, Custom, or Custom Conversion

Meta's server events carry an event_name you control, and the platform treats names outside its standard set as custom events (server event parameters). That gives three legitimate shapes for a deposit:

The standard-event route buys the most optimizer capability but spends the Purchase name - which may also carry other offers' money in the same pixel, muddying the picture. Custom-event routing keeps deposits cleanly separated and, through a custom conversion built on top, still becomes an optimization target in the ad set; the corpus walkthrough of affiliate custom conversions documents that path step by step. Many buyers run both: Purchase for confirmed money at the pixel level, an FTD custom event for the vertical-specific signal.

TikTok's Events API plays the same role on the TikTok side: server events with names you control, feeding the same custom-versus-standard decision.

Wiring FTD Through the Tracker

The concrete pipeline looks like this:

1. The network's postback announces a conversion with status deposit - or the vertical's equivalent - and the payout the user actually deposited.
2. The tracker records the conversion on its click row, with the transaction parameter distinguishing multiple deposits: Keitaro's tid-style parameter "records separate conversions instead of overwriting the previous one" - exactly what repeat deposits need (postback URL).
3. First-deposit logic - keyed by the conversion identity the tracker stored - marks the user's earliest deposit; repeat deposits keep their own rows.
4. Delivery then forwards: FTD as its named event, repeat deposits as their own - each with the deposit amount as value and the currency code (custom data parameters).

One naming discipline keeps the data usable: decide the event names once ("FTD", "RepeatDeposit"), document which tracker status maps to which, and never let a campaign-specific name leak into the pixel. Event-name sprawl is invisible until you try to build a custom conversion and find four spellings of the same deposit.

Value, Timing, and Volume for Deposit Events

Three platform rules shape the deposit stream:

1. Value. The deposit amount belongs in custom_data.value with its currency - the same payout-as-value discipline from the payout guide, minus the clawback complexity most deposit flows avoid because the deposit itself is the confirmed money fact.
2. Timing. event_time may sit at most seven days in the past, and one stale event fails an entire request (using the API). Deposit confirmations are usually fast, which makes FTD streams naturally friendly to the window.
3. Volume. Optimization needs a steady supply of the named event - which is a warming discipline, not a switch: feed the event consistently before scaling on it (pixel warming).

Hold questions rarely bite here - a deposit is confirmed at creation - but rebill-style offers and card-verification flows can add their own confirmation lag, and then the status-policy logic from the hold guide applies unchanged.

Verifying the Deposit Stream

Before trusting the signal:

1. Trigger or simulate a real deposit through the campaign link - network test postbacks carry no real subid, as the postback troubleshooting documentation warns.
2. Confirm the conversion row in the tracker got the deposit status, the value, and the transaction identity.
3. Watch the platform side: Meta's Test Events shows the named event arriving, and Events Manager reflects it within about 20 minutes (get started).
4. After enough volume, build the custom conversion and confirm it appears in the ad set optimization dropdown before wiring a campaign to it.

For free one-shot tests of the Meta leg, Pixel Activator sends named test events with just a dataset ID and token.

FTD Custom Event: Frequently Asked Questions

Sources