PIE vs ICE for Shopify CRO: Score Your Fix List

Quick answer: PIE (Potential, Importance, Ease) and ICE (Impact, Confidence, Ease) both rate each fix on three questions and rank the list by the result. PIE suits a list built from page and funnel data, because it starts from how badly a page performs and how valuable its traffic is; ICE suits a mixed list, because it scores how much evidence backs each idea. Both break where the scores rest on opinion, which drifts towards whatever the scorer wants to build. Pick one, write down what each score means, and hold it for a quarter so you can check the scores against what happened.

You have a list. Show delivery costs earlier. Add a sticky add-to-cart button on mobile. Rebuild the filters. Redesign the home page. Someone’s cousin thinks you need a quiz. There are thirty items, a developer with a few days a month, and nobody agrees what goes first.

Scoring frameworks exist to settle that argument with something better than the loudest voice. The two you will meet most often are PIE and ICE. A third, PXL, was written as a reaction to both. All three were built to rank test ideas, which matters if your store does not have the traffic to test most of its list.

This guide covers what each originator actually wrote, how to score a Shopify fix list, a worked example, where the frameworks break (inflated self-scoring and subjective Potential), and why I tell founders to hold one framework for a quarter.

Two disclosures. First, the final phase of Prism3’s six-phase CRO audit is a recommendations report scored with PIE, so I have a working preference, and the weaknesses below apply to the method I use. Second, everything scored in this post is hypothetical. It is not client data, and none of the scores predicts what a fix would do to anyone’s conversion rate.

Where PIE, ICE and PXL came from

Here is what the originators’ own pages say, as read on 31 October 2026.

PIE comes from Chris Goward. In an article for Practical Ecommerce dated 12 December 2013, he describes it as a tool his firm, WiderFunnel, developed to decide where to start testing. The three letters:

• Potential: how much a page can improve. Goward says you are ranking your pages by how poorly they perform, and to draw on web analytics data, customer data and expert heuristic analysis.
• Importance: how valuable the page’s traffic is. His most important pages are the ones with the highest volume and the costliest traffic.
• Ease: how hard the test is to run, covering technical work and also organisational or political barriers.

Two details matter later. Goward frames PIE around pages (his caption says it helps you decide the best page to test), not individual fixes. And the article gives no scale and no formula: the table that produces the ranking is an image. A 1 to 10 scale and averaging are conventions, not something the article states.

ICE is credited to Sean Ellis, founder of GrowthHackers. CXL’s write-up says the ICE score was popularised by him. The earliest first-hand source I could open is a post from Ellis on X dated 1 December 2015, saying his team used an ICE score (Impact, Confidence and Ease) with a 1 to 10 rating for the GrowthHackers projects site. In a talk at SaaStr Annual 2016 he explains the three questions: if this works, is the impact high; do I have a lot of data supporting it (confidence); and is it relatively easy to test. An idea that scores well across all three is the one to run. The transcript I read does not say whether to add, average or multiply the scores, and I could not find the first time he published the idea, so I will not give a date for that.

PXL is CXL’s. Peep Laja’s article was first published on 27 September 2016 (the page shows it as last updated 16 September 2026). CXL built it because it found PIE and ICE useful but too open to interpretation. Instead of asking for a broad estimate, PXL asks specific questions, and most are scored 0 or 1. CXL credits a binary model shown at CXL Live 2016 by Pauline Marol and Josephine Foucher of Hotwire as an inspiration, along with a second model it also calls ICE (Impact, Cost, Effort, each scored 1 or 2). If someone hands you an “ICE score”, check which one they mean; this post covers Impact, Confidence, Ease.

Before you score: separate the gates from the fixes

Some items on a fix list are not fixes. They are gates: things that must be true before any score means anything.

• Tracking you cannot trust. If GA4 and Shopify disagree on orders and nobody can say why, every conversion number you feed into a score is suspect. In our CRO audit the tracking check sits inside the first phase, the quantitative data analysis, for this reason. Our guide to GA4 and Shopify Analytics explains why the two count differently.
• A broken payment method, a checkout error or a page that fails to load on a phone. These are bugs, not prioritisation questions.

Gates do not fit PIE or ICE. What is the Potential of fixing a duplicated purchase event? It converts nobody. It only lets you see whether anything else did. Score it anyway and it lands mid-table, yet it has to be done first. Do the gates first, outside the scoring, and score what is left.

Then be clear what you are scoring. These frameworks rank test ideas or pages. On a store between $150K and $1M in revenue you will often ship fixes without testing them, because there may not be enough traffic to read a test. Ranking still works, but “Impact” and “Potential” now mean how much a fix probably matters, not a forecast of a test result. Our guide to A/B testing on low-traffic Shopify stores covers when to test and when to ship and measure before and after.

Candidates for the list come from three places, and each should leave an evidence trail you can point to later.

