Required Datapoints
- Total Number of Visitors to demo-eligible pages
- Total Number of Demo Requests
- Source Channel (optional)
- CTA Variant or Test Version (optional)
Demo Request Rate measures the percentage of site or landing page visitors who submit a request for a product demo. It helps gauge the effectiveness of messaging, targeting, and CTA clarity in generating sales interest.
Demo Request Rate is a key indicator of message-market fit and lead intent, reflecting how effectively your site and marketing convert interest into hand-raising behavior — typically a request to speak with sales or see the product.
The relevance and interpretation of this metric shift depending on the model or product:
A falling trend typically signals value proposition misalignment, CTA friction, or poor targeting, which helps teams optimize conversion paths, messaging clarity, and buyer experience.
By segmenting by cohort — such as traffic source, campaign, industry, or page variant — you unlock insights for improving ad targeting, revising landing pages, or reworking CTA placement.
Demo Request Rate informs:
These are the main factors that directly impact the metric. Understanding these lets you know what levers you can pull to improve the outcome
Actionable ideas to optimize this KPI, from fast, low-effort wins to strategic initiatives that drive measurable impact.
Activities commonly tied to improving or operationalizing this KPI.
| Activity | Description |
|---|---|
| Conversion Optimization | Conversion Optimization involves a continuous process of analyzing, testing, and refining the entire buyer journey to increase the percentage of prospects who become paying customers. It improves performance by removing friction, testing changes, and scaling what works. Relevant KPIs include Demo Request Rate. |
| Website Strategy | Website Strategy focuses on planning, developing, and continuously optimizing a company’s web presence to support business objectives and drive growth. It gives teams a clear plan for where to focus, how to sequence work, and what to measure. Relevant KPIs include Demo Request Rate and Engaged Unique Visitors. |
| ICP Targeting | ICP Targeting involves defining, categorizing, and prioritizing Ideal Customer Profiles (ICPs) to ensure alignment across go-to-market teams. It gives teams a clear plan for where to focus, how to sequence work, and what to measure. Relevant KPIs include Cost per Aware ICP Account and Demo Request Rate. |
| CTA Testing | CTA Testing involves systematically evaluating and refining prompts, messages, or buttons that motivate users to take specific actions—such as signing up, requesting a demo, starting a free trial, or making a purchase—across digital touchpoints. It improves performance by removing friction, testing changes, and scaling what works. Relevant KPIs include Demo Request Rate and First Referral Conversion Time. |
This KPI is associated with the following stages in the AAARRR (Pirate Metrics) funnel:
This KPI is classified as a lagging Indicator. It reflects the results of past actions or behaviors and is used to validate performance or assess the impact of previous strategies.
This role is directly accountable for the KPI and is expected to drive progress and decisions around it.
These roles contribute directly to performance and typically partner on execution, reporting, or optimization.
These leading indicators influence this KPI and act as early signals that forecast future changes in this KPI.
These lagging indicators confirm, quantify, or amplify this KPI and help explain the broader business impact on this KPI after the fact.
How this KPI is structured in Cube.js, including its key measures, dimensions, and calculation logic for consistent reporting.
cube('VisitorMetrics', { sql: `SELECT * FROM visitor_metrics`, measures: { totalVisitors: { sql: `total_visitors`, type: 'sum', title: 'Total Number of Visitors', description: 'Total number of visitors to demo-eligible pages.' } }, dimensions: { id: { sql: `id`, type: 'number', primaryKey: true }, sourceChannel: { sql: `source_channel`, type: 'string', title: 'Source Channel', description: 'The channel through which the visitor arrived.' }, ctaVariant: { sql: `cta_variant`, type: 'string', title: 'CTA Variant', description: 'The variant or test version of the CTA.' }, visitDate: { sql: `visit_date`, type: 'time', title: 'Visit Date', description: 'The date of the visit.' } }})cube('DemoRequestMetrics', { sql: `SELECT * FROM demo_request_metrics`, measures: { totalDemoRequests: { sql: `total_demo_requests`, type: 'sum', title: 'Total Number of Demo Requests', description: 'Total number of demo requests submitted by visitors.' } }, dimensions: { id: { sql: `id`, type: 'number', primaryKey: true }, requestDate: { sql: `request_date`, type: 'time', title: 'Request Date', description: 'The date the demo request was submitted.' } }})cube('DemoRequestRate', { sql: `SELECT * FROM demo_request_rate`, measures: { demoRequestRate: { sql: `total_demo_requests / NULLIF(total_visitors, 0)`, type: 'number', title: 'Demo Request Rate', description: 'The percentage of visitors who submitted a demo request.' } }, dimensions: { id: { sql: `id`, type: 'number', primaryKey: true }, calculationDate: { sql: `calculation_date`, type: 'time', title: 'Calculation Date', description: 'The date of the rate calculation.' } }, joins: { VisitorMetrics: { relationship: 'belongsTo', sql: `${CUBE}.visitor_id = ${VisitorMetrics}.id` }, DemoRequestMetrics: { relationship: 'belongsTo', sql: `${CUBE}.demo_request_id = ${DemoRequestMetrics}.id` } }})Note: This is a reference implementation and should be used as a starting point. You’ll need to adapt it to match your own data model and schema