Business Dashboard and Reporting FAQ: Metrics, Design, and Tooling

A business dashboard is a visual display of the most important information needed to achieve one or more objectives, consolidated and arranged on a single screen so decision-makers can monitor performance at a glance. Unlike a data dump — which merely outputs raw tables, logs, or unstructured datasets — a well-designed dashboard provides curated, pre-analyzed insights that connect directly to business outcomes. Dashboards turn data into decisions; data dumps turn data into confusion. This dashboard reporting FAQ answers the most common questions teams ask about metrics, design, and tooling in plain, direct language. That distinction between insight and noise is the foundation of everything that follows: every metric choice, every design decision, and every technology investment traces back to whether your dashboard helps someone make a better decision, faster.

In July 2026, dashboard reporting has matured into the operational backbone of modern enterprises. According to Gartner's 2025 data and analytics forecast, organizations that invest in modern business intelligence (BI) and dashboard infrastructure see measurably faster time-to-decision and stronger alignment between strategy and execution. Yet for all their ubiquity, too many dashboards fail: cluttered with vanity metrics, disconnected from business goals, or ignored entirely by the people they were built for. Getting dashboard reporting right demands careful thinking about metrics, design, technology, and governance — not just connecting a chart to a database.

This FAQ covers everything from foundational concepts to advanced implementation strategies. Whether you are building your first KPI dashboard, evaluating self-service BI tools versus embedded analytics, or trying to fix a reporting program that has spiraled out of control, you will find practical, actionable answers organized by theme. Each section addresses the questions our readers ask most frequently, grounded in real-world experience and industry research. The goal is not to catalog every feature of every tool but to equip you with the principles that separate dashboards that drive action from those that gather dust.

Getting Started: Dashboard Reporting Fundamentals

What Is a Business Dashboard and How Does It Differ From a Data Dump?

A business dashboard is a consolidated, visual interface that displays key performance indicators (KPIs) and critical business reporting metrics on a single screen, enabling users to monitor organizational health and make informed decisions at a glance. A data dump, by contrast, is an unstructured or semi-structured output of raw data — think of a CSV export, a SQL query result pasted into a spreadsheet, or an unfiltered log file. The fundamental difference lies in purpose: dashboards are built for decision-making, while data dumps require the viewer to do the work of interpreting, cleaning, and contextualizing before any insight emerges.

The table below summarizes the key distinctions:

Aspect	Business Dashboard	Data Dump
Purpose	Drive decisions and action	Store or transmit raw information
Presentation	Visual, curated, single-screen	Tabular, exhaustive, multi-page
Audience	Executives, managers, frontline operators	Analysts, data engineers, power users
Time to Insight	Seconds (glanceable)	Minutes to hours (requires analysis)
Data Volume	Aggregated and summarized	Granular and unbounded

A well-constructed dashboard answers a specific business question — "Are we on track to hit quarterly revenue?" or "Which support channels have the longest resolution times?" A data dump simply says, "Here is everything; figure it out yourself." Organizations that confuse the two often end up with dashboard sprawl: dozens of screens that look impressive but fail to drive any action because nobody can identify what matters.

Why Do Modern Organizations Need Dashboard Reporting?

In a business environment where speed of decision-making is a competitive advantage, dashboard reporting provides the real-time or near-real-time visibility that spreadsheets and static reports cannot match. According to McKinsey's research on data-driven organizations, companies that embed analytics into their operational workflows outperform peers on revenue growth, customer retention, and operational efficiency by a significant margin. The era of waiting for the monthly finance packet to understand business performance is over — in 2026, leaders expect answers in seconds, not weeks.

The benefits of effective dashboard reporting extend across the entire organization:

• Alignment: When every team sees the same KPIs rendered from the same data sources, priorities stay synchronized across departments and conflicting narratives disappear.
• Agility: Real-time visibility into critical metrics lets teams respond to anomalies — a sudden drop in conversion rate, a spike in support ticket volume — before they escalate into full-blown crises.
• Accountability: Transparent, accessible dashboards create ownership for results. When performance metrics are visible to peers and leadership alike, accountability becomes baked into the culture.
• Efficiency: Automated dashboard reporting eliminates the manual, error-prone work of compiling weekly or monthly slide decks, freeing analysts to focus on interpretation rather than data wrangling.
• Data literacy: Well-designed dashboards teach people to think analytically by making data accessible and interpretable, gradually raising the organization's collective analytical capability.

