Карта контентных доказательств: какие факты, демо и отзывы нужны для разных обещаний

К лендингу, посту или презентации часто прикладывают отзыв, скриншот, демо или цифру из старой таблицы. Формально подтверждение есть, но оно может доказывать не то, что обещает текст.

Отзыв подтверждает опыт конкретного человека. Демо показывает функцию или процесс в показанных условиях. Кейс фиксирует события одного проекта. Они не делают результат типичным и не доказывают причинность.

Карта доказательств меняет порядок работы:

claim → требуемый proof → доступный источник → proof gap → допустимая публичная формулировка.

Для каждого обещания видны нужный proof, источник, gap, владелец, разрешение и допустимая формулировка. Команда заранее планирует proof-активы, а не подкрепляет любой claim первым удобным скриншотом.

Claim, proof и proof gap: три разные вещи

Claim — утверждение, которое читатель должен принять как правду. Явный, или express claim: «в системе есть ручное согласование». Подразумеваемый, или implied claim: заголовок «получи результат без участия редактора» вместе с демо готового материала сообщает больше буквального текста.

Американская FTC рекомендует оценивать общий смысл рекламы: заголовок, изображение, демонстрацию, контекст и пропущенные условия. Объективному обещанию нужен подходящий proof и разумное основание до распространения claim. Это описано в FTC Policy Statement Regarding Advertising Substantiation и Advertising FAQ для малого бизнеса.

Proof asset — материал, который подтверждает именно этот claim: первичный документ, лог, выгрузка, запись демо, отзыв, кейс, данные по группе, сравнительный тест, исследование или честное ограничение.

Proof gap возникает, когда публичная формулировка сильнее подтверждения: один показ функции превращают в обещание стабильного результата для всех; отзыв участника — в «большинство получает»; рост после изменения — в причинный эффект.

Для первого прохода выпиши из оффера, лендинга и пяти основных продажных материалов каждое проверяемое обещание. Пока не оценивай истинность: зафиксируй обещание и вывод читателя.

Карта claim → proof: какой актив нужен разным обещаниям

Каждый proof-актив отвечает на свой вопрос и имеет границу применимости.

Скриншот, отзыв и эксперимент отвечают на разные вопросы. Чем точнее claim, тем проще выбрать подходящий материал и не приписать ему лишнего.

Таблица — авторская практическая редакционная рамка статьи, а не официальный стандарт или набор «общепринятых типов». Она различает объективные данные, отзывы, демо, наблюдения и дизайны для причинного вывода. Соответствие claim и evidence поддерживают FTC и британская CAP/ASA guidance по substantiation.

Тип обещания	Подходящий proof asset	Что он реально подтверждает	Где проходит граница
Существование функции или этапа	Живое демо, скринкаст, интерфейс, документация	Функция или этап есть и работает в показанной версии и условиях	Не доказывает надёжность на масштабе, бизнес-эффект или доступность в другой версии
Процесс выполнения	Скринкаст полного прохода, workflow, журнал выполнения, версия регламента	Такая последовательность действий реально выполнялась	Один проход не подтверждает типичную скорость, качество или отсутствие сбоев
Факт, число, дата, состав	Первичный документ, экспорт, audit log, счётчик с методикой	Значение зафиксировано в конкретном источнике и срезе	Нужны период, единицы, фильтры и способ подсчёта. Скриншот без происхождения слаб
Индивидуальный опыт	Подлинный отзыв, запись или транскрипт, контекст и разрешение	Конкретный человек сообщил такой опыт или мнение	Не доказывает причинность, типичный результат или эффективность для других
Результат одного кейса	Baseline, действия, сроки, outcome, исходные данные, ограничения	В одном контексте наблюдалась такая последовательность и результат	Без сравнения нельзя исключить другие причины и переносить результат на всех
Типичный результат или частота	Определённая группа, полная выборка результатов, метод подсчёта, denominator	Распределение результата в указанной группе и периоде	Лучшие отзывы и кейсы не показывают типичность. Нужны исключения и вариативность
Сравнительное превосходство	Сопоставимый тест на одной задаче и в одинаковых условиях, заранее заданная метрика	Разницу по конкретной характеристике в заданных условиях	Тест не доказывает «лучше вообще» и лидерство среди непроверенных альтернатив
Причинный эффект	Рандомизированный эксперимент, сильный квазиэксперимент или другой дизайн с обоснованным сравнением	При выполнении допущений поддерживает вывод о влиянии X на Y	Корреляция, before/after, отзыв и один кейс причинность не устанавливают
Экспертное или научное утверждение	Первичный стандарт, регулятор, систематический обзор, guideline, релевантное исследование	Состояние знания или нормы в указанной области и границах	Авторитет не заменяет данные. Источник должен быть актуален и применим к claim
Обещание с высокой неопределённостью	Ограничения, prerequisites, диапазон, failure cases, сценарии неприменимости	Границы использования и известные условия отказа	Ограничение не доказывает основной claim и не должно прятаться под сильным заголовком

