Analytics event tracking for remittance apps: one name for every step

"Three platforms all claim the same conversion." A head of growth says it. The product lead nods, because their numbers disagree with all 3. Google Ads reports one figure, Meta another, the MMP a third, and the core platform says fewer first transfers happened than any of them.

None of the tools is broken. They are counting different things under similar names, at different moments, with different attribution rules. Analytics event tracking for remittance apps fails less on tooling than on definitions.

This guide sets out the event map we build, the naming rules behind it, how it maps across tools, and how to reconcile it against the ledger.

Why analytics event tracking for remittance apps breaks

Most remittance app analytics set-ups grow one request at a time. A developer adds a signup event for the launch campaign. An agency adds its own. The MMP SDK arrives with default events. A year later there are 3 events that each mean "registered" and none that means "verified".

That produces 3 failures:

1. Names drift. sign_up, registration_complete and CompleteRegistration describe the same step in 3 tools, and nobody is sure they fire at the same moment.
2. Events fire at the wrong moment. A "transfer complete" event fires when the confirmation screen loads, not when the payout partner confirms. Failed and reversed transfers still count.
3. Attribution overlaps. Each platform claims every conversion it touched within its own window. Add the claims together and they exceed what happened.

The first 2 are fixable with a taxonomy. The third is fixable only with reconciliation.

The event taxonomy from install to repeat transfer

A taxonomy is the agreed list of events, their names, when each fires, and which system is the source of truth. It is a document before it is a tag.

What does a remittance app event map look like?

This is an illustrative map for an app-led operator. Adjust the steps to your own onboarding and KYC flow.

What is a post-KYC event?

A post-KYC event is any event that fires after a sender passes verification, most often kyc_approved. It matters because it fires far more often than a first transfer yet predicts one far better than a registration. For low-volume corridors it is usually the best event to send to ad platforms for bidding.

The 6 naming rules

1. One name per step, used unchanged in every tool.
2. Lowercase snake_case, verb in the past tense: kyc_approved, not KYCApprove.
3. Steps, not screens. Name what happened, not which screen loaded.
4. Parameters for variation. Corridor, payout method and platform are parameters, never separate event names.
5. Server events for money and verification. Anything a finance director would ask about fires from the backend.
6. Versioned document. Every change is logged with a date and an owner.

The data layer and what stays out of it

The data layer is the structured object your website and app pass to tag managers and SDKs. Define it once, with the same parameter names as the taxonomy.

The parameters that earn their place: send_country, receive_country, corridor, payout_method, payin_method, platform, transfer_number, and, for agent-led operators, branch_id or agent_code.

What stays out: names, document data, account numbers, balances and exact transfer amounts. Sensitive financial information should not be exposed to advertising platforms. Where value-based bidding needs a number, send a modelled value band agreed with your data protection owner.

Licensing and AML questions go to a qualified adviser. We handle advertising and marketing compliance.

GA4 events for fintech and MMP event mapping

The taxonomy only works if every tool receives the same event under the same name. The mapping table is where that gets agreed.

GA4 events for fintech apps should use custom events for these steps, marked as key events where they drive decisions. MMP event mapping sends the same events from your server to the MMP, which forwards them to ad networks under each network's own event name. Keep a column for that translation.

On iOS, map SKAdNetwork conversion values to the furthest step a sender can reach inside the measurement window, which for most operators is a post-KYC event rather than a first transfer.

Server-side tracking and consent

Server-side sending, through Meta's Conversions API, Google Ads offline imports and MMP server-to-server events, makes money events accurate and less exposed to browser loss. It does not remove consent obligations. Carry the consent state with every event, use Google's Consent Mode on the web, and configure SDK consent in the app. Deduplicate browser and server copies of the same event with a shared event ID.

This is the work our app and web analytics setup team does: plan, name, connect and document, before any budget moves.

Reconcile against your transfer records

Platforms will always claim more than happened. Reconciliation is how you know by how much.

Once a week, compare 3 numbers for each corridor: first transfers in your ledger, first transfers reported by each platform, and first transfers attributed in the MMP. Report the gap. Do not force the numbers to match.

Your CRM needs the same stages, so lifecycle messaging and attribution use one definition of "verified" and "first-transfer sender". Our CRM implementation work builds that lifecycle model around the same event names.

4 dashboards that stop at the first transfer

These 4 dashboards cover most decisions. Each splits by channel, corridor and device.

1. Acquisition: spend, installs, registrations and cost per first send by source.
2. Signup: registration completion by step and platform.
3. Verification: KYC start to approval, time in the verification queue, and drop-off by document type and device. Our guide to the KYC onboarding process covers what to do with it.
4. First transfer: approved senders who fund, time to first transfer, and first transfer by corridor and payout method.

Repeat send and cohort views come next. The app install and user acquisition team reads those cohorts to judge channels on verified senders, not installs, for the reasons set out in Your cost per install is lying to you.

Where to start

Write the taxonomy, move money events to the server, carry corridor on every event, map it across tools, and reconcile against the ledger every week. The arguments about which platform is right stop when everyone reads the same definitions.

If your tools still disagree, the Google Ads for money transfer companies guide shows how clean events change bidding, and the money transfer business model shows what the numbers are for. When you want a written view of what is broken and what it costs, Book a Growth Audit. The tracking map is one of its 4 deliverables, and you keep it either way.