Patrick Bass Area: mobieusKnow (audit p6) · Surface: /know admin/analytics, GET /api/v1/know/pages · Dimension: improve-existing · Severity: major
Per-article view counts, search-term logs (especially zero-result searches), and a 'top articles / trending' dashboard are core KB analytics in Zendesk, Help Scout, Intercom, and Notion. They tell the community manager what members actually read and what they search for and can't find — the raw material for deciding what to write next. mobieusKnow tracks nothing: no views, no search log, no zero-result capture. The V1 API was clearly designed expecting a view_count field, which signals the feature was intended but never built; that intent should be completed so the metric exists and the API stops referencing a phantom column.
Evidence
knowledge_pages has no view_count column (schema.sql:3424-3441: id, slug, title, current_revision_id, tags, created_by, created_at, updated_at, deleted_at, deleted_by). KnowledgeController::show() never increments any view counter. Yet the V1 API queries and returns kp.view_count in three places — pagesList SELECT (KnowledgeApiController.php:50), search SELECT (line 246), and shapePage (line 270: `'view_count' => (int) ($p['view_count'] ?? 0)`) — and the API even sorts search results `ORDER BY kp.view_count DESC` (line 252), a column that does not exist on the real table. So there is both a missing feature (no analytics) and a broken API surface that presumes it.Suggested fix. Add view_count to knowledge_pages (plus a lightweight knowledge_search_log for queries + result counts), increment views in show(), and build a small analytics panel: top pages by views, pages with low helpfulness, and top zero-result searches. This also makes the existing API view_count references correct instead of always returning 0.
Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.
Patrick Bass
@mobieus
