{
 "generated_at": "2026-08-19T07:31:24.420Z",
 "собрано_из": {
  "опыты": [
   "out/proof/p1.json",
   "out/proof/p2.json",
   "out/proof/p3.json",
   "out/proof/p4.json",
   "out/proof/p5.json"
  ],
  "данные": "public/live-full.json, живой прогон от 16.08.2026, 3637 кандидатов",
  "разбор": "research/aso-tools-decision.md от 18.08.2026",
  "сборщик": "scraper/proof/assemble.js"
 },
 "verdict": {
  "holds": true,
  "one_liner": "Покупать частотность сейчас незачем — но не по той причине, которую написал разбор.",
  "text": "Практический вывод разбора — «не покупать ничего из ASO-инструментов сейчас» — держится, и держится на самом сильном месте: продаваемая ось отвечает не на тот вопрос, который решает проект. Спрос ранжирует исход «ниша пуста и её держит побиваемый» хуже монетки (AUC 0.4205 против 0.5002 у случайного порядка), бесплатный замер выдачи даёт 0.8888, а идеальная по конструкции частотка с весом, подобранным на тех же данных, добавляет к модели 0.0011 AUC. Купленная цифра тратится вдобавок к нашему скану, а не вместо него. Бесплатное числовое поле подсказок объёма действительно не содержит: с седьмой строки значения одинаковы у всех полных ответов — и у whatsapp с десятью миллиардами установок у лидера, и у польского «co to za hit» с пятьюдесятью тысячами; связь значения с популярностью нулевая. Непроведённый тест из разбора проведён: на неотобранных 3569 кандидатах спрос не отличает пустую нишу от занятой. Два аргумента разбора при проверке развалились, и прятать это незачем. Первый: опыт 3 показал, что «вендоры просто перепродают наш же сигнал» доказано только на полном наборе, где апловский якорь уперт в пол у 95% кандидатов; на витрине, где кросс-чек App Store реально сделан, порог 0,7 проходит один вариант из трёх. И аргумент «после подстановки витрина почти не изменилась» не значит вообще ничего: чистый шум оставляет на месте 75% топ-100, а полностью выключенный спрос — 94%, больше любой подстановки. Второй: утверждение «цена запроса к API ASOMobile в токенах не опубликована нигде» опровергнуто первоисточником — в документации Usage Result лежит пример с конкретными ценами, включая /keyword-check/ = 0 токенов. Это пример, а не прайс, и он спорит со страницей тарифов, но слово «нигде» было неверным. Ещё одна поправка внутри: опыт 2 сначала заявил, что прокси «смотрит в обратную сторону»; состязательная проверка это опровергла — знак наведён составом выборки, внутри одного гео и одной длины запроса AUC 0.4829 с интервалом, накрывающим 0,5. Правильная формулировка скучнее и честнее: прокси не показывает ничего. Итог: решение то же, обоснование другое. Не покупаем, потому что ось не та и потому что скан выдачи всё равно придётся делать целиком, а не потому что вендорская цифра — это наш собственный сигнал с наценкой. Последнее ни доказано, ни опровергнуто: ни один вендор так и не был опрошен ни одной нашей реальной фразой.",
  "чтоПоказало": {
   "опытовЗа": [
    "p1",
    "p2",
    "p5"
   ],
   "опытовПротив": [
    "p3"
   ],
   "опытовБезЗнака": [
    "p4"
   ],
   "опровергнутоСостязательнойПроверкой": [
    "p2",
    "p3"
   ],
   "опровергнутыхВендорскихФактов": [
    "Цена запроса к API ASOMobile в токенах не опубликована нигде"
   ]
  }
 },
 "experiments": [
  {
   "id": "p1",
   "title": "Что на самом деле лежит в google:suggestrelevance",
   "отработал": true,
   "ran_at": "2026-08-19T06:55:05.302Z",
   "question": "Несёт ли единственное бесплатное числовое поле автоподсказок хоть каплю информации об объёме поиска — или это чистая функция ранга?",
   "headline": "Начиная с 7-й строки google:suggestrelevance одинаков у всех 22 полных ответов (558, 557, … 550) — от «whatsapp» с 10000000000 установок у лидера до «co to za hit» с 50000; внутри ответа Спирмен с позицией равен −1 во всех 31 ответах, весь размах значений 2.275× при разбросе популярности в 10^5.3, связь значения на позиции 0 с установками лидера выдачи Play нулевая: Спирмен -0.1664 (интервал -0.491…0.172).",
   "method": "Взяли три группы фраз: двенадцать заведомо жирных голов по разным языкам, двенадцать середняков и двенадцать настоящих 4-5-словных хвостов из живого прогона от 16.08.2026. По каждой фразе дёрнули автоподсказку Google с client=chrome и вытащили массив google:suggestrelevance из четвёртого элемента ответа, а также google:verbatimrelevance. Внутри каждого ответа посчитали Спирмена между значением и номером строки, а между ответами — разброс значения на фиксированных позициях 0, 1 и 2. Настоящую популярность взяли бесплатным замером: установки лидера выдачи Play по той же фразе (для голов — живой поиск num=5, для остальных — уже собранная выдача из live-full.json), и сопоставили с ней значение на позиции 0. Отдельно посчитали, какую долю дисперсии значения объясняет один только номер строки (eta² по позиции), и сколько всего разных значений встречается. Наконец, проверили автоподсказку самого Google Play через gplay.suggest — есть ли в её ответе хоть одно числовое поле.",
   "key_numbers": [
    {
     "label": "ответов, где связь значения с номером строки ровно −1",
     "value": 31,
     "note": "из 31 ответа с тремя и более подсказками — то есть значение просто убывает по позиции",
     "из": "numbers.спирменВнутриОтвета.сколькоРовноМинусЕдиница"
    },
    {
     "label": "позиций, где значение одинаково у всех полных ответов",
     "value": 9,
     "note": "у 22 ответов на 15 строк: с 7-й строки идёт та же лесенка 558, 557, … 550 и у whatsapp, и у четырёхсловного хвоста",
     "из": "numbers.поВсемПозициям.лесенка.средиОтветовНа15Строк.позицийСОдинаковымЗначениемУВсех"
    },
    {
     "label": "Спирмен значения на первой строке с установками лидера выдачи",
     "value": -0.1664,
     "note": "интервал −0.491…0.172, n=31 — связи с популярностью нет",
     "из": "numbers.корреляцияСУстановкамиЛидера.спирмен"
    },
    {
     "label": "весь размах значений поля, раз",
     "value": 2.275,
     "note": "при разбросе установок лидера в 10^5.3 раза",
     "из": "numbers.поВсемПозициям.отношениеМаксКМин"
    },
    {
     "label": "разных значений на 391 наблюдение",
     "value": 26,
     "note": "словарь поля крошечный, 95,4% наблюдений лежат между 550 и 604",
     "из": "numbers.поВсемПозициям.разныхЗначений"
    },
    {
     "label": "разных значений установок за всей корреляцией",
     "value": 9,
     "note": "мера популярности грубая: у 8 строк из 31 лидер выдачи — одно и то же приложение",
     "из": "numbers.корреляцияСУстановкамиЛидера.качествоМерыПопулярности.разныхЗначенийУстановок"
    },
    {
     "label": "фраз из 36 не вернули даже трёх подсказок",
     "value": 5,
     "note": "по настоящему хвосту у Google бесплатно нет ни чисел, ни строчек",
     "из": "numbers.пустыеОтветы.сколько"
    },
    {
     "label": "есть ли числовое поле в автоподсказке самого Google Play",
     "value": false,
     "note": "четыре пробы, во всех — только строки",
     "из": "numbers.автоподсказкаPlay.естьЛиЧисловоеПоле"
    }
   ],
   "supports_verdict": true,
   "caveats": [
    "Проверялись подсказки веб-поиска Google (suggestqueries), а не внутренняя частотность Google Play — про неё этот опыт не говорит ничего, кроме того, что бесплатного числа там нет.",
    "Установки лидера выдачи Play — грубый прокси популярности запроса: они меряют размер приложения, а не число поисков. Отсутствие связи со значением подсказки не доказывает, что запросы одинаково популярны, — оно доказывает, что значение не следует за размером лидера.",
    "Клиент client=chrome возвращает свою шкалу релевантности; другие клиенты (firefox, toolbar) могут отдавать иные наборы полей, они не проверялись.",
    "По 36 запросам нельзя утверждать, что во всём мире у поля ровно такой словарь значений: утверждение сильное только про то, что разброс между головой и хвостом отсутствует.",
    "Опыт не проверяет платные источники частотности — он закрывает только вопрос «есть ли объём в бесплатном поле подсказок».",
    "Поправка к формулировке разбора: чистой функцией одного ранга поле всё-таки не является. Верхние две-три строки иногда получают отдельные высокие отметки (700, 750, 800, 900, 1050, 1250), и что именно их включает, из этих данных понять не удалось: ни дословный повтор запроса, ни продолжение запроса одним словом их не объясняют. Доказано только то, что с популярностью эти отметки не связаны.",
    "Обращений к сети за один прогон опыта: 64 — 36 к suggestqueries, 12 поисков Play, 12 карточек приложений, 4 подсказки самого Play. В этом запуске живыми ушли 0, остальное отдал дисковый кэш (64 попаданий).",
    "Мера популярности грубее, чем кажется по n: установки Play округлены до ступенек (1e6, 5e6, 1e7 …), а у «голов» на разных языках лидер выдачи часто одно и то же приложение (калькулятор Samsung). Сколько за корреляцией стоит по-настоящему разных чисел и приложений, видно в блоке качествоМерыПопулярности; с такой мерой и 31 строкой опыт способен заметить только сильную связь, а слабую — нет.",
    "Номер строки, с которого значения совпадают у всех, зависит от того, кто попал в выборку: чем меньше в ней ответов, тем раньше сходятся. Устойчиво здесь не «седьмая строка», а сам факт: ниже верхушки значение не отличает whatsapp от четырёхсловного хвоста.",
    "Пять фраз из 36 подсказок вообще не вернули (или вернули меньше трёх) — они выпали из расчётов. Это тоже ответ по существу: по настоящему хвосту у Google бесплатно нет даже строчек, не то что чисел."
   ],
   "adversarial": {
    "refuted": false,
    "confidence": "высокая",
    "fixed": true,
    "problems": [
     "Цена прогона в caveats была вписана руками и врала: «63 живых запроса: 36 suggest, 12 поисков, 11 карточек, 4 подсказки Play». Счётчик самого клиента показывает 64 обращения, а проверка живьём показала, что лёгкая выдача Play не отдаёт installs ни у одной из 12 голов — значит карточек было 12, а не 11. Починил: теперь счётчики по видам считаются в коде, в JSON пишется 64 (36/12/12/4).",
     "Поле «ответовСоСтрогимУбыванием» считалось нестрого (v <= предыдущего) при том, что называется строгим. На этих данных связок нет и число не менялось (31), но на другой выборке подпись разошлась бы с расчётом. Починил на строгое сравнение.",
     "Мера популярности вырождена сильнее, чем видно по n=31: установки Play округлены до ступенек, всего 9 различных значений на 31 строку, и у 8 строк лидер выдачи — буквально одно и то же приложение (калькулятор Samsung на восьми языках). Нулевой Спирмен при такой мере закрывает только сильную связь; слабую опыт заметить не в состоянии. Добавил в JSON посчитанный блок качествоМерыПопулярности и оговорку.",
     "«Начиная с 7-й строки» — свойство конкретной выборки, а не константа. На моей независимой выборке из 24 новых фраз значения сходятся с 6-й строки, у одной только группы «голова» — тоже с 6-й. Устойчив сам факт совпадения ниже верхушки, а не номер строки. Добавил посчитанный разрез по группам и оговорку.",
     "Спирмен −1 внутри ответа — почти тавтология: любая строго убывающая последовательность даёт ровно −1, так что это описание монотонности, а не независимое свидетельство против «частотности». Само по себе не ошибка, но вес у этого числа меньше, чем кажется по формулировке headline.",
     "Установки лидера для голов меряются живым поиском Play + карточкой сегодня, а для середины и хвоста берутся из снимка live-full.json от 16.08. Источники разные, хотя поле одно (minInstalls топ-1). На вывод это не влияет, но пары в корреляции не вполне однородны.",
     "Пять фраз из 36 (в том числе оба «alarma despertador sin anuncios» — дубль одной фразы в es-ES и es-MX) выпали по фильтру n>=3 и не участвуют ни в одном расчёте; headline «во всех 31 ответах» относится к уже отфильтрованному множеству. В caveats это раскрыто, но из headline не видно."
    ],
    "note": "Вывод устоял. Перезапустил всё на ДРУГОЙ выборке (24 новые фразы из того же прогона, другие гео-слоты, другие пороги установок, 24 живых запроса): внутри ответа Спирмен с позицией = −1 во всех 18 ответах, значения совпадают у всех полных ответов начиная с 6-й строки, а связь значения на позиции 0 с установками лидера +0.0881 (интервал −0.405…0.554) — снова ноль, только с другим знаком шума. На объединённой выборке n=49 Спирмен −0.0286 (интервал −0.301…0.243), лесенка одинакова у всех 35 полных ответов начиная с позиции 6. Все числа headline сверены с JSON и сходятся. Найдены и починены прямо в p1-suggest-relevance.js две настоящие ошибки: вписанная руками и неверная разбивка цены прогона (было «63: 36/12/11/4», на деле 64: 36/12/12/4 — карточку пришлось тянуть для всех 12 голов) и нестрогое сравнение под именем «строгое убывание». Плюс добавлены посчитанные кодом блоки, показывающие слабое место опыта: за корреляцией стоит всего 9 различных значений установок и одно приложение-лидер на 8 строк, поэтому «связи нет» здесь честно означает «сильной связи нет», а номер седьмой строки зависит от выборки. Скрипт перезапущен, отработал без живых запросов (64 попадания в кэш), supports_verdict остался true.",
    "источник": "состязательная проверка вторым агентом, 19.08.2026"
   }
  },
  {
   "id": "p2",
   "title": "Тест, который разбор признал непроведённым: различает ли спрос-прокси пустую нишу и занятую на неотобранном множестве",
   "отработал": true,
   "ran_at": "2026-08-19T06:57:25.572Z",
   "question": "Знаменитая σ прокси меряна на уже отобранном верху. Если взять все 3637 кандидатов подряд — различает ли наш бесплатный спрос «пусто» и «занято», и различает ли хоть один из бесплатных признаков лучше?",
   "headline": "На неотобранных 3569 кандидатах AUC спроса на «пусто против занято» 0.4289 (интервал 0.4098–0.4489) — различать пустую нишу и занятую спрос не умеет; при этом обратный знак наведён составом выборки: внутри одного гео и одной длины запроса AUC 0.4829 (0.459–0.5083, p=0.18891), то есть ровно монетка.",
   "method": "Берём весь живой прогон целиком, ничего не отбирая, и выбрасываем только класс ERROR — там скан выдачи не состоялся, класса ниши просто нет. Сначала считаем describe(demand) на четырёх вложенных множествах (всё, без ошибок, витрина, топ-200) плюс топ-200 по самому спросу, и на каждом берём бутстрап-интервал для σ с фиксированным seed — чтобы видеть, сколько разброса съедает отбор. Затем главный вопрос: AUC спроса на метку «пусто против занято», к нему разница средних, Коэна d и перестановочный тест на 5000 перемешиваний. Ровно те же величины считаем для побиваемости инкумбента, установок лидера в log10, лексического совпадения maxL3 и наличия точного приложения в App Store, и отдельно помечаем, какие из этих признаков сами участвуют в определении класса — их высокая AUC не заслуга, а тавтология. Спирмен спроса с установками лидера считаем с интервалом и сверяем с 0,108 из разбора; дополнительно — Спирмен спроса с числом отзывов точного приложения в App Store, это единственный независимо замеренный спрос в наших данных. Разрезаем неотобранное множество по гео и по числу слов в запросе и смотрим, есть ли подгруппа, где AUC уезжает от монетки хотя бы на 0,10. И в конце — главная поправка: общая AUC складывает разные рынки и разные длины запроса, а на скан кандидатов отбирали по специфичности, умноженной на спрос, поэтому и то и другое связано с классом ниши искусственно. Поэтому считаем ещё стратифицированную AUC: внутри гео, внутри числа токенов и внутри пары «гео и число токенов», складывая внутристратные AUC с весом «пусто × занято», с бутстрап-интервалом и перестановкой меток внутри страты.",
   "key_numbers": [
    {
     "label": "AUC спроса на «пусто против занято», всё в одной куче",
     "value": 0.4289,
     "note": "интервал 0.4098–0.4489 на 3569 неотобранных кандидатах",
     "из": "numbers.demandDiscrimination.unselected.auc"
    },
    {
     "label": "та же AUC внутри одного гео и одной длины запроса",
     "value": 0.4829,
     "note": "интервал 0.459–0.5083, перестановочный p=0.18891 — ровно монетка",
     "из": "numbers.stratified.byGeoAndTokens.auc"
    },
    {
     "label": "Спирмен спроса с установками лидера",
     "value": 0.1077,
     "note": "разбор приводил 0,108 — цифра подтвердилась, интервал 0.0767–0.1405",
     "из": "numbers.correlations.demandVsLeaderInstallsLog.rho"
    },
    {
     "label": "Спирмен спроса с числом отзывов двойника в App Store",
     "value": 0.0199,
     "note": "единственная независимо замеренная величина спроса в наших данных, n=230, интервал −0.1093…0.1537",
     "из": "numbers.correlations.demandVsAppStoreRatings.rho"
    },
    {
     "label": "σ спроса на всём наборе",
     "value": 0.1431,
     "note": "на топ-200, отобранном по самому спросу, она падает до 0.0353 — часть «прокси не различает» есть эффект отбора",
     "из": "numbers.spreadBySelection.allCandidates.sd"
    },
    {
     "label": "во сколько раз σ съедается отбором по спросу",
     "value": 0.2467,
     "note": "от полного набора остаётся четверть разброса",
     "из": "numbers.spreadShrinkRatios.top200DemandVsAll"
    },
    {
     "label": "AUC лучшего бесплатного признака — лексической занятости топ-3",
     "value": 0.7671,
     "note": "но он входит в определение класса ниши, поэтому это измерение своей же формулы, а не предсказание",
     "из": "numbers.signalRanking.0.auc"
    },
    {
     "label": "AUC спроса в id-ID — единственном гео, где он работает в нужную сторону",
     "value": 0.6782,
     "note": "n=113, поправку на 21 сравнение не проходит",
     "из": "numbers.subgroups.byGeo.4.auc"
    }
   ],
   "supports_verdict": true,
   "caveats": [
    "Опыт ничего не говорит о вендорских числах: они не запрашивались ни разу, здесь меряется только наш собственный прокси и то, что уже лежит в данных.",
    "Метка «пусто/занято» — это наш же classifyGap, а не факт рынка. Если классификатор неправ, неправ и тест; проверить его можно только выпуском приложения.",
    "Побиваемость, установки лидера и maxL3 входят в само определение класса — их AUC не предсказание, а измерение собственной формулы. Сравнивать их с demand по-честному нельзя, они помечены флагом partOfLabelDefinition.",
    "Множество из 3637 кандидатов не является случайной выборкой из всех 126 086 отфильтрованных ключей: отбор на скан шёл по selectionScore = специфичность × спрос, то есть слабый остаточный отбор по спросу тут всё-таки есть. Список неотсканированных ключей в этот воркtree не попал, поэтому величину остаточного отбора замерить не удалось.",
    "Гео сильно перекошено: больше половины кандидатов — ru-RU, поэтому общие числа в основном про русскую выдачу.",
    "App Store проверен не у всех, а только у части кандидатов, — по этому признаку выборка меньше и она сама отобрана крос-чеком.",
    "Разрезы по гео и по числу слов — это 21 сравнений подряд; поправка на множественность здесь применена, но при сотне наблюдений на гео тест всё равно почти ничего не увидит, кроме очень крупного эффекта. Про мелкие гео опыт честно не знает ничего.",
    "Единственная подгруппа с «правильным» знаком (id-ID, AUC 0,678) держится на 113 наблюдениях и не проходит поправку. Опровергнуть её этот опыт тоже не может — нужен отдельный прогон по Индонезии.",
    "Общая AUC 0.4289 — это смесь рынков и длин запроса. Внутри одного гео AUC 0.4712, внутри гео и длины — 0.4829 с интервалом 0.459–0.5083, накрывающим 0,5. Поэтому «прокси смотрит в обратную сторону» этот опыт НЕ показывает: он показывает, что прокси не показывает ничего.",
    "Стратификация по числу токенов — не безобидная поправка: число токенов входило в правило отбора на скан (selectionScore = специфичность × спрос), поэтому среди отсканированных длина и спрос связаны искусственно. Считать, какой из двух ответов ближе к правде, можно было бы только на случайной выборке ключей, а её в данных нет.",
    "Сверка σ с разбором остаётся приблизительной: разбор считал на 3403 кандидатах, у нас их 3637, и совпадение 0,1282 с σ топ-200 по баллу — это совпадение чисел, а не доказанное соответствие множеств."
   ],
   "adversarial": {
    "refuted": true,
    "confidence": "средняя",
    "fixed": true,
    "problems": [
     "Главное: направление «выше спрос — чаще занято» не выдерживает стратификации. Стратифицированный AUC внутри гео — 0,4712 [0,4483–0,4963], внутри гео и числа токенов — 0,4829 [0,459–0,5083] при перестановочном p=0,189, то есть интервал накрывает 0,5. Отъезд от монетки падает с 0,071 до 0,017. Заявление «прокси смотрит в обратную сторону» опыт не показывает.",
     "Причина смещения — состав выборки, и она видна в данных. Гео с высоким средним спросом имеют меньше пустых ниш (ru-RU: спрос 0,51 при 47% пустых; vi-VN: 0,72 при 15%), а отбор кандидатов на скан шёл по selectionScore = специфичность(число токенов) × спрос, из-за чего среди отсканированных спрос отрицательно связан с длиной запроса (Спирмен по ru-RU −0,315), а длина сильно связана с классом ниши. Общая AUC складывает эти три вещи в одну цифру. В опыте это упомянуто одной строкой caveats как «слабый остаточный отбор», хотя именно оно и производит заявленный знак.",
     "«Обратная сторона» даже не универсальна: 6 из 17 гео дают AUC выше 0,5 (id-ID 0,678, it-IT 0,578, pt-BR 0,554, ro-RO 0,566, nl-NL 0,517, pl-PL 0,507). Внутри ru-RU по стратам числа токенов AUC 0,50 / 0,44 / 0,51 / 0,48 — монетка.",
     "claimCheck.verdict делал сильное заявление «подписи в разборе съехали: 0,128 — это σ отобранного топ-200 по баллу» на основании совпадения 0,1282 с 0,1284 при допуске 0,005, тогда как бутстрап-интервал σ топ-200 равен 0,1176–0,1382, а разбор прямо пишет n=3403 — такого набора нет ни в одной версии public/live-full.json (в истории git 3637 / 2268 / 1314). То же с 0,0411, которое лишь на волосок попадает в интервал 0,0292–0,0414. Текст вердикта смягчён до «совпадение чисел, а не доказанное соответствие множеств».",
     "Мелочи, не влияющие на вывод: top200Demand сортируется из all вместе с классом ERROR, а top200Score — из отфильтрованных по конечному score, отборы не совсем сопоставимы; порог множественности пограничный (id-ID p=0,0026 против alphaCorrected 0,00238), а при 5000 перестановок минимально достижимый p равен 0,0002, поэтому все «0,0002» — это упор в пол, а не измеренная величина.",
     "Оговорка к моей же поправке: стратификация по числу токенов — не бесплатная. Токены входят в правило отбора на скан, поэтому связь длины и спроса среди отсканированных искусственна; условное распределение по токенам убирает наведённую связь, но при желании это можно назвать и переподгонкой. Стратификация только по гео знак сохраняет (0,4712, p=0,018). Рассудить окончательно можно было бы лишь на случайной выборке ключей, а её в данных нет — это записано в caveats."
    ],
    "note": "Арифметика опыта чистая: AUC 0,4289 на 3569 кандидатах, ДИ 0,4098–0,4489, все числа headline сходятся с JSON, auc() корректно обрабатывает связки через средние ранги, утечки нет (classifyGap не использует demand), выбор метки устойчив (ZERO против NO 0,4196; без PARTIAL 0,4272; PARTIAL к пустым 0,4484; ERROR обратно в занятые 0,4289). Первая половина вывода — «прокси не различает пустое и занятое» — держится при любой разумной перенастройке. Вторая половина — «смотрит в обратную сторону» — не держится: она наведена перекосом гео и правилом отбора на скан, и после стратификации по гео и длине запроса от неё остаётся 0,4829 с интервалом, накрывающим 0,5, и p=0,189. Поэтому вывод в заявленной формулировке опровергнут, а решение «не покупать» (supports_verdict=true) от этого только крепче: прокси не показывает ничего ни в ту, ни в другую сторону. Файл опыта поправлен: добавлен раздел numbers.stratified со стратифицированным AUC, бутстрап-интервалом и перестановкой меток внутри страты, профиль гео, корреляции спроса с числом токенов, переписаны headline, answer.plain, method и caveats, смягчён claimCheck.verdict. Скрипт перезапущен, /workspaces/MediaMagic/MediaMagicASO/trees/3a8fe070f9/scraper/out/proof/p2.json перезаписан, менялся только p2-proxy-discrimination.js, ничего не коммитил.",
    "источник": "состязательная проверка вторым агентом, 19.08.2026"
   }
  },
  {
   "id": "p3",
   "title": "Что именно продаётся за 59–229 долларов в месяц",
   "отработал": true,
   "ran_at": "2026-08-19T06:55:12.116Z",
   "question": "Если собрать вендорскую «частотность Google Play» ровно по их же опубликованному рецепту, но из бесплатных входов, — получим ли мы другой порядок кандидатов, чем даёт наш собственный спрос?",
   "headline": "Вендорская модель совпадает с нашим спросом по Спирмену на 0.7574–0.8225 на полном наборе (на витрине падает до 0.566), а «78–93% топ-100 витрины на месте» ничего не значит: перемешанная своя же цифра оставляет 82%, чистый шум — 75%, а выключенный спрос — 94%",
   "method": "Вендорскую цифру собрали ровно по опубликованному рецепту: V = anchor^a × (5 + 95·S)^(1−a) на шкале AppTweak 5–100 с полом на 5. S — композит автоподсказок из позиции в подсказках (AppFollow: «на подсказках стора и позиции в них»), широты появления (число независимых путей) и общего числа путей. anchor — апловский якорь (AppTweak: «сверка с данными популярности поиска Apple»): есть точное соответствие в App Store — якорь растёт по логарифму числа отзывов, нет — падает на пол 5, как настоящий индекс Search Ads падает на минимум для хвоста. Умножение, а не сложение, взято у Asodesk («число App Store × население × доля Android»); показатель a задаёт, насколько вендор опирается на Apple, и прогнан в трёх вариантах: 0 (AppFollow), 0,5 (AppTweak), 0,75 (Asodesk). Порядок сравнивали Спирменом и Кендаллом с нашим demand и с голой позицией в подсказках, а верхушки — overlapAtK при k=50/100/200 с детерминированным разрывом связок по id. Дальше подставили вендорскую цифру (делённую на 100, чтобы попасть в нашу шкалу) вместо слагаемого спроса в logScore, заново свернули дубли интента как в score.js и замерили пересечение топ-100 и сдвиг рангов; отдельно проверили арифметику пустого ответа через Math.max(1e-6, demand). К подстановке добавили контроль, без которого её число не читается: те же 100 мест сравнили с подстановкой равномерного шума, константы (спрос выключен), нашего спроса вверх ногами и 30 перемешиваний самой вендорской цифры с фиксированными сидами; и отдельно посчитали крайний вариант модели без подсказок вовсе, чтобы увидеть, сколько в совпадении порядков от рецепта, а сколько от нашего же входа.",
   "key_numbers": [
    {
     "label": "Спирмен вендорской модели с нашим спросом на всём наборе, вариант «только подсказки»",
     "value": 0.8225,
     "note": "у варианта «Apple решает» 0.7574 — то есть на полном наборе рецепт вендора и наш спрос дают почти один порядок",
     "из": "numbers.порядок.наВсех.A.спирменСНашимСпросом"
    },
    {
     "label": "тот же Спирмен на витрине, вариант «Apple решает»",
     "value": 0.5662,
     "note": "на витрине порог 0,7 держит только вариант A (0.80); у B 0.59, у C 0.57",
     "из": "numbers.порядок.наВитрине.C.спирменСНашимСпросом"
    },
    {
     "label": "вариантов из трёх, где «нам перепродают наш сигнал» подтверждается на витрине",
     "value": 1,
     "note": "на полном наборе таких три из трёх — но там апловский якорь уперт в пол у 95% ключей",
     "из": "numbers.проверкаПорога.вариантовВышеПорогаНаВитрине"
    },
    {
     "label": "доля кандидатов, у которых апловский якорь на полу шкалы",
     "value": 0.9513,
     "note": "кросс-чек App Store проведён у 952 из 3637, точное соответствие нашлось у 230",
     "из": "numbers.апловскийЯкорь.наПолуДоля"
    },
    {
     "label": "Спирмен модели с нашим спросом, если убрать подсказки из рецепта",
     "value": 0.0693,
     "note": "совпадение исчезает — значит меряется наш же вход, а не независимая вендорская цифра",
     "из": "numbers.проверкаНаТавтологию.безПодсказокНаВсех.спирменСНашимСпросом"
    },
    {
     "label": "доля топ-100 витрины на месте, если спрос вообще выключить",
     "value": 0.94,
     "note": "чистый шум оставляет 0.75, реальная подстановка 0.78–0.93 — аргумент «витрина почти не изменилась» не значит ничего",
     "из": "numbers.контрольПодстановки.топ100ПриВыключенномСпросе"
    },
    {
     "label": "доля перемешиваний, которые не хуже реальной подстановки варианта C",
     "value": 0.9333,
     "note": "свой контроль уверенно бьёт только вариант A",
     "из": "numbers.контрольПодстановки.поВариантам.C.долиПеремешиванийНеХуже"
    },
    {
     "label": "сколько баллов отнимает один пустой ответ вендора",
     "value": -4.8354,
     "note": "разбор говорил −4,84 при полном размахе витрины 5,071 — арифметика подтвердилась, лидер витрины падает на 676-е место из 678",
     "из": "numbers.пустойОтвет.слагаемоеСпросаНаПолу"
    }
   ],
   "supports_verdict": false,
   "caveats": [
    "Это не замер вендорской цифры. Ни ASOMobile, ни AppTweak, ни Asodesk не были опрошены ни одной нашей фразой — их данные закрыты авторизацией. Мы восстановили модель по их же опубликованным словам о методике, а не получили их числа.",
    "Веса внутри рецепта вендоры не публикуют. Три варианта покрывают диапазон «Apple не участвует» — «Apple решает», но конкретные 0,7/0,2/0,1 и прочие взяты нами, а не у вендора.",
    "Апловский якорь — замена, а не оригинал. Настоящий индекс популярности Search Ads мы не видим; вместо него берём наличие точного соответствия в App Store и число отзывов, и только у 952 из 3637 кандидатов кросс-чек вообще проводился — у остальных якорь принудительно на полу.",
    "Опыт не доказывает, что настоящая купленная цифра совпала бы с нашей моделью. Если у вендора внутри есть источник, о котором он не написал (клики по подсказкам, панели, данные рекламы), порядок может оказаться другим — именно это и должен показать бесплатный триал.",
    "Подстановка в скоринг сделана на текущих весах конфига (вес спроса 0,35). При другом весе размер сдвига будет другим, хотя направление — нет.",
    "Части кандидатов (1314 из 3637) demandInfo достался от старой формулы v2 без префиксного признака, поэтому широта появления для них считалась по числу сидов, а не по невложенным корням дерева.",
    "Порог «выше 0,7 — перепродают наш сигнал» выполняется у всех трёх вариантов на полном наборе, но на витрине его проходит только вариант A (у B 0,674, у C 0,627). Там, где кросс-чек App Store реально проведён, апловский множитель добавляет немного своего — то есть купленная цифра не полностью сводится к нашей подсказке.",
    "Голое пересечение топ-50/100 между нашим спросом и вендорской цифрой низкое (6–18% на полном наборе), но читать его как «совсем другой порядок» нельзя: обе шкалы дискретны, на границе топ-200 у нашего спроса 158 ключей с одинаковым значением, и верхушку определяет правило разрыва связок.",
    "Мы не проверяли, как купленная цифра повлияла бы на ОТБОР кандидатов до сканирования — только на пере-ранжирование уже отсканированных 3637.",
    "Пересечение топ-100 после подстановки само по себе не доказывает ничего. Слагаемое спроса разбрасывает баллы куда слабее остального logScore, поэтому витрину не ломает почти никакая подстановка: чистый шум оставляет на месте 75% топ-100, перемешанная вендорская цифра — 82–85%, а вовсе выключенный спрос — 94%, то есть больше любого из вариантов. Свой контроль уверенно бьёт только вариант A; у B реальная подстановка неотличима от перемешанной, у C — хуже перемешанной.",
    "Корреляция вендорской цифры с нашей позицией в подсказках заложена в неё арифметикой: позиция входит в модель с весом 0,4–0,7. Проверка порога 0,7 тут не измерение, а пересчёт того, что мы сами собрали. Косвенное подтверждение: если собрать модель на одном апловском якоре, без подсказок вовсе, спирмен с нашим спросом падает до 0.0693.",
    "На витрине — том самом множестве, ради которого всё и делается, — спирмен вендорской цифры с нашим спросом держится выше 0,7 только у варианта A (0,80); у B он 0,59, у C 0,57. Совпадение порядков заметно лишь там, где апловский якорь уперт в пол у 95% ключей."
   ],
   "adversarial": {
    "refuted": true,
    "confidence": "высокая",
    "fixed": true,
    "problems": [
     "Третья опора вывода («подстановка вендорской цифры оставляет на месте 78–93% топ-100 витрины») не измеряет ничего: у опыта не было контроля. Перезапустил подстановку с заведомо пустыми признаками на тех же 818 eligible-строках — чистый шум U(0,05..1) оставляет 75% топ-100, наш собственный спрос ВВЕРХ НОГАМИ — 81%, а вовсе выключенный спрос (константа) — 94%, то есть больше любого из трёх вендорских вариантов. Число 78–93% говорит о том, что слагаемое спроса почти не влияет на витрину, а не о том, что вендорский порядок совпал с нашим.",
     "Нулевое распределение по 30 перемешиваниям самой вендорской цифры (те же значения, связь с ключом разрушена, сиды фиксированы): A реально 0,93 против медианы 0,84 — бьёт контроль (0 из 30 перемешиваний не хуже); B реально 0,86 против медианы 0,85 — неотличим от случайного (14 из 30 не хуже); C реально 0,78 против медианы 0,82 — ХУЖЕ случайного (28 из 30 не хуже). То есть у двух вариантов из трёх подстановка «вендорской» цифры меняет витрину так же или сильнее, чем случайная перестановка тех же чисел.",
     "Критерий вывода в коде был вакуумным: out.supports_verdict = ... && minOverlap100 >= 0.7. Порог 0,7 по пересечению топ-100 проходит даже чистый шум (0,75) и перевёрнутый спрос (0,81), так что это условие не могло дать false ни при каком результате.",
     "Корреляция «с голой позицией в подсказках 0,822–0,948» — тавтология, а не измерение: positionTerm входит в саму модель с весом 0,4–0,7 и функционально совпадает с positionComponent из computeDemandV3 (1/(1+bestPosition)). Крайний вариант модели без подсказок (a=1, только апловский якорь) даёт спирмен с нашим спросом 0,069 и с позицией 0,037. Порог разбора «выше 0,7 — перепродают наш сигнал» здесь проверяется на числе, которое мы сами и собрали из этого сигнала.",
     "Сравнение на разных подмножествах. Заголовок и supports_verdict брали спирмен только с полного набора (0,757–0,823), а на витрине — том единственном множестве, ради которого всё делается, — он падает до 0,595 (B) и 0,566 (C), ниже порога 0,7. В оговорках было честно указано лишь про падение спирмена с ПОЗИЦИЕЙ (0,674 и 0,627), про падение корреляции со спросом — нет.",
     "Причина живучести витрины посчитана: sd слагаемого спроса 0,070, sd вендорского слагаемого 0,111–0,165, а sd остальной части logScore — 0,901. Спрос даёт меньше десятой доли разброса балла, поэтому топ витрины устойчив к любой подстановке.",
     "Не ошибка, но ослабляет заявленный разброс настроек: у 95,1% кандидатов апловский якорь уперт в пол 5, поэтому на полном наборе варианты B и C фактически схлопываются в монотонную функцию от того же S, что и A (у B и C одинаковые 209 различных значений). «Три независимых набора весов» на полном наборе почти не независимы.",
     "Проверил все числа из заявленного вывода по файлу — выдумок нет: 0,7574–0,8225 (спирмен со спросом), 0,8217–0,9484 (с позицией), 78–93% (топ-100) совпадают с JSON. Прозаические числа в комментариях тоже сошлись с данными: 507 из 678 строк витрины с кросс-чеком, 952 из 3637 проверенных, 1314 строк со старой формулой v2, 158 связок на границе топ-200. Арифметика пустого ответа (−4,8354 и размах 5,071) верна."
    ],
    "note": "Вывод опыта в заявленном виде не держится, и после починки сам скрипт это теперь показывает: supports_verdict перевернулся с true на false. Арифметика опыта корректна, но одна из трёх опор оказалась пустой. Починил прямо в /workspaces/MediaMagic/MediaMagicASO/trees/3a8fe070f9/scraper/proof/p3-vendor-model.js: добавил блок numbers.контрольПодстановки (шум, константа, перевёрнутый спрос, 30 сидированных перемешиваний вендорской цифры, сравнение sd слагаемых), блок numbers.проверкаНаТавтологию (модель без подсказок, a=1), блок numbers.выводПоЧастям, заменил вакуумное условие minOverlap100>=0.7 на «подстановка бьёт собственный перемешанный контроль у всех трёх вариантов» и добавил требование, чтобы спирмен со спросом держался выше 0,7 не только на полном наборе, но и на витрине; переписал headline и добавил три оговорки. Скрипт перезапущен, /workspaces/MediaMagic/MediaMagicASO/trees/3a8fe070f9/scraper/out/proof/p3.json перезаписан. Что осталось живым: вариант A (буквально AppFollow, только подсказки) действительно воспроизводит наш порядок и бьёт контроль — спирмен со спросом 0,822 на всех и 0,800 на витрине, подстановка держит 93% топ-100 против 84% у перемешивания. То есть качественная мысль разбора «за деньги продают порядок наших же подсказок» не опровергнута, но доказана она теперь только для чисто саджестного рецепта, а не для всех трёх, и не через пересечение топ-100. Правил только свой файл, ничего не коммитил.",
    "источник": "состязательная проверка вторым агентом, 19.08.2026"
   }
  },
  {
   "id": "p4",
   "title": "Внешний якорь: просмотры Википедии как настоящий замер внимания к теме",
   "отработал": true,
   "ran_at": "2026-08-19T07:12:04.340Z",
   "question": "Есть ли бесплатный источник, где числа реально замерены, а не смоделированы, и связаны ли с ним наши сигналы спроса?",
   "headline": "настоящие счётчики просмотров получены по 157 темам из 180 за 337 анонимных запроса и 0 долларов (медиана 8608 просмотров за 12 месяцев), но статья про сам запрос нашлась лишь у 15% выборки, и связи нашего спроса с этим замером нет: Спирмен -0.0528 на всех 157 строках и -0.1596 на 27 строках с совпадением по теме",
   "method": "Из полного датасета живого прогона взята выборка по 45 кандидатов на каждый класс гэпа; внутри класса кандидаты добираются круговым обходом гео, чтобы русские строки (половина датасета) не задавили остальные языки, а повторы одного запроса на одном языке схлопнуты в одно наблюдение. По каждому запросу через поиск Википедии на языке кандидата берётся лучшая статья, её заголовок сверяется с запросом тем же морфологическим матчером, которым в скане меряется совпадение заголовка приложения. Просмотры берутся одним запросом за 12 полных месяцев (текущий месяц исключён, он неполный) через REST-эндпоинт per-article и суммируются. Корреляции считаются рангами (Спирмен и Кендалл) в трёх режимах — строгое совпадение заголовка, частичное и вообще без фильтра, — потому что наши ключи это фразы из трёх-пяти слов, а заголовок энциклопедии почти никогда не повторяет фразу целиком. Те же связи пересчитаны с поправкой на язык: ранги внутри языкового раздела нормируются на размер группы и складываются в общий пул, иначе корреляция ловила бы просто разницу в размере языковых Википедий. Доверительные интервалы — бутстрап по парам с фиксированным seed, сравнение классов гэпа — перестановочный тест.",
   "key_numbers": [
    {
     "label": "тем из 180 получили настоящие счётчики просмотров",
     "value": 157,
     "note": "бесплатно, без ключа, анонимно",
     "из": "numbers.покрытиеВикипедией.статьяНайдена"
    },
    {
     "label": "доля выборки, где статья действительно про сам запрос",
     "value": 0.15,
     "note": "у остальных поиск отдал лучшую по релевантности статью, а не ту, что нужна",
     "из": "numbers.покрытиеВикипедией.доляЧастичногоСовпадения"
    },
    {
     "label": "медиана просмотров за 12 месяцев",
     "value": 8608,
     "note": "от 17 до 1 399 879, сумма по выборке 8 395 702",
     "из": "numbers.просмотры12м.всеНайденные.median"
    },
    {
     "label": "Спирмен нашего спроса с просмотрами, все 157 строк",
     "value": -0.0528,
     "note": "интервал −0.206…0.1148 — ноль",
     "из": "numbers.корреляции.всеНайденныеСтатьи.спросИПросмотры.spearman"
    },
    {
     "label": "тот же Спирмен на 27 строках, где статья про запрос",
     "value": -0.1596,
     "note": "интервал −0.501…0.2349 — тоже ноль, только шумнее",
     "из": "numbers.корреляции.частичноеСовпадение.спросИПросмотры.spearman"
    },
    {
     "label": "Спирмен нашего итогового балла с просмотрами",
     "value": 0.4135,
     "note": "интервал 0.0479–0.7212, n=27 — единственная связь, которая не накрывает ноль, но выборка крошечная",
     "из": "numbers.корреляции.частичноеСовпадение.нашScoreИПросмотры.spearman"
    },
    {
     "label": "тот же Спирмен, если опустить порог совпадения до 0.3",
     "value": -0.3215,
     "note": "одно число решает и долю совпадений (38% вместо 15%), и знак связи — метод не доведён",
     "из": "numbers.чувствительностьКПорогу.2.спросИПросмотры"
    },
    {
     "label": "запросов к Википедии на весь замер",
     "value": 337,
     "note": "ноль долларов, ключ не нужен",
     "из": "numbers.ценаЗамера.запросовЕслиСНуля"
    }
   ],
   "supports_verdict": null,
   "caveats": [
    "Просмотры Википедии — это внимание к ТЕМЕ, а не число поисков в Google Play. Ни один коэффициент отсюда нельзя пересчитать в установки или в запросы стора.",
    "Совпадение заголовка статьи с запросом мерится лексически. Тема может совпадать по смыслу при слабом совпадении слов и наоборот — часть строк отсеяна или зачтена ошибочно.",
    "Поиск Википедии всегда отдаёт лучшую по релевантности статью, а не «статью про этот запрос». Для широких слов это может быть статья про совсем другой предмет — примеры такого промаха сохранены в примерыСлабогоСовпадения.",
    "Выборка в 180 запросов из 3637 стратифицирована по классу гэпа и по гео, но не по тематике: перекос по темам внутри классов не контролировался.",
    "Отсутствие статьи не доказывает отсутствия спроса — Википедия покрывает энциклопедические темы, а не «приложение для X».",
    "Опыт не сравнивает нас с вендором напрямую: у вендоров такого показателя в продукте нет вовсе, поэтому сопоставлять не с чем. Он не доказывает и того, что вендорская частотность плоха — только то, что независимый бесплатный замер существует.",
    "Корреляция считается по одной точке на запрос за 12 месяцев; сезонность и тренд внутри года не разбирались, хотя помесячные ряды получены.",
    "Просмотры суммированы за окно в 12 месяцев, но у части статей ряд короче: статью могли создать недавно. Такие строки суммой недооценены, отдельной нормировки на длину ряда в корреляциях нет — счётчик коротких рядов и распределение просмотров в месяц лежат в numbers.",
    "Корреляция около нуля здесь НЕ означает, что наш спрос плох. Она означает, что энциклопедический интерес к теме и намерение искать приложение в сторе — разные величины. Из этого опыта нельзя сделать вывод ни в пользу нашего прокси, ни против него.",
    "Исход опыта чувствителен к порогу совпадения заголовка, и это видно в numbers.чувствительностьКПорогу. При объявленном пороге 0.5 совпало 15% выборки и связь спроса с просмотрами нулевая. Опустить порог до 0.3, то есть «статья хотя бы про треть слов запроса», — совпадает уже 38% выборки, формальное условие «якорь зацепился» (треть) выполняется, а Спирмен спроса с просмотрами становится −0.32. Одно число решает и долю совпадений, и знак связи, поэтому ни «якорь не зацепился», ни «связи нет» нельзя считать твёрдыми: они верны для порога 0.5 и только для него.",
    "Корреляция на всех 157 строках почти наверняка меряет шум: у 130 из них заголовок статьи не про запрос (медиана совпадения 0.25, есть строки вроде «wecker kostenlos ohne werbung» → статья про Райнхарда Мая). Ноль на таком наборе означает «наш спрос не связан со случайной статьёй», а это не тот вопрос, который задавался.",
    "Слабая привязка статей к запросам — это в том числе свойство поиска Википедии по длинным фразам-намерениям вроде «будильник бесплатно без рекламы». Другой способ подбора статьи (по словарю тем, по Wikidata, по ручной разметке) дал бы другую долю совпадений; здесь проверен только полнотекстовый поиск с выбором лучшего из трёх."
   ],
   "adversarial": {
    "refuted": false,
    "confidence": "высокая",
    "fixed": true,
    "problems": [
     "ПОЧИНЕНО. В поКлассамГэпа поле «сПросмотрами» считало не то, что называется: там лежал счётчик совпавших по теме строк (5/10/3/9), а не строк со счётчиком просмотров (39/39/39/40). Рядом со «статьяНайдена: 39» это читалось как «просмотры удалось получить только у пяти из тридцати девяти», хотя на верхнем уровне честно стоит «статьяЕстьНоСчётчикаНет: 0». Там же «медианаПросмотров12м» считалась по трём-десяти совпавшим строкам, а не по всем со счётчиком, и от этого переворачивается порядок классов: PARTIAL по совпавшим 5730, по всем со счётчиком 21918 — то есть из самого низкого становится самым высоким. Теперь оба среза лежат отдельными полями с честными именами.",
     "ПОЧИНЕНО. Таблица поЯзыкам строилась только по 27 совпавшим строкам и нигде об этом не говорила. Голландский выглядел как «n=1, медиана 7708», чешский как «n=1», хотя счётчики получены по 11 и 10 темам соответственно; два языка из пятнадцати вообще пропадали из таблицы. Пересчитана по всем 157 строкам со счётчиком, доля совпавших по теме вынесена отдельным полем.",
     "ЧАСТИЧНО ПОЧИНЕНО (добавлен блок чувствительностьКПорогу и оговорка, сам вывод не менял). Оба утверждения хедлайна держатся ровно на одном произвольном числе — пороге совпадения заголовка 0.5. Опустить его до 0.3 («статья хотя бы про треть слов запроса») — и совпадает уже 38% выборки вместо 15%, то есть заранее объявленное условие «якорь зацепился, если совпало не меньше трети» выполняется и supports_verdict по собственному правилу скрипта перевернулся бы с null на true. На том же пороге Спирмен спроса с просмотрами не нулевой, а -0.3215 (при 0.2 — -0.2801). Проверено перезапуском на реальных titleL, не рассуждением.",
     "Хедлайн выборочен. На том же подмножестве из 27 совпавших строк, где спрос даёт -0.16, наш итоговый score даёт +0.4135 с интервалом [0.048, 0.721], и я проверил пятью разными seed — нижняя граница везде выше нуля (от 0.003 до 0.048). То есть на строках, где статья действительно про запрос, связь с нашим score есть, а хедлайн говорит только про demand и объявляет «связи нет». Формально он прав (речь про спрос), но по факту это отбор удобного из девяти посчитанных коэффициентов.",
     "ДОБАВЛЕНА ОГОВОРКА. Главное число -0.0528 посчитано на наборе, где у 130 строк из 157 заголовок статьи не про запрос (медиана совпадения 0.25, десятки строк с совпадением 0 — «будильник без рекламы» → статья про Райнхарда Мая). Ноль на таком наборе означает «наш спрос не связан со случайной статьёй», а это не тот вопрос, который задавался. Опыт это признаёт в оговорках, но число всё равно вынесено в хедлайн как основное.",
     "НЕ ПОЧИНЕНО (починка требует свежей выборки и ~337 живых запросов, а на вывод не влияет). Круговой обход гео никогда не сдвигает точку старта: 45 строк на класс при 17 гео дают три захода, и в третьем достаются только первые 11 гео по алфавиту. В итоге cs-CZ, de-DE, en-* получили по 12 строк, а tr-TR, uk-UA, vi-VN — по 8. Перекос систематический, а не случайный, и метод обещает «круговой обход», умалчивая об этом. На вывод не влияет: джекнайф по языкам держит Спирмен в коридоре от -0.083 до +0.032.",
     "Этот прогон не сделал ни одного живого запроса — все 337 пришли из кэша, а «потраченоДолларов: 0» вообще не измеряется, это константа, зашитая в AsoClient.cost(). Так что сам по себе прогон не доказывает, что эндпоинты сегодня отвечают анонимно. Я проверил это отдельно тремя живыми запросами без ключа: отвечают, и цифры сходятся с кэшем ровно."
    ],
    "note": "Вывод устоял. Каждое число из p4.json я пересчитал заново из /workspaces/MediaMagic/MediaMagicASO/trees/3a8fe070f9/scraper/out/proof/p4-rows.json — 157/180, 27 совпадений, 15%, медиана 8608, Спирмен -0.0528 и -0.1596, бутстрап-интервал [-0.206, 0.1148], перестановочный p=0.5911 — всё совпало до знака. Сами данные не подделаны: я сходил живьём в Wikimedia без ключа и получил ровно те же суммы (Ohm's law 367477, ADHD 1399879), и немецкий поиск действительно отдаёт «Reinhard Mey» на «wecker kostenlos deutsch ohne werbung». Выборка чистая: 68 отброшенных кандидатов — это ровно класс ERROR, где нет score, утечки признака нет, деления на ноль нет, знаки на месте. Ключевое число -0.0528 держится при всех разумных перенастройках, которые я проверил перезапуском: просмотры в месяц вместо суммы за год -0.046, только полные 12-месячные ряды -0.0055, только строки где поиск сам поставил статью первой -0.0596, джекнайф по всем 15 языкам даёт от -0.083 до +0.032, пять разных seed бутстрапа дают интервалы, которые все накрывают ноль. Но я нашёл две настоящие ошибки разметки в JSON и починил их в /workspaces/MediaMagic/MediaMagicASO/trees/3a8fe070f9/scraper/proof/p4-external-anchor.js, скрипт перезапущен (0 живых запросов, 337 из кэша).",
    "источник": "состязательная проверка вторым агентом, 19.08.2026"
   }
  },
  {
   "id": "p5",
   "title": "Ось, которую предлагают купить, — не та, что решает",
   "отработал": true,
   "ran_at": "2026-08-19T06:49:33.786Z",
   "question": "Что лучше ранжирует «ниша пуста и её держит побиваемый» — спрос (то, что продают под словом «частотность») или замер выдачи, и сколько в самом лучшем случае добавила бы идеальная частотка?",
   "headline": "Спрос как ранжировщик даёт AUC 0.4205 на исходе «ниша пуста и побиваема» (случайный порядок — 0.5002), замер выдачи — 0.8888; идеальная по конструкции частотка с подобранным весом добавляет к модели +0.0011 AUC.",
   "method": "Исход задан так, что узнать его можно только после нашего бесплатного скана выдачи: «пусто и побиваемо» = класс гэпа ZERO или WEAK И побиваемость инкумбента выше медианы по всему набору (0.4045). Четыре ранжировщика сравниваются на одном множестве: (а) только спрос demandV3, (б) равновзвешенная смесь трёх замеров выдачи — побиваемость, «лидер мелкий» по логарифму установок и «лексически свободно» = 1 минус максимальный матч в топ-3, (в) текущий logScore целиком, (г) 200 случайных порядков как пол. Считаем AUC (эквивалент U-статистики) и точность на верхушках 50/100/200; связки в спросе ломаются одной детерминированной перетасовкой, иначе они бесплатно унаследовали бы порядок готовой модели, в котором файл и лежит. Потолок частотности: подмешиваем к logScore ранг по логарифму установок лидера — замеренный размер аудитории темы, сигнал спроса заведомо сильнее любой вендорской оценки — и перебираем вес от -1.5 до +1.5, беря лучший AUC (подгонка на тех же данных, то есть верхняя граница с запасом в пользу вендора). Отдельно проверяем, различает ли спрос сам класс гэпа, и считаем цену обоих путей в запросах.",
   "key_numbers": [
    {
     "label": "AUC спроса на исходе «ниша пуста и её держит побиваемый»",
     "value": 0.4205,
     "note": "интервал 0.3999–0.4428, случайный порядок даёт 0.5002",
     "из": "numbers.ранжировщики.спрос.auc"
    },
    {
     "label": "AUC бесплатного замера выдачи на том же исходе",
     "value": 0.8888,
     "note": "побиваемость, размер лидера и лексическая свобода — всё из нашего же скана",
     "из": "numbers.ранжировщики.замер_выдачи.auc"
    },
    {
     "label": "AUC текущей модели целиком",
     "value": 0.9707,
     "note": "точность на топ-100 равна 1.0",
     "из": "numbers.ранжировщики.полная_модель.auc"
    },
    {
     "label": "сколько добавляет к модели идеальная частотка с подобранным весом",
     "value": 0.0011,
     "note": "вес подобран на тех же данных — это верхняя граница с запасом в пользу покупки",
     "из": "numbers.потолок_частотности.прибавка_auc_потолок"
    },
    {
     "label": "потолок AUC для любой монотонной частотки на вопросе «пусто ли»",
     "value": 0.5711,
     "note": "выше этого не прыгнет ни одна вендорская шкала, как её ни точни",
     "из": "numbers.про_пустоту.потолок_для_любой_монотонной_частотки"
    },
    {
     "label": "запросов стоил весь наш путь на 3637 ключей",
     "value": 115069,
     "note": "из них 98 054 подсказки; денег потрачено 0",
     "из": "numbers.цена.наш_путь.запросов_всего"
    },
    {
     "label": "кредитов AppTweak на один прогон по 3637 ключам",
     "value": 36370,
     "note": "по их же опубликованному правилу 10 кредитов за ключ; в разборе стояло 36 734 — расхождение в 364 кредита за сами запросы",
     "из": "numbers.цена.apptweak.кредитов_на_3637_ключей"
    },
    {
     "label": "кредитов, если считать частотку до сканирования, а не после",
     "value": 1260860,
     "note": "6,3 месячных лимита тарифа Lite — купленная цифра может быть только пере-ранжировщиком, не фильтром отбора",
     "из": "numbers.цена.apptweak.кредитов_на_всю_воронку_отбора"
    }
   ],
   "supports_verdict": true,
   "caveats": [
    "Исход по построению вычисляется из того же замера выдачи, на котором строятся ранжировщики (б) и (в) — их высокий AUC отчасти тавтология. Смысл опыта не в том, что замер побеждает, а в том, что спрос не отличает исход вовсе: у него доступа к этим данным нет ни в каком виде.",
    "Спрос здесь — наш demandV3, а не число вендора. Вендорское число не замерялось ни разу: ни один платный API не был опрошен нашей фразой. Мы допускаем, что вендорская частотка не хуже нашей (опыт 3), но это допущение, а не измерение.",
    "Потолок «идеальной частотки» — установки лидера выдачи. Это тоже величина из нашего бесплатного скана, а не то, что продаёт вендор; вес к ней подобран на тех же данных, без отложенной выборки. Значит это верхняя граница с запасом в пользу покупки, и реальный вендорский сигнал до неё не дотянется.",
    "Опыт не доказывает, что частотность бесполезна вообще. Он показывает только, что она не отвечает на вопрос «пуста ли ниша и побиваем ли тот, кто её держит». Для отсева совсем мёртвых запросов (нулевой спрос) она может быть полезна — этого мы здесь не проверяли, потому что нулевого спроса в наборе нет по построению: все ключи пришли из живых подсказок стора.",
    "Общий рейтинг смешивает гео, у которых спрос считался по-разному (дерево префиксов у ru-RU и en-US, сиды у остальных), и часть эффекта даёт именно это: внутри ru-RU AUC спроса 0.4642, внутри en-US 0.4424 — ближе к 0.5, чем общий 0.4205, но всё равно ниже пола.",
    "Все 3637 кандидатов уже прошли отбор до скана (specificityFactor и порог по спросу), поэтому набор не случайная выборка из стора, а верх нашей воронки. На неотобранном множестве числа были бы другими.",
    "Цена вендорского пути посчитана по опубликованным правилам из разбора (10 кредитов за ключ, батч 10, €166 за 200 000 кредитов), а не по счёту от вендора. Цена ASOMobile в токенах не опубликована — посчитать её нельзя, поэтому в JSON стоит null, а не число.",
    "Класс гэпа и побиваемость — оценки нашего же кода на замерах от 15-16.08.2026. Если выдача с тех пор поменялась, поменяется и исход; опыт не про устойчивость во времени."
   ],
   "adversarial": {
    "refuted": false,
    "confidence": "высокая",
    "fixed": false,
    "problems": [
     "Общий AUC спроса 0.4205 сильно преувеличен смешиванием гео: спрос считается внутри гео и по-разному, и если считать AUC внутри страт и складывать с весом по числу пар, получается 0.4631 (по гео) и 0.4574 (по гео и длине фразы). В отчёте показаны только ru-RU (0.4642) и en-US (0.4424), потому что фильтр list.length < 200 выбрасывает 15 гео из 17, и сводного стратифицированного числа нет вовсе. Вывод «спрос у пола» держится, но в заголовок вынесена самая крайняя версия числа.",
     "«Потолок частотности +0.0011» измерен как прибавка к модели, которая уже даёт 0.9707. Я подставил вместо частотки сам исход (идеальный оракул) — он поднимает AUC до 1.0, то есть максимум, который может добавить ЛЮБОЙ сигнал, это 0.0293. Значит критерий «меньше 0.02» покрывает 68% всего доступного диапазона, и в JSON эта верхняя планка не названа. На исходе ZERO+WEAK+PARTIAL тот же подобранный вес даёт уже +0.0315, и supports_verdict стал бы false.",
     "Спрос не «на уровне жребия»: перестановка меток (2000 раскладов) даёт p около 0.0005, а перевёрнутый спрос ранжирует исход на AUC 0.5795. То есть частотность несёт пригодный сигнал — просто со знаком минус. В самом JSON это сказано честно («слегка вредит»), но формулировка заголовка «на уровне жребия и даже чуть хуже» это смазывает.",
     "Сравнение спроса (0.4205) и замера выдачи (0.8888) почти тавтологично: исход — это функция от gapClass и побиваемости, gapClass в classifyGap определяется порогом по maxL3 и установкам, а serp собран ровно из побиваемости, установок и 1 минус maxL3. Caveat это признаёт («отчасти тавтология»), но слово «отчасти» мягче, чем есть на деле — второй ранжировщик видит буквально те же три величины, из которых сделана метка.",
     "Мелочь в цене: 364 запроса к AppTweak получаются, только если батч из 10 ключей может смешивать страны. Страна у них параметр запроса, так что по нашим 17 гео честно выходит 370 запросов. На кредиты (36 370) и на вывод это не влияет.",
     "Мелочь в статистике: разница_средних_спроса_zero_против_no = 0.0379 — это модуль, permutationTest возвращает abs. Реальный знак отрицательный (ZERO 0.5379 против NO 0.5758), то есть у пустых ниш спрос НИЖЕ. Знак восстанавливается по таблице классов рядом, но в поле «наблюдаемая_разница» его нет."
    ],
    "note": "Вывод устоял. Скрипт перезапускается и даёт байт в байт тот же JSON (кроме ran_at); все четыре числа из заявления (0.4205, 0.5002, 0.8888, +0.0011) реально лежат в файле и пересчитываются кодом. Вычислительной ошибки нет: logScore действительно сумма weight*ln(part) с весом спроса 0.35 (проверил по scoreParts), поэтому замена спроса на частотку корректна; auc в stats.js — Манн-Уитни со средними рангами, связки спроса (140 уникальных значений) обрабатываются правильно; перезапуск с четырьмя разными seed перетасовки не меняет точность@50 (спрос 0.22, замер 0.92, модель 1.0); шесть альтернативных определений исхода (порог побиваемости p25/p75, только ZERO, +PARTIAL, просто пустота) дают AUC спроса 0.41-0.43 — ни при одной настройке спрос не поднимается к 0.5 сверху. Главное сомнение: общий AUC 0.4205 наполовину эффект смешивания гео — стратифицированный по всем 17 гео он 0.4631, по гео и длине фразы 0.4574, а в отчёте показаны только ru-RU и en-US (порог в 200 кандидатов отсекает 15 гео) и нет сводного числа. Второе сомнение: «потолок +0.0011» — это прибавка к модели, которая уже на 0.9707, где даже идеальный оракул добавляет всего 0.0293 (замерил), так что планка «меньше 0.02» покрывает почти весь доступный диапазон, и на исходе ZERO+WEAK+PARTIAL тот же потолок уже +0.0315, то есть supports_verdict перевернулся бы. Ни то, ни другое не отменяет решающего числа: на любом разумном определении исхода спрос не даёт модели ничего, а вендорские кредиты тратятся вдобавок к скану.",
    "источник": "состязательная проверка вторым агентом, 19.08.2026"
   }
  }
 ],
 "vendor_facts": [
  {
   "claim": "ASOMobile Free: $0, 20 ключей, без привязки карты, 0 API-кредитов",
   "status": "подтверждён",
   "evidence": "В HTML страницы тарифов блок FREE: «Free plan | No card needed | 20 keywords / 2 apps / 1 teammate / 10 competitors / 100 responses to reviews / 0 AI limits / 0 API credits». Все три части утверждения дословно с сайта.",
   "url": "https://asomobile.net/en/pricing/",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "Цены ASOMobile: $59 / $119 / $229 / $299 в месяц",
   "status": "подтверждён",
   "evidence": "Помесячно: ASO Indie $59 (500 ключей, 1000 API-кредитов), ASO Pro $119 (1500, 5000), ASO Max $229 (4000, 50 000), Maximum $299 (6000, 100 000). При годовой оплате те же планы: $47 / $95 / $183 / $239 в месяц, то есть $564 / $1140 / $2196 / $2868 в год.",
   "url": "https://asomobile.net/en/pricing/",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "Цена запроса к API ASOMobile в токенах не опубликована нигде",
   "status": "опровергнут",
   "evidence": "Слово «нигде» не держится. Тарифной таблицы по эндпоинтам нет, но в публичной документации Usage Result лежит пример ответа с конкретными ценами: /app-keywords/ tokens_cost 10, /app-ranking/ 5, /keyword-check/ 0, и описание поля «число токенов, списанных за запрос (0 для бесплатных методов)». Оговорка: это пример, а не прайс — в том же примере plan: Pro, tokens_total 10000, тогда как страница тарифов даёт Pro = 5000 кредитов. На /en/api/ сказано, что у каждого типа запроса фиксированная цена в токенах, а сама цифра видна только внутри аккаунта.",
   "url": "https://api.asomobile.net/usage-result-39489207e0",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "Лимиты частоты запросов к API ASOMobile не опубликованы",
   "status": "подтверждён",
   "evidence": "Скачаны все 56 файлов документации через llms.txt и прогреплены: слов rate limit / requests per нет ни в обзоре, ни в одном эндпоинте. Страница /en/api/ упоминает только лимит токенов, видимый в аккаунте, но не частотный лимит.",
   "url": "https://api.asomobile.net/overview-asomobile-api-1447147m0",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "ASOMobile сама пишет, что Search Volume — оценка по своей методике, а не абсолютная цифра",
   "status": "подтверждён",
   "evidence": "Дословно из статьи от 08.07.2026: «ни App Store, ни Google Play не публикуют сырой органический объём поиска. ASOMobile оценивает его собственной методикой для обеих платформ — прогнозное число дневных поисков, которое позволяет сравнивать ключи, но не абсолютная величина».",
   "url": "https://asomobile.net/en/blog/app-store-keyword-research-search-intent-relevance-and-how-to-find-the-right-words/",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "/keyword-check/ принимает один ключ на запрос",
   "status": "подтверждён",
   "evidence": "OpenAPI-спека: параметр keyword, in: query, тип string, обязательный — не массив и не список через запятую. Батч-режима у эндпоинта нет.",
   "url": "https://api.asomobile.net/keyword-check-request-20886130e0",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "У /keyword-check/ нет параметра языка — только страна",
   "status": "подтверждён",
   "evidence": "Полный список параметров: platform (обязательный), ios_device (необязательный), country (обязательный, ISO 3166-2), keyword (обязательный). Параметра language нет. Грепом по всем 56 файлам документации строки «name: language» нет ни в одном эндпоинте — язык существует только как справочник поддерживаемых языков.",
   "url": "https://api.asomobile.net/keyword-check-request-20886130e0",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "У API ASOMobile тикетный флоу: запрос → ticket_id → отдельный запрос результата",
   "status": "подтверждён",
   "evidence": "Обзор: «каждый эндпоинт работает в два шага: инициализация запроса возвращает ticket_id, затем результат забирается через GET /endpoint/result?ticket_id=…». Подтверждается спеками: GET /keyword-check/ отдаёт 201 с ticket_id, а /keyword-check/result требует ticket_id обязательным параметром.",
   "url": "https://api.asomobile.net/overview-asomobile-api-1447147m0",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "С 29.09.2025 в США ключей с индексом популярности Apple Search Ads выше минимума стало 39 254 вместо 165 875",
   "status": "подтверждён",
   "evidence": "Дословно: с 29 сентября 2025 число ключей в App Store США с популярностью Apple Ads выше 5 упало с 165 875 до 39 254, то есть 126 621 ключ выпал из прежних нормальных диапазонов, суммарно −77,4%. Разбивка 29.09 → 07.10: Medium (20–59) 98 151 → 24 565, Low (10–19) 66 779 → 10 907, High (60–84) 916 → 2007. Там же: новый отчёт Apple включает только высокочастотные ключи (SAP ≥ 35). Страница обновлена 09.08.2026. Оговорка: это замер вендора ASO.dev по официальному API Apple, а не публикация самой Apple — Apple такой статистики не публикует.",
   "url": "https://aso.dev/blog/apple-ads-popularity-massive-drop/",
   "checked_on": "2026-08-19"
  },
  {
   "claim": "AppTweak выпустила новую модель объёма 11.08.2026",
   "status": "подтверждён",
   "evidence": "Каллаут в документации API: с 11 августа 2026 поле volume возвращает AppTweak Volume Estimate — собственную оценку поискового спроса, построенную на многолетней истории реальных объёмов и дополнительных рыночных сигналах; имя поля, формат и шкала 5–100 не изменились. Оговорка: текст первоисточника дошёл до сборщика обрезанным на фразе про новую метрику, поэтому приведено только то, что видно целиком, а ссылку дописывать за проверяющего мы не стали.",
   "url": null,
   "url_note": "адрес страницы в переданной проверке обрезан — проверять придётся заново",
   "checked_on": "2026-08-19"
  }
 ],
 "cost": {
  "ours": {
   "что": "бесплатный путь: собрать подсказки, отсканировать выдачу, сверить с App Store",
   "ключейОтсканировано": 3637,
   "запросовВсего": 115069,
   "разбивка": {
    "подсказки": 98054,
    "выдачаPlay": 3964,
    "карточкиПриложений": 12097,
    "appStore": 954
   },
   "измеряющихЗапросовНаКлюч": 4.68,
   "запросовНаОдинНайденныйИсход": 141.71,
   "денегUsd": 0,
   "самиДоказательства": {
    "обращенийКСети": 401,
    "поОпытам": {
     "p1": 64,
     "p2": 0,
     "p3": 0,
     "p4": 337,
     "p5": 0,
     "всего": 401
    },
    "денегUsd": 0,
    "комментарий": "в этих запусках всё отдал дисковый кэш, живых запросов ушло ноль; цифра — сколько бы стоило с нуля"
   }
  },
  "theirs": {
   "apptweak": {
    "правило": "10 кредитов за ключ, батч до 10 ключей на запрос",
    "запросовНа3637Ключей": 364,
    "кредитовНа3637Ключей": 36370,
    "вЕвроПоТарифуLite": 30.19,
    "прогоновВМесяцНаLite": 5.5,
    "кредитовНаВсюВоронкуОтбора": 1260860,
    "месячныхЛимитовLiteНаВоронку": 6.3,
    "расхождениеСРазбором": "36 734 = 3637 ключей × 10 кредитов + 364 запроса: в разборе к цене ключей добавлен ещё кредит за сам запрос, прямой счёт по правилу «10 за ключ» даёт 36 370",
    "тарифИзРазбора": "API Lite €166/мес — цифра из разбора, снята с сайта вендора одним чтением и вторым проходом не подтверждена"
   },
   "asomobile": {
    "правило": "GET /keyword-check/ — один ключ на запрос, батча для наших фраз нет",
    "запросовНа3637Ключей": 3637,
    "кредитовНа3637Ключей": null,
    "почемуNull": "цена запроса в токенах нигде не опубликована — до оплаты стоимость прогона неизвестна",
    "поправкаКПочемуNull": "формулировка «нигде не опубликована» пришла из опыта 5 и перепроверку не прошла: пример с ценами в токенах в документации есть. Прайса по эндпоинтам всё равно нет, так что кредиты за прогон посчитать по-прежнему не из чего — но слово «нигде» неверное.",
    "тарифыСПервоисточника": {
     "free": "$0, 20 ключей, 0 API-кредитов, без карты",
     "помесячно": {
      "indie": 59,
      "pro": 119,
      "max": 229,
      "maximum": 299
     },
     "годовая": {
      "indie": 47,
      "pro": 95,
      "max": 183,
      "maximum": 239
     },
     "кредитовВПлане": {
      "indie": 1000,
      "pro": 5000,
      "max": 50000,
      "maximum": 100000
     },
     "проверено": "2026-08-19, asomobile.net/en/pricing"
    },
    "ценаЗапросаВТокенах": "в документации есть пример: /app-keywords/ 10, /app-ranking/ 5, /keyword-check/ 0. Это пример ответа, а не прайс — в нём же plan Pro с 10 000 токенов против 5000 на странице тарифов. Письменной цены от поддержки нет."
   },
   "главное": "вендорские кредиты тратятся ВДОБАВОК к нашему скану, а не вместо него: исход «пусто и побиваемо» из частотности не выводится ни при какой её точности, значит скан выдачи всё равно придётся делать целиком"
  }
 },
 "open_questions": [
  "Ни один вендор так и не был опрошен ни одной нашей реальной фразой: данные лежат за авторизацией, живой эндпоинт ASOMobile отдаёт 401. Всё, что здесь сказано про вендорскую цифру, — вывод из их опубликованных слов о методике, а не замер.",
  "Опыт 3 восстановил вендорский рецепт из бесплатных входов, и на витрине он с нашим спросом расходится (Спирмен 0.57–0.59 у двух вариантов из трёх). Значит утверждение «нам перепродают наш же сигнал» на том множестве, ради которого всё и делается, не доказано. Ответ даёт только бесплатный триал AppTweak.",
  "Цена запроса /keyword-check/ в токенах: в документации пример говорит 0, страница тарифов даёт Pro = 5000 кредитов, а тот же пример — 10 000. До письменного ответа поддержки стоимость прогона по 3637 ключам неизвестна, а это разница между $59 и $229 в месяц.",
  "Новая модель AppTweak Volume Estimate вышла 11.08.2026 и заявлена ровно против того, на чём стоит наш вывод, — «всё упёрлось в минимум, особенно на неанглийских рынках». Ни одной нашей фразой она не проверена. Если она работает, ответ меняется.",
  "Остаточный отбор внутри 3637 кандидатов замерить не удалось: список неотсканированных ключей в этот воркtree не попал, поэтому насколько наш набор смещён относительно всех 126 086 ключей воронки — неизвестно.",
  "id-ID — единственное гео, где спрос различает пустую нишу и занятую в правильную сторону (AUC 0.678 на 113 наблюдениях). Поправку на множественность это не проходит, но и опровергнуть нечем: отдельного прогона по Индонезии не было.",
  "Внешний якорь через Википедию не доведён до устойчивого метода: порог совпадения заголовка решает и долю совпадений, и знак связи. Нужен другой способ привязки темы (Wikidata, словарь, ручная разметка), иначе этот источник нельзя использовать как проверку.",
  "Настоящие поисковые запросы Google Play (выгрузка Play Console, $25 за аккаунт разработчика) не проверены живьём — а это единственный источник, где частотность Play не оценка, а факт. Про порог сворачивания редких терминов в «Other» Google ничего не публикует.",
  "Состязательную проверку прошли все пять опытов, и два из них она развернула: у третьего опоры «подстановка почти не меняет витрину» не оказалось вовсе (шум держит 75% топ-100, выключенный спрос — 94%), у второго знак связи оказался наведён составом выборки. Проверяющих было по одному на опыт: второго независимого мнения ни по одному выводу нет."
 ]
}