Incrementality testing на app install: как проверить, что канал даёт новые инсталлы, а не отбирает старые

Incrementality testing на app install: как проверить, что канал даёт новые инсталлы, а не отбирает старые

Если держать тест на уровне трёх правил, математика не нужна. Сравниваешь тестовую группу и контроль: в одной показы идёт, в другой — нет. Считаешь разницу по инсталлам, CPA и post-install event rate. Если канал «работает», но в контроле падение почти такое же, это не инкремент, а переток.

База для теста:
— фиксируй гео, платформу и окно атрибуции;
— не мешай несколько каналов в один эксперимент;
— держи стабильный бюджет и креативы;
— смотри не только installs, но и first purchase / signup / D1 retention.

Ошибка, которая ломает выводы: запускать тест на слишком коротком окне. У app install есть лаг по атрибуции и по конверсии в событие, поэтому смотри хотя бы на полный цикл покупки решения пользователем. Иначе канал может выглядеть слабым только потому, что postback ещё не доехал или аудитория дозревает позже.

Если разница между тестом и контролем есть только в CPI, а event rate и удержание одинаковые, канал просто дешевле покупает уже существующий спрос. Если же растут и инсталлы, и downstream-метрики, это уже инкремент. У UA тут один ориентир: платим за прирост, а не за шум.