GMV is a terrible debugging target. It is useful as a business result, but if you start from “GMV is down” and jump straight to “add a promotion module,” you are guessing.

Growth engineering gets useful when a business idea becomes a testable causal chain: hypothesis, tracking, experiment, decision, rollout, and measurement. Without that chain, a feature can ship, GMV can move, and nobody can honestly say whether the feature caused it.

Figure: Growth engineering validation loop. A business idea becomes a metric hypothesis, tracking design, experiment, decision, and impact measurement. generated by gpt-image-2.

GMV is an output, not a root cause

In ecommerce, GMV is usually the headline metric. That makes sense. It tells you the total transaction volume that moved through the marketplace.

It does not tell you where the system broke.

GMV can fall because fewer users arrived, because users saw irrelevant products, because product detail pages loaded slowly, because inventory disappeared, because checkout added friction, because payment failed, because the order service had a callback issue, or because average order value fell.

Those are different problems. They need different owners and different fixes.

The debugging analogy is obvious. If a long request chain fails and you only look at the final error, you are debugging without logs. Growth work has the same failure mode. A top-line metric moved, but the causal path is invisible.

Turn the transaction path into a funnel

The first useful move is to split GMV by user flow.

To increase GMV, you need enough users to reach a successful order, and you need those orders to carry enough value. That can be modeled as a funnel from traffic to product exposure, product intent, checkout, payment, and order success.

Figure: Ecommerce conversion funnel from entry traffic to order success and GMV. generated by gpt-image-2.

One simplified decomposition looks like this:

1
2
3
4
5
6
7
8

GMV
= UV
× PDP arrival rate
× Add to cart / buy now rate
× Checkout start rate
× Payment success rate
× Orders per buyer
× AOV

Each stage points to a different class of work:

This is already better than arguing about “growth.” Now the problem has a location.

If PDP arrival drops, a UI promotion rewrite is probably noise. Check routing, page performance, product state, and tracking first. If payment succeeds but order creation drops, the growth team should stop debating copy and look at the transaction backend.

Split GMV by user type too

The funnel view explains where users drop. The operating view explains which users changed.

The same GMV can be decomposed by new users, existing buyers, reactivated users, high value users, low frequency users, region, or acquisition channel.

1
2
3
4
5

Segment GMV
= active users in the segment
× purchase conversion rate
× orders per buyer
× AOV

That split matters because the fix changes:

The data structure is the point. If every discussion starts from one giant GMV number, every proposed fix sounds plausible. Once GMV is split by flow and segment, many ideas become obviously wrong.

Do not optimize a local metric in isolation

A funnel can still lie if the stages are not connected.

Imagine you only optimize the conversion from homepage view to PDP view. The most extreme solution is to redirect every homepage visit to a product detail page. PDP arrival becomes 100%. The business gets worse.

The same thing happens with app download banners. You can increase app opens by nagging users harder. If those users do not place an order, return on day 7, or retain any value, the “win” is traffic transport.

Useful growth metrics need propagation. A feature should improve a local step and transmit value to the final business outcome.

Figure: Web and app growth path. A promo click can continue through web checkout or branch into app activation, order, and retention. generated by gpt-image-2.

This is why I like to read a funnel as an ownership map:

You usually need all four. Funnel analysis finds the leak. Cohort analysis tells you whether the traffic was any good. Attribution prevents fake credit. A/B testing separates causation from timing noise.

A concrete case: Mobile Web purchase intent to app order

Here is a common ecommerce shape.

Mobile Web has stable traffic because search, social shares, SEO pages, and campaign links land there. The app has higher GMV per buyer, better login state, richer payment flow, and better retention mechanics, but app daily active users are under pressure.

The lazy answer is “show a bigger app banner.”

The better question is narrower: when a Mobile Web user has already shown purchase intent, should we route them through an app landing page before purchase?

That gives us a real hypothesis:

1. There is a high intent Mobile Web population, shown by Buy Now, Add to Cart, coupon claim, or campaign product click.
2. The current web to app handoff is weak because banners are generic, deeplinks lose context, or product and coupon state is not preserved.
3. If the handoff happens at the purchase moment and carries product, offer, and attribution context, app first order, retention, and GMV per eligible user should improve.

Measure the handoff as two funnels

The measurement path should not stop at app open.

App open is cheap. App order is harder. D7 and D30 retention are harder again. Long term value is where the answer becomes useful.

Figure: MWeb-to-App measurement funnel for the app landing experiment. Value is measured per eligible MWeb UV rather than total GMV alone. generated by gpt-image-2.

The chain should include:

The denominator matters. “Total app GMV increased” can be caused by unrelated app campaigns. “Web-assisted app paid GMV per eligible Mobile Web UV” is much harder to fake.

Design the experiment so it can lose

A useful experiment has a real chance to say no.

For the app landing case, the setup can be simple:

Figure: A/B experiment split for the app landing page. Stable buckets keep control and treatment comparable while metrics and guardrails decide rollout. generated by gpt-image-2.

Stable bucketing is not paperwork. If users change groups on refresh, the result is garbage. If the treatment steals GMV from Web direct purchase and total GMV does not rise, the result is also garbage.

Guardrails stop local wins from becoming business losses.

Attribution is the data contract

The whole case depends on attribution.

If the app order cannot be tied back to the web touchpoint, the experiment cannot prove much. App orders may rise, but you will not know whether the app landing page caused it.

The handoff needs a stable web_attribution_id or equivalent identifier that survives from Mobile Web to app order.

Figure: Cross-channel attribution handoff. The web touchpoint carries an attribution_id through landing, deeplink, app landing, and app order. generated by gpt-image-2.

At minimum, the event chain should cover:

1
2
3
4
5
6
7

mweb_buy_now_click
app_landing_page_view
deeplink_click
deeplink_success
app_target_page_view
app_login_success
app_order_success

And the event payload needs enough context to join the chain:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

web_attribution_id
user_id
device_id
session_id
product_id
sku_id
campaign_id
entrance
source_page
target_page
btm_chain
experiment_id
variant_id
app_installed_flag
login_state

The exact fields will vary by system. The principle stays the same: the attribution key must cross the channel boundary, and the experiment variant must travel with it.

Decide with a matrix, not a victory lap

When the experiment ends, do not look for the one green metric that makes the feature look good.

Use a decision matrix:

The ideal result is boring:

1
2
3
4
5
6

Treatment group
Web-assisted app GMV per eligible UV increases
Total paid GMV increases
Web direct GMV is not materially damaged
D7 / D30 retention is healthy
Refund, complaint, performance, and bounce guardrails stay clean

Boring is good here. Growth systems should produce decisions, not vibes.

The useful mental model

Growth engineering is not “move a metric up.” That framing is too vague to be useful.

The better model is closer to production debugging:

1. Split the top-line metric into a flow and a segment structure.
2. Connect local actions to downstream value.
3. Preserve attribution across the whole path.
4. Run experiments that can reject the idea.
5. Use guardrails so a local win cannot hide a business loss.

If a feature cannot be expressed as a causal chain, the first task is not implementation. The first task is to fix the data model until the question can be answered.