Analytics setup for remittance companies
The board asks what a first transfer costs by channel, and three tools give three different answers. The measurement plan comes before tagging, and every event has one name.
Remittance only · Transfers measured, not clicks · One name per event
Analytics setup for remittance companies measures the transaction lifecycle, not the page view: signup started, KYC completed, first transfer, second transfer and the value of each. One event taxonomy is written first, then implemented across the site, the app, the CRM and every ad platform, so the cost per first transfer reads the same wherever anybody actually looks at the number.
What changes in reporting
Most operators have four tools, four different numbers and no idea which one is right. Four things change.
Installs counted
The report ends at the install, where the spending starts.
Transfers counted
The report ends at the first transfer, and at the second.
Every tool disagrees
GA4, the MMP and the CRM each report a different number.
One name per event
Signup completed means the same thing in all four tools.
Channels judged blind
Spend gets moved on the cost per click and nothing else.
Channels judged on sends
Every source is read down to the first transfer value itself.
Consent left to chance
The tags fire before anybody has agreed to anything at all.
Consent carried through
The consent state travels with every single event that fires.
What the whole setup covers
Four rows of work, run in order. The plan is written before a single tag goes anywhere near it.
What actually gets measured instead
Installs and page views are not the measurement problem at all. For remittance businesses, analytics should move beyond: Page views, Clicks, App installs and measure the actual transaction lifecycle.
- Measurement plan written first
- Transaction KPIs agreed up front
- Reporting needs all written down
One name for every single event
One event name per action, used in the app, on the website, in the CRM and in every ad platform. Transfer: Beneficiary added; Quote created; Payment selected; Transfer initiated; Transfer completed
- Acquisition events all named once
- Registration and KYC events set
- Retention events named as well
Value, and what it stays out of
Transaction value can be measured, and it should be, but not all of it belongs in an ad platform. Sensitive financial information should not be unnecessarily exposed to advertising platforms.
- Transfer value tracked properly
- Revenue kept out of the pixels
- Server-side events where needed
Testing it, and writing it down
Duplicate events, missing events and wrong values get tested before anybody reports a number. The consent state travels with every single event. Implement analytics according to relevant privacy requirements.
- Duplicate events all hunted down
- DataLayer spec handed to the devs
- Consent state sits on every event
What you actually receive
Six artefacts, all of them yours to keep. The taxonomy is what stops the arguments later on.
Measurement plan
Which questions the reporting has to answer, and exactly which of the numbers answer them all.
The event taxonomy
Every single event's name, all its parameters and the exact moment that it is meant to fire.
DataLayer specification
What the developers actually implement, written so that it needs no meetings to explain it.
Conversion event map
Which events become ad conversions, CRM records or lifecycle triggers, and which ones do not.
Four dashboards
The acquisition, the signup, the verification and the first transfer, each on its own screen.
Data quality report
Which events fire twice, which ones never fire, and which ones carry the wrong value entirely.
How the setup work runs
Four stages, run in order. Nothing gets tagged at all before the taxonomy has been signed off.
What the reporting actually has to answer
The commercial questions come first, the indicators that answer them come second, and the technology comes last of all, every single time.
- 01Business objectives written out
- 02Acquisition KPIs agreed up front
- 03Transaction KPIs defined as well
- 04Lifecycle KPIs named in there too
- 05Reporting needs written down first
One name, and it gets used everywhere
Signup completed must describe the same event, with identical parameters, in GA4, in the attribution tool and on every advertising platform.
- 01Acquisition events get named once
- 02Signup and KYC events all defined
- 03Transfer events named properly
- 04Retention events named as well
- 05Parameters agreed for each one
Where an install becomes a real sender
The install is not the finish line. Track: Website → App Store → Install → Registration → Transfer where attribution infrastructure allows.
- 01The web to app handoff tracked
- 02Deep links measured per campaign
- 03Cross-domain tracking gets fixed
- 04Server-side events where useful
- 05Consent Mode configured properly
Whether any of the numbers can be trusted
Duplicate events, missing events and wrong values get hunted before dashboards are built, because a wrong number is worse than no number.
- 01Every event gets tested twice over
- 02Revenue values checked properly
- 03Attribution sanity checked too
- 04Dashboards built on clean data
- 05Documentation handed to the devs
What the work actually does
Twenty groups of work sit behind the service, and these twelve are what actually gets built first.
Web analytics
GA4, Tag Manager, Search Console
App analytics
Firebase, AppsFlyer, Adjust, Branch
Event taxonomy
One name, used in every tool
Conversion mapping
Which events become conversions
Value tracking
Transfer value, fees and revenue
Cross-domain work
Site, portal and payment domains
Web to app tracking
Install through to first transfer
Deep link tracking
Campaigns that land on a corridor
Server-side setup
Conversions API and server tags
Consent and privacy
Consent Mode and SDK consent
The dashboards
Acquisition through to corridor
Three ways to buy this
One of these will fit, whether nothing is tagged yet or everything is being tagged twice over.
Complete analytics build
The plan, the taxonomy, the tags, the testing and the dashboards, delivered once for both of them.
- Fixed fee, agreed before we start
- Plan written before any tagging
- Documentation handed over after
Complete taxonomy build
The naming, the parameters and the specification, all handed over to your own development team.
- One fixed fee, three weeks total
- Your own developers do the build
- Spec is yours to keep for good
Complete tracking audit
What fires twice, what never fires at all, and what the reporting is quietly getting wrong.
- Two weeks, priced before we start
- No obligation to rebuild with us
- Every broken event is listed out
Four steps to clean data
Two weeks of planning, and then the build. Clean reporting usually lands inside a month or so.
Agree the plan
WEEK 1-2The commercial questions first, then the indicators that will actually answer them.
Name the events
WEEK 3One taxonomy for the app, the website, the CRM and every single ad platform there is.
Build and test
WEEK 4-6Tags, SDKs and the server-side events implemented, then tested one event at a time.
Document it all
WEEK 7The specification, the dashboards and the quality report, handed over to your own team.
How results get reported
No client figure appears without written permission. These three are facts about how the work is run.
Questions operators ask first
Answers come first. Where the honest answer is no, it says no and explains what to do instead.
Both. An agent-led operator adds the branch and the agent code as parameters, so a counter transfer lands in the same reporting as an app one.
Yes. GA4, Firebase, whichever MMP you run and the CRM all take the same event names, which is the point of writing the taxonomy first.
Yes. Corridor is a parameter on every transfer event, so corridor margin and cost per first send read from the same dashboard.
Yes. Analytics setup for remittance companies is all that gets built, so KYC completed and first transfer are events from the start, not additions.
Sensitive financial information should not be unnecessarily exposed to advertising platforms. Licensing and AML questions go to a qualified adviser.
Analytics and tag manager access, the MMP, your CRM, the corridor list, and whoever owns the release cycle for the app and the site.
Two weeks to plan and name, then two to four weeks to implement and test, depending on how much of it needs a developer.
Yes. KYC started, KYC completed and first transfer are events like any other, so the verification funnel and the ad platforms read the same data.
Yes. Corridor, send country and receive country are parameters, so a new route appears in reporting without any new tagging work.
Yes. Second transfer, repeat transfer and reactivation are named events, which is what makes a lifecycle campaign measurable rather than hopeful.
Every acquisition source carries through to the first transfer event and its value, so cost per first send is a number rather than an estimate.
Four dashboards: acquisition, signup, verification and first transfer, each split by channel, by corridor and by device, from the same event set.
Build a reliable measurement system connecting customer acquisition, website behaviour, app behaviour, registration, verification, transactions and lifecycle activity. Then spend follows it.
Wasted spend removed once channels can be compared honestly. Analytics setup for remittance companies pays for itself on the first budget decision it corrects.
Indirectly. You cannot improve send frequency you cannot see, and second transfer is usually the event nobody thought to name.
Operators, remittance apps and payout platforms on the roster
Marks appear once written permission is on file for each operator.
Fix the numbers before the spend
If two tools disagree about first transfers, every budget decision after that is a guess. A fixed-fee growth audit will say which number to believe.
You keep the measurement plan whether or not we build it.