[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"post-fake-installs-vs-otchety-manica":3},{"id":4,"title":5,"slug":6,"description":7,"excerpt":7,"content":8,"body":8,"cover_path":9,"cover_url":10,"cover":10,"inline_path":11,"tags":12,"published_at":13,"published":14,"author_id":15,"author":16,"created_at":17,"updated_at":18},43,"Фейковые установки против отчётов тестировщиков: что происходит с метриками","fake-installs-vs-otchety-manica","Сценарное сравнение: две команды с одинаковым бюджетом. Одна купила поток установок, вторая заказала честные тесты с отчётами. Что стало с retention, аналитикой, рекламными алгоритмами и решениями через три месяца.","## Сценарий: две команды, один бюджет, разные решения\r\n\r\nДва приложения вышли в один месяц. Оба — сервисы доставки продуктов в средних городах. Оба с бюджетом 60 000 ₽ на «раскачку». Оба под давлением: инвестор попросил показать динамику к концу квартала.\r\n\r\n**Команда А** решила, что главное — цифры на дашборде. Они нашли подрядчика, который обещал «трафик с реальных устройств», и купили пакет установок. Логика: больше установок → выше позиция в сторе → больше органики → инвестор доволен.\r\n\r\n**Команда Б** решила, что главное — понять, почему из первых 200 органических установок заказ сделали 11 человек. Они запустили кампанию честного тестирования по сценариям: 40 человек проходят путь от установки до оформления заказа и пишут отчёты.\r\n\r\nДальше — что произошло с метриками у каждой через неделю, через месяц и через квартал. Это не моральная притча: мы разберём механику, по которой фейковые установки технически ломают систему принятия решений. Статья не объясняет, как покупать такой трафик, и не рассматривает манипуляцию рейтингами как допустимую тактику — она объясняет, **что именно ломается** и как это выглядит в цифрах.\r\n\r\n## Неделя 1: дашборд Команды А выглядит лучше\r\n\r\nЧерез семь дней у Команды А в аналитике 4 300 установок. У Команды Б — 240 органических плюс 40 тестовых прохождений.\r\n\r\nЕсли смотреть только на график установок, А выигрывает с огромным отрывом. Инвестор видит кривую вверх. Внутри команды — эйфория.\r\n\r\nНо посмотрим на второй слой метрик.\r\n\r\n| Метрика, неделя 1 | Команда А (купленный поток) | Команда Б (честные тесты) |\r\n|---|---|---|\r\n| Установки | 4 300 | 240 |\r\n| Открыли приложение | 3 900 | 232 |\r\n| Дошли до каталога | 2 100 | 198 |\r\n| Добавили товар в корзину | 180 | 96 |\r\n| Оформили заказ | 12 | 21 |\r\n| Retention D1 | 6 % | 27 % |\r\n| Отчётов с описанием проблем | 0 | 34 |\r\n| Средняя длина сессии | 34 сек | 4 мин 12 сек |\r\n\r\nОбратите внимание на строку «оформили заказ»: у Команды А при 18-кратном объёме установок — меньше реальных заказов. И ноль информации о том, почему.\r\n\r\nЕщё важнее retention D1 = 6 %. Эта цифра теперь **в вашей исторической базе навсегда**. Все последующие сравнения «как было \u002F как стало» будут опираться на искажённый базис.\r\n\r\n## Что технически происходит с аналитикой\r\n\r\nАналитическая система не знает, что часть пользователей ненастоящая. Она честно усредняет всё, что получила. Последствия распределяются по нескольким уровням.\r\n\r\n**1. Когорты становятся нечитаемыми.** Retention считается по когортам установки. Если 90 % когорты — пустышки, то retention когорты не описывает поведение никого: ни реальных пользователей (их сигнал утоплен), ни фейковых (у них нет поведения).\r\n\r\n**2. Средние значения теряют смысл.** Средняя длина сессии 34 секунды — это не «пользователи быстро уходят». Это среднее между «открыл и закрыл» и «пользовался 8 минут». Медиана и перцентили спасают частично, но только если вы знаете, что нужно их смотреть — а вы не знаете, потому что не различаете источники.\r\n\r\n**3. Воронка показывает ложные узкие места.** У Команды А отвал между «каталог» и «корзина» составил 91 %. Команда потратила две недели на переделку каталога. Настоящая проблема была на шаге выбора адреса доставки — но до него доходило слишком мало реальных людей, чтобы это стало заметно в графике.\r\n\r\n**4. A\u002FB-тесты перестают работать.** Если в обе группы попадает шум, разница между вариантами размывается. Тест, который раньше показал бы эффект за неделю, теперь не покажет его никогда: мощность теста убита дисперсией мусора.\r\n\r\n**5. Алгоритмы рекламных кабинетов учатся на мусоре.** Если вы передаёте события в рекламные системы для оптимизации, а часть событий не соответствует реальному поведению, вы буквально описываете алгоритму профиль «идеального пользователя», который ничего не покупает. Он найдёт вам ещё таких же.\r\n\r\n:::chart type=bar title=\"Доля пригодных для решений данных, % (сценарий команд А и Б)\"\r\nКоманда А: аналитика|15\r\nКоманда А: A\u002FB-тесты|10\r\nКоманда А: обратная связь|0\r\nКоманда Б: аналитика|85\r\nКоманда Б: A\u002FB-тесты|80\r\nКоманда Б: обратная связь|90\r\n:::\r\n\r\n![Что происходит с воронкой, когда в когорту попадает искусственный трафик](inline-mid.jpg)\r\n\r\n## Месяц 1: расхождение становится очевидным\r\n\r\nКоманда Б за месяц провела три волны тестов (40 + 25 + 25 = 90 прохождений) и внесла изменения:\r\n\r\n- На шаге выбора адреса 19 из 40 тестировщиков не смогли найти свой дом, потому что поле требовало точного формата улицы. Переделали на подсказки при вводе.\r\n- 12 человек написали, что не поняли, откуда берётся цена доставки. Добавили пояснение до оформления, а не после.\r\n- 8 человек столкнулись с тем, что корзина очищалась при смене города. Исправили баг.\r\n- 22 человека отметили, что время доставки становится видно только на последнем экране. Перенесли наверх.\r\n\r\nRetention D1 по органическим пользователям вырос с 27 % до 38 %. Конверсия в первый заказ — с 8,7 % до 16,1 %.\r\n\r\nКоманда А за месяц:\r\n\r\n- Позиция в категории поднялась на несколько мест, потом вернулась.\r\n- Органика выросла незначительно — потому что алгоритмы сторов учитывают не только объём установок, но и удержание, вовлечённость, удаления. Пустые установки дают плохие сигналы качества.\r\n- Реальных отзывов почти нет, а рейтинг начал падать: настоящие пользователи, приходящие из органики, натыкались на ту же проблему с адресом.\r\n- Бюджет закончился. Понимания продукта — ноль.\r\n\r\n| Итог месяца | Команда А | Команда Б |\r\n|---|---|---|\r\n| Потрачено | 60 000 ₽ | ≈ 10 260 ₽ (90 тестов с комиссией) |\r\n| Найдено и исправлено проблем | 0 подтверждённых | 4 существенных |\r\n| Конверсия в первый заказ | 0,3 % | 16,1 % |\r\n| Retention D1 (реальные пользователи) | неизвестно | 38 % |\r\n| Остаток бюджета на рекламу | 0 ₽ | ≈ 49 700 ₽ |\r\n| Риск по правилам платформ | Высокий | Отсутствует |\r\n| Доверие к внутренней аналитике | Подорвано | Сохранено |\r\n\r\nСтрока «остаток бюджета» — самая недооценённая. Команда Б не просто узнала больше. Она сохранила 83 % бюджета, который теперь можно потратить на рекламу **уже работающего** продукта.\r\n\r\n## Квартал: последствия, которые не видны сразу\r\n\r\nК третьему месяцу у Команды А появились проблемы второго порядка.\r\n\r\n**Потеря доверия к цифрам внутри команды.** Когда все знают, что часть трафика ненастоящая, любой спор упирается в «а это реальные данные или нет?». Аналитик перестаёт быть арбитром. Решения принимаются по авторитету, а не по фактам.\r\n\r\n**Невозможность сравнить периоды.** Инвестор просит: покажите динамику retention за квартал. Но первый месяц — с искусственным трафиком, второй — частично, третий — чистый. Retention «вырос» с 6 % до 19 % не потому, что продукт улучшился, а потому, что мусор вымылся из когорт. Это не достижение, но выглядит как достижение — и команда рискует сделать ложный вывод о том, какие действия помогли.\r\n\r\n**Риск со стороны платформ.** App Store Review Guidelines и Google Play Developer Program Policies прямо запрещают манипуляцию установками, рейтингами и отзывами. Платформы располагают собственными системами выявления аномалий: неестественные паттерны установок, кластеры устройств, несоответствие поведения нормальным распределениям, синхронные оценки. Санкции варьируются от обнуления рейтинговых сигналов до удаления приложения и блокировки аккаунта разработчика. Важно понимать: риск не исчезает со временем — он реализуется, когда платформа решит проверить, а не когда команда решит остановиться.\r\n\r\n**Испорченный маркетинговый фундамент.** Модели похожих аудиторий, обученные на мусорных событиях, придётся обнулять и переобучать. Это месяцы работы.\r\n\r\nКоманда Б к третьему месяцу имеет базу из 140 отчётов, в которых зафиксировано, как менялось восприятие продукта. Это уникальный материал: тексты для страницы в сторе, формулировки для онбординга, список того, что было непонятно, и подтверждение, что стало понятно.\r\n\r\n:::compare\r\nЧто остаётся от купленных установок|Что остаётся от честных отчётов\r\nГрафик, который нельзя использовать|База знаний о продукте\r\nИспорченная историческая база метрик|Чистая базовая линия для сравнений\r\nОбученные на мусоре алгоритмы|Корректные события для оптимизации\r\nРиск санкций платформы|Отсутствие регуляторного риска\r\nНоль знаний о причинах отвала|Список причин с частотностью\r\nНулевой остаток бюджета|Бюджет на рекламу готового продукта\r\nНедоверие к аналитике внутри команды|Общий язык фактов в команде\r\n:::\r\n\r\n## Как отличить честный тест от искусственной установки на уровне данных\r\n\r\nПолезное упражнение — понять, чем отличается «пользователь, который действительно прошёл сценарий» от записи в логах, которая просто существует.\r\n\r\nЧестный тестовый прогон в данных выглядит так:\r\n\r\n- Сессия длиной несколько минут с неравномерными интервалами между событиями (человек читает, думает, ищет).\r\n- Наличие «ошибочных» траекторий: заход не туда, возврат назад, повторное нажатие. Живое поведение всегда содержит шум навигации.\r\n- Разнообразие устройств и версий ОС, соответствующее реальному распределению рынка.\r\n- Наличие текстового артефакта вне приложения — отчёта с описанием и скриншотами.\r\n- Скриншот, который совпадает с состоянием, зафиксированным в логах по времени.\r\n\r\nИскусственная установка выглядит иначе: короткая сессия или её отсутствие, слишком ровные интервалы, отсутствие ошибочных траекторий, кластеризация по устройствам и времени, полное отсутствие внешнего артефакта.\r\n\r\nКлючевая мысль: **отчёт — это внешнее доказательство, которое нельзя подделать так же дешёво, как событие в логе**. Именно поэтому модель «оплата за принятый отчёт» устойчивее, чем модель «оплата за установку». Событие стоит копейки и не требует человека. Отчёт со скриншотами и описанием шагов требует, чтобы человек действительно прошёл путь.\r\n\r\n| Признак | Честное прохождение | Искусственная установка |\r\n|---|---|---|\r\n| Длина сессии | Минуты, неравномерно | Секунды или ноль |\r\n| Траектория | С возвратами и ошибками | Прямая или отсутствует |\r\n| Внешний артефакт | Отчёт, скриншоты | Нет |\r\n| Устройства | Разнообразные | Кластеры |\r\n| Проверяемость | Автор принимает или отклоняет | Нечего проверять |\r\n| Влияние на метрики | Улучшает понимание | Разрушает базис |\r\n\r\n## Механика модерации как антифрод-контур\r\n\r\nНа платформе вроде Manica защита от «пустой работы» встроена в сам процесс, а не приделана сбоку.\r\n\r\n**Чек-лист задаёт проверяемые требования.** Если шаг требует скриншот экрана оплаты, отчёт без него нельзя принять.\r\n\r\n**Автор кампании модерирует вручную.** Он смотрит на соответствие отчёта чек-листу и решает: принять или отклонить с указанием причины.\r\n\r\n**Оплата и комиссия начисляются только за принятые отчёты.** Это меняет экономику для исполнителя: халтура не приносит денег, поэтому нет смысла ею заниматься. Сравните с моделью «оплата за факт установки», где халтура — единственная экономически рациональная стратегия.\r\n\r\n**Спорные случаи разбираются по формальным критериям.** Именно поэтому критерии приёмки важно публиковать заранее: без них модерация становится произволом, и система теряет доверие с обеих сторон.\r\n\r\n**История отчётов накапливается.** Исполнитель с длинной историей принятых работ — сам по себе сигнал качества.\r\n\r\n:::chart type=bar title=\"Стоимость одного заказа, оформленного реальным пользователем (₽, сценарий)\"\r\nКоманда А: купленный поток|5000\r\nКоманда Б: после 3 волн тестов|420\r\n:::\r\n\r\nЦифра для Команды А получена простым делением: 60 000 ₽ на 12 заказов. Она абсурдна, и это главный аргумент: покупка объёма не решала задачу, для которой её покупали.\r\n\r\n## Что делать, если искусственный трафик уже попал в данные\r\n\r\nСитуация встречается: команда пришла в проект, а в истории уже есть сомнительный период. Практические шаги:\r\n\r\n1. **Найдите и задокументируйте границы периода.** Даты начала и конца, источники, объём. Без этого дальше работать нельзя.\r\n2. **Пометьте затронутые когорты флагом в аналитике.** Не удаляйте — исключайте из расчётов осознанно, чтобы решение было воспроизводимым.\r\n3. **Постройте новую базовую линию на чистом периоде.** Минимум 4 недели без искусственного трафика.\r\n4. **Пересчитайте ключевые метрики только по органическим и проверяемым источникам.** Сравнивайте будущие результаты с новым базисом, а не с историческим.\r\n5. **Обнулите и переобучите модели похожих аудиторий**, если события уходили в рекламные системы.\r\n6. **Напишите внутренний changelog методики.** Через полгода никто не вспомнит, почему в дашборде разрыв, и появится соблазн «дорисовать» историю.\r\n7. **Замените источник данных о качестве.** Вместо объёма — отчёты по сценариям, которые дают причины и не загрязняют когорты.\r\n\r\nЭто неприятная, но конечная работа. Гораздо хуже — продолжать принимать решения по испорченным данным.\r\n\r\n:::quiz\r\nКоманда видит: за месяц 5 000 установок, retention D1 = 5 %, 9 заказов. Подрядчик уверяет, что трафик «с реальных устройств». Что это означает для аналитики?\r\nA) Канал слабый, надо сменить подрядчика и закупить ещё объём\r\nB) Аудитория не та, нужно менять позиционирование\r\nC) Данные нельзя использовать для продуктовых решений: когорты загрязнены, воронка показывает ложные узкие места, базовая линия метрик испорчена\r\nD) Всё нормально, retention низкий у всех новых приложений\r\nПравильный: C\r\nПояснение: retention 5 % при 5 000 установок и 9 заказах — это не характеристика канала или аудитории, а признак того, что в когорте почти нет реального поведения. Такие данные нельзя использовать ни для оценки продукта, ни для A\u002FB-тестов, ни для обучения рекламных алгоритмов. Вариант A удваивает проблему, B делает вывод из недостоверных данных, D ошибочно нормализует аномалию.\r\n:::\r\n\r\n## FAQ\r\n\r\n**Разве нельзя просто «разбавить» купленные установки реальными и смотреть на реальных отдельно?**\r\nТеоретически — если бы вы могли надёжно разделить источники. На практике атрибуция неидеальна, часть мусора попадёт в «органику», а средние по продукту всё равно будут искажены. Плюс остаётся риск со стороны платформы, который не зависит от вашей внутренней разметки.\r\n\r\n**А если цель не аналитика, а только позиция в сторе?**\r\nАлгоритмы сторов учитывают удержание, вовлечённость и удаления, а не только установки. Пустые установки дают отрицательные сигналы качества, поэтому эффект нестабилен и обычно краткосрочен. Плюс это прямое нарушение правил платформ.\r\n\r\n**Сколько честных тестов нужно, чтобы заменить «объём»?**\r\nОни решают другую задачу, поэтому не заменяют. Для поиска причин отвала достаточно 20–50 прохождений. Для оценки экономики нужен реальный рекламный трафик — но уже после того, как причины устранены.\r\n\r\n**Инвестор просит показать рост установок. Что показывать?**\r\nКонверсию в ключевое действие, retention, стоимость реального заказа и список исправленных проблем с подтверждением. Это сильнее, чем график установок: он показывает, что команда умеет находить и устранять причины, а не только тратить бюджет.\r\n\r\n**Комиссия 15 % не делает честные тесты дороже покупки установок за единицу?**\r\nЗа единицу — да, отчёт дороже установки в десятки раз. Но считать надо не за единицу, а за результат. В сценарии выше стоимость одного реального заказа отличалась более чем в десять раз в пользу честных тестов.\r\n\r\n## Итоги\r\n\r\n- Купленные установки улучшают график и одновременно уничтожают способность читать данные: когорты, средние, воронка, A\u002FB-тесты и обучение рекламных алгоритмов страдают одновременно.\r\n- Самое дорогое последствие — испорченная историческая база: все будущие сравнения «до \u002F после» опираются на ложный базис.\r\n- Отчёт с шагами и скриншотами — внешнее доказательство, которое нельзя подделать так же дешёво, как событие в логе. Поэтому оплата за принятый отчёт устойчивее оплаты за установку.\r\n- Модерация с публичными критериями приёмки — рабочий антифрод-контур: халтура экономически невыгодна исполнителю.\r\n- Правила App Store и Google Play прямо запрещают манипуляцию установками и рейтингами; риск реализуется по решению платформы, а не команды.\r\n- Если искусственный трафик уже в данных — пометьте период, постройте новую базовую линию, задокументируйте методику.\r\n\r\n## Заключение\r\n\r\nЧерез квартал Команда А имела красивый график за первый месяц, испорченную аналитику, нулевой бюджет и незакрытый риск. Команда Б — конверсию в заказ выше в несколько раз, 140 отчётов в базе знаний, почти весь бюджет нетронутым и понимание, на что его тратить.\r\n\r\nРазница между ними не в морали и не в бюджете. Разница в том, что одна команда покупала **цифру**, а вторая покупала **знание**. Цифру можно нарисовать, но по ней нельзя работать. Знание неудобно, зато по нему можно написать код и заработать деньги.\r\n","\u002Fstorage\u002Farticles\u002F42-fake-installs-vs-otchety-manica\u002Fcover.jpg","https:\u002F\u002Fmanica.mrdev.ru\u002Fstorage\u002Farticles\u002F42-fake-installs-vs-otchety-manica\u002Fcover.jpg","\u002Fstorage\u002Farticles\u002F42-fake-installs-vs-otchety-manica\u002Finline.jpg",[],"2026-09-05T00:00:00+03:00",true,1,"Admin","2026-09-26T01:41:38+03:00","2026-09-26T01:49:01+03:00"]