Это методическая часть исследования: мы фиксируем, что считать релевантным событием для рынка онлайн‑школ, как собирать и проверять данные, и каким должен быть единый формат карточки мероприятия. Под «карточкой мероприятия» понимается стандартизированная запись в наборе данных с обязательными и дополнительными полями, пригодная для сравнения событий по годам и метрикам. Методика исключает оценочные суждения и опирается на проверяемые признаки: программу, даты, формат, организатора и состав спикеров.
Цель раздела — задать практические правила отбора и верификации, чтобы свести к минимуму расхождения и ручные трактовки. Мы описываем, какие источники считаем базовыми, как действовать при недоступности страниц и в каких случаях используется веб‑архив. Отдельно определяем, как фиксировать спикеров и темы, и как версионировать изменения в данных, чтобы любая правка имела прозрачную историю.
Рамки данных задаются целевой отраслью — инфобизнес и онлайн‑школы: продукты обучения, платформы и сервисы для запуска, продажи и доставки обучающих программ, методологии обучения и маркетинга, партнерские экосистемы и инфраструктура. Мы не включаем события, где EdTech упоминается эпизодически, без выделенных секций или спикеров по теме. Требование к источникам — наличие публичной программы и следов проведения: анонсы, страницы в соцсетях, пост‑релизы или видеозаписи.
Ключевой принцип — воспроизводимость. Каждый включенный объект должен быть подтвержден двумя независимыми источниками или одним первичным — официальной программой. Для спорных случаев приоритет у первичных материалов: программа, повестка дня, пленарные сессии, страницы организатора. Если страницы удалены или изменены, используем веб‑архив с фиксацией даты снимка. Все исправления проходят версионирование с комментарием, что именно изменено и по какому сигналу.
Принцип нейтральности контента исключает маркетинговые формулировки. В описании карточки используются ровно те названия, что указаны в программе: без добавления рекламных эпитетов и без нормализации до «удобных» синонимов. Если есть локализация на нескольких языках, выбираем язык оригинальной программы, а транслитерацию фиксируем отдельным полем. Это снижает риск потери точного соответствия с источником.
Важен принцип единого формата сравнения. Все поля карточки и их значения заданы схемой данных: типы, допустимые справочники, ограничения и единицы измерения. Любое отклонение фиксируется как исключение с обоснованием. Если поле не применимо, используется явная метка NULL/NA согласно словарю, а не произвольные комментарии в тексте.
Критерий «масштаб» фиксируется по емкости программы: минимум два полноценных трека или один трек с не менее чем пятью докладами и ключевым спикером. Для митапов релевантность определяется устойчивой серией и доступностью записей. Единичные встречи без повестки, закрытые клубные ужины и платные мастер‑классы без открытой программы не включаем, поскольку невозможно обеспечить сопоставимость.
Критерий «регулярность» означает повторяемость бренда события или последовательность выпусков. Преимущество у серийных мероприятий, но разовые форумы учитываются, если вклад в повестку рынка заметен по структуре программы и составу спикеров. Регулярность не подменяет профильность: ежегодная встреча без профильной повестки исключается.
Критерий «публичность источников» требует доступных артефактов: программа, афиша, пресс‑релиз, пост‑релиз, видеозаписи или стенограммы. Если доступны только закрытые рассылки, подтверждение считаем недостаточным. Допускается опора на агрегаторы событий и деловую прессу, но итоговую верификацию всегда закрываем первичной программой или видео.
Исключения группируем в четырех категориях. Первое — «непрофильная повестка» (общие IT‑форумы без выделенного EdTech трека). Второе — «дефицит источников» (нет программы и записей). Третье — «рекламные активности» (road‑show, product demo без конференционной части). Четвертое — «локальные закрытые встречи» без открытой регистрации и публикации повестки. Для каждой карточки исключения сохраняем причину в поле audit_note.
Краевые случаи обрабатываем по правилу минимальной достаточности: наличие программы с темами и спикерами плюс два независимых подтверждения дат и площадки. Если часть подтверждений противоречит друг другу, версию данных помечаем как «под вопросом» до появления записи сессий или пост‑релиза. Это убирает риск включения событий‑«миражей», которые были отменены или сменили формат.
Источники данных делим на первичные и вторичные. К первичным относятся официальные сайты событий и организаторов, страницы с программой и архивы программ, видеоканалы с записями докладов, стенограммы и слайды, опубликованные на ресурсах событий. Ко вторичным источникам относим публикации отраслевых СМИ, деловой прессы, агрегаторы событий и тикет‑платформы, а также профили спикеров в профессиональных сетях и их личные сайты.
При недоступности страниц используем веб‑архив. Дата снимка критична: мы сохраняем ссылку на снимок и фиксируем штамп времени в полях evidence_snapshot_date и evidence_note. Если текст на снимке противоречит видео, приоритет у видеозаписи. Для записей лайв‑стримов дополнительно сверяем заголовок, время и ведущих, чтобы исключить подмену.
Поисковые запросы для первичного и вторичного поиска формулируем на двух языках. Запросы должны сужать повестку к онлайн‑школам и EdTech, чтобы исключить смежные отрасли. Ниже задаем репрезентативный пул, который покрывает основные сценарии отбора и сверки.
Разнообразие источников снижает риск систематической ошибки. Официальные страницы дают точные названия и расписание. Видеозаписи подтверждают факт проведения и состав спикеров. Пресса и агрегаторы помогают отсечь отмененные события и уточнить локацию и даты. Профессиональные профили спикеров позволяют уточнить должности на момент выступления, если в программе указаны устаревшие роли.
Схема реализуется в виде JSON/CSV с фиксированными справочниками и перечислениями. Каждое поле имеет краткое определение, тип, обязательность и правила заполнения. Для полей с ограниченным набором значений используем справочники, которые версионируются вместе с датасетом. Это важно: изменение справочника «форматы» или «типы организаторов» без версии затруднит воспроизводимость прошлых выгрузок.
В карточке недопустимы произвольные комментарии внутри данных. Любая пояснительная информация вносится в поля audit_note и evidence_note, где допустим свободный текст. Для ссылок на артефакты храним контрольные идентификаторы и датированные отметки снимков, но не публикуем внешние URL в итоговом тексте. Это соблюдает правило разделения итоговой публикации и пакета источников.
Структура карточки едина для всех лет. Новые поля добавляются через минорную версию схемы и не ломают обратную совместимость. Удаление или переименование полей допускается только с мажорной версией и конвертером для старых наборов. Такие изменения сопровождаются миграционными заметками, чтобы аналитические скрипты могли корректно интерпретировать данные прошлых лет.
Эти поля закрывают основные вопросы: что за событие, кто организатор, когда и где прошло, в каком формате, и насколько верифицируемы материалы. Для city и country используем точно те формы, что встречаются в программе или пост‑релизе. Если указаны несколько площадок, выбираем основную и уточняем в audit_note. Для «гибридного» формата обязательно фиксируем признак онлайн‑трансляции и офлайн‑локацию.
Правила подсчета tracks_count и talks_count стандартизированы. Треком считаем последовательность слотов с общей тематикой в отдельном зале или поток онлайн. Слоты — это доклады, панели, fireside chats, мастер‑классы внутри программы. Мы не учитываем coffee‑break, регистрацию и закрытие. Если программа дробит один доклад на часть 1/2, считаем это одним слотом, если из описания следует единство темы и спикера.
Для video_availability важно не путать «анонсы записей» и фактическое наличие. «Ожидаются» ставим только при явном обещании организатора и не позже 90 дней от даты окончания события — после этого статусы пересматриваем и ставим «нет», если записи не появились. Это дисциплинирует обновления и точность аналитики по доступности контента.
Поля аудитории и посещаемости требуют особой дисциплины. Мы разделяем заявленную и подтвержденную посещаемость: первое — цифры из анонсов или пресс‑релизов, второе — оценки по пост‑релизам, отчётам площадок и материалам с места. Разница между ними — частый случай. Если применяем оценочную методику (например, по заполненности зала), кратко описываем подход в audit_note, не подменяя им числовое поле.
Расширенные поля по фокусу треков (lms_focus, marketing_focus) помогают оценивать баланс повестки: технологические аспекты платформ (LMS) против маркетинга и продаж онлайн‑школ. Тематическое кодирование в topics_taxonomy строится на закрытом справочнике: продукт, методология, маркетинг, продажи, удержание, аналитика, платформа, правовые вопросы, международная экспансия. Справочник версионируется и хранит обратную совместимость меток с годами.
Примечание по записям (recording_links_note) хранит только факт наличия и тип площадки, без внешних ссылок. Это соблюдает правило редакции — итоговый текст и пакет источников передаются отдельно. Для активаций после события (cta_post_event) фиксируем доминирующий тип: публикация записей, приглашение на воркшопы, предложение курса как апсейла или перевод аудитории в сообщество. В контексте последующего анализа такие поля помогают увидеть, как события влияют на повторные продажи из базы.
При наличии данных о билетной модели (ticketing_model) мы не пытаемся реконструировать прайсы. Достаточно бинарных признаков платности и приглашений. Если формат «invite‑only», карточка сохраняется только при наличии публичной программы и записей. Отсутствие открытой регистрации не исключает событие автоматически, если выполнены остальные критерии.
Каждое изменение карточки проходит две проверки: первичную — составителем, и вторичную — редактором данных. Для спорных полей добавляем evidence_note с кратким описанием источника и причин расхождения. Если расхождение не снимается, карточка получает статус «needs_review» и исключается из сводных метрик до закрытия вопроса. Это гарантирует чистоту аналитических выборок.
Верификация спикеров и тем проводится в два этапа. Этап 1 — сверка с официальной программой: фиксируем все слоты, их названия, роли (keynote, доклад, панель), расписание и привязку к трекам. Этап 2 — сверка по видеозаписям или пост‑релизам: подтверждаем факт выступления, соответствие заголовка и состав участников. Если в записи название отличается от анонсного, приоритет у факта, но анонсная версия сохраняется в альтернативном поле title_announced.
Должности и аффилиации спикеров фиксируем на момент выступления. Если программа содержит устаревшую должность, а профессиональный профиль спикера на дату события другой, в карточке сохраняем формулировку программы, а актуальную на дату выступления добавляем в поле position_verified с пометкой источника в evidence_note. Такой подход сохраняет соответствие артефактам и при этом повышает точность поиска по организациям.
Для панелей и круглых столов состав участников проверяем по видео и фотографиям. Если один или несколько участников заменены, изменение отражаем в notes на уровне слота, а в списке спикеров сохраняем фактически выступивших. Незаполненные роли модераторов мы не реконструируем по догадкам — если явных подтверждений нет, оставляем поле пустым.
Тематическое кодирование выполняется после верификации фактов. Сначала фиксируем «как есть», затем присваиваем коды из topics_taxonomy. Один слот может иметь несколько тематических кодов, но не больше трех: это ограничение снижает размывание аналитики и удерживает кодировку на уровне основных акцентов. Для кейнотов допускается более обобщенный набор кодов, для воркшопов — более прикладной.
Типичные проблемы — переименования докладов, отмены слотов и переносы. В таких случаях мы сохраняем оба состояния: анонс и факт. В полях slot_status используем значения «проведен», «отменен», «заменен», «перенесен». Если слот перенесен на другое издание события, перекрестные ссылки в данных не создаем, а оставляем пояснение в notes. Для видео‑плейлистов сверяем порядок и количество роликов с программой, чтобы исключить пропуски.
Для кейсов, где нет видеозаписей, допускаем подтверждение по стенограммам или фотоматериалам из официальных источников. В обоих случаях сохраняем описательный evidence_note. Любая верификация через личные страницы спикеров в соцсетях должна подкрепляться вторым независимым источником. Исключение — если речь о цитировании официального анонса организатора, дублированного спикером без изменений.
Названия событий сохраняем точно в той форме, в какой они указаны в программе. Если существует официальная англоязычная версия, добавляем поле title_en. Если в разных источниках используются варианты названия, приоритет у программы и визуальной айдентики события (афиши, заставки в видео). Сокращения без подтверждения в официальных материалах не используем.
Организатора фиксируем по публичному названию. Если организатор действует через дочернюю структуру, указываем фактического оператора события, но в поле organizer_group добавляем материнскую организацию. Для партнерских событий с несколькими организаторами сохраняем всех, разделяя роли «совместно с» и «при поддержке». Роль партнера‑хостера площадки не подменяет организатора.
Версионирование — обязательная часть методики. Каждая правка карточки сопровождается bump версии датасета и коротким changelog. Используем семантическую схему: MAJOR.MINOR.PATCH. PATCH — исправления без изменения схемы (опечатки, уточнения дат). MINOR — добавлены поля, обновлены записи, расширены справочники. MAJOR — изменена схема полей или логика кодирования. Для каждой версии храним freeze‑выгрузку и контрольные суммы.
Для 2026 года все упоминания будущих дат и анонсов маркируем явно: поле forecast_flag=true и раздел примечаний с описанием источника анонса. В итоговых расчетах такие карточки исключаются из ретроспективной статистики, но остаются в отдельной выборке прогнозов. Это соблюдает правило отделения фактов от анонсов и снимает риск искажения трендов.
Если обнаруживается расхождение между программой и записью, решение принимаем по правилу приоритета факта: фиксация «как проведено», с сохранением анонсной версии в дополнительных полях. При обнаружении существенных расхождений в датах или локациях карточка помечается как «reconciled» с указанием версии, в которой исправление внесено. Любой сторонний сигнал (публикация в прессе, агрегатор) без первичного подтверждения не инициирует исправление.
Этап поиска начинается с построения запросов и сборки источников по категориям: первичные, вторичные, подтверждающие. Результаты вносятся в таблицу кандидатов с признаками релевантности и уровня доступности материалов. На этом этапе важно фиксировать не только явные попадания, но и пограничные случаи — они пригодятся при расширении рамок исследования. По завершении поиск замораживается, чтобы не размывать выборку во время проверки.
Версии наборов данных сопровождаются контрольными суммами и списком затронутых карточек. В changelog фиксируем: краткое описание изменений, диапазон карточек, причину правки и ответственного. Если правки массовые (например, пересчет tracks_count по измененным правилам), добавляем миграционную заметку с алгоритмом перерасчета. Это позволяет воспроизвести результат в независимой среде и сопоставить метрики между версиями.
Для облегчения последующего анализа формируем инкрементальные пакеты: diff‑файлы между версиями, где отражены добавления, удаления и изменения на уровне полей. Такой подход ускоряет валидацию и интеграцию с аналитическими дашбордами. При подготовке сводных обзоров редакции мы используем эти пакеты как источник правок, не затрагивая базовый freeze.
Журналы QA структурированы по категориям: структура данных, фактология, кодирование тематик, соответствие справочникам, консистентность дат и локаций, наличие записей. Для каждой карточки указываем статус проверки и ссылку на артефакты. В операционном процессе полезно подключать дашборды для руководителя, чтобы отслеживать прогресс по стадиям и выделять блокеры: дефицит источников, спорные статусы слотов, задержки с публикацией записей.
Если исследование дополняется транзакционными данными (например, динамика публикаций в соцсетях или активность каналов), мы храним их в отдельном слое и не смешиваем с карточками событий. Любые производные метрики маркируются как «расчетные» и имеют собственный словарь. Это разграничение защищает от неосознанного использования прокси‑показателей вместо фактологии и упрощает ревизии.
Форматы данных: основная выгрузка в CSV/JSON, справочники — в CSV, журналы — в Markdown/CSV, визуальные артефакты — в изображениях и PDF. Для записей и крупных файлов храним контрольные идентификаторы и датированные примечания, но не публикуем прямые ссылки в тексте. При необходимости редакция запрашивает доступ к пакету источников отдельно. Это соблюдает принцип отделения аналитики от носителей доказательств.
К каждому выпуску формируем README c описанием полей, версиями справочников, известными ограничениями и списком нерешенных вопросов. Для автоматизации импорта полезны заранее подготовленные схемы валидации и тестовые выборки. Если редакции требуется сверка по метрикам охвата, мы прикладываем отдельную записку с методикой оценки и отмечаем, какие числа являются оценочными.
В процессе согласования удобно использовать отчёты по трафику для контроля публикаций и сроков выхода записей, если это влияет на дедлайны верификации. Для редакционных рассылок и коммуникаций со спикерами допустимо подключать CRM‑маркетинг по базе, но эти контакты не смешиваются с исследовательскими артефактами. Любые игровые механики промо, например игровые акции, относятся к операционному маркетингу и не отражаются в карточках, кроме случаев, когда они становятся частью программы.
При передаче важно сохранить привязку ко времени. Все файлы в пакете содержат штамп сборки и идентификатор версии. Если пакет пересобран для правок редакции, увеличиваем PATCH‑версию и оставляем заметку с перечислением исправлений. Для крупных обновлений, затрагивающих схему полей или справочники, выпускаем MINOR или MAJOR версии с отдельной миграционной инструкцией.
Версионирование данных — неотъемлемая часть качества. Каждое исправление сопровождается журналом изменений, а спорные случаи получают статус для повторной проверки. Разделение итогового текста и пакета источников защищает итоговую публикацию от внешних ссылок и сохраняет доказательную базу отдельно. Такая дисциплина превращает набор карточек в надежный аналитический ресурс, который корректно масштабируется и выдерживает повторные аудиты.
Цель раздела — задать практические правила отбора и верификации, чтобы свести к минимуму расхождения и ручные трактовки. Мы описываем, какие источники считаем базовыми, как действовать при недоступности страниц и в каких случаях используется веб‑архив. Отдельно определяем, как фиксировать спикеров и темы, и как версионировать изменения в данных, чтобы любая правка имела прозрачную историю.
Ключевые разделы:
Принципы отбора и рамки данных
Под «событием» в контексте исследования понимается офлайн‑ или онлайн‑активность с публичной программой: конференция, саммит, выставка, отраслевой форум, профильный конгресс, митап с повесткой докладов, а также гибридные форматы. Единицей учета служит одно издание события (год/выпуск), а не бренд целой серии. Это важно, потому что состав треков, фокус и масштаб меняются из года в год, и сравнимость достигается только на уровне изданий.Рамки данных задаются целевой отраслью — инфобизнес и онлайн‑школы: продукты обучения, платформы и сервисы для запуска, продажи и доставки обучающих программ, методологии обучения и маркетинга, партнерские экосистемы и инфраструктура. Мы не включаем события, где EdTech упоминается эпизодически, без выделенных секций или спикеров по теме. Требование к источникам — наличие публичной программы и следов проведения: анонсы, страницы в соцсетях, пост‑релизы или видеозаписи.
Ключевой принцип — воспроизводимость. Каждый включенный объект должен быть подтвержден двумя независимыми источниками или одним первичным — официальной программой. Для спорных случаев приоритет у первичных материалов: программа, повестка дня, пленарные сессии, страницы организатора. Если страницы удалены или изменены, используем веб‑архив с фиксацией даты снимка. Все исправления проходят версионирование с комментарием, что именно изменено и по какому сигналу.
Принцип нейтральности контента исключает маркетинговые формулировки. В описании карточки используются ровно те названия, что указаны в программе: без добавления рекламных эпитетов и без нормализации до «удобных» синонимов. Если есть локализация на нескольких языках, выбираем язык оригинальной программы, а транслитерацию фиксируем отдельным полем. Это снижает риск потери точного соответствия с источником.
Важен принцип единого формата сравнения. Все поля карточки и их значения заданы схемой данных: типы, допустимые справочники, ограничения и единицы измерения. Любое отклонение фиксируется как исключение с обоснованием. Если поле не применимо, используется явная метка NULL/NA согласно словарю, а не произвольные комментарии в тексте.
📉Комментарий:
При сомнениях относительно отнесения события к отрасли действует правило «доказанного профиля»: наличие специализированного трека или ≥30% программы по теме онлайн‑школ.
Критерии релевантности и исключения
Критерий «профиль повестки» означает тематическое ядро: содержание докладов и треков относится к созданию, продвижению, продаже и доставке образовательных продуктов онлайн‑школ. Допускаются смежные темы — маркетплейсы курсов, платформы вебинаров, B2B‑сегмент корпоративного обучения, инструменты аналитики и удержания студентов. Непрофильным считаем общий digital‑маркетинг, если образовательный контекст не выделен явно.Критерий «масштаб» фиксируется по емкости программы: минимум два полноценных трека или один трек с не менее чем пятью докладами и ключевым спикером. Для митапов релевантность определяется устойчивой серией и доступностью записей. Единичные встречи без повестки, закрытые клубные ужины и платные мастер‑классы без открытой программы не включаем, поскольку невозможно обеспечить сопоставимость.
Критерий «регулярность» означает повторяемость бренда события или последовательность выпусков. Преимущество у серийных мероприятий, но разовые форумы учитываются, если вклад в повестку рынка заметен по структуре программы и составу спикеров. Регулярность не подменяет профильность: ежегодная встреча без профильной повестки исключается.
Критерий «публичность источников» требует доступных артефактов: программа, афиша, пресс‑релиз, пост‑релиз, видеозаписи или стенограммы. Если доступны только закрытые рассылки, подтверждение считаем недостаточным. Допускается опора на агрегаторы событий и деловую прессу, но итоговую верификацию всегда закрываем первичной программой или видео.
Исключения группируем в четырех категориях. Первое — «непрофильная повестка» (общие IT‑форумы без выделенного EdTech трека). Второе — «дефицит источников» (нет программы и записей). Третье — «рекламные активности» (road‑show, product demo без конференционной части). Четвертое — «локальные закрытые встречи» без открытой регистрации и публикации повестки. Для каждой карточки исключения сохраняем причину в поле audit_note.
Краевые случаи обрабатываем по правилу минимальной достаточности: наличие программы с темами и спикерами плюс два независимых подтверждения дат и площадки. Если часть подтверждений противоречит друг другу, версию данных помечаем как «под вопросом» до появления записи сессий или пост‑релиза. Это убирает риск включения событий‑«миражей», которые были отменены или сменили формат.
География, языки и источники данных
География охватывает глобальный рынок, но приоритет у стран, где заметна активность онлайн‑школ и есть публичные программы на понятных редакции языках. Язык карточки совпадает с языком оригинальной программы. Если событие многоязычное, темы и имена спикеров указываем как в программе для каждого слота, без самостоятельных переводов. Для англоязычных имен допускаем поле с транслитерацией.Источники данных делим на первичные и вторичные. К первичным относятся официальные сайты событий и организаторов, страницы с программой и архивы программ, видеоканалы с записями докладов, стенограммы и слайды, опубликованные на ресурсах событий. Ко вторичным источникам относим публикации отраслевых СМИ, деловой прессы, агрегаторы событий и тикет‑платформы, а также профили спикеров в профессиональных сетях и их личные сайты.
При недоступности страниц используем веб‑архив. Дата снимка критична: мы сохраняем ссылку на снимок и фиксируем штамп времени в полях evidence_snapshot_date и evidence_note. Если текст на снимке противоречит видео, приоритет у видеозаписи. Для записей лайв‑стримов дополнительно сверяем заголовок, время и ведущих, чтобы исключить подмену.
Поисковые запросы для первичного и вторичного поиска формулируем на двух языках. Запросы должны сужать повестку к онлайн‑школам и EdTech, чтобы исключить смежные отрасли. Ниже задаем репрезентативный пул, который покрывает основные сценарии отбора и сверки.
- конференция по онлайн‑школам программа
- EdTech conference agenda speakers
- саммит онлайн‑образования расписание треков
- education technology expo program keynote
- выставка образовательных технологий список спикеров
- online course business conference agenda
- маркетинг онлайн‑школ конференция доклады
- LMS platform summit schedule
- конференция продюсеров онлайн‑курсов повестка
- edtech forum recordings playlist
Разнообразие источников снижает риск систематической ошибки. Официальные страницы дают точные названия и расписание. Видеозаписи подтверждают факт проведения и состав спикеров. Пресса и агрегаторы помогают отсечь отмененные события и уточнить локацию и даты. Профессиональные профили спикеров позволяют уточнить должности на момент выступления, если в программе указаны устаревшие роли.
Структура карточки мероприятия
Карточка мероприятия — это формальная схема данных с четко типизированными полями. Цель схемы — обеспечить сопоставимость изданий по годам и форматам, а также минимизировать ручную нормализацию при аналитике. Обязательная часть карточки покрывает идентификацию, базовую фактологию и верифицируемые атрибуты. Дополнительная часть хранит расширенные метрики и контекст.Схема реализуется в виде JSON/CSV с фиксированными справочниками и перечислениями. Каждое поле имеет краткое определение, тип, обязательность и правила заполнения. Для полей с ограниченным набором значений используем справочники, которые версионируются вместе с датасетом. Это важно: изменение справочника «форматы» или «типы организаторов» без версии затруднит воспроизводимость прошлых выгрузок.
В карточке недопустимы произвольные комментарии внутри данных. Любая пояснительная информация вносится в поля audit_note и evidence_note, где допустим свободный текст. Для ссылок на артефакты храним контрольные идентификаторы и датированные отметки снимков, но не публикуем внешние URL в итоговом тексте. Это соблюдает правило разделения итоговой публикации и пакета источников.
Структура карточки едина для всех лет. Новые поля добавляются через минорную версию схемы и не ломают обратную совместимость. Удаление или переименование полей допускается только с мажорной версией и конвертером для старых наборов. Такие изменения сопровождаются миграционными заметками, чтобы аналитические скрипты могли корректно интерпретировать данные прошлых лет.
Обязательные поля (название, организатор, даты, локация, формат)
Обязательные поля обеспечивают уникальную идентификацию и базовый контекст. Они заполняются всегда, иначе карточка не попадает в основной корпус. Ниже приводим спецификацию обязательных полей с краткими определениями и правилами заполнения.| Поле | Определение | Тип | Обязательность | Правила |
|---|---|---|---|---|
| id | Уникальный идентификатор издания события | string | да | Формат event_slug_YYYY; только латиница и «_» |
| title | Официальное название издания | string | да | Точное соответствие программе, без маркетинговых добавок |
| organizer_name | Название организатора | string | да | Юридическое или публичное имя, как в программе |
| organizer_type | Тип организатора | enum | да | «компания», «платформа», «медиа», «вуз», «ассоциация», «орган власти», «экосистема» |
| start_date | Дата начала | date | да | ГГГГ‑ММ‑ДД; сверка по 2 источникам или программе |
| end_date | Дата окончания | date | да | ГГГГ‑ММ‑ДД; если один день — равно start_date |
| city | Город проведения (или «онлайн») | string | да | Транслитерация не используется; язык оригинала |
| country | Страна | string | да | Полное название на языке программы |
| venue | Площадка | string | да | Как в программе или пост‑релизе; для онлайн — «n/a» |
| format | Формат проведения | enum | да | «офлайн», «онлайн», «гибрид» |
| program_url_note | Примечание к источнику программы | string | да | Краткое описание источника без URL |
| evidence_snapshot_date | Дата снимка источника | date | да | Если использован веб‑архив; иначе NA |
| language | Язык программы | enum | да | «ru», «en», «другой» с уточнением в note |
| tracks_count | Число треков | integer | да | Подсчет по программе; минимум 1 |
| talks_count | Число докладов/слотов | integer | да | Подсчет по программе |
| video_availability | Наличие записей | enum | да | «полные», «частичные», «нет», «ожидаются» |
Эти поля закрывают основные вопросы: что за событие, кто организатор, когда и где прошло, в каком формате, и насколько верифицируемы материалы. Для city и country используем точно те формы, что встречаются в программе или пост‑релизе. Если указаны несколько площадок, выбираем основную и уточняем в audit_note. Для «гибридного» формата обязательно фиксируем признак онлайн‑трансляции и офлайн‑локацию.
Правила подсчета tracks_count и talks_count стандартизированы. Треком считаем последовательность слотов с общей тематикой в отдельном зале или поток онлайн. Слоты — это доклады, панели, fireside chats, мастер‑классы внутри программы. Мы не учитываем coffee‑break, регистрацию и закрытие. Если программа дробит один доклад на часть 1/2, считаем это одним слотом, если из описания следует единство темы и спикера.
Для video_availability важно не путать «анонсы записей» и фактическое наличие. «Ожидаются» ставим только при явном обещании организатора и не позже 90 дней от даты окончания события — после этого статусы пересматриваем и ставим «нет», если записи не появились. Это дисциплинирует обновления и точность аналитики по доступности контента.
Дополнительные поля (аудитория, треки, посещаемость, запись)
Дополнительные поля раскрывают детали структуры программы, аудитории и охвата. Они не обязательны для включения, но повышают качество анализа. Если в источниках нет надежного подтверждения, поле оставляем пустым и фиксируем причину в audit_note. Любые оценочные числа маркируем как «оценка» с указанием метода.| Поле | Определение | Тип | Обязательность | Правила |
|---|---|---|---|---|
| audience_profile | Профиль аудитории | enum | нет | «основатели онлайн‑школ», «методисты», «маркетологи», «платформы/партнеры», «инвесторы», «смешанная» |
| attendance_claimed | Заявленная посещаемость | integer | нет | Только из официальных объявлений; указывать «оценка», если разнится |
| attendance_verified | Подтвержденная посещаемость | integer | нет | По отчетам, фото‑/видео‑материалам, данным площадки |
| tracks | Список треков | array | нет | Структура: код, название, краткое описание |
| recording_links_note | Примечание к записям | string | нет | Описание источника записей без URL |
| sponsors_note | Партнеры/спонсоры (примечания) | string | нет | Только подтвержденные статусы участия |
| topics_taxonomy | Коды тематик | array | нет | Справочник тематик; множественный выбор |
| lms_focus | Признак фокуса на платформах | boolean | нет | true, если выделен отдельный трек по платформам |
| marketing_focus | Признак фокуса на маркетинге | boolean | нет | true, если трек по маркетингу онлайн‑школ |
| ticketing_model | Модель билетов | enum | нет | «free», «paid», «free+paid», «invite‑only» |
| cta_post_event | Пост‑ивент активности | enum | нет | «записи», «воркшопы», «курс‑апселл», «сообщество», «нет» |
Поля аудитории и посещаемости требуют особой дисциплины. Мы разделяем заявленную и подтвержденную посещаемость: первое — цифры из анонсов или пресс‑релизов, второе — оценки по пост‑релизам, отчётам площадок и материалам с места. Разница между ними — частый случай. Если применяем оценочную методику (например, по заполненности зала), кратко описываем подход в audit_note, не подменяя им числовое поле.
Расширенные поля по фокусу треков (lms_focus, marketing_focus) помогают оценивать баланс повестки: технологические аспекты платформ (LMS) против маркетинга и продаж онлайн‑школ. Тематическое кодирование в topics_taxonomy строится на закрытом справочнике: продукт, методология, маркетинг, продажи, удержание, аналитика, платформа, правовые вопросы, международная экспансия. Справочник версионируется и хранит обратную совместимость меток с годами.
Примечание по записям (recording_links_note) хранит только факт наличия и тип площадки, без внешних ссылок. Это соблюдает правило редакции — итоговый текст и пакет источников передаются отдельно. Для активаций после события (cta_post_event) фиксируем доминирующий тип: публикация записей, приглашение на воркшопы, предложение курса как апсейла или перевод аудитории в сообщество. В контексте последующего анализа такие поля помогают увидеть, как события влияют на повторные продажи из базы.
При наличии данных о билетной модели (ticketing_model) мы не пытаемся реконструировать прайсы. Достаточно бинарных признаков платности и приглашений. Если формат «invite‑only», карточка сохраняется только при наличии публичной программы и записей. Отсутствие открытой регистрации не исключает событие автоматически, если выполнены остальные критерии.
Верификация и контроль качества
Контроль качества строится на двух уровнях: валидация структуры данных и подтверждение содержательных фактов. Первый уровень проверяет соответствие схемам и справочникам: типы, обязательность, допустимые значения. Второй уровень сверяет данные с источниками: программы, записи, пресс‑материалы и агрегаторы. Мы избегаем «склеек» разных лет или выпусков одного бренда и всегда фиксируем идентификатор издания.Каждое изменение карточки проходит две проверки: первичную — составителем, и вторичную — редактором данных. Для спорных полей добавляем evidence_note с кратким описанием источника и причин расхождения. Если расхождение не снимается, карточка получает статус «needs_review» и исключается из сводных метрик до закрытия вопроса. Это гарантирует чистоту аналитических выборок.
Спикеры и темы: как фиксировать и проверять
Под «спикером» понимается физическое лицо, выступающее с докладом или в составе панели. Под «темой» — заголовок слота, как он указан в программе, без адаптации под редакционные стандарты. В карточке мы работаем не на уровне свободного текста, а на уровне структурированных сущностей: слот программы, спикер, роль, организация, должность, язык выступления, трек.Верификация спикеров и тем проводится в два этапа. Этап 1 — сверка с официальной программой: фиксируем все слоты, их названия, роли (keynote, доклад, панель), расписание и привязку к трекам. Этап 2 — сверка по видеозаписям или пост‑релизам: подтверждаем факт выступления, соответствие заголовка и состав участников. Если в записи название отличается от анонсного, приоритет у факта, но анонсная версия сохраняется в альтернативном поле title_announced.
Должности и аффилиации спикеров фиксируем на момент выступления. Если программа содержит устаревшую должность, а профессиональный профиль спикера на дату события другой, в карточке сохраняем формулировку программы, а актуальную на дату выступления добавляем в поле position_verified с пометкой источника в evidence_note. Такой подход сохраняет соответствие артефактам и при этом повышает точность поиска по организациям.
Для панелей и круглых столов состав участников проверяем по видео и фотографиям. Если один или несколько участников заменены, изменение отражаем в notes на уровне слота, а в списке спикеров сохраняем фактически выступивших. Незаполненные роли модераторов мы не реконструируем по догадкам — если явных подтверждений нет, оставляем поле пустым.
Тематическое кодирование выполняется после верификации фактов. Сначала фиксируем «как есть», затем присваиваем коды из topics_taxonomy. Один слот может иметь несколько тематических кодов, но не больше трех: это ограничение снижает размывание аналитики и удерживает кодировку на уровне основных акцентов. Для кейнотов допускается более обобщенный набор кодов, для воркшопов — более прикладной.
Типичные проблемы — переименования докладов, отмены слотов и переносы. В таких случаях мы сохраняем оба состояния: анонс и факт. В полях slot_status используем значения «проведен», «отменен», «заменен», «перенесен». Если слот перенесен на другое издание события, перекрестные ссылки в данных не создаем, а оставляем пояснение в notes. Для видео‑плейлистов сверяем порядок и количество роликов с программой, чтобы исключить пропуски.
Для кейсов, где нет видеозаписей, допускаем подтверждение по стенограммам или фотоматериалам из официальных источников. В обоих случаях сохраняем описательный evidence_note. Любая верификация через личные страницы спикеров в соцсетях должна подкрепляться вторым независимым источником. Исключение — если речь о цитировании официального анонса организатора, дублированного спикером без изменений.
Даты, названия, организаторы: сверка и версионирование
Даты сверяем по двум источникам минимум. Приоритет у официальной программы и пост‑релиза. Если даты на сайте и в пресс‑материале расходятся, проверяем видеозаписи по дате публикации и по указанной дате проведения в описании. Для гибридных форматов возможна разная дата офлайн‑части и онлайн‑трансляции — в карточке храним обе: start_date/offline_date и online_date, если расхождение превышает один день.Названия событий сохраняем точно в той форме, в какой они указаны в программе. Если существует официальная англоязычная версия, добавляем поле title_en. Если в разных источниках используются варианты названия, приоритет у программы и визуальной айдентики события (афиши, заставки в видео). Сокращения без подтверждения в официальных материалах не используем.
Организатора фиксируем по публичному названию. Если организатор действует через дочернюю структуру, указываем фактического оператора события, но в поле organizer_group добавляем материнскую организацию. Для партнерских событий с несколькими организаторами сохраняем всех, разделяя роли «совместно с» и «при поддержке». Роль партнера‑хостера площадки не подменяет организатора.
Версионирование — обязательная часть методики. Каждая правка карточки сопровождается bump версии датасета и коротким changelog. Используем семантическую схему: MAJOR.MINOR.PATCH. PATCH — исправления без изменения схемы (опечатки, уточнения дат). MINOR — добавлены поля, обновлены записи, расширены справочники. MAJOR — изменена схема полей или логика кодирования. Для каждой версии храним freeze‑выгрузку и контрольные суммы.
Для 2026 года все упоминания будущих дат и анонсов маркируем явно: поле forecast_flag=true и раздел примечаний с описанием источника анонса. В итоговых расчетах такие карточки исключаются из ретроспективной статистики, но остаются в отдельной выборке прогнозов. Это соблюдает правило отделения фактов от анонсов и снимает риск искажения трендов.
Если обнаруживается расхождение между программой и записью, решение принимаем по правилу приоритета факта: фиксация «как проведено», с сохранением анонсной версии в дополнительных полях. При обнаружении существенных расхождений в датах или локациях карточка помечается как «reconciled» с указанием версии, в которой исправление внесено. Любой сторонний сигнал (публикация в прессе, агрегатор) без первичного подтверждения не инициирует исправление.
📉Комментарий:
При изменении таймлайна из‑за форс‑мажора добавляйте отдельное поле incident_note — это помогает объяснить разрывы в статистике без перегрузки основной карточки.
Рабочий процесс и артефакты
Рабочий процесс разделен на этапы: поиск, первичная фильтрация, формирование черновых карточек, первичная верификация, вторичная верификация, кодирование тематик, контроль качества и выпуск версии датасета. На каждом этапе сохраняются артефакты: список кандидатов, чек‑лист верификации, протокол расхождений и журнал изменений. Такая структура уменьшает потери информации и ускоряет повторные проходы.Этап поиска начинается с построения запросов и сборки источников по категориям: первичные, вторичные, подтверждающие. Результаты вносятся в таблицу кандидатов с признаками релевантности и уровня доступности материалов. На этом этапе важно фиксировать не только явные попадания, но и пограничные случаи — они пригодятся при расширении рамок исследования. По завершении поиск замораживается, чтобы не размывать выборку во время проверки.
Именование файлов и версии наборов данных
Именование файлов подчинено схеме, которая позволяет понять содержимое без открытия. Для freeze‑выгрузок используем паттерн: dataset_edtech_events_{region}_{YYYYMMDD}_v{MAJOR.MINOR.PATCH}.{csv|json}. Для служебных журналов: changelog_{YYYYMMDD}.md, qa_report_{YYYYMMDD}.md, discrepancies_{YYYYMMDD}.csv, sources_bundle_{YYYYMMDD}.zip. Все даты — в UTC, чтобы избежать неоднозначности при международной географии.Версии наборов данных сопровождаются контрольными суммами и списком затронутых карточек. В changelog фиксируем: краткое описание изменений, диапазон карточек, причину правки и ответственного. Если правки массовые (например, пересчет tracks_count по измененным правилам), добавляем миграционную заметку с алгоритмом перерасчета. Это позволяет воспроизвести результат в независимой среде и сопоставить метрики между версиями.
Для облегчения последующего анализа формируем инкрементальные пакеты: diff‑файлы между версиями, где отражены добавления, удаления и изменения на уровне полей. Такой подход ускоряет валидацию и интеграцию с аналитическими дашбордами. При подготовке сводных обзоров редакции мы используем эти пакеты как источник правок, не затрагивая базовый freeze.
Журналы QA структурированы по категориям: структура данных, фактология, кодирование тематик, соответствие справочникам, консистентность дат и локаций, наличие записей. Для каждой карточки указываем статус проверки и ссылку на артефакты. В операционном процессе полезно подключать дашборды для руководителя, чтобы отслеживать прогресс по стадиям и выделять блокеры: дефицит источников, спорные статусы слотов, задержки с публикацией записей.
Если исследование дополняется транзакционными данными (например, динамика публикаций в соцсетях или активность каналов), мы храним их в отдельном слое и не смешиваем с карточками событий. Любые производные метрики маркируются как «расчетные» и имеют собственный словарь. Это разграничение защищает от неосознанного использования прокси‑показателей вместо фактологии и упрощает ревизии.
Форматы передачи материалов в редакцию
Передача материалов включает два логических пакета: итоговый текст и пакет источников. Итоговый текст — это выверенная аналитическая часть без внешних ссылок, с отсылками к артефактам только через примечания. Пакет источников — архив с программами, снимками веб‑архива, выписками из пресс‑материалов, чек‑листами верификации и протоколами расхождений. Пакеты синхронизируются по идентификатору версии датасета.Форматы данных: основная выгрузка в CSV/JSON, справочники — в CSV, журналы — в Markdown/CSV, визуальные артефакты — в изображениях и PDF. Для записей и крупных файлов храним контрольные идентификаторы и датированные примечания, но не публикуем прямые ссылки в тексте. При необходимости редакция запрашивает доступ к пакету источников отдельно. Это соблюдает принцип отделения аналитики от носителей доказательств.
К каждому выпуску формируем README c описанием полей, версиями справочников, известными ограничениями и списком нерешенных вопросов. Для автоматизации импорта полезны заранее подготовленные схемы валидации и тестовые выборки. Если редакции требуется сверка по метрикам охвата, мы прикладываем отдельную записку с методикой оценки и отмечаем, какие числа являются оценочными.
В процессе согласования удобно использовать отчёты по трафику для контроля публикаций и сроков выхода записей, если это влияет на дедлайны верификации. Для редакционных рассылок и коммуникаций со спикерами допустимо подключать CRM‑маркетинг по базе, но эти контакты не смешиваются с исследовательскими артефактами. Любые игровые механики промо, например игровые акции, относятся к операционному маркетингу и не отражаются в карточках, кроме случаев, когда они становятся частью программы.
При передаче важно сохранить привязку ко времени. Все файлы в пакете содержат штамп сборки и идентификатор версии. Если пакет пересобран для правок редакции, увеличиваем PATCH‑версию и оставляем заметку с перечислением исправлений. Для крупных обновлений, затрагивающих схему полей или справочники, выпускаем MINOR или MAJOR версии с отдельной миграционной инструкцией.
Выводы
Методика задает воспроизводимые правила отбора и проверки событий для рынка онлайн‑школ. Основанием включения служат профиль повестки, масштаб и регулярность, подтвержденные программой и независимыми источниками. Карточка мероприятия имеет единый формат обязательных и дополнительных полей, что обеспечивает сопоставимость данных по годам и форматам. Верификация спикеров и тем проводится в два этапа, с приоритетом первичных материалов и видеозаписей.Версионирование данных — неотъемлемая часть качества. Каждое исправление сопровождается журналом изменений, а спорные случаи получают статус для повторной проверки. Разделение итогового текста и пакета источников защищает итоговую публикацию от внешних ссылок и сохраняет доказательную базу отдельно. Такая дисциплина превращает набор карточек в надежный аналитический ресурс, который корректно масштабируется и выдерживает повторные аудиты.
📣Присоединяйтесь к Telegram-каналу
«База — не таблица имён, а живой актив». В постах — как сегментировать клиентов, оживить их и выстроить дожимы, чтобы они покупали снова.
авторизуйтесь