# Testing an App Install Banner on Mobile Product Pages

Page: https://alidemirbas.com.tr/en/lab/ab-test-library/tests/testing-an-app-install-banner-on-mobile-product-pages

## Hypothesis

If the banner on the product page moves some visitors into the app, a purchase left unfinished on the web may be completed there, though the banner can also interrupt the current session. When extra app purchases outweigh what is lost on the web, cross-channel revenue per visitor could rise.

## When to run this test

If mobile-web losses cluster after the product page in analytics and survey answers show visitors asking about the app, the app may be able to ease that journey, and this banner test can show whether it does. What you should see is installs rising while purchases lost on the web come back in the app. If the losses come from missing information or slow loading on the product page, address that first; if you cannot match web and app identities yet, fix attribution first. Keep the banner out of the payment flow and set it up so it does not reopen on every page.

## Primary metric

**Cross-channel revenue per visitor**: Attribute web and app revenue to the originally assigned visitor over a fixed period; record identity-matching gaps and deduplicate orders.

## Other metrics

- **App install rate**: Measure installs per assigned mobile-web visitor.
- **Web purchase conversion rate (CR)**: Track whether purchases are lost on the web.
- **Session continuation rate**: Make sure visitors do not drop out of the journey.
- **Seven-day app retention**: Use retention among attributed installs as a diagnostic and also report returning app users per assigned visitor.

## What to check before and during the test

- **Banner**: Add one dismissible app banner to eligible mobile-web pages.
- **Placement**: Keep placement and presentation fixed.
- **Audience**: Define eligible users before the test and keep the definition fixed.
- **Offer**: Keep existing app incentives unchanged; changing the discount is a separate test.
- **Attribution**: Check cross-channel identity matching before making a decision from combined revenue.

## What to watch when reading the result

- A higher app install rate does not justify ignoring a drop in web purchase conversion. Cross-channel revenue per visitor, with orders deduplicated, is the deciding measure; if session continuation falls, the banner may be breaking up the shopping journey.
- This result comes from this placement and presentation on product pages under the current app incentives; test it on other pages before extending it there. Read app revenue and retention over one fixed follow-up period, and report retention both among attributed installs and as returning app users per assigned visitor.
- When the result is murky, check whether identity-matching gaps cluster in one arm, since unmatched orders can hide a difference. Run the web purchase conversion numbers through the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test) to see whether that gap is more than chance. It does not test average revenue, so treat the noisier revenue gap with the same caution.

## Frequently Asked Questions

### Does increased installation make the app banner a winner?

No. Use cross-channel revenue per originally assigned visitor as the primary outcome. Web purchases lost without compensating app revenue are not established gains.

### How should web and app revenue be combined?

Use a shared attribution window, deduplicate orders and document identity-linking gaps. Validate cross-channel matching before using the combined outcome for the decision.

### Where should the banner not appear?

Avoid interrupting checkout, provide dismissal and prevent repeated reopening during the session. Keep placement stable and monitor continuation of the shopping task.