The most successful organizations treat dashboards not as IT projects but as communication tools. A dashboard that nobody looks at, no matter how technically sophisticated, is a failure. The goal is adoption, clarity, and action — not just pixels on a screen.

Metrics Design and KPI Selection for Business Dashboards

How Do I Choose the Right Metrics for KPI Dashboards?

Choosing the right KPIs begins with a clear articulation of your business objectives. Every metric on a dashboard should trace back to a specific strategic goal. If you cannot draw a direct line from a number to a priority that the leadership team cares about, cut it. A widely used starting point is the SMART framework — metrics should be Specific, Measurable, Achievable, Relevant, and Time-bound. But beyond SMART, there are additional dimensions that separate high-impact KPI dashboards from collections of random charts:

• Strategic alignment: Does this metric directly measure progress toward a stated business objective? A manufacturing dashboard showing total machine uptime is useful; one showing uptime segmented by production line and correlated with output quality is strategically aligned.
• Actionability: Can someone who sees this metric do something about it? If a KPI moves in the wrong direction and no one knows what lever to pull, it is a vanity metric, not a management tool.
• Comparability: Does the metric have a meaningful benchmark — against historical performance, against targets, or against industry peers? Isolated numbers without context are misleading. A revenue figure of $5 million means nothing until you know the target was $4.8 million and last quarter was $4.5 million.
• Data reliability: Is the underlying data source consistent, accurate, and timely? A KPI based on unreliable data will erode trust in the entire dashboard, and once trust is lost, rebuilding it can take quarters.

Start with three to seven metrics per dashboard. Anything more, and you risk diluting focus. The best dashboards are ruthlessly curated — they show what matters, not everything that can be measured. If you find yourself adding a tenth KPI, step back and ask whether you are building a dashboard or an encyclopedia.

What Is the Difference Between Lagging and Leading Indicators?

Lagging indicators measure outcomes that have already occurred, providing a rearview-mirror view of performance. Revenue, profit margin, customer churn rate, and employee turnover are classic examples — they tell you what happened, but only after the fact and too late to change it. Leading indicators, by contrast, measure activities and signals that predict future outcomes. Sales pipeline velocity, employee engagement scores, website traffic trends, and customer onboarding completion rates all serve as early-warning signals for what is coming next. Both types are essential for metrics design, but they serve profoundly different management purposes.

The comparison below highlights when to use each type and the trade-offs involved:

Aspect	Lagging Indicators	Leading Indicators
Time Orientation	Backward-looking; measures past results	Forward-looking; predicts future outcomes
Examples	Revenue, profit margin, churn rate, NPS	Pipeline velocity, engagement score, trial sign-ups, training completion
Primary Use	Performance evaluation, financial reporting, accountability	Strategic course correction, early intervention, operational agility
Update Frequency	Monthly, quarterly, or aligned to fiscal cycles	Daily, weekly, or real-time
Key Risk	Too late to change the outcome once the number lands	May not correlate perfectly with the outcome you are trying to predict

A balanced dashboard includes both types: leading indicators to steer the ship and lagging indicators to confirm you arrived at the right destination. For example, a SaaS company might track monthly recurring revenue — a classic lagging indicator — alongside trial-to-paid conversion rate and feature adoption velocity, both of which are leading indicators. The leadership team gets both a rearview mirror and a windshield, enabling them to adjust course before the quarterly numbers come in.

"What gets measured gets managed — but what gets measured poorly gets managed poorly. The art of KPI design lies in selecting the few metrics that actually drive behavior in the right direction, not in measuring everything that happens to be quantifiable."

Attributed to Peter Drucker, Management Consultant and Author

Dashboard Design, Data Visualization, and Common UX Mistakes

What Data Visualization Principles Should Guide Dashboard Design?

Effective dashboard design follows principles refined over decades of research in human-computer interaction and data visualization. As outlined by Tableau's data visualization best practices, these principles guide users from confusion to clarity. They apply regardless of the tool you use — Power BI, Tableau, Looker, Metabase, or a custom-built solution:

