---
title: PIE Prioritization
published: true
index: 0
---

# Prioritize supported Shopify opportunities with PIE

Score actionable opportunities only after the Issue inclusion gate. PIE does not establish conversion lift; keep P0–P3 severity/urgency and canonical category separate.

| Component | What it measures | 1 | 5 | 10 |
| --- | --- | --- | --- | --- |
| Potential | Evidence-supported room to improve the affected experience | Small gap | Meaningful gap | Severe, persistent barrier |
| Importance | Relevant reach and business importance | Narrow, low-value reach | Material cohort | Broad or business-critical reach |
| Ease | Implementation, dependencies, QA and measurement effort; higher is easier | Complex, high effort | Moderate effort | Small, well-understood change |

Use integers 1–10, interpolating between anchors, with one target-bound rationale per score. Cite measured reach when available; never invent traffic, uplift, revenue or effort. Public evidence can establish a critical purchase barrier, not its traffic share. Record confidence and uncertainty separately.

Calculate `PIE = (Potential + Importance + Ease) / 3`, rounded to one decimal. If any component lacks evidence, mark it and the total `unscored` and name the smallest investigation. Never substitute zero or a midpoint.

Honor urgency and dependencies first, explaining overrides. Within comparable groups, sort by descending PIE, Importance, Potential, then ascending stable Issue/item ID. Keep unscored items in an explicit investigation disposition with their severity; an urgent unscored defect need not rank last.

Put scores, rationales, total, confidence and overrides in Issue/roadmap details or schema-permitted text. Add no Data keys, priority enums, collections or scoring schema. A Check's `scored: false` concerns grading, not opportunity priority; terminal outcomes remain unchanged.

## Use reach when prioritizing an existing Issue

Apply reach across the audit after direct evidence establishes an actionable Issue. Reach is prioritization context, not a separate evaluative Check, terminal outcome or duplicate Issue. Keep the underlying Check outcome and canonical category unchanged.

Use available target-bound aggregate analytics or comparable supplied reports. Map the affected routes or templates to sessions, users or page views on the same basis; record the source/property, time window, segment and denominator. Account for campaign, outage, migration and measurement-quality distortions. Repository evidence can establish shared-component scope, but not traffic share. Reuse compatible evidence without automatically running another report or requesting another integration.

Use verified reach in PIE Importance and explain any P0–P3 priority adjustment on the original Issue. Reach alone may raise its priority by at most one level and cannot create P0, prove a defect or establish conversion lift. Low or unavailable measured reach does not negate an observed severe barrier. Preserve an evidence-supported priority when analytics is missing; leave unsupported PIE components unscored and name the smallest investigation. Missing reach data does not block an otherwise browser-supported Check.