Your cost per install is lying to you

Cost per install is the most reported number in mobile acquisition and one of the least useful in remittance. It is not wrong, exactly. It measures precisely what it says. The problem is that in a business where money is earned three steps later, it measures the wrong thing confidently.

We have audited accounts with genuinely excellent install economics that were losing money on every cohort. Clean structure, refreshed creative, competitive cost per install, and a board asking why acquisition spend was growing faster than transfer volume.

What cost per install actually measures

It measures how cheaply you can persuade someone to download an app. That is a real skill and it is not the same skill as persuading someone to complete identity verification and then send money to another country.

In a consumer app where the install is close to the value event, the two correlate well enough that the distinction rarely matters. In remittance they diverge sharply, because between the install and the revenue sit three steps with meaningful drop-off at each.

Three of the four rows cost money and earn none. An install that stops at row three has cost you media spend and a verification fee, and it will continue costing you in support and storage.

An install that never completes verification costs you twice: once to acquire it and again to service it.

The three steps nobody bids toward

Install to signup is usually fine. Signup to KYC completion is where the loss concentrates, and KYC to first transfer is where momentum is lost during manual review. Together these three steps commonly turn 100 installs into fewer than 25 senders.

That ratio is the thing that varies between operators. Two companies with identical cost per install can have install-to-sender rates of 38% and 17%, which means one is paying roughly twice as much per actual customer as the other, invisibly.

Why the algorithm learns the wrong thing

This is the part that does real damage. Ad platforms optimise toward whatever event you send them. If the only event flowing back is an install, the algorithm becomes efficient at finding people who install readily.

People who install readily and people who complete financial verification are not the same population. Over a few weeks of learning, a campaign optimised to installs will systematically find more of the first group and fewer of the second. Cost per install improves. Cost per sender gets worse. Both trends are the algorithm doing exactly what it was told.

Optimised to installs, the algorithm gets better at finding people who never verify. That is not a failure. That is the instruction working.

Fixing it requires feeding post-KYC and first-send events back to every platform you spend on, then allowing a full learning cycle before judging the result. On iOS this means designing SKAdNetwork conversion values around verification rather than around session count, which is a real piece of work and is usually skipped.

The reconciliation problem

There is a second, quieter version of this problem. Three ad platforms will each claim credit for the same sender, and nobody checks.

In most accounts we audit, the sum of platform-reported conversions exceeds the number of transfers the business actually recorded, sometimes by forty percent or more. This is not deception. Each platform reports what it can see under its own attribution window, and no platform is responsible for reconciling against the others.

The consequence is that every channel looks profitable, the media budget grows on the strength of numbers that overlap, and finance eventually asks a question nobody can answer. Building a reconciliation layer above the platforms, and reporting the gap rather than absorbing it, changes that conversation permanently.

What to bid toward instead

1. Instrument the funnel through to first completed transfer, split by corridor, device tier and document type.

2. Feed post-KYC and first-send events back to every platform you spend on.

3. Design SKAdNetwork conversion values around verification, not around installs or sessions.

4. Rebuild campaign structure by corridor rather than by creative theme, so budget can follow corridor margin.

5. Report cost per completed first send as the headline number and cost per install as a diagnostic.

6. Reconcile platform-claimed conversions against your own data monthly, and state the gap.

Do this in order. Feeding post-KYC events back to the platforms before fixing a broken verification flow teaches the algorithm to avoid exactly the sender segment your business depends on.

The conversation with your board

Here is the uncomfortable part. When you make this change, cost per install goes up. Usually by fifteen to twenty-five percent, and it stays up.

That is the expected and correct outcome of bidding toward a harder event. You are asking the platform to find people who will complete identity verification and send money internationally, which is a smaller and more valuable population than people who will tap install.

Have the conversation before you make the change rather than after. A board watching cost per install rise for three weeks without context will intervene, and they will be right to, because from where they are sitting the only visible number got worse.

What you are trading is a metric nobody banks for a metric finance recognises. Cost per completed sender, payback period, and eventually corridor margin. Those are the three numbers that decide whether acquisition spend is an investment or a leak.