• The Five-Second Rule: A viewer should grasp the dashboard's primary message within five seconds of looking at it. If they need to study the screen to understand what it is telling them, the design has failed. This rule forces ruthless prioritization of what appears on the canvas.
• Information Hierarchy: Place the most critical metrics at the top-left (where eyes naturally land in Western reading cultures), with supporting details flowing downward and to the right. The most important number on the dashboard should be the most visually prominent element.
• Data-Ink Ratio: Minimize non-data elements — heavy grid lines, decorative graphics, 3D effects, and excessive color gradients. Every pixel should either convey data or support its interpretation. When in doubt, remove it and see if the insight survives.
• Consistent Visual Language: Use the same chart types, colors, and scales for comparable data across the dashboard. If blue represents "current period" in one chart and "prior year" in another, you are forcing the user to re-learn the visual grammar with every glance.
• Context Through Comparison: Metrics displayed in isolation are meaningless. Always show comparisons — versus target, versus prior period, or versus a relevant industry benchmark. A single number on a screen is a data point; a number with context is an insight.

"Above all else, show the data. The best dashboards fade into the background and let the numbers speak for themselves. When a viewer notices the design before the insight, something has gone wrong."

Edward R. Tufte, Author of "The Visual Display of Quantitative Information" (paraphrased)

What Are the Most Common Dashboard Design Mistakes?

Even experienced teams routinely fall into predictable traps when designing dashboards. Recognizing these pitfalls in advance can save months of rework and thousands of dollars in abandoned BI investments. Here are the five most frequent and damaging mistakes:

1. Overcrowding: Cramming twenty charts onto a single screen because "the data exists." This violates the five-second rule and guarantees that no single insight will register. If a dashboard needs a scroll bar and a user manual, it has already failed.
2. Wrong Chart Types: Using pie charts for more than four categories, line charts for categorical data, or 3D bar charts that distort proportions. Choose chart types based on the relationship you are trying to convey — comparison, composition, distribution, or relationship — not based on what looks most visually striking.
3. Vanity Metrics on Prime Real Estate: Placing "total page views" or "number of app downloads" at the top of the dashboard when those numbers do not connect to revenue, retention, or any strategic business objective.
4. Ignoring Color Accessibility: Relying exclusively on red-green distinctions that are invisible to approximately 8% of male viewers. Use saturation, patterns, or explicit labels as redundant encodings so the meaning survives even without color perception.
5. No Call to Action: A dashboard that declares "sales are down" but does not guide the user toward investigation or remediation is incomplete. Every alert or anomaly should link to a drill-down, a detailed report, or a defined action plan.

What Are the Key Considerations for Mobile Dashboard Design?

Mobile dashboard design is not simply a scaled-down version of a desktop layout. The constraints of smaller screens, touch-based interaction, and on-the-go usage patterns demand a fundamentally different approach to business reporting on mobile devices. As Nielsen Norman Group's mobile UX research consistently shows, mobile users are more goal-directed and less tolerant of friction than desktop users, which raises the bar for mobile dashboard clarity:

• Prioritize ruthlessly: A mobile dashboard should show three to five metrics at most — the ones an executive needs between meetings or a field manager needs on-site. Everything else belongs behind a tap or on a desktop screen.
• Design for touch: Tap targets should be at least 44 by 44 pixels. Avoid hover-dependent interactions entirely — they do not exist on mobile. Every interactive element should be tappable with a thumb.
• Vertical stacking: Desktop dashboards can use multi-column grids; mobile dashboards should stack KPIs vertically in a single scrollable column. Users scroll vertically on phones; horizontal scrolling signals a layout failure.
• Optimize load time: Mobile users on cellular connections will abandon a dashboard that takes more than three seconds to render. Pre-aggregate data server-side and minimize the payload sent to the device.
• Use progressive disclosure: Show summary numbers with the option to tap for drill-down detail, rather than overwhelming the small screen with dense data upfront. The mobile view should answer the question, "Am I on track?" — and let the desktop view answer, "Why or why not?"

Platforms such as Informat offer responsive dashboard builders that let teams design once and deploy across desktop and mobile, reducing the maintenance burden of managing separate dashboard versions for different device form factors.

Technology and Integration: Self-Service BI, Embedded Analytics, and Real-Time Analytics

How Do Self-Service BI and Embedded Analytics Compare?

