What needs to be finished first
A North Star Metric or at least one clear top-level metric with definition and measurement source is available.
A live experimentation or feature-flag platform provides at least seven days of data points per variant.
What needs to be ready before start
Table with columns top metric, counter metric, definition, data source, threshold, owner; link to current metric documentation; list of active experiments; dashboard template.
One owner per top metric (PM or growth lead); one data analyst with tracking access; one engineering representative for performance counters; optional trust or support representative for complaint counters.
Current values and trends of top metrics (last 4 weeks); known historical side effects of past optimizations; planned experiments in the quarter; list of sensitive metrics (latency, refunds, NPS).
60-90 min
Share the table, pre-fill top metrics, leave data source column empty. Prepare a dashboard with top metric plus placeholder counter metrics so each agreed counter metric can be wired in immediately.
The one question this method answers
What undesirable side effect would increasing the top metric cause, and how can we detect it early?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Confirm main metrics | 10 min | For each top metric verify definition, calculation, and owner. Remove or clarify metrics without clear calculation before counter metrics are introduced. | If the top metric itself is unclear, counter metrics are useless. Better stop here than build around the problem. |
2Phase 2: Collect side effects | 20 min | Brainstorm 3-5 plausible negative side effects per top metric: what would also deteriorate if someone maximizes the top metric at any cost? Include categories such as performance, complaints, refunds, quality of engagement. | Intentionally play out the worst interpretation of the top metric. If you are too polite here, the counter metric will not be effective. |
3Phase 3: Select counter metrics | 20 min | Define 1-2 counter metrics per top metric that best proxy for the identified side effect. Define data source, calculation, and allowed variance in writing. | No more than 2 counter metrics per top metric, otherwise every experiment hits some counter metric threshold and no one takes action. |
4Phase 4: Thresholds and consequences | 15 min | Set threshold for each counter metric where the experiment is paused or investigation is triggered. Record owner and escalation path. | Thresholds must be fixed before experiment start, not during review. Otherwise thresholds become retrofitted after the fact. |
5Phase 5: Wire into reporting | 10-15 min | Add counter metrics directly in the top-metric dashboard so they appear automatically in each review. Record owner and review cadence. | Counter metrics not in the same dashboard as the top metric are simply forgotten in reviews. |
What comes out at the end
Table or Notion page with columns top metric, counter metric, definition, data source, threshold, consequence at breach, owner, last review. Linked from strategy wiki and each experiment template.
Quarterly snapshot with date and responsible person. Record changes to thresholds or definitions in the edit log with rationale. Keep old thresholds, do not overwrite, so experiment evaluations stay comparable.
Compact working template for Counter Metrics with context, input, output artifacts, and next step.
Protective metrics that surface unwanted side effects of a primary metric.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
| Top metric | Counter metric | Threshold | Owner |
|---|---|---|---|
| Activation rate (D1) | p95 onboarding endpoint latency | > 1200 ms | @ben |
| Activation rate (D1) | Support tickets per 1000 sign-ups | > 12 (baseline 7) | @lisa |
| Trial-to-paid | 30-day refund rate | > 4.5% | @marcus |
| Trial-to-paid | NPS from new paying users | < 22 | @anna |
Consequence at breach: Experiment is automatically stopped and a postmortem is required within 48 hours. Last review: 12.05.2026.
Recognize symptoms and steer against them
Counter metric hardly moves regardless of what the experiment does.
Check with analytics if the metric is actually sensitive enough. If not, replace it with a more reactive proxy, for example complaints instead of churn.
Every experiment fails at least one of eight counter metrics and nobody stops meaningfully.
Limit to at most 2 per top metric. What does not fit in top 2 belongs to separate monitoring, not guardrail layer.
Thresholds are discussed only during review, often just above current value.
Fix thresholds in writing before experiment start. Any later changes require an ADR or DIBB note with rationale.
Counter metric breaches but owner cannot pause experiment because decision rights are elsewhere.
Each counter metric owner must have stop or escalation authority. Otherwise change owner or document escalation path explicitly.
In review, the team only sees the top metric while counter metrics are behind one level and get overlooked.
Place counter metrics next to the top metric in the same dashboard and mark thresholds visually.
Counter metric reacts far too late or has high variance, so breaches are detected too late.
Run a power analysis with analytics to confirm that the metric can change significantly in the experiment window, otherwise use a leading proxy instead.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.