Indirectly. The full per-row chain is too granular for a chart axis. SleekView Charts groups by chain prefix (first N question-answer pairs), which is the right granularity for funnel analysis. Adjust N to widen or narrow the prefix-based grouping.

Each card runs an aggregation against the takings storage at render time. Heavy aggregations are cached per view for a configurable duration; default lists stay responsive because the queries use standard WP table indexes on submitted_date and quiz_id.

Yes. The dashboard filter scopes every card to the chosen quiz_id. Useful for per-quiz funnel reviews, since result distribution and path-prefix counts only make operational sense within one quiz at a time for most cases.

Yes. Chained Quiz uses standard WP storage. Multi-language sites running WPML or Polylang see takings tied to the language version of the quiz; SleekView Charts reads them as-is and lets you filter by language column where the plugin records it.

Yes. Build a Number card with a derived column: count of takings where email is non-empty divided by total takings, multiplied by 100. The agent UI offers derived-column composition for the common funnel ratios.

Yes. A Pie or Bar grouped by result label shows distribution across the catalogue. Result labels defined in the quiz but absent from any taking show as zero-count, which surfaces unreachable branches immediately.

Yes for reasonable analytical windows. Date-scoped charts stay fast on installations with millions of takings because the date index does the heavy lifting. All-time aggregates without a date filter are heavier and opt-in per view.

No. The chart view focuses on the read side. Tagging takings (CRM-imported, follow-up-scheduled) happens on the table view, and the next chart refresh reflects those tags in any filters that reference them.