Self-service business intelligence (BI) gives end users the tools to build, modify, and explore their own dashboards without writing SQL or involving IT. Embedded analytics, by contrast, integrates dashboards and reporting directly into the applications that users already work in — CRM systems, ERP platforms, customer portals, or internal tools. Both approaches have strong merit, but they serve fundamentally different user populations and use cases:

Aspect	Self-Service BI	Embedded Analytics
Primary Audience	Analysts, managers, and power users who want to explore data independently	End users who need insights inside the applications they already use daily
Customization	High — users build and modify their own views ad-hoc	Lower — dashboards are built by developers or platform teams and surfaced in-app
Integration Depth	Standalone BI platform accessed separately from operational tools	Deeply integrated; analytics appear as a native, seamless part of the host application
Go-to-Market Context	Internal productivity; democratizing data access across the organization	External-facing or operational; monetizing analytics as a product feature for customers
Example Tools	Tableau, Power BI, Looker, Metabase, ThoughtSpot	Informat, Sisense, Logi Analytics, Cube, Sigma Computing

The choice is not binary. Many organizations deploy self-service BI for internal analyst teams while simultaneously embedding analytics directly into customer-facing products and operational tools. The key strategic question is: where does your audience already spend their time? Build dashboards there. If your sales team lives in Salesforce, embed the pipeline analytics inside Salesforce. If your customers log into your SaaS product every morning, surface their usage analytics on the home screen — not in a separate BI portal they will never visit.

What Refresh Frequency Should My Dashboard Use?

Refresh frequency ranges from real-time streaming to monthly batch updates, and the right choice depends entirely on the decision speed your metrics support. According to Forbes' coverage of data analytics trends, the majority of organizations over-invest in real-time capabilities they do not actually need, paying for streaming infrastructure to update metrics that influence decisions made weekly or monthly. Match the refresh cadence to the decision cadence:

• Real-time (sub-second to seconds): Essential for operational dashboards monitoring server health, manufacturing line throughput, fraud detection, or live campaign performance. Real-time is expensive, both in infrastructure cost and cognitive load — deploy it only where sub-second latency changes a decision.
• Near-real-time (1 to 15 minutes): Appropriate for customer support queues, e-commerce order monitoring, and social media sentiment tracking. Provides timely awareness without the full overhead of streaming architectures.
• Hourly: Suitable for intraday sales tracking, logistics dashboards, and call center performance monitoring. Balances freshness with computational efficiency.
• Daily: The workhorse of most business dashboards — finance KPIs, marketing funnel metrics, HR dashboards. Overnight batch processing is cost-effective and sufficient for metrics that inform strategic rather than real-time operational decisions.
• Weekly or Monthly: Reserved for executive summaries, board reporting packages, and long-cycle metrics like employee engagement scores or customer lifetime value, where the underlying data simply does not change fast enough to warrant more frequent updates.

How Do I Connect Multiple Data Sources to a Single Dashboard?

Modern dashboards rarely pull from a single source. A typical executive dashboard might combine CRM data from Salesforce, financial data from an ERP system, web analytics from Google Analytics 4, and operational data from an internal PostgreSQL database. The challenge is not just connecting these sources — it is doing so in a way that is performant, maintainable, and consistent. Three architectural patterns dominate:

1. Direct Query or Live Connection: The dashboard tool connects directly to each source via native connectors, ODBC, or JDBC drivers. Simple to set up initially but can create performance bottlenecks when queries span multiple systems, and it couples the dashboard tightly to the source schema.
2. Data Warehouse or Lakehouse Layer: All source data is ingested — via ETL or ELT pipelines — into a centralized repository like Snowflake, Google BigQuery, Databricks, or Amazon Redshift. The dashboard queries a single, optimized source. This is the recommended approach for most organizations with more than three data sources.
3. Semantic Layer or Metrics Store: A unified business logic layer sits between the warehouse and the dashboard, defining metrics once and reusing them across all dashboards. Tools like dbt's Semantic Layer, Looker's LookML, and Cube implement this pattern, ensuring that "revenue" means exactly the same thing on every dashboard in the organization — from the CEO's strategic view to the regional manager's operational detail.

Start with the warehouse approach if you have the data engineering resources; otherwise, begin with direct connections and plan to migrate to a centralized model as dashboard complexity and stakeholder count grow. The semantic layer can be added incrementally once consistent metric definitions become a pain point — which they almost always do as dashboard adoption scales.