В таблице встречаются принципы FTC для рекламы в США и CAP/ASA для британской рекламы вне телевидения и радио. Они полезны как операционные ориентиры по доказательности, но не заменяют юридическую проверку в России или другой юрисдикции.

Почему отзыв, кейс и демо нельзя менять местами

Отзыв доказывает сообщение человека, а не причинный эффект

Проверь подлинность, контекст, возможный стимул и разрешение. CAP/ASA советует хранить подтверждение подлинности и контактные данные, получать разрешение и не вырывать отзыв из контекста. Подробности: guidance по testimonials and endorsements.

Даже подлинный отзыв не доказывает эффективность. Проверяемому утверждению внутри него нужен отдельный proof, о чём CAP/ASA пишет прямо. По FTC, endorsement не позволяет заявить то, что рекламодатель не мог бы обоснованно заявить сам. Фраза «результаты могут отличаться» не всегда снимает впечатление типичности исключительного результата. См. FTC Endorsement Guides Q&A.

Кейс показывает контекст и последовательность

Хороший кейс фиксирует baseline, изменение, момент измерения, данные и ограничения. Это наблюдение в конкретной ситуации.

Последовательность «сделали X, затем получили Y» не означает причинность. Нужны обоснованный контрфактический сценарий и проверка альтернативных объяснений. Глава Cochrane о нерандомизированных исследованиях разбирает confounding, selection bias, допущения дизайна и применимость. Источник относится к исследованиям здоровья; отраслевые требования проверяй отдельно.

Демо показывает только показанный процесс

Процессное демо отвечает на узкий вопрос: «сработала ли функция или цепочка в этой версии и условиях?». Запиши полный проход, входные данные, версию, участие человека и результат.

Оно не доказывает окупаемость, типичную скорость, качество на любом входе или результат каждого пользователя. Для outcome нужны outcome data, для типичности — определённая группа, для причинности — подходящий дизайн сравнения.

Как собрать карту доказательств до производства контента

1. Раздели составные обещания

Фраза «система быстро создаёт точный контент в голосе эксперта» содержит минимум три claims: про скорость, точность и голос. У каждого будет свой критерий и свой источник. Одна ссылка не подтверждает весь пакет.

2. Допиши аудиторию, задачу и implied claim

Кто читает claim и какое решение принимает? Что он поймёт из заголовка, изображения, кейса и умолчаний? Не выдумывай язык, мотив или барьер аудитории: ставь needs-custdev и планируй исследование.

3. Оцени риск ошибки

Оцени риск как низкий, средний или высокий и запиши последствие для денег, здоровья, безопасности, репутации или покупки. Чем выше цена ошибки и сильнее claim, тем строже proof.

4. Сначала зафиксируй требуемый proof

Не открывай папку с отзывами, пока не решил, какой материал нужен. Иначе легко выбрать самое удобное подтверждение, а не подходящее.

5. Привяжи источник, владельца и разрешение

Запиши прямой URL, ID документа, выгрузку, запись или репозиторий. Добавь владельца, который отвечает за актуальность. Разрешение проверяй отдельным полем: подлинный отзыв всё равно нельзя публиковать автоматически.

Для хранения карты подойдут таблица или база со статусами и владельцами. Если используешь Notion, посмотри, как связать базу, статусы и человеческое согласование. Инструмент здесь вторичен. Главное, чтобы источник можно было найти и перепроверить.

6. Присвой evidence label

Статус не должен маскировать силу доказательства. Используй четыре рабочие метки:

verified: claim сверён с идентифицируемым первичным источником, его границы и дата понятны;
observed: есть зафиксированное наблюдение, опыт или кейс, но нет основания для универсального или причинного вывода;
hypothesis: рабочее предположение, которое нельзя публиковать как факт;
needs-custdev: утверждение об аудитории требует интервью, данных или другого customer research.

