CPP experiment: conversion lift vs downstream payer quality

Apple’s custom product pages documentation states operators can compare product-page impressions, downloads, redownloads and conversion rates in App Analytics, and can also view retention and average proceeds per paying user for each CPP versus the default page. That is the official definition set this lab uses. It does not publish an industry CVR or payer-rate average.

Define the calculation (labelled synthetic)

Inputs (synthetic teaching example, not a measured campaign):

• impressions_default, downloads_default
• impressions_cpp, downloads_cpp
• payers_default, payers_cpp among those download cohorts
• Optional: proceeds_default, proceeds_cpp (average proceeds per paying user × payers)

Definitions:

• cvr = downloads / impressions
• payer_rate = payers / downloads
• cvr_lift = cvr_cpp / cvr_default - 1
• payer_lift = payer_rate_cpp / payer_rate_default - 1

A page can win conversion and still lose payer quality. Do not retire the default page on CVR alone if payer_lift is negative and proceeds fall.

Worked synthetic example

CVR lift = +30%. Payer-rate lift = −20%. Absolute payers rise only slightly (200 → 208). If average proceeds per paying user also fall, contribution can decline despite the CVR win.

Evidence and limits

Apple documents that App Analytics can show retention and average proceeds per paying user by CPP. This lab does not claim those fields equal MMP ROAS. Product page optimization is a separate traffic-split test (up to three treatments, up to 90 days) and is not a substitute for CPP↔paid creative message match. No live account was inspected.

Download the artifact.

Research checked 20 September 2026. Local draft; human editorial review pending.