• Analytics (Shopify Analytics and GA4): where sessions come from, the device split, where people drop off.
• Session recordings and heatmaps: why they drop off. Our guide to reading Shopify session recordings covers what to look for.
• Customer questions and reviews: what people cannot find or do not believe.

If the list mixes search fixes with conversion fixes, decide that trade-off first. Our guide to fixing SEO or CRO first covers it.

How to score a Shopify fix list with PIE

PIE was designed to rank pages, so the first adaptation is to score each fix against the page or step it sits on. That creates a quirk: two fixes on the same product page share the same Importance, and if you score Potential for the page as a whole they share that too, so Ease alone separates them. I score Potential per fix instead: how much of the page’s problem does this fix address? That is my adaptation, not Goward’s.

My convention is to score each letter from 1 to 10, add the three and divide by three. Write down yours. Here are example bands for a Shopify store; replace them with your own numbers.

Potential has no neat external anchor, which is its weakness. The best I know is to tie it to the data Goward names: a high Potential means analytics shows this step losing noticeably more shoppers than the steps around it, and recordings or customer questions point at the same thing. A low Potential means the step already performs about as well as its neighbours.

If much of a page’s traffic is paid, its Importance goes up, which is Goward’s point about costly traffic. Prism3 does not run ads or email, but Google’s help for the GA4 Landing page report says that adding “Session source / medium” as a secondary dimension shows the traffic sources for each landing page, which is where to look.

How to score the same list with ICE

ICE swaps Potential and Importance for Impact and Confidence. In practice:

• Impact: if it works, how much does it move the step? Resist the urge to put a percentage on it. Use bands: small, noticeable, large.
• Confidence: how much evidence supports it? This is the letter ICE adds, and it is where your evidence trail enters. A convention I use: 1 to 3 is opinion only; 4 to 6 is one source of evidence; 7 to 9 is two independent sources, such as analytics plus recordings plus customer emails; 10 is a fix that already worked on this store.
• Ease: the same as PIE.

You will see the scores averaged and you will see them multiplied. Neither Goward’s article nor Ellis’s talk (as read) settles it, so you choose, and the example below shows the choice is not cosmetic.

A worked example (hypothetical)

Take a hypothetical Australian store selling skincare, with most traffic on phones. These scores are invented to show the mechanics. They are not from a real store and do not predict results. The gates (tracking, payments, mobile load) are already sorted. Six fixes remain:

1. Show a delivery cost estimate in the cart (before checkout)
2. Add a delivery and returns summary beside Add to cart on mobile product pages
3. Redesign the home page hero
4. Add a sticky Add to cart bar on mobile product pages
5. Rebuild the collection filters for mobile
6. Add customer reviews to product pages

Fixes 1 and 2 are the sort of items our guides on surprise checkout costs and shipping and returns messaging for Australian stores cover in detail. Here they are just list items.

The arithmetic for fix 1 under PIE: 8 + 9 + 7 = 24, divided by 3 is 8.0. Under ICE: 8 + 7 + 7 = 22, divided by 3 is 7.3, and 8 × 7 × 7 is 392.

What the scores say

The top three agree. Fixes 1, 2 and 4 lead under both frameworks, and the hero redesign sits at or near the bottom. On a short list built from evidence, the choice of letters changes less than people argue about. I would not spend an hour deciding between PIE and ICE for a list like this.

They disagree on the winner. PIE puts fix 2 first (8.3 against 8.0). ICE multiplied puts fix 1 first (392 against 378), and ICE averaged ties them. The trade is the same each time: fix 2 is easier to build (Ease 9 against 7) and fix 1 is expected to matter more (Impact 8 against 6). Where the methods disagree, look at that pair: effort and expected effect are pulling in opposite directions, and a human call is needed.

Averaging creates ties; multiplying breaks them. Under the ICE average, fixes 1 and 2 tie at 7.3 and fixes 3 and 5 tie at 5.7. Under the product, every fix has its own number. Multiplying also punishes one low score harder: fix 3’s Ease of 3 drags its product to 144, the lowest on the list, while the average leaves it level with fix 5. Neither method is wrong. They give different lists, which is a good reason to choose once.

Where each framework breaks

Inflated self-scoring

CXL names the problem for PIE: if you want to push your own idea through, you can “tack on a couple points to potential”, because it is a subjective number anyway. The same applies to Impact and Confidence in ICE.

See what that does to the hypothetical list. Say the person who wants the home page redesign re-scores it. Under PIE they give Potential 9 (the hero is the first thing everyone sees) and Importance 8 (every visitor lands on it). Each number sounds defensible. The total goes from 15 to 20, the PIE score from 5.0 to 6.7, and the hero climbs from last to joint fourth, level with the reviews fix.