Это внутренние workflow-метки, а не научная шкала. verified не означает «истина навсегда». Метка говорит, что публичная формулировка соответствует конкретному источнику и его границам на дату проверки.

7. Запиши допустимую публичную формулировку

Формулировка не должна быть сильнее источника. «В одном проекте после изменения наблюдали X» честнее, чем «изменение повышает X». «В показанном процессе» точнее, чем «всегда». Если приходится прятать ограничение мелким шрифтом, перепиши основной claim.

Шаблон карты контентных доказательств

Скопируй таблицу в рабочую базу. Обязательные поля уже стоят в нужном порядке: сначала обещание и риск, затем критерий proof, источник, ответственность и только после этого публичный текст.

claim	аудитория/задача	риск	требуемый тип proof	доступный источник	владелец	разрешение	статус verified/observed/hypothesis/needs-custdev	публичная формулировка	следующий шаг	дата пересмотра
[одно атомарное обещание]	[кто читает и какое решение принимает]	[уровень + последствие ошибки]	[демо / документ / отзыв / кейс / cohort / comparison / causal study / expert source / limitation]	[URL, doc ID, выгрузка или запись без секретов]	[роль или человек]	[да / нет / не требуется / неясно]	[одна метка]	[текст не сильнее evidence]	[добыть / проверить / сузить / снять]	[YYYY-MM-DD]
В рабочем процессе есть этап ручного согласования	Маркетолог проверяет, остаётся ли финальное решение у человека	Средний: можно создать ложное впечатление об автопилоте	Скринкаст полного прохода + версия workflow	Тестовый скринкаст и схема процесса	Редактор процесса	Неясно: проверить интерфейс и данные	observed	В показанном тестовом маршруте материал проходит ручное согласование	Проверить разрешение, повторить демо на актуальной версии и зафиксировать условия	YYYY-MM-DD

Как работать с шаблоном:

Заполни claims из оффера и основных материалов. Одна строка, одно обещание.
Не подставляй найденный отзыв в колонку «требуемый proof», если claim требует данных по группе или сравнения.
Если источника нет, оставь поле пустым и поставь следующий шаг. Не маскируй gap ссылкой на вторичный пересказ.
Проверь permission до передачи актива автору или дизайнеру.
На дату пересмотра сверь версию продукта, период, метод измерения и публичный текст.

Во внутреннюю версию можно добавить scope/conditions, метод измерения, период, размер и состав группы, denominator, исключения и версию продукта. Обязательные колонки при этом не убирай.

Что делать, если доказательства пока нет

Если доказательство слабее обещания, усиливают proof или ослабляют формулировку.

Proof gap не нужно заполнять красивой формулировкой. Сначала найди точное место разрыва: подлинность, измерение, типичность, сравнение или причинность.

Задай пять вопросов:

Какой буквальный и подразумеваемый вывод сделает читатель?
Что доступный актив подтверждает напрямую?
Какой шаг вывода остаётся без основания?
Помогут ли контекст, baseline, период, denominator или ограничение?
Кто должен проверить метод и допустимость, если цена ошибки высокая?

После диагностики выбери действие:

Ситуация	Что делать	Как временно писать публично
Есть демо, но нет outcome data	Добыть данные или оставить claim на уровне процесса	«Функция сработала в показанных условиях»
Есть один кейс	Описать baseline, действия, результат и ограничения	«В этом проекте наблюдали...»
Есть отзыв, но claim про типичный результат	Собрать полную группу и метод подсчёта	Не делать claim о большинстве или среднем
Есть before/after, но нет причинного дизайна	Проверить альтернативные причины, спроектировать сравнение	«После изменения наблюдали...», без «из-за»
Нет permission	Обезличить только при допустимости или снять актив	Не публиковать цитату, имя и детали
Claim основан на догадке об аудитории	Поставить `needs-custdev`, провести интервью или анализ данных	Не выдавать мотивацию аудитории за факт

Ещё три нормальных решения: сузить обещание, раскрыть условия или снять claim. Плохое решение одно: оставить сильный заголовок и спрятать противоречащую ему оговорку внизу.

Где помогает ИИ, а где решение остаётся за человеком

ИИ подключается после того, как человек определил аудиторию, claims, источники и правила. Он может:

