SavePearlHarbor

Управление контентом от одной базы до целой системы

—

от автора

admin

Управление контентом: от одной базы до целой системы

Привет, Хабр! В этой статье хочу показать, что управление процессом создания контента, его публикации и отчётности может быть не коробочным решением или тем, что часто видно в обычной таблице, а гибкой системой, собранной на базе платформ-конструкторов типа Notion и Buildin.ai.

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

Именно поэтому стандартный подход к управлению контент-планом и системой управления производством лежит где-то между простой таблицей в Excel или коробочным решением со стандартным набором CMS-инструментов.

Но это неминуемо приводит к жёстким фрустрациям:

  • в таблицу нельзя вставить всё, что хочется;

  • в таблице нельзя создавать связи между записями;

  • в коробках всегда чувствуешь себя зажатым логикой тех, кто их делал;

  • в коробках всегда приходится искать ход конём, так как они никогда не отражают именно твой бизнес-процесс со всеми его нюансами.

Открытость и гибкость архитектуры

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

Не нужно бояться создавать свою систему

Если у вас есть возможность хотя бы попробовать расширить границы своей системы управления, то стоит попробовать. На мой экспертный взгляд, лучших решения два: Notion — если вас не связывают санкционные ограничения, и Buildin.ai — как его максимально корректный аналог с примерно идентичным UX.

С чего начать?

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

Такую систему я создаю в настоящий момент. От неё мне нужно удобно:

  • управлять темами материалов;

  • создавать план публикаций;

  • фиксировать каналы коммуникации и сегменты рынка;

  • размещать черновики и уже опубликованные материалы;

  • хранить сопутствующие материалы: обложки, скриншоты;

  • фиксировать реакции, на которые нужно отреагировать;

  • непосредственно работать с карточками материалов относительно их состояния:

    • по статусу;

    • по датам;

    • по типу;

    • по назначению и т.д.

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

Помимо размещённых материалов, база данных имеет важную, хотя и не уникальную особенность — специализированные виды со специально отфильтрованным контентом:

  • все;

  • 🧠 по темам — то, что видно на скриншоте;

  • 📅 по месяцам;

  • 😎 мои — темы и материалы, придуманные мной, а не AI;

  • ✨ темы;

  • ✅ видео — уже опубликованные видео;

  • ✅ статьи — уже опубликованные статьи;

  • ✅ публикации — все опубликованные материалы в формате шкалы времени.

Что сейчас внутри записи?

Запись может быть одновременно чем угодно:

  • темой;

  • статьёй;

  • постом в паблике;

  • видео.

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

Архитектура свойств и их назначение

  • результат — формула, автоматически показывает факт публикации. Пока её нет — ⏳, после появления ссылки на ресурс — ✅ опубликовано, если тип Тема — показывает ее статус. 

if(contains(prop("Тип"), "✨ Тема"), prop("Статус"), if(prop("Дата публикации"), "✅ опубликовано", "⏳"))

  • дата план — свойство даты, показывает примерный план публикации материала;

  • дата факт — свойство даты, показывает фактическую дату публикации;

  • статус — свойство выбора значения, оно нужно для отражения состояния публикации. В моём случае они пока такие:

  • месяц и неделя — свойства выбора, показывают месяц и неделю для удобства фильтрации по этим признакам среди всех материалов;

  • тип — свойство выбора, показывает тип публикации, необходимый для фильтрации материалов по типам;

  • идея — свойство выбора, необходимо для фильтрации моих материалов и материалов, придуманных AI;

  • цель — текстовое свойство, необходимо для уточнения цели публикации и задачи, которую она решает;

  • тема — свойство типа self-relation, необходимо для связи темы с материалами и наоборот;

  • публикации — свойство типа self-relation, это обратный relation от свойства «тема», включает в себя публикации по теме;

  • ценность — свойство выбора, полезно для валидации ценности идей;

  • краткое описание — текстовое поле, где хранится описание к материалу, например к видеоролику;

  • обложка — свойство файла, позволяет размещать файл обложки материала;

  • площадка — свойство-формула, показывает название площадки исходя из того, в каком именно свойстве размещена ссылка на публикацию.

if(empty(prop("VK Video")), "", "VK Video") +if(empty(prop("YouTube")), "", if(empty(prop("VK Video")), "YouTube", " • YouTube")) +if(empty(prop("RuTube")), "", if(empty(prop("VK Video")) and empty(prop("YouTube")), "RuTube", " • RuTube")) +if(empty(prop("VC")), "", if(empty(prop("VK Video")) and empty(prop("YouTube")) and empty(prop("RuTube")), "VC", " • VC")) +if(empty(prop("Hubr")), "", if(empty(prop("VK Video")) and empty(prop("YouTube")) and empty(prop("RuTube")) and empty(prop("VC")), "Habr", " • Habr"))

  • файл материала — свойство файла, включает в себя файл с опубликованным материалом;

  • YouTube и ещё масса других свойств, каждое — под отдельную площадку, где публикуется материал.

Здесь можно спросить, почему для каждой площадки нужно отдельное свойство, ведь можно иметь одно свойство, например «ссылка», и одно свойство с названием площадки. Да, такое решение тоже возможно, но если один и тот же материал будет размещён на разных площадках, нужно создавать разные записи в базе.

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

Но, учитывая, что эту часть я ещё только буду реализовывать в структуре системы управления контентом, у меня ещё будет время додумать эту архитектуру.

А как вы поступаете в подобном случае? Будет полезно ваше мнение.

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

Что планирую дальше?

  1. Создать базу статистики для учёта охвата материала по разным временным метрикам.

  2. Создать базу реакций для работы с обратной связью.

  3. Создать базу задач для управления задачами в рамках медиапроцесса.

  4. Создать базу площадок, чтобы иметь по ним отдельную статистику.

Может быть, что-то посоветуете ещё — буду рад вашим идеям в комментариях.

ссылка на оригинал статьи https://habr.com/ru/articles/1054960/