Under ICE, they give Impact 10 and Confidence 8 and leave Ease at 3. The average moves from 5.7 to 7.0, level with the sticky bar for third place. The product moves from 144 to 240, which beats the reviews fix at 210. Nobody lied; everybody rounded in the direction they hoped for.

You cannot remove this, because the person who proposed an idea usually knows it best. You can narrow it, and the rules below do that.

Subjective Potential (and Impact, and Confidence)

CXL’s critique is blunt. On PIE, the criteria leave too much open to interpretation, and if you knew in advance how much potential an idea had you would not need a prioritisation model. On ICE, if you could guess the impact you would not need to test, and “how confident am I?” is hard to answer in advance. CXL’s view is that two of ICE’s three scores are largely gut feeling and easy to skew.

I think the criticism lands, with one qualification. CXL also calls Importance and Ease hard to place objectively; my view is that they can be tied to something outside the scorer’s head: session data for the first, the person who builds the fix for the second. Potential, Impact and Confidence have nothing external to hold them still. The practical answer is to make them checkable: Potential becomes “this step loses more shoppers than its neighbours and recordings agree”, and Confidence becomes a count of independent evidence.

Ease is scored by the wrong person

The person asking for a fix often scores its Ease, and people who do not build things tend to underestimate effort. CXL says developers tend to underestimate time too, but that ideally a developer takes part in the prioritisation discussion and the answer is bracketed by estimated time. Goward adds that Ease covers organisational and political barriers: a home page change that needs four approvals is not easy, whatever the code says. Ask the person who builds the fix, and ask who has to approve it.

The average hides a blocker

An item scoring 10, 10 and 1 averages 7.0, the same as an item scoring 7, 7 and 7. In real life the first one cannot ship. A simple rule: any item with an Ease of 1 or 2 goes on a “needs a plan” list, not into the next batch, whatever its average.

A high score is not a forecast

CXL’s FAQ makes the point about PXL, and it holds for all three: a high score ranks which hypothesis to try first, it does not predict that the result will win. A fix at the top of the list can still do nothing. That is why you measure after you ship.

Rules that make any score harder to bend

None of these comes from a framework’s originator unless I say so. They are what I would do on a small store.

1. Write what each number means before you score. Define a 3, a 6 and a 9 for each letter, using your own session data and developer time, as in the table above.
2. Pin Importance and Ease to something outside the scorer’s head. Importance comes from analytics. Ease comes from whoever builds the fix. That leaves only Potential, Impact and Confidence open to argument.
3. Require an evidence line for any soft score above 6. One sentence: “recordings show shoppers scrolling past the shipping note”, “three customers asked about delivery times”. No evidence, the score is capped at 6. This borrows the spirit of PXL, where ideas that come from opinion score lower than ideas backed by user testing, qualitative feedback, heatmaps or analytics.
4. Score separately, then compare. Each person scores the list alone before anyone sees anyone else’s numbers, and you discuss only the items where scores are far apart. This is my practice, not a published rule; it stops the first speaker setting the anchor.
5. The proposer does not hold the pen. The person who suggested an idea does not score it.
6. Keep a log. For each fix record the scores, the evidence line, who scored it and the date. Without it you cannot check anything later.

What about PXL?

PXL swaps broad scores for specific questions: is the change above the fold, is it noticeable within five seconds, does it add or remove something, does it run on a high-traffic page, and is it backed by user testing, qualitative feedback, heatmaps or eye tracking, or analytics. Ease is bracketed by estimated implementation time. Most answers are 0 or 1, with extra weight on noticeability (2 or 0), on adding or removing elements, and on ease. CXL encourages you to customise the criteria.

The strength is that people have to bring evidence and there are fewer places to nudge a number. The cost is that it assumes A/B tests and research behind each idea. I read the questions in CXL’s post, not the spreadsheet, so check the template for exact weights. You can borrow its yes/no evidence questions for the evidence line in rule 3 without adopting PXL.

Which one should you use?

Hold one framework for a quarter

This is the advice I give founders most often. It is mine, not any originator’s. Choose one framework, lock the rules, and use it for a quarter before you judge it. A quarter is a rule of thumb, not a researched number: what you need is enough shipped fixes to compare, so extend it if you ship very few.

Scores only mean something against each other. A 7.3 in one framework says nothing about a 392 in another. Switch halfway and the list reorders for reasons that have nothing to do with your store, as the averaging against multiplying comparison above showed.

You can only calibrate after work is done. The loop is: score before, measure after, compare, adjust. If your Impact scores were consistently higher than what the fixes delivered, you have learned that you over-score Impact. You cannot learn that if the definition changed halfway through.

Switching is how people get the answer they wanted. If a framework ranks your favourite idea low, the next one may rank it higher. That is the inflation problem one level up.

What to lock, and what can change

