Product optimisation
A poor return is a symptom. Optimisation is the ongoing work of finding out whether the cause sits in the product, the measurement pipeline or the campaign, then changing that one thing and holding it long enough to read the result honestly.
- Funnels & cohorts
- Activation & retention
- Experiment design
- Product · pipeline · campaign
GROW
Data, measurement & growth
The layer that keeps the other two honest. Event models, conversion tracking and attribution that make performance legible, and continuous optimisation of the product and the spend together rather than one at a time.
Also in this band
A disappointing return is a symptom, not a diagnosis. The cause sits in one of three places: the product, where people arrive and do not get to the value; the measurement pipeline, where the event describing that value fires wrongly or not at all; or the campaign, where budget is buying the wrong people at the wrong price. Optimisation is the discipline of finding out which, and changing that one.
Most arrangements cannot do that. An agency can change bids and creative but cannot ship an onboarding change. A development studio can ship the change but has no view of what the campaign is buying. The work then bends towards whatever the contract permits, which is why so much optimisation is bidding adjustments made in place of a product fix. Because the same business owns the build, the measurement and the media here, the change is made where it will work.
This is an ongoing engagement rather than a project with a delivery date. What it contains in a given month is decided by what the numbers say that month: one month is store listing and first-session work, the next is a refund pattern and a pricing observation, the one after is creative fatigue. Some months the honest recommendation is to change nothing yet, because the data behind the idea is still too thin to read.
The states this work is meant for
Four patterns. Each one looks like an advertising problem from the outside, and in each the cause can sit in any of the three layers.
- Return fell and nobody can say why
- The blended return has fallen across successive months and each owner has a different explanation. The media side points at the app, the product side points at the traffic, and neither has the other's data. Nothing is measured across the boundary, so the argument is settled by whoever is more confident rather than by evidence.
- Traffic arrives and leaves before activating
- Acquisition is doing its job. Sessions land, installs happen, and then the funnel loses most of them before the moment where the product becomes useful. Permission prompts, an account wall, a long form or an empty first screen each take their share. Because no one has counted the drop step by step, the fix is guessed at rather than located.
- Users come once and never return
- Day-one numbers look acceptable and day-seven does not. The cohort curve flattens near zero, so every new user has to be bought again to hold the same active base. Retention gets handled as a marketing problem when the question underneath it is about value: the thing people came for either was never found, or was found once and then had no reason to be needed a second time.
- Changes are made constantly, none are read
- Something is adjusted every week: a headline, a bid target, a screen, a price. Several move at once, none is recorded, and the next month's numbers cannot be attributed to any of them. The account and the product both drift, and the only honest statement left is that things changed and the result changed too.
What the work covers
Six strands of work. Which of them a given month contains is decided by the evidence in front of us, not by a fixed deliverable list agreed before anyone looked.
Funnel analysis end to end
The full path is counted in one place: impression, click, arrival, first session, activation, repeat use and payment. Each step gets a number and a denominator, so a drop can be named rather than described. Where the pipeline cannot yet see a step, that gap is treated as a finding.
- A single funnel definition agreed in writing, used by every report afterwards
- Step-by-step conversion rates with the denominator stated at each stage
- Drop-off segmented by source, campaign, geography, device and app version
- Funnels rebuilt in BigQuery where the platform's own view aggregates too early
- Known blind spots listed openly rather than filled with an estimate
Activation and onboarding
Activation is defined as the first moment the product does the thing it was downloaded for, then measured as a completion rate rather than a feeling. Onboarding is examined step by step on real devices and real connections, including the states that are easy to skip in testing: no data, denied permission, failed sign-in.
- A written activation definition with the event and parameters that prove it
- First-session completion measured per step, not as a single aggregate
- Permission and sign-in prompts reviewed for timing, wording and placement
- Empty, loading, offline and error states tested on a mid-range device
- Time-to-value measured from open to the first useful outcome
- Sign-up friction reduced only where the removed field is genuinely unused
Retention, engagement and cohort economics
Cohorts are read by acquisition source rather than only in aggregate, because two sources can carry an identical install cost and behave nothing alike by the second week. Engagement is measured against the value moment rather than against session count. Revenue per cohort is followed far enough out to see whether payback is real or deferred.
- Day-one, day-seven and day-thirty retention split by campaign, creative and geography
- Cohort revenue curves compared against acquisition cost over the same window
- Feature engagement measured against the value moment, not screen views
- Churn and uninstall points located in the session where they occur
- Resurrection and repeat-purchase behaviour separated from first-time behaviour
- Refunds, chargebacks and cancellations netted off before any return is quoted
Conversion surfaces: pages and listings
A landing page and a store listing are the same argument in two formats, so both are treated as conversion surfaces rather than as marketing artefacts. Copy, first screenshot, above-the-fold offer, form length and proof are examined against what the traffic was promised in the ad. Changes are shipped one at a time where volume allows.
- Message match traced from ad copy through to the page or listing headline
- Store listing icon, opening screenshots and short description treated as the test surface
- Form fields, error handling and validation reviewed on a real handset
- Store experiments and page variants run where install volume supports a read
- Localised listings checked separately, since one market's winner is not another's
Pricing, paywall and payment observation
We report what the pricing and paywall are doing, not what you should charge. That means where people stop, which plan is chosen, how trials convert, where payment fails and what refunds cluster around. Pricing is a commercial decision that belongs to you; our part is making the current behaviour visible and checking the mechanics work.
- Paywall view, start, complete and abandon measured as a funnel of its own
- Plan mix and trial-to-paid conversion reported by cohort and by source
- Payment failure, decline and retry behaviour checked against the billing provider
- Refund and chargeback reasons grouped so a product cause is separable from a billing one
- Subscription state verified as an event, so campaigns can bid on real revenue
Technical performance on the conversion path
Speed and reliability are conversion variables. A slow first paint, a layout shift under a button, a checkout call that times out on a weak connection and a crash on one Android version all show up as a conversion rate, never as an error report anyone reads. We measure them on the paths that carry revenue.
- Core Web Vitals measured on the pages that carry conversions, not the homepage
- App start time, screen render and crash-free rate read per version and per device tier
- API latency and error rates on sign-in, checkout and payment calls
- Third-party scripts and SDKs audited for what they cost the conversion path
- Failed requests correlated with the funnel step they interrupt
How the engagement runs
The order is the point. Nothing is changed before a baseline exists, and nothing is judged before the date it was agreed it would be judged on.
- 01
Baseline all three layers before changing anything
We read the product analytics, the measurement pipeline and the ad accounts together, and write down what each currently says. Where they disagree, the disagreement itself is recorded as a finding. This baseline is what every later claim is measured against, and it is written down before anyone is permitted to propose a change to any of the three.
- 02
Locate the constraint, then prioritise
One constraint is holding the outcome back more than the others. We identify where it sits — product, pipeline or campaign — and rank candidate changes by the size of the step they affect, the confidence behind the evidence and the effort to ship. A cheap change on a step almost nobody reaches is not a priority.
- 03
One hypothesis, one read-out date, one stop condition
Every change is written as a hypothesis with the metric that would confirm it, the sample or period needed to read it, and the date the read happens. A stop condition is set at the same time: the spend, the loss or the elapsed period at which the test ends regardless of how promising it looks.
- 04
Ship the change where it belongs
If the answer is a product change, it is built and released. If it is a mis-fired event, it is corrected in the pipeline and verified before spend continues. If it is a bidding, budget or creative problem, it is handled in the account. The decision follows the evidence, not whichever of the three is easiest to invoice for.
- 05
Read it, record it, report it on a cadence
At the read-out date the result is stated plainly: it worked, it did not, or the evidence is still too thin to say either. Ideas that were dropped go into the log next to why they were dropped, so a suggestion already tested cannot return later dressed as a fresh insight. Reports arrive on the agreed rhythm with the working numbers attached, rather than as a deck built the night before a meeting.
One optimisation cycle
A cycle is a fixed shape, run repeatedly. Its length is set by how long the metric in question takes to produce a readable signal, not by the calendar.
- 01
Read the evidence
The cycle opens by looking, not by deciding. Funnel steps, cohort curves, event health, spend and creative data are pulled for the same period and read side by side, because each of those views is misleading when read on its own.
- 02
Locate the constraint
The drop is placed in one of three layers. A step that loses people who reached it points at the product. A step reporting impossible numbers points at the pipeline. A step that loses the wrong people early points at the campaign.
- 03
Form one hypothesis
The finding is written as a single sentence someone can disagree with: this step loses people because of that cause, and moving it would show up here. Vague intentions to improve engagement are not hypotheses and cannot be read afterwards.
- 04
Make one structured change
One variable moves. The change is shipped in the layer the evidence pointed at, with the measurement for it in place before release, and everything else in the account and the product is deliberately held still for the duration.
- 05
Hold it long enough to read
The change runs to the agreed period or sample, not to the point where somebody grows impatient with it. Learning phases, weekly cycles and conversions that land days after the click all mean an early read can be noise wearing the shape of a result.
- 06
Decide and record
Keep it, revert it, or declare the data too thin. The decision, the numbers behind it and the reasoning go into a running log, so the next cycle starts from what is already known rather than from memory.
Optimising the campaign, or optimising the system
The difference is not effort or attention. It is the range of places a fix is allowed to be made once the evidence points somewhere.
Campaign-only optimisation
- The available levers are bids, budgets, audiences and creative, and nothing else
- A drop after the click is described as a traffic quality problem, because that is the reachable explanation
- A mis-fired event is worked around rather than fixed, since the code belongs to someone else
- Retention, refunds and repeat revenue sit outside the reporting, so the return is quoted gross
- Once the account is genuinely well built, the remaining moves become cosmetic
Whole-system optimisation
- The lever chosen is the one the evidence points at, in whichever of the three layers it sits
- A drop after the click is counted step by step and fixed in the product where it belongs
- A broken event is corrected in the code and verified before more budget runs against it
- Refunds, cancellations and repeat revenue are netted into the same view as spend
- Once the account is genuinely well built, the work moves on instead of inventing changes
What gets examined each cycle
The same list is worked through every cycle, whether or not anything looks wrong from the outside. The point is not the lines that read normally but the one that does not, and working the list in full is the only way to reach it without already knowing where to look.
- Acquisition mix and cost by source, with each source's cohort quality carried alongside its price
- Store listing or landing page conversion rate, split by market and by traffic source
- First-session and activation completion, measured step by step rather than as one rate
- Day-N retention by cohort, compared against the cohorts acquired before and beside it
- Feature engagement against the value moment, not against session count or screen views
- Conversion and revenue events firing correctly, with values, currency and deduplication checked
- Refunds and chargebacks, grouped by reason and netted off the reported return
- Technical performance and error rates on the conversion path, on real devices and connections
- Geographic and device splits, since a decline can sit entirely inside one market or one handset tier
- Creative fatigue: frequency, first-impression share and the point where a set stops earning its budget
- Budget pacing against the stop conditions agreed for each open test
- Open experiments and their read-out dates, including the ones due to be ended without a winner
Tools the work happens in
Every entry below is a product name, present only to identify where a given piece of this work is carried out. Listing one asserts nothing: no partnership, no certification or accreditation, no reseller status, no sponsorship and no endorsement. The marks belong to the organisations that own them, and we neither act for those organisations nor hold ourselves out as doing so.
- Product and behaviour analytics
- Google Analytics 4
- Firebase Analytics
- BigQuery
- Google Play Console
- App Store Connect
- Crashlytics
- PostHog
- Experimentation and rollout
- Firebase Remote Config
- Firebase A/B Testing
- Google Play store listing experiments
- App Store product page optimisation
- Google Ads experiments
- Meta A/B tests
- Performance and reliability
- Lighthouse
- PageSpeed Insights
- Chrome DevTools
- web-vitals
- Firebase Performance Monitoring
- Android vitals
- Sentry
- Reporting and modelling
- Looker Studio
- BigQuery
- SQL
- Google Sheets
- Python
- pandas
What you end up with
- A funnel counted end to end, from impression through to repeat revenue
- An activation definition everyone uses, backed by an event that can be verified
- Retention and cohort economics read by source, not only in aggregate
- A running log of what was changed, what it did, and what was abandoned
- Changes made in the layer that actually holds the outcome back
What people ask before starting
01Is this a project, or an ongoing arrangement?
Ongoing. There is no delivery date, because the work is a repeating cycle rather than a scope. It runs on a monthly basis with an agreed cadence of reads and reports, and either side can end it with notice. What it contains in a given month is decided by the evidence that month, not fixed in advance by a package.
02What does this cost, and is any of it tied to results?
A monthly fee for the cycle, plus quoted work where a change needs real engineering time. We do not take a percentage of ad spend, because that pays us more for spending more and nothing for telling you to spend less. We do not work on a share of uplift either, since attributing uplift to one party is exactly the argument this work exists to settle.
03Who owns the accounts, the data and the code?
You do, throughout. Analytics properties, BigQuery projects, ad accounts, store listings and code repositories all sit in your name, and we operate inside them on permissions you issue and can withdraw at any point. Experiment logs, funnel definitions and working notes reach you as they are written rather than in a handover at the end. Should the engagement stop, you get the final log, our permissions come off, and we write to confirm that they are gone.
04What happens in a month when nothing improves?
You are told that, in writing, with the numbers attached. Some cycles end with a reverted change and a narrowed hypothesis. Some end with the recommendation to change nothing yet, because the data is too thin to act on. We guarantee no return, no conversion rate and no ranking. A cycle that removes a wrong explanation has done useful work even when the chart is flat.
05Are you a Google, Meta or Apple partner?
No. MNF Infotech is an independent proprietorship. It holds no partner status, no reseller arrangement and no certification, it has no authority to represent Google, Meta, Apple or any other platform, and none of those companies endorse it or have engaged it to act for them. The product names on this page say which console a piece of the work is done in, nothing further. Where a procurement checklist asks for a partner badge, better to learn that before we begin than afterwards.
06What will you not do?
We will not run several changes at once so a good month can be claimed by whichever one is convenient. We will not tell you what to charge; pricing is yours, and we report what the current price is doing. We will not describe an early read as a result, run an experiment past its stop condition, or recommend more spend into a funnel we have already told you is leaking.
What this work usually connects to
Have the whole funnel looked at
Send what you have: an analytics property, an ad account, a store listing, or just the number that stopped making sense. We will tell you which of the three layers we would examine first.
Directcontact@mnfinfotech.com