Розробка бази знань для мобільного додатку

Уявіть: додаток виріс до 50+ екранів, підтримка тоне в однотипних питаннях — 40% звернень стосуються одного й того ж. Документація розкидана по Google Docs, Confluence та Jira. Клієнти йдуть, бо не можуть знайти відповідь за 2 хвилини. База знань (Knowledge Base) вирішує це, але її реалізація — не просто пошук по сторінках. Ми розповімо, як спроектувати та впровадити мобільну базу знань, яка працюватиме офлайн, синхронізуватиметься з CMS, забезпечить миттєвий пошук FTS5 та дасть аналітику. Наш досвід — понад 10 років інженерної практики, тому ми гарантуємо стабільну синхронізацію та швидкий пошук.

Як влаштована архітектура мобільної бази знань?

Джерела контенту та синхронізація

Найбільш універсальний підхід — власна або headless CMS (Contentful, Strapi, Sanity) з REST/GraphQL API. Мобільний клієнт завантажує статті при першому запуску та при оновленні, зберігає в локальній БД. Синхронізація за updatedAt: при кожному запуску завантажуємо лише змінені статті з моменту останнього sync-timestamp. Якщо мережа недоступна, зміни накопичуються та застосовуються при наступному підключенні. Конфлікти вирішуються за принципом «останній виграє». Зазвичай це 10–20 КБ даних на оновлення, що займає менше секунди при стабільному з'єднанні.

// Android: Room-схема для статей бази знань @Entity(tableName = "kb_articles") data class KbArticle( @PrimaryKey val id: String, val title: String, val content: String, // Markdown або HTML val categoryId: String, val updatedAt: Long, val searchIndex: String // нормалізований текст для FTS ) 

Інтеграція з Zendesk Help Center / Freshdesk Solutions

Якщо підтримка вже на Zendesk — Help Center API надає статті напряму. Для кастомного дизайну використовуємо Zendesk Guide API: GET /api/v2/help_center/articles.json. Response містить body в HTML — рендеримо через WebView з кастомним CSS, що відповідає дизайн-системі додатку.

Чому локальний пошук FTS кращий за серверний?

Пошук по тисячі статей на сервері при кожному запиті — зайвий round-trip та залежність від мережі. Для мобільного додатку краще локальний Full-Text Search (FTS5). Він працює миттєво, без інтернету, і навантажує лише пристрій.

Android — Room FTS4:

@Fts4(contentEntity = KbArticle::class) @Entity(tableName = "kb_articles_fts") data class KbArticleFts( val title: String, val searchIndex: String ) @Dao interface KbSearchDao { @Query("SELECT * FROM kb_articles WHERE id IN " + "(SELECT rowid FROM kb_articles_fts WHERE kb_articles_fts MATCH :query)") suspend fun search(query: String): List<KbArticle> } 

iOS — SQLite з FTS5 через GRDB.swift:

try db.create(virtualTable: "articles_fts", using: FTS5()) { t in t.column("title") t.column("body") t.tokenizer = .unicode61() } 

Як забезпечити офлайн-доступ та аналітику?

Рендеринг Markdown/HTML

Статті часто зберігаються в Markdown. Ми обираємо нативні бібліотеки: Markwon для Android та Down для iOS. Вони підтримують таблиці, code blocks з підсвічуванням синтаксису та зображення — достатньо для технічної документації. WebView дає повний HTML/CSS, але повільніший у навігації. Для базового Markdown на iOS 15+ можна використовувати AttributedString без залежностей.

Офлайн-доступ

База знань повинна працювати без інтернету. Всі статті після першого завантаження зберігаються локально. Зображення кешуються через Kingfisher (iOS) або Coil (Android) з налаштуванням максимального розміру кешу — 200 МБ. Оновлюємо дані лише при появі мережі.

Аналітика та зворотний зв'язок

Кнопка оцінки корисності статті — простий механізм зворотного зв'язку. Відправляємо подію з article_id та helpful: true/false в Firebase Analytics.

Analytics.logEvent("kb_article_feedback", parameters: [ "article_id": article.id, "helpful": isHelpful ? "yes" : "no", "time_spent_seconds": Int(Date().timeIntervalSince(openedAt)) ]) 

time_spent_seconds дає додатковий сигнал: якщо користувач прочитав за 3 секунди і натиснув «не корисно» — стаття не на тему. Якщо провів 5 хвилин і натиснув «корисно» — контент глибокий та релевантний. Така аналітика допомагає доопрацьовувати документацію.

Що входить у роботу?

• Документація: схема БД, опис API, інструкція з оновлення контенту.
• Доступи: тестові акаунти до CMS, App Store Connect / Google Play Console.
• Вихідний код: репозиторій з модулем бази знань, покриття тестами 80%+.
• Навчання: воркшоп для команди підтримки з наповнення контенту.
• Підтримка: 2 тижні безкоштовного супроводу після релізу.

Етапи розробки та терміни

Вартість розробки розраховується індивідуально після аудиту. Економія часу користувачів на пошук інформації окупає витрати протягом першого місяця. Готові оцінити ваш проєкт — зв'яжіться з нами для консультації. Замовте розробку бази знань під ключ і отримайте стабільне рішення, яке покращить користувацький досвід.