Governance and Access: Business Reporting Controls and Data Quality

Who Should Have Access to Business Dashboards and at What Permission Level?

Not every dashboard should be visible to every employee. Effective dashboard governance requires a structured approach to access control that balances transparency with data sensitivity and role relevance. The most widely adopted framework is role-based access control (RBAC) mapped to three organizational tiers:

• Executive Tier: Full view access to strategic, organization-wide dashboards covering revenue, profitability, market share, and company-level KPIs. Executives typically receive view-only access to governed, certified dashboards to prevent accidental modification of carefully curated views that serve as the organizational single source of truth.
• Management Tier: Access to departmental and cross-functional dashboards relevant to their span of control. Managers may have edit permissions for their team's operational dashboards but view-only access to company-wide strategic views. This tier benefits most from self-service capabilities — the ability to create ad-hoc explorations within a governed data sandbox.
• Individual Contributor Tier: Access to team-level operational dashboards and personal performance metrics. These users often have the greatest need for customized, role-specific views, which requires a platform that supports personal dashboard creation without compromising the integrity of certified, organization-wide metrics.

Additionally, row-level security should be applied so that a regional sales manager sees only their region's data, even when viewing a dashboard built on a global dataset. According to Gartner's guidance on analytics governance, organizations that implement RBAC and row-level security early in their BI journey avoid the painful and expensive retrofitting process that many late-adopters face when sensitive data inevitably leaks through ungoverned dashboards.

How Do I Ensure Data Quality and Consistency Across Dashboards?

Nothing erodes trust in dashboard reporting faster than inconsistent numbers. When the sales dashboard says $4.2 million and the finance dashboard says $3.9 million for the same period, users stop trusting both — and often stop using dashboards entirely. Data quality and consistency require proactive, systematic governance rather than reactive cleanup:

