Offline Conversion Tracking for Brokers and Operators: Optimising Ads Toward FTDs, Not Form Fills

Ad platforms optimise toward whatever you tell them is a conversion. For most forex brokers, crypto platforms and gambling operators, that is a registration form, because it is the last event the ad platform’s tag can see. The events that make money come later and happen in your CRM or back office: KYC approval, a first-time deposit (FTD), a second deposit. If the platform never sees those, its bidding learns to find people who fill in forms, not people who fund accounts.

Offline conversion tracking closes that gap by sending those later events back to Google and Meta, matched to the ad interaction that started the journey. This guide covers how the pipeline works, what Google and Meta document about it, the consent requirements for European traffic, and the mistakes that most often make the data unreliable.

Why form-fill optimisation goes wrong in regulated verticals

In lead-generation verticals, form completions and funded accounts often come from different audiences. Some sources produce plenty of registrations that never pass KYC or never deposit. Others produce fewer sign-ups but more depositors. If registration is the only signal, automated bidding will favour the first group, and cost per lead can improve while cost per FTD gets worse. Our forex lead qualification framework sets out which downstream stages are worth tracking. This article is about getting those stages back into the ad platforms.

The pipeline, step by step

1. Capture the click identifier at landing. Store the ad platform’s click ID from the landing URL (for Google Ads, the GCLID) in a first-party cookie or session. Write it to the registration record together with the timestamp and campaign parameters.
2. Carry it through onboarding. The ID has to survive every hand-off: from the marketing site to the client portal, from the portal to the CRM, and across devices where possible. Most pipelines break at one of these points.
3. Collect hashing-ready first-party data, with consent. Email address and phone number, normalised consistently, so they can be hashed and used as match keys (see below).
4. Define the offline events. Typically registration (already tracked online), KYC approved, FTD, and a quality event such as a second deposit or a deposit above a threshold. Each becomes a separate conversion action.
5. Upload on a schedule. Send events from the CRM or back office to each platform through its API or a connector, with the event time, the value if you use value-based bidding, and the match keys.
6. Reconcile. Compare platform-reported conversions with CRM counts by campaign every week.

Google Ads: offline import and enhanced conversions for leads

Google gives each ad click a unique ID: “Google Ads provides you with unique IDs, called Google Click ID (GCLID), for every click that comes to your website from an ad” (Google Ads Help: offline conversion imports). Classic offline conversion import matches CRM events to clicks using that ID.

Google now points new setups to a newer method: “If you have not already adopted offline conversion import, we recommend starting with enhanced conversions for leads instead.” Google describes enhanced conversions for leads as “an upgraded version of offline conversion import that uses user-provided data, such as email addresses, to supplement imported offline conversion data.” It explains that “The hashed customer data is compared to hashed customer data of signed-in Google Accounts and attributed to ad events” (Google Ads Help: enhanced conversions for leads). In practice, this makes matching more reliable when the GCLID gets lost between landing and deposit, for example when a user registers on mobile and deposits later on desktop.

Mind the conversion window. Google lets you set the click-through conversion window “anywhere from 1 to 30, 60, or 90 days for Search and Display campaigns depending on the conversion source” (Google Ads Help: conversion windows). Before choosing a window for each action, check how long your registration-to-FTD delay actually is in your own CRM data. If many deposits arrive after the window closes, they will never be credited to the ad.

Meta: Conversions API alongside the pixel

Meta’s server-side equivalent is the Conversions API. Meta states: “For optimal ad performance, we recommend that advertisers implement the Conversions API alongside their Meta Pixel.” When the same event is sent from both the browser and the server, Meta deduplicates it using two fields. The pixel’s eventID must match the server event’s event_id, and the event names must match. Meta also notes that “events are only deduplicated if they are received within 48 hours of when we receive the first event with a given event_id” (Meta: deduplicate pixel and server events).

Deduplication only matters for events both sources can see, usually registration. Events that happen only in the back office, such as KYC approval or FTD, are sent server-side only, as their own events. Don’t reuse the registration event name for them.

Consent for European traffic

Offline tracking is still personal-data processing. For users in Europe, Google’s EU user consent policy requires that “certain disclosures are given to, and consents obtained from, end users in the European Economic Area, the UK and Switzerland,” and warns that Google may limit or suspend use of its products if you don’t comply. Google’s consent mode reference lists the consent signals tags respect. It notes that “The ad_user_data consent type is required for measurement use cases, such as enhanced conversions and tag-based conversion tracking” (Google Ads Help: consent mode reference).

What this means for the pipeline:

• Store each user’s consent state on the lead record next to the click ID. Don’t keep it only in the browser.
• Agree with your data-protection lead which consent states allow which uploads, and apply that rule in the upload job, not by hand.
• Make sure your privacy notice covers sharing hashed identifiers with advertising platforms for measurement.

Choosing the event to optimise toward

Sending every downstream event doesn’t mean bidding on all of them. Some trade-offs to consider:

• Volume vs. quality. FTD is usually the event that matters commercially, but lower-volume campaigns may not generate enough FTDs for automated bidding to learn from. KYC-approved can be a useful middle step: closer to revenue than a registration, and more frequent than an FTD.
• Values. If you pass deposit values for value-based bidding, decide whether to send the raw deposit or a capped or tiered value. A few very large deposits can distort what the algorithm learns.
• Consistency across markets. Use the same event definitions in every geography, so campaign comparisons mean something.

Attribution across channels, including creators and organic, is a separate question. We cover it in influencer marketing attribution beyond last-click.

Where offline tracking usually breaks

• Lost click IDs. Redirects, domain changes between the marketing site and the portal, or forms that drop URL parameters. Test the full journey from ad click to CRM record on every landing page template.
• Timezone mismatches. Event times uploaded without a timezone, or in the wrong one, can land outside the window or on the wrong day.
• Double counting. Both a partner connector and your own script uploading the same FTD, or browser and server registration events without matching IDs.
• Silent failures. Upload jobs that error for days before anyone notices. Monitor upload status and match rates as you would any production system.
• Landing pages that leak intent. Pages that don’t convert qualified visitors limit what offline data can improve. Our notes on landing page optimisation for trading platforms cover the front of the funnel.

Implementation checklist

• Click IDs captured, stored first-party and written to the CRM record
• Email and phone normalised and hashed per each platform’s specification
• Consent state stored per lead and enforced in the upload logic
• Separate conversion actions for registration, KYC approved and FTD
• Conversion windows set from your own registration-to-FTD delay data
• Meta browser and server events deduplicated with matching event IDs and names
• Automated uploads with alerting on failures and falling match rates
• Weekly reconciliation of platform conversions against CRM counts by campaign

All of this sits within each platform’s advertising policies for financial services, crypto and gambling. Those policies decide whether you can advertise in a market at all. Check the current Google financial services policy and Meta’s Advertising Standards before launch.