Chatbase trains a chatbot on uploaded documents and exposes it through an embed snippet plus a webhook. The full conversation analytics live inside the Chatbase dashboard, which is fine for product owners who live there. The WordPress side still receives useful signals: webhook events posted back per session, lead capture rows when a chat collects an email, and the embed configuration per page or post.

SleekView Charts reads those WordPress-side rows directly. Whatever the WordPress integration plugin (Chatbase widget, custom shortcode handler or a generic webhook receiver like WP Webhooks) stores in postmeta, options or a custom table is fair game.

A Number card surfaces webhook events received this month. A Pie splits events across event types (chat_started, lead_captured, escalation). A Bar groups events per entry page so editors see where Chatbase is doing real work. An Area trends events per day so a sudden drop, often caused by an embed misconfiguration or domain change, becomes visible the day it happens.

Chatbase's product dashboard is the right place to inspect conversations, train the bot and review per-document performance. It is not the right place to answer WordPress-specific questions, like which page hosts the widget that produces most leads, whether the WordPress webhook receiver is still receiving events at the expected rate, or how Chatbase volume compares with other lead surfaces on the same site. A KPI of monthly webhook events, a donut of event types, a bar of events per entry page and a daily area trend turn the WordPress side of the integration into its own dashboard.

Two dashboards reading the right side of the integration each, instead of one dashboard pretending it covers both.