извлечь candidate claims из оффера и контент-плана;
разделить составную фразу на атомарные утверждения;
найти дубли и противоречия;
сопоставить claims с уже переданными документами, демо и отзывами;
подсветить gaps и подготовить список запросов владельцам;
отметить слова риска: «гарантированно», «всегда», «лучший», «доказано», «типичный», «из-за».

Но ИИ не знает отсутствующий факт, не выдаёт разрешение на публикацию и не создаёт причинность красивым объяснением. Человек решает, репрезентативна ли выборка, применим ли источник, допустим ли claim, что соответствует стратегии и можно ли выпускать материал.

Карта становится входом для ИИ, а не очередным списком промптов. Если нужно передать модели проверенный контекст, используй принципы из гайда по prompt engineering для контента. Для SEO-материалов отдельно пригодится процесс, где источники, реальный опыт и human review собираются до публикации. Ни один из этих шагов не даёт гарантии позиции в поиске.

Когда карта встроена в source of truth, команда видит актуальные формулировки, ограничения и владельцев, а не собирает доказательства заново под каждый пост. В разборе системы Фабрики Контента можно посмотреть, как source of truth, фактчекинг и человеческий контроль связываются с производственным процессом. Это полезный следующий слой после того, как сама карта уже собрана.

Частые ошибки

«В отзыве написано, значит доказано». Отзыв может быть подлинным и всё равно не подтверждать объективную эффективность.
«После внедрения выросло, значит из-за внедрения». Последовательность не исключает другие причины.
«На демо получилось, значит получится у всех». Демо ограничено показанными входами, версией и условиями.
«Есть скриншот цифры, источник понятен». Без периода, фильтров, единиц и метода скриншот трудно перепроверить.
«Results may vary всё исправит». Общая оговорка может не убрать впечатление типичного результата.
Одна proof-ссылка стоит рядом с пакетом claims. Раздели обещание и проверь каждый кусок отдельно.
Два пересказа считаются двумя источниками. Они могут вести к одному первичному документу или повторять друг друга.
Карта превращается в предфактчек статьи. Её задача шире: заранее спланировать proof-активы для оффера и контентной системы. Проверку конкретной цифры или цитаты перед публикацией делай отдельным паспортом утверждения.

FAQ

Можно ли считать отзыв доказательством результата?

Он подтверждает, что конкретный человек сообщил такой опыт, если подлинность проверена. Но отзыв сам по себе не доказывает объективную эффективность, причинность или типичный результат. Для этих claims нужны отдельные данные подходящего типа.

Чем кейс отличается от причинного доказательства?

Кейс фиксирует контекст, действия и наблюдаемый outcome. Причинный вывод требует обоснованного сравнения с тем, что произошло бы без вмешательства, плюс проверки альтернативных объяснений и допущений дизайна.

Что доказывает процессное демо?

Что функция или процесс сработали в показанных условиях и версии. Оно не подтверждает автоматически окупаемость, стабильность на масштабе или результат любого пользователя.

Что делать, если есть только один сильный кейс?

Публиковать его как конкретное наблюдение: с baseline, действиями, сроками, исходными данными и ограничениями. Не называть результат типичным и не приписывать причинность без подходящего дизайна. Параллельно можно планировать данные по группе или контролируемое сравнение.

Достаточно ли написать «результаты могут отличаться»?

Не всегда. Если материал создаёт впечатление, что исключительный результат обычен, общая оговорка может не исправить общий смысл. Нужны данные о типичном результате либо ясное раскрытие ожидаемого результата и условий. Это принцип FTC для рекламного контекста США, а не юридическая консультация для России.

Нужно ли доказывать субъективное мнение?

Личное мнение отличается от объективного claim. Но контекст может превратить фразу «мне понравилось» в обещание эффективности или превосходства. Смотри на вероятную интерпретацию читателя, а не только на намерение автора.

Улучшает ли карта доказательств позиции в Google?

Прямой рост позиций обещать нельзя. Google рекомендует ясные источники, evidence of expertise, first-hand experience, описание того, как создавался или тестировался материал, и отсутствие легко проверяемых ошибок. Эти принципы собраны в гайде Google по people-first content. Карта помогает организовать такую работу, но не является отдельным фактором ранжирования и не гарантирует позицию.

Источники

Регуляторные материалы ниже описывают принципы США и Великобритании. Они не заменяют локальную юридическую консультацию.