Lock the framework and scale, what a 3, a 6 and a 9 mean for each letter, how the scores combine, who scores (proposers do not), the evidence-line requirement and the gates list. During the quarter you can add new ideas, and you can re-score an item when new evidence arrives if you write down what it was. You cannot re-score because someone is keen, and you do not change the definitions or the formula.

A dated caution about your data

If Importance rests on session counts, mind the calendar. Shopify’s changelog entry on its session measurement improvements, effective 21 September 2026, says that when you compare reports before and after that date you should treat it as a new baseline for session-based metrics. It lists conversion rate among the metrics that may look different, and says orders, sales and customer counts are not changed. Do not compare an Importance score built on August sessions with one built on October sessions as if they were the same measure, and check Shopify’s documentation for how the change affects your reports.

The review at the end of the quarter

For each fix you shipped, put the predicted rank next to what you saw. On a store without the traffic for clean tests, “what you saw” will be directional, a before-and-after comparison read with care. Then ask which score was off, and whether it was off in the same direction every time. If Confidence was high for everything, tighten its definition. If Ease was always optimistic, give the builder the pen. Change the rules once, then hold them for the next quarter.

Ship it or test it?

The score decides the order, not the method. On a store of this size most top-ranked fixes are ship-and-measure: clearer delivery information, a sticky button, reviews near the buy button. Reserve a true A/B test for fixes where traffic can carry it. The product page CRO checklist covers the page most of your top items will sit on. For how a full audit produces the list in the first place, see our guide to the Shopify CRO audit and why forensic CRO differs from regular CRO.

Key takeaways

• PIE (Chris Goward, developed at WiderFunnel) scores Potential, Importance and Ease. ICE (popularised by Sean Ellis of GrowthHackers) scores Impact, Confidence and Ease. PXL (Peep Laja, CXL, 2016) replaces broad scores with mostly yes/no evidence questions.
• In the originators’ pages I read, PIE has no stated scale or formula, and Ellis’s talk does not state one for ICE. The 1 to 10 scale and the average or product are conventions, so write down yours.
• On a short, evidence-led list PIE and ICE put mostly the same fixes at the top. Where they disagree, look at that fix.
• Both break where scores are opinion: Potential, Impact and Confidence. A few defensible-sounding nudges can move a fix from last place to joint fourth.
• Anchor Importance to session data and Ease to whoever builds the fix, require an evidence line for high soft scores, score separately, and keep a log.
• Do gates (tracking, payment bugs, mobile load) first and outside the scoring.
• Hold one framework, one scale and one formula for a quarter, then compare predicted rank with what you saw before changing anything.
• A high score ranks what to do first. It does not predict that the fix will work.

FAQs

What is the difference between PIE and ICE?

PIE scores Potential, Importance and Ease. ICE scores Impact, Confidence and Ease. In PIE the second question is how valuable the traffic to a page is, and in ICE it is how much evidence supports the idea. PIE starts from pages and funnel data, and ICE starts from ideas. Both lean on opinion for their softer scores, so the habits around scoring matter more than which one you choose.

Who created PIE, ICE and PXL?

PIE comes from Chris Goward, whose 12 December 2013 Practical Ecommerce article describes it as a tool WiderFunnel developed. ICE is credited to Sean Ellis, founder of GrowthHackers, and CXL describes it as popularised by him; the earliest first-hand source I could open is his post on X from 1 December 2015. PXL was developed by CXL and written up by Peep Laja in an article first published on 27 September 2016.

Should I multiply or average the scores?

Either, as long as you pick one and keep it. Averaging lets two strong scores cover a weak one and often produces ties. Multiplying punishes a single low score harder and separates the list more. In the hypothetical list above, averaging tied two pairs of fixes and multiplying did not.

Can a store that cannot run A/B tests use these frameworks?

Yes, for ranking. They were built for test ideas, but nothing stops you ranking fixes. The difference is that you will usually judge the result with a before-and-after comparison, which is weaker than a test, so lean harder on evidence when you score. The low-traffic testing guide linked earlier explains when a test is worth running.

How do I stop people inflating their scores?

You cannot stop it, but you can narrow it. Tie Importance to session data, get Ease from whoever builds the fix, require a one-line evidence note for any high score on Potential, Impact or Confidence, have people score separately before comparing, and do not let the person who proposed an idea score it. Keep a log so that a quarter later you can see who was consistently optimistic.

Does a high score mean the fix will work?

No. A score ranks the order in which to do things, based on your estimates. CXL says so about PXL, and it holds for every framework here. Measure after you ship.

Want a second opinion on your fix list?

If you have a long list and cannot tell which three fixes to do first, that is the job of our Shopify CRO service, where the final phase of the six-phase audit is a recommendations report scored with PIE. A smaller first step: book a free 30-minute diagnostic or tell us about your store. We share your Shopify store on screen and name two or three conversion leaks live, and tell you whether they are worth fixing. No pitch.