МАТЧАСТЬ / CONTENT TYPES & TEMPLATES / DOCUMENT 23 / 02.09.2026
Типы материалов и шаблоны публикаций
Какие форматы должны существовать в CMS «Матчасти», какие поля обязательны для каждого, как отличать статью от кейса, новости, мнения, интервью и исследования, как превращать текст в структурированные данные и какие шаблоны нужны бизнесу, редактору, поисковикам и будущему AI Visibility layer.
8основных content types в полной модели
5форматов достаточно для коммерческого MVP
3 осиформат, происхождение и legal status хранятся отдельно
Typedкейс и исследование — не просто Article с другим заголовком
1. Главное решение
«Матчасть» не должна иметь один универсальный редактор «Новая статья». На этапе создания пользователь выбирает реальный формат материала, а CMS показывает поля и quality gates, соответствующие этому формату. Общий rich-text остаётся, но вокруг него существует структурированная оболочка.
PUBLICATION
│
├─ FORMAT
│ ARTICLE
│ CASE
│ EXPERT_OPINION
│ INTERVIEW
│ RESEARCH
│ NEWS
│ EVENT
│ FIELD_SNAPSHOT
│
├─ ORIGIN
│ EDITORIAL
│ CONTRIBUTED
│ CLIENT_SUBMITTED
│ EDITOR_CREATED_FOR_CLIENT
│
├─ LEGAL STATUS
│ EDITORIAL
│ DIRECTORY/INFO
│ ADVERTISING
│ REVIEW
│
└─ COMMERCIAL STATUS
FREE_EDITORIAL
PAID_PUBLICATION
SPONSORED_RESEARCH
INTERNAL_SEED
Эти оси НЕ объединять в одно поле.
2. Почему формат нельзя определять по тому, кто заплатил
Платный материал может быть кейсом, экспертной статьёй, исследованием или новостью. А бесплатный редакционный материал может использовать тот же формат. «Partner» — это не жанр текста, а commercial/legal relationship.
| Материал | Format | Origin | Legal |
|---|---|---|---|
| Редакция написала анализ CRM-рынка | ARTICLE / RESEARCH | EDITORIAL | EDITORIAL |
| SaaS-компания прислала полезный кейс бесплатно | CASE | CONTRIBUTED | После classification |
| Клиент оплатил кейс с CTA | CASE | CLIENT_SUBMITTED | ADVERTISING |
| Компания оплатила исследование, выводы независимы | RESEARCH | EDITORIAL / SPONSORED | Legal review + visible sponsorship |
3. Что показывает рынок
РБК Компании уже использует типизированные формы: новость, кейс, мнение эксперта, мероприятие и другие форматы. В справке отдельно подчёркивается, что «Кейс» нужен для подробного описания задачи, методологии, процесса и решения, тогда как новость подходит для конкретного инфоповода или краткого сообщения о результате. «Мнение эксперта» строится от первого лица эксперта и не предназначено для описания услуг и цен компании.
Хабр также разделяет статьи, новости и короткие посты, а корпоративным авторам отдельно предлагает кейсы, факапы, технические разборы, материалы конференций, бенчмарки и новости. При этом в рекомендациях прямо предупреждает, что новость компании не должна превращаться в обычный пресс-релиз.
Вывод: типизированные формы работают не только как UX-удобство. Они заставляют автора дать читателю именно те данные, которые делают материал полезным.
4. Основная taxonomy «Матчасти»
| Format | Главный вопрос читателя | MVP |
|---|---|---|
| ARTICLE | Как это устроено / как разобраться? | Да |
| CASE | Как решили реальную задачу и что получилось? | Да |
| EXPERT_OPINION | Что думает специалист и почему? | Да |
| INTERVIEW | Что может рассказать конкретный человек? | Да |
| RESEARCH | Что показывают данные? | Да |
| NEWS | Что произошло? | Да, но коммерчески ограниченно |
| EVENT | Что, где и когда состоится? | P1 |
| FIELD_SNAPSHOT | Что рассказывает выборка реальных малых бизнесов? | Эксперимент / Idea 002 |
5. Не запускать 20 форматов
Типизация полезна, пока жанры реально меняют структуру данных. Если создать отдельный тип для «гайда», «ликбеза», «аналитики», «чеклиста», «колонки», «лонгрида» и «обзора», CMS станет непонятной.
ARTICLE покрывает поджанры через дополнительное поле:
ARTICLE.subtype:
EXPLAINER
HOW_TO
ANALYSIS
GUIDE
COMPARISON
REVIEW
TREND
OPINIONATED_ANALYSIS
Поджанр влияет на подсказки,
но не создаёт новую таблицу/URL-type.
6. Универсальные поля любой публикации
publication core
title
dek / summary
body
publication_type
subtype optional
author relations
company relations
topic relations
industry relations
source list
images/assets
legal_status
commercial_status
disclosure
published_at
updated_at
canonical_url
index_state
editorial_state
verification_state
version
reader_job
main_claim
7. Reader Job — обязательное поле
Редактор до публикации должен уметь закончить фразу: «После чтения человек сможет…»
ARTICLE:
…понять, чем GEO отличается от SEO
CASE:
…увидеть, как агентство решило конкретную задачу
RESEARCH:
…узнать, как распределяются цены на рынке
NEWS:
…понять, что изменилось и кого это касается
EXPERT:
…понять позицию специалиста и её аргументы
Reader Job не обязательно показывать публично, но он полезен для moderation и AI precheck.
8. ARTICLE — базовый объясняющий формат
| Поле | Обязательно? | Назначение |
|---|---|---|
| Title | Да | Конкретное обещание материала |
| Summary/dek | Да | Что читатель получит |
| Reader job | Да, internal | Quality gate |
| Main thesis | Да | Главная мысль |
| Body blocks | Да | Основное содержание |
| Sources | По необходимости, но обязательны для проверяемых claims | Доказательность |
| Topics | Да | Graph/navigation |
| Author | Да | Accountability |
9. ARTICLE template
1. Заголовок
2. Короткий анонс
3. Контекст / почему тема важна
4. Главный вопрос
5. Объяснение
6. Подтемы / шаги / аргументы
7. Примеры / данные / источники
8. Ограничения / исключения
9. Вывод
10. Sources / related entities
Не обязательна одинаковая
видимая структура у всех статей:
это skeleton, а не генератор одинаковых текстов.
10. ARTICLE anti-template
Не превращать шаблон в AI-формулу «введение → три преимущества → вывод». Структурированные поля помогают добыть содержательные данные, а редактор затем собирает естественный материал.
11. CASE — главный коммерческий формат
РБК Компании отличает кейс от новости именно глубиной описания действий, методологии и процесса. Хабр также рассматривает рабочий кейс, включая неудачу, как один из ключевых корпоративных форматов.
CASE CORE:
WHO
кто исполнитель
CLIENT
для кого
CONTEXT
что происходило
PROBLEM
какая была проблема
BASELINE
что было до
GOAL
что хотели изменить
CONSTRAINTS
сроки / бюджет / ограничения
PROCESS
что делали
DECISIONS
почему выбрали именно это
RESULT
что изменилось
EVIDENCE
чем подтверждается
LIMITATIONS
что не получилось / что нельзя обобщать
CLIENT CONFIRMATION
если доступно
12. CASE structured fields
| Поле | Тип | Обязательность |
|---|---|---|
| vendor_entity_id | relation | Да |
| client_entity_id | relation | Если раскрывается |
| problem | text | Да |
| goal | text | Да |
| baseline_metrics | claim set | Если есть |
| process | blocks | Да |
| tools/products | relations | Если релевантно |
| result_claims | claims | Да, если кейс заявляет результат |
| verification | state | Да |
| limitations | text | Да для качественного стандарта |
13. Кейс без процесса — не кейс
Если компания сообщает только: «мы внедрили продукт, клиент получил +20%», но не может объяснить задачу, ход работы и происхождение результата, материал лучше классифицировать как NEWS / partner announcement, а не как полноценный CASE.
14. Factual result claims
RESULT:
"конверсия выросла на 34%"
required metadata:
metric definition
before
after
period
measurement source
who supplied data
client confirmation status
possible confounders/limitations
Эти поля позже позволяют строить verified case cards и снижать количество маркетинговых цифр без контекста.
15. Failed Case / Postmortem
«Матчасть» должна сознательно принимать кейсы провалов. Хабр справедливо отмечает, что неудачный кейс иногда полезнее истории успеха.
POSTMORTEM subtype:
goal
what happened
failure signal
root causes
wrong assumptions
what was tried
what changed afterwards
what others can learn
Это сильный editorial differentiator: площадка не превращается в коллекцию одних побед.
16. EXPERT_OPINION
РБК Компании требует, чтобы «Мнение эксперта» представляло реальную позицию спикера и не превращалось в описание услуг/цен. Для «Матчасти» этот формат должен быть ещё более структурированным.
EXPERT OPINION:
question
→ clear thesis
→ expert answer
→ arguments
→ evidence/examples
→ counterargument
→ where this view does not apply
→ practical conclusion
AUTHOR:
verified Person
+
current/relevant affiliation
17. Expert Opinion fields
| Поле | Зачем |
|---|---|
| expert_entity_id | Не текстовое имя, а Person relation |
| question | Что именно обсуждается |
| position | Короткая тезисная позиция |
| arguments | Почему эксперт так считает |
| evidence | Источники/опыт |
| counterpoint | Где есть спор или альтернатива |
| affiliation_snapshot | Роль на момент публикации |
18. Expert ≠ рекламный spokesperson
Материал «наш CEO считает наш продукт лучшим» не становится экспертным только потому, что у CEO есть фотография и должность.
19. INTERVIEW
INTERVIEW:
subject
why this person
context
questions
answers
fact-check notes
entities mentioned
sources for factual claims
editorial intro
takeaways optional
Интервью — редакционный формат. Клиент может оплатить production/placement, но вопросы не должны превращаться в заранее написанный рекламный FAQ.
20. Interview modes
| Mode | Описание |
|---|---|
| Q&A | Вопрос-ответ с лёгкой редактурой |
| Narrative interview | Авторский текст с цитатами героя |
| Expert briefing | Короткий разбор одной темы |
| Multi-expert roundtable | Несколько экспертов отвечают на одинаковые/связанные вопросы |
21. Quote provenance
quote
speaker_entity_id
source:
audio transcript
written response
public event
source URL
timestamp/page optional
editorial_edits:
grammar only / condensed / approved
approval state
Особенно важно для later fact disputes.
22. RESEARCH — стратегически важный формат
Исследования — главный способ «Матчасти» создавать собственный независимый спрос и data moat. Именно этот формат превращает сайт из площадки публикаций в источник первичных данных.
RESEARCH:
research question
methodology
sample
collection period
data source
eligibility criteria
variables
analysis
findings
charts/tables
limitations
raw/aggregated dataset if publishable
license
authors/researchers
sponsor disclosure
version
23. Research mandatory fields
| Поле | Обязательно? |
|---|---|
| research_question | Да |
| methodology | Да |
| sample_size | Если выборочное исследование |
| sample_definition | Да |
| collection_period | Да |
| data_origin | Да |
| limitations | Да |
| findings | Да |
| dataset_relation | Если dataset публикуется |
| sponsor_entity | Если есть спонсор |
24. Research ≠ статья с несколькими цифрами
Нельзя маркировать каждую подборку статистики как «исследование». Если нет исследовательского вопроса, методологии и описания данных, это Article/Analysis.
25. Survey, snapshot, research — разные уровни доказательности
| Label | Когда использовать |
|---|---|
| Опрос | Собраны ответы респондентов; выводы ограничены выборкой. |
| Срез / Field Snapshot | Небольшая или exploratory выборка, цель — показать практики/разброс, а не репрезентативно описать весь рынок. |
| Исследование | Есть формальная методология, достаточная для заявленных выводов. |
| Dataset | Есть реально опубликованный структурированный набор данных. |
26. FIELD_SNAPSHOT — прямое развитие Идеи 002
Идею про малые бизнесы стоит закрепить как самостоятельный исследовательско-редакционный subtype, а не как «бесплатные статьи за анкету».
FIELD SNAPSHOT
topic:
"небольшие кондитерские"
questionnaire:
city
price range
products
ingredients/process
sales channels
order volume optional
business age
public resource
free-text answers
participants:
10–50+ businesses
output:
aggregated observations
ranges
patterns
exceptions
participant examples
quotes
links
methodology
limitations
27. Что FIELD_SNAPSHOT не должен обещать
Если ответили 12 кондитеров из Москвы и Подмосковья, нельзя писать «рынок кондитерских России устроен так».
Правильные заголовки:
"12 небольших кондитеров рассказали,
как формируют цену на торты"
"Как продают домашнюю выпечку:
срез небольших мастерских Москвы и Подмосковья"
НЕ:
"Исследование всего рынка кондитерских России"
28. Questionnaire responses как источник
participant response
→ Source entity
→ claims
→ participant company entity
→ verification status
→ research dataset row
→ publication mention
public wording:
"по данным участников опроса"
"компания сообщила"
"из 18 опрошенных..."
29. NEWS
Хабр формулирует хороший стандарт: новость ценят за свежесть; она отвечает на «кто, что, где, когда, почему, как», а первые ключевые ответы должны быть понятны уже из лида. РБК Компании также просит не отклоняться от инфоповода и не перегружать новость справкой о компании/продукте.
NEWS:
event
who
what
when
where if relevant
why it matters
source
context
what changes next
LEAD:
who + what + when
в одном коротком блоке
30. NEWS structured fields
| Поле | Назначение |
|---|---|
| event_date | Дата события, не только publish time |
| subject_entities | Кто участвует |
| event_type | launch / funding / regulation / appointment / partnership / release... |
| primary_source | Откуда известен факт |
| editorial_context | Почему это важно |
| update_state | Developing / final / corrected |
31. Press release ≠ News
Хабр прямо отмечает, что корпоративная новость похожа на пресс-релиз структурно, но не должна им быть. «Матчасть» принимает тот же принцип.
PRESS RELEASE INPUT:
"Компания X, лидер инновационных решений,
с гордостью сообщает..."
NEWS OUTPUT:
"Компания X запустила Y 2 сентября.
Продукт делает Z.
По словам компании...
Для рынка важно потому что..."
32. Commercial news
Paid company news можно принимать как отдельный SKU только при наличии реального события. «Мы давно предоставляем качественные услуги» — не новость.
| Инфоповод | News? |
|---|---|
| Запуск продукта | Да |
| M&A / инвестиция / партнёрство | Да |
| Изменение регулирования и реакция компании | Да |
| Новая должность / назначение | Если значимо |
| «Мы существуем уже 10 лет» без события | Возможно milestone, нужен контекст |
| Общее описание услуг | Нет |
33. EVENT
EVENT:
name
organizer
start/end
timezone
location / online URL
audience
topic
program
speakers
registration URL
price if any
capacity optional
status:
scheduled
postponed
cancelled
completed
На MVP можно не выводить отдельный верхнеуровневый раздел мероприятий, но структурированный тип пригодится для компаний и будущего distribution.
34. Event после окончания
После события URL не удалять. Переводить в completed и, если есть контент, добавлять материалы: запись, тезисы, отчёт, презентации. Это превращает временный event page в долговременный knowledge asset.
35. COMPARISON — subtype Article, но с отдельными quality gates
COMPARISON:
what is compared
selection criteria
why these participants
evaluation criteria
data sources
commercial conflicts
results
who each option fits
limitations
date snapshot
Если место участника куплено, это не независимое сравнение. Sponsored participants должны раскрываться, а платная позиция не может маскироваться под editorial ranking.
36. GUIDE / HOW-TO
HOW_TO:
goal
prerequisites
steps
examples
errors
verification/test
result
version / relevant date
Не обязательно использовать
Google HowTo rich-result assumptions:
формат существует для reader value.
37. EXPLAINER
EXPLAINER:
term/question
short answer
why it matters
how it works
components
examples
common misconceptions
related concepts
sources
Это идеальный формат для Context Bridge из Idea 001.
38. Context Bridge types
| Новая тема | Подходящие мосты |
|---|---|
| Новый рынок | Explainer + comparison |
| Новая технология | Explainer + expert opinion |
| Новая отрасль | Field Snapshot + market overview |
| Новый коммерческий кейс | Background article + adjacent case |
39. Word count — не quality criterion
Не устанавливать правило «статья минимум 5 000 знаков». Длина определяется задачей. Хабр использует разные форматы от коротких постов до лонгридов; ценность формата определяется не объёмом, а полнотой ответа.
В CMS можно использовать soft guidance:
| Format | Ориентир, не gate |
|---|---|
| News | Коротко, насколько позволяет событие |
| Expert Opinion | Обычно 4–10 тыс. знаков |
| Article | Обычно 6–20 тыс. |
| Case | Обычно 7–20 тыс. |
| Research | По методологии; может быть существенно длиннее |
Диапазоны — внутренний редакционный ориентир, не требования конкурентов или поисковиков.
40. Универсальный block editor
CONTENT BLOCKS:
paragraph
heading
quote
callout
image
gallery
video/embed
table
chart
code
steps
metrics
source citation
entity card
expert quote
company card
dataset download
methodology note
disclosure
correction/update note
41. Typed blocks важнее Markdown-всё-в-одном
Если метрика, цитата, источник и entity card являются typed blocks, мы можем валидировать их, переиспользовать в других страницах и анализировать машинно.
METRIC BLOCK:
value=34
unit=%
label="рост конверсии"
baseline=12.1
result=16.2
period=...
source_id=...
verification=...
Не просто:
"+34%" внутри HTML.
42. Citation block
CITATION:
source_id
display_title
url
supporting_claim_ids
quote optional
accessed_at
editor_note internal
Это связывает документ 14 (источники), 19 (provenance), 21 (structured data) и будущий AI fact-check.
43. Entity card block
ENTITY CARD
entity_id
relation_to_article
display_fields:
logo
name
short description
verification badge
official link
content pulls from graph
not duplicated manually in article.
44. Disclosure block — системный
Редактор не вставляет текст «Реклама» вручную в body. Disclosure формируется из legal/commercial state.
legal_status=ADVERTISING
→ system renders:
"Реклама"
advertiser info
erid
commercial label
sponsored research:
→ sponsor disclosure
→ legal ad layer if applicable
45. Format picker в CMS
"Что вы хотите рассказать?"
1. Объяснить тему
→ ARTICLE
2. Показать реальную работу над задачей
→ CASE
3. Дать позицию специалиста
→ EXPERT OPINION
4. Провести интервью
→ INTERVIEW
5. Показать данные
→ RESEARCH
6. Сообщить о новом событии
→ NEWS
7. Анонсировать мероприятие
→ EVENT
Пользователю не обязательно знать редакционную терминологию заранее. Интерфейс может определить формат через задачу.
46. Auto-suggest format
user uploads text
→ AI precheck:
looks like press release
has event date
has result metrics
has Q&A
has methodology
...
suggest:
"Похоже, это новость"
или
"У вас есть материал для кейса,
но не хватает описания процесса"
USER/EDITOR confirms.
AI предлагает, но не меняет формат автономно после публикации.
47. Форматные completion checks
| Format | Critical missing data |
|---|---|
| CASE | Нет problem/process/result |
| RESEARCH | Нет methodology/sample/limitations |
| NEWS | Нет event/date/source |
| EXPERT | Нет verified Person/clear position |
| INTERVIEW | Нет speaker/source/provenance |
48. Quality Gates общие
BEFORE REVIEW:
□ format identified
□ reader job
□ title
□ main claim
□ author/responsible human
□ company/entity relations
□ topics
□ source coverage
□ link roles
□ image provenance
□ legal classification
□ commercial relationship
□ duplicate scan
□ AI-content risk
□ format-specific fields
49. Commercial fields не видны editorial author’у полностью
CMS разделяет:
Content workspace
Текст, факты, источники, entities, визуалы.
Commercial/legal workspace
Order, advertiser, payer, campaign, erid, billing, legal status.
Редактор видит необходимые disclosures, но article body не превращается в CRM.
50. Origin field
origin:
EDITORIAL
CONTRIBUTED
CLIENT_SUBMITTED
EDITOR_CREATED_FOR_CLIENT
SYNDICATED? later
TRANSLATED? later
origin determines:
workflow
rights checks
editing responsibility
origin does NOT determine:
legal status automatically.
51. Authoring model
| Model | Byline |
|---|---|
| Автор сам написал | Person author |
| Редактор написал по интервью | Редактор author; эксперт source/interviewee |
| Компания предоставила материал | Person/Organization according to policy |
| AI помог подготовить | Ответственный human author остаётся |
52. AI Disclosure
Следуем документу 14: AI assistance сама по себе не создаёт новый формат. Важна существенность его роли.
ai_assistance:
NONE
LIGHT
SUBSTANTIAL
SYNTHETIC_VISUAL
TRANSCRIPTION
TRANSLATION
disclosure_required:
rule engine + editor decision
53. Content rights fields
rights:
text_rights_confirmed
image_rights_confirmed
quote_permission if needed
dataset_license
third_party_assets
syndication_status
exclusive/nonexclusive
client warranties
Публичный production pipeline не должен принимать изображения «нашли в Google» без source/provenance.
54. Duplicate / prior publication
| Situation | Policy |
|---|---|
| Оригинальный материал | Лучший вариант |
| Материал ранее в корпоративном блоге клиента | Нужна существенная адаптация/новая value; canonical/syndication strategy отдельно |
| Одинаковый пресс-релиз на 50 сайтах | Не публиковать как обычный Article |
| Перевод собственного уникального research | Можно при корректном rights/original reference |
55. Title fields
title_public
title_seo optional/generated
slug
social_title optional
DEFAULT:
one good public title
used broadly
НЕ:
три разных misleading titles
для SEO / соцсетей / AI.
56. Headlines: правила
РБК Компании рекомендует, чтобы заголовок соответствовал выбранному формату и содержанию; Хабр подчёркивает высокую роль заголовка во входе в материал. Для «Матчасти»:
- заголовок описывает реальную содержательную ценность;
- конкретика лучше абстрактного маркетинга;
- числа проверены;
- не использовать «№1/лучший» без методологии;
- не писать рекламный slogan вместо headline;
- не скрывать компанию, если она центральный объект и это важно читателю.
57. Summary/dek
SUMMARY answers:
что здесь
для кого
почему читать
Не:
"В современном мире технологии
играют всё более важную роль..."
58. Visual requirements by format
| Format | Preferred visual |
|---|---|
| Article | Обложка + схемы/примеры где полезно |
| Case | Process diagram, before/after, screenshots, metrics |
| Research | Charts/tables + downloadable data where possible |
| Interview | Verified portrait/documentary photo |
| News | Event/product/documentary visual |
| Field Snapshot | Charts/maps/distributions, а не коллаж рекламных логотипов |
59. Charts как first-class content block
CHART:
dataset_id
chart_type
x/y
units
title
note
source
methodology relation
accessible data table
image fallback
Если chart строится из structured data, позже его можно переиспользовать в отчётах, соцсетях и AI summaries.
60. Research chart rule
График без подписанного источника, базы расчёта и периода не проходит research moderation.
61. CTA policy by format
| Format | CTA |
|---|---|
| Editorial Article | Обычно related reading / topic / source |
| Partner Article | До 1 primary commercial CTA по базовой модели + sponsored link |
| Case | Можно официальный CTA после содержательной части |
| Research | Dataset/download/methodology; sponsor CTA отдельно и прозрачно |
| News | Источник / официальный релиз; promotional CTA минимально |
62. Related content system
RELATED candidates:
same topic
same entity
same industry
adjacent topic
Context Bridge
same expert
same research chain
ranking:
reader usefulness first
paid slot:
separate promoted inventory
with disclosure.
63. Search/GEO metadata from format
SEO/GEO слой не должен заставлять автора вручную заполнять 30 полей.
GENERATED FROM CONTENT:
meta title
description suggestion
schema type
mainEntity
about entities
author
dates
image
breadcrumbs
sitemap class
AI/search summary candidates
EDITOR:
reviews important fields.
64. Schema mapping
| Mathchast format | Основная Schema.org projection |
|---|---|
| ARTICLE | Article |
| CASE | Article |
| EXPERT_OPINION | Article |
| INTERVIEW | Article |
| RESEARCH | Article + Dataset when real dataset exists |
| NEWS | NewsArticle |
| EVENT | Event where applicable |
| FIELD_SNAPSHOT | Article / Research + Dataset if published |
65. URL mapping
ARTICLE → /articles/
CASE → /cases/
RESEARCH → /research/
NEWS → /news/
EXPERT OPINION:
either /articles/
with format badge
not separate route required
INTERVIEW:
either /articles/
with format badge
EVENT:
later /events/
FIELD SNAPSHOT:
research subtype
→ /research/
Не каждый CMS content type обязан иметь отдельную URL-папку. URL taxonomy должна оставаться понятной читателю.
66. Почему Opinion и Interview можно хранить как type, но публиковать в /articles/
Они меняют structured fields и workflow, но для публичной IA остаются долгими содержательными материалами. Это снижает fragmentation archive.
67. Content status state machine
IDEA
→ DRAFT
→ PRECHECK
→ NEEDS_DATA
→ EDITORIAL_REVIEW
→ NEEDS_CHANGES
→ FACT_CHECK
→ LEGAL_REVIEW if needed
→ APPROVED
→ SCHEDULED
→ PUBLISHED
later:
UPDATED
CORRECTED
ARCHIVED
MOVED
TAKEDOWN
68. Format-specific review order
| Format | Первый главный check |
|---|---|
| Case | Есть ли реальный процесс и доказуемый результат? |
| Research | Позволяет ли методология делать заявленные выводы? |
| News | Есть ли настоящий инфоповод? |
| Expert | Есть ли содержательная позиция реального эксперта? |
| Interview | Есть ли редакционная ценность ответов? |
| Article | Даёт ли материал самостоятельный answer? |
69. AI Precheck outputs
AI may return:
suggested_format
reader_job_candidate
main_claims[]
entities[]
sources_detected[]
missing_fields[]
promo_ratio signal
duplicate_similarity
unsupported_claims[]
topic_candidates[]
legal_flags[]
link_candidates[]
title_issues[]
style_issues[]
BUT:
editor decides publication.
70. Promo ratio — не жёсткая математика
Хабр в рекомендациях использует ориентир 75–85% пользы и 15–25% рекламы как практическую формулу корпоративного материала. Для «Матчасти» это полезный heuristic, но не автоматический числовой gate: важнее reader value и transparent commercial status.
AI может подсветить «большая часть текста описывает преимущества продукта», но не вычислять псевдоточную «реклама 27,4%».
71. Template versioning
content_template
type=CASE
version=3
required_fields
optional_fields
validation_rules
prompts/help
schema_mapper
active_from
old publication:
keeps historical data
can migrate explicitly
Шаблон будет улучшаться. Поэтому его версия должна быть известна системе.
72. Dynamic questionnaires
Одна из сильных механик: вместо blank editor клиент проходит форматный бриф, после чего редактор/AI собирает draft.
CASE questionnaire:
Кто клиент?
Какая проблема?
Что было до?
Какие ограничения?
Что сделали?
Почему?
Что изменилось?
Какими данными подтверждается?
Что не получилось?
Можно ли запросить подтверждение клиента?
→ structured answers
→ draft
→ editor
73. Research questionnaire
Что хотим узнать?
Какой источник данных?
Кого/что включаем?
Размер выборки?
Период?
Как собирались ответы?
Какие исключения?
Какие ограничения?
Что можно опубликовать?
Есть ли raw data?
74. News questionnaire
Что произошло?
Когда?
Кто участник?
Почему это новое?
Где первоисточник?
Что меняется?
Кого затрагивает?
Есть ли подтверждающий документ?
75. Expert questionnaire
Какой вопрос?
Какова ваша позиция одним предложением?
Почему?
Какой опыт это подтверждает?
Какие есть исключения?
С чем вы не согласны?
Какой практический вывод?
76. Малый бизнес: questionnaire template
Для Idea 002 лучше использовать динамические отраслевые формы поверх общего ядра.
COMMON:
company/person
city
business age
size range
product/service
price range
sales channels
public URL
open answer
publication consent
source/verification
VERTICAL:
Confectionery:
cake types
average order
ingredients
lead time
seasonality
SaaS:
MRR range optional
team size
pricing model
sales cycle
stack
→ compatible shared data
+ useful vertical specificity.
77. Consent fields для Field Snapshot
participant permissions:
use answers in aggregate
quote with attribution
mention company name
link official resource
publish price range
contact for clarification
include in future recurring wave
withdraw before publication deadline
Legal wording:
to be finalized later.
78. Structured form ≠ forced public disclosure
Некоторые ответы могут использоваться только агрегированно. В data model:
answer.visibility:
PUBLIC_ATTRIBUTED
PUBLIC_AGGREGATED_ONLY
EDITORIAL_ONLY
PRIVATE_NOT_FOR_PUBLICATION
Это может резко повысить качество исследовательских ответов: бизнес сможет дать чувствительный диапазон для статистики, не публикуя его рядом со своим названием.
79. Content packs
| Pack | Состав |
|---|---|
| Expert launch | Company profile + expert profile + Expert Opinion |
| Case launch | Case + company relations + verification |
| Research launch | Research + Dataset + charts + methodology |
| Context Pack later | Partner piece + 2–3 independent/contextual pieces |
| Field Snapshot | Questionnaire + aggregated article + participant graph |
80. Что входит в commercial MVP
CLIENT CAN BUY:
CASE
ARTICLE
EXPERT OPINION
INTERVIEW production
NEWS with real event
RESEARCH:
custom/high-touch,
not self-service first
FIELD SNAPSHOT:
free/editorial acquisition experiment
81. Что не продавать self-service на старте
| Формат | Почему |
|---|---|
| Независимый рейтинг | Conflict of interest |
| Review компании | Нет reputation methodology |
| Research с «нужным выводом» | Разрушает доверие |
| Публикация без moderation | Ключевой риск проекта |
| Press-release dump | Низкая reader value |
82. Public badges формата
Кейс
Мнение эксперта
Интервью
Исследование
Новость
Разбор
Гайд
отдельно:
Редакционный материал
Партнёрский материал / Реклама
Спонсировано
FORMAT badge
не заменяет
COMMERCIAL disclosure.
83. Content type analytics
measure by format:
approval rate
revision count
time to publish
reader engagement
search impressions
CTA clicks
AI citations
repeat purchase
correction rate
source completeness
Later:
which formats create best
business + reader value.
84. Template effectiveness
Если кейсы с новым шаблоном требуют на 40% меньше редакторских правок, это измеримый product improvement. Поэтому CMS должна сохранять template_version.
85. Editorial templates должны быть живыми
Не считать этот документ раз и навсегда утверждённой формой. Первые 50–100 публикаций покажут, какие вопросы реально вытягивают полезные данные, а какие создают бюрократию.
86. MVP template test
Сделать по 5 реальных материалов:
5 Articles
5 Cases
5 Expert Opinions
5 News
5 Research/Field Snapshot
для каждого:
time to collect
missing fields
editor time
user friction
reader quality
structured data completeness
→ revise templates
before scale.
87. Критерий хорошего шаблона
Хороший шаблон не заставляет автора писать одинаково. Он заставляет его принести редакции нужные факты.
88. Итоговая P0 data model
publication
publication_type
publication_subtype
origin
legal_status
commercial_status
reader_job
main_claim
content_blocks
authors
entity_relations
topic_relations
claims
sources
assets
links
disclosure
format_payload JSON/typed tables
template_version
editorial_state
verification_state
version
89. Решение документа
Утвердить typed publishing engine. Коммерческий MVP поддерживает Article, Case, Expert Opinion, Interview, Research и News; Event — P1, Field Snapshot — исследовательский эксперимент на основе Идеи 002. Формат, origin, legal status и commercial status являются независимыми полями. Каждый формат имеет собственные обязательные данные и quality gates. Case хранит problem/process/result/evidence; Research — methodology/sample/limitations/dataset; News — event/date/source; Expert Opinion — verified expert/position/arguments; Interview — speaker/quote provenance. Rich text дополняется typed blocks для metrics, citations, entities, charts и disclosures. Форматные questionnaires становятся основой self-service onboarding и будущего AI-assisted drafting.
90. Что этот документ разблокирует
Mathchast_23 content types
→ Mathchast_24 CMS & moderation workflow
→ Mathchast_25 AI precheck/editor
→ Mathchast_26 distribution engine
→ Mathchast_27 reader product
→ Mathchast_28 seed content
→ Mathchast_29 client cabinet
→ Mathchast_32 publication analytics
→ Mathchast_40 technical architecture
Источники исследования
- РБК Компании — типизированные форматы: новость, мероприятие, кейс, мнение эксперта и требования к ним
- РБК Компании — различия между кейсом, новостью и мнением эксперта; требования к достоверности и оформлению
- РБК Компании — публичный слой экспертных материалов и профилей
- Хабр — корпоративные форматы: рабочие кейсы, факапы, материалы конференций, бенчмарки, корпоративные новости
- Хабр — рекомендации по полезности корпоративного контента и ориентир польза/реклама
- Хабр — структура публикации и влияние заголовка/лида/изображения
- Хабр — статьи, новости, посты и требования к новостному формату
- Хабр, 2026 — данные по корпоративному контенту: статьи, новости, посты и спецпроекты
- ADPASS — требования к релевантности, полезности, качеству и редакционным правкам статей
- ADPASS — отдельные правила рекламных материалов и завуалированного продвижения
- Cossa — редакционные требования к авторским материалам и необходимость сильной содержательной идеи
- Cossa — раздельные каналы для статей, новостей и коммерческого сотрудничества
- Google Search Central — Article / NewsArticle structured data and author/date fields
- Google Search Central — people-first content, original information, research and analysis
Структура полей, MVP taxonomy, questionnaire design, Field Snapshot, шаблонные диапазоны длины, validation rules, content blocks и workflow являются проектными решениями «Матчасти». Рыночные примеры используются как ориентиры, а не как шаблоны для копирования. Field Snapshot напрямую развивает ранее зафиксированную Идею 002 о бесплатном слое первичных данных малого бизнеса.