Skip to main content

​
Overview

Health score configurations are versioned to maintain a historical record of how scoring has evolved. This allows you to track changes, understand their impact, and analyze trends across configuration updates.
Why versioning matters: When you change weights or thresholds, customer scores will change. Version history helps you understand whether score changes are due to customer behavior or configuration changes.

​
What is a Configuration Version?

A configuration version is a snapshot of your health score settings at a specific point in time, including:
  • Category weights (Revenue, Usage, Engagement, Support, Market Signals)
  • Metric thresholds for each category
  • Scoring formulas
  • Active date range
Example versions:
  • v1.0 - Initial configuration (2024-01-15 to 2024-03-01)
  • v1.1 - Adjusted Support weight (2024-03-01 to 2024-05-15)
  • v2.0 - Major rebalancing after churn analysis (2024-05-15 to present)

​
Why Version Configurations?

Track Changes

Maintain a record of all configuration modifications, who made them, and why

Analyze Impact

See how configuration changes affected customer scores and outcomes

Explain Score Changes

When a customer’s score changes significantly, determine if it’s behavior or configuration

​
Viewing Version History

1

Navigate to Health Scores Settings

Go to Settings → Health Scores
2

Click 'Version History'

You’ll see a timeline of all configuration versions
3

Review Each Version

For each version, you can see:
  • Version number and name
  • Activation date
  • End date (when next version activated, or “Present” if current)
  • Who created it
  • What changed (summary)
  • Full configuration details
4

Compare Versions

Click Compare to see differences between two versions side-by-side

​
Version Lifecycle

When to create a new version:
  • Initial setup
  • After testing reveals needed changes
  • Quarterly review suggests adjustments
  • Business priorities shift
  • New data sources added
How to create:
  1. Navigate to Health Scores settings
  2. Click New Version or Edit (creates new version automatically)
  3. Make changes to weights, thresholds, metrics
  4. Test the new version
  5. Save with a descriptive version name
Naming conventions:
  • Major changes: v2.0, v3.0 (significant weight changes, new metrics)
  • Minor changes: v1.1, v1.2 (threshold adjustments, small tweaks)
  • Include date: “v2.0 - 2024-Q2 Rebalance”
  • Include reason: “v1.1 - Increased Usage Weight”

​
Understanding Version Impact on Scores

​
Version Markers on Health Score Timelines

When viewing a customer’s health score over time, version markers appear on the chart: Example: 
Health Score Timeline for "Acme Corp"

100 |
    |     v1.0              v2.0
 80 |  ------------●-------------------
    |              ↑
 60 |              Score jumped due to
    |              configuration change
 40 |
    |
  0 |_________________________________
    Jan   Feb   Mar   Apr   May   Jun
Interpreting:
  • Before March: Scored using v1.0 configuration
  • March: v2.0 activated
  • After March: Scored using v2.0 configuration
  • Score increase at marker: Not customer improvement, just configuration change

​
Comparing Versions

1

Select Two Versions

From version history, click Compare and select two versions
2

Review Differences

Side-by-side comparison shows:Category weights:
Categoryv1.0v2.0Change
Revenue30%20%-10%
Usage25%35%+10%
Engagement20%20%-
Support15%15%-
Market Signals10%10%-
Threshold changes:
  • Revenue → MRR Trend: Healthy threshold changed from +5% to +10%
  • Usage → Active Users: Declining threshold changed from -10% to -15%
3

View Impact Analysis

Quivly shows predicted impact:
  • Estimated score changes for sample customers
  • How many customers will move between tiers
  • Which categories have biggest impact

​
Next Steps

Configuration

Create and edit health score configurations

Testing Scores

Test configurations before creating new versions

Interpreting Scores

Learn how to read scores across versions

​
Key Takeaways

Version configurations instead of overwriting them to maintain historical context.
Version markers appear on health score timelines, showing when configuration changed.
Document each version with clear notes on what changed and why.
Analyze version impact after activation to ensure changes improved prediction accuracy.
Version quarterly rather than constantly - too many versions create instability.