1. Establish a single source of truth (SSOT): Every metric should be defined once, in one place, and referenced by all dashboards. If "active users" means something different to the product team than it does to the marketing team, create two distinct, clearly named metrics rather than reusing the same label with divergent definitions.
2. Implement a semantic layer: A metrics store — whether built in dbt, Looker, or a custom solution — centralizes business logic so that every dashboard references the same underlying calculation. Fix the definition once, and every dashboard across the organization updates automatically.
3. Automate data quality checks: Validate freshness (did today's data actually load into the warehouse?), completeness (are critical fields unexpectedly null?), and consistency (does row count match the source system?) at every pipeline stage. Tools like Great Expectations, Monte Carlo, and dbt tests make this automation accessible to teams without dedicated data engineering staff.
4. Version-control dashboard definitions: Treat dashboard specifications like code — store them in Git repositories, review changes through pull requests, and maintain a structured change log. This practice, increasingly known as analytics-as-code, transforms dashboard management from an ad-hoc, tribal-knowledge process into a disciplined engineering practice that scales across teams.

"Trust arrives on foot but leaves on horseback. A single data quality incident — one wrong number spotted by a skeptical executive — can undo months of dashboard adoption effort. Investing in governance upfront is not overhead; it is the foundation on which every successful analytics program is built."

Forrester Research, 2025 Data and Analytics Governance Survey (paraphrased finding)

Trends, Pitfalls, and the Road Ahead for Business Dashboards

What Trends Are Shaping the Future of Business Dashboards?

The dashboard landscape in July 2026 looks markedly different from even three years ago. Several converging trends — driven by advances in AI, changing user expectations, and maturing data infrastructure — are reshaping what dashboards can do and how users interact with them:

• AI-Powered Natural Language Querying: Instead of clicking through filters and drill-down paths, users increasingly type plain-English questions — "Show me Q2 revenue by region, broken down by product line" — and receive an auto-generated visualization in response. Microsoft's integration of Copilot into Power BI, generally available since 2024, and Salesforce's Einstein AI capabilities across the Tableau platform (2024–2025) have made NLQ a mainstream expectation rather than an experimental feature.
• Automated Insight Generation: Modern dashboards do not just display data; they automatically surface anomalies, trends, and correlations that warrant human attention. This shifts the user's role from analyst to investigator — the system finds the signal, and the human decides what to do about it.
• Embedded Analytics as a Product Feature: Software companies increasingly embed dashboards directly into their products as a competitive differentiator. Customers now expect analytics to be native to the applications they use daily, not siloed in separate BI platforms they have to remember to log into.
• Streaming and Event-Driven Architectures: The rise of Apache Kafka, Redpanda, and cloud-native streaming services has made continuous, real-time data pipelines practical for organizations beyond the tech giants and financial institutions. More dashboards are going real-time as the infrastructure cost and complexity drop.
• Low-Code and No-Code Dashboard Building: Platforms that let non-developers build and deploy sophisticated dashboards — without writing SQL, configuring servers, or understanding data modeling — are accelerating dashboard adoption across organizations where BI talent is scarce and the backlog for the data team stretches into months.

What Are the Biggest Mistakes Organizations Make With Dashboard Programs?

Beyond individual design errors, there are strategic-level missteps that undermine entire dashboard initiatives. These are the mistakes that turn six-figure BI investments into shelfware — software that is technically deployed but functionally abandoned. According to Harvard Business Review's coverage of analytics leadership, the organizations that extract the most value from their BI investments are distinguished less by their tool choices and more by their organizational practices:

1. Building Dashboards Without Defined Audiences: If you cannot name five specific people who will use a dashboard and describe exactly what decision it will inform, do not build it. Audience-first design is the single highest-correlation factor with dashboard program success. Every dashboard should have a named sponsor and a documented use case before the first chart is drawn.
2. Dashboard Proliferation Without Governance: Organizations that let anyone build and publish dashboards without oversight quickly accumulate hundreds of overlapping, contradictory, and abandoned dashboards. The inevitable result is "dashboard fatigue" — users stop checking any dashboard because they cannot tell which numbers to trust or where to find the view they need.
3. Treating Dashboards as the Finish Line: A dashboard is not an outcome; a better business decision is an outcome. Organizations that celebrate dashboard launches rather than the measurable business improvements those dashboards enable are optimizing for the wrong metric. Ask not "How many dashboards did we ship?" but "What decisions changed because of the dashboards we shipped?"
4. Underinvesting in Data Literacy Training: Deploying sophisticated BI tools without teaching people how to read charts, understand basic statistical concepts, and distinguish correlation from causation guarantees low adoption. Tool training and data literacy education are separate disciplines — invest in both, and start the literacy work before the tool rollout.
5. Ignoring Dashboard Performance: A dashboard that takes thirty seconds to load will not be used, no matter how insightful its content might be. Performance is a feature — budget for query optimization, intelligent caching layers, and materialized views from day one, not as an afterthought when users start complaining.

Conclusion: Building a Dashboard Culture That Drives Business Results

Business dashboard reporting, when executed thoughtfully, is one of the highest-leverage investments an organization can make. It aligns teams around shared metrics and a common understanding of reality, accelerates decision-making from weeks to minutes, and surfaces patterns and anomalies that would otherwise remain buried in spreadsheets, databases, and email threads. But the gap between a dashboard that transforms an organization and one that languishes unused is wide — and it is almost never about the technology alone.

The organizations that get the most value from dashboard reporting share three characteristics.

• They invest in people, not just platforms: Data literacy and dashboard design skills receive as much budget and attention as BI tooling itself, because tools amplify human capability but cannot substitute for it.
• They govern like engineers: Dashboard definitions live under version control with peer review, automated data quality testing, and clear ownership — the same discipline applied to production software.
• They measure decisions, not dashboards: A dashboard launch is not the outcome; a demonstrably better, faster business decision enabled by that dashboard is the outcome that counts.

Whether you are evaluating KPI dashboards for the first time, redesigning a dashboard that has grown cluttered and confusing over years of incremental additions, or building an embedded analytics experience for paying customers, the principles in this dashboard reporting FAQ apply universally. Start with the question you are trying to answer, not the data you happen to have. Choose metrics that matter to the specific people who will use the dashboard. Design for clarity above cleverness. Govern for trust and consistency. And never stop asking the hardest question of all: "Is this dashboard actually changing how we make decisions?" If the answer after six months is no, tear it down and start over — a dashboard that does not drive action is just digital wallpaper.

For organizations looking to build custom dashboards on top of their existing data infrastructure without writing code, platforms like Informat offer low-code dashboard-building capabilities that integrate with multiple data sources and support role-based access control, enabling teams to move from concept to production dashboard in hours rather than weeks.