How Priceify tests stay safe and statistically valid.

On the Products step, choose AI suggested, set a min–max band as a percent or a dollar amount, then click Suggest. Control stays at the catalog price. Suggest prices only the variation whose tab is open, so each variation keeps its own band and its own prices — open Variation B and click Suggest there to price it. You can still edit any cell before launch.

The band is signed, so it can test a lower price as well as a higher one. Enter 10 and 20 to test 10–20% dearer; enter −20 and −10 to test 10–20% cheaper. That matters because a price test asks which price earns more, and for some products the answer is a lower one: a product selling badly may simply cost more than its shoppers will pay, and offering less is the only way to find out. Enter −15 and 20 and you have allowed either, which leaves the choice to the suggestion — the AI then picks a direction per product, since that is exactly the judgement you cannot make from the outside. Max price change bounds the distance from the current price, so it caps a cut and a rise at the same figure.

A dollar band works the same way and stays a flat cash amount on every product: $4–$8 adds $4–$8 whether the product sells for $20 or $200, and −$8 to −$4 takes the same off both. Each product is still capped on its own by your price safety settings, so a flat dollar move never pushes a cheap product past your max price change.

One thing the band cannot override is your minimum margin. A cut is refused at the price where the margin would fall below it: a $100 product costing $60, with a 35% minimum margin, will not be priced under $92.31 however wide a discount you ask for — and Priceify says how many prices that affected rather than quietly showing a smaller cut. A product already selling below your minimum margin gets no room to go lower at all, since a test is not the place to correct that.

When AI is available, it decides the range each product’s test should explore inside your min–max, and Priceify spaces the variations across that range. The split matters: how much headroom a product has is a pricing judgement, and how far apart the variations need to be is a statistics one. A product with a healthy known margin gets a range reaching the far end of what you allowed; one with a thin margin, or no recorded cost at all, is kept closer to its current price. A slow seller gets a wider range rather than a gentler one, because a small price difference cannot be detected on light traffic — a cautious band on a quiet product is a test that never concludes. The model sees current price, currency, margin percent, 30-day units, opportunity score and your two price safety settings — the next guide lists every field exactly. It answers by row position rather than by product id, so it cannot name a product you did not select.

Where your band allows both directions, choosing one is part of what the model is asked to do. It is told not to assume a higher price is better, to propose a cut where the evidence points to a product being priced above what its shoppers will pay — weak sales despite a promising product — and to expect the extra orders to more than pay for the lower margin, because a cut that does not is just a smaller profit. It is also told never to propose a cut on a thin margin, or on a product whose cost the shop has not recorded: thin margin means the lost profit is most of the profit, and an unrecorded cost means nobody knows how much a cut gives away.

Each change becomes a price: catalog × (1 + change%), then rounded to a price a shop would actually set. A 12.3% rise on a $38.90 product works out at $43.68, and it is offered as $43.99. That is not decoration: shoppers react to a price ending as well as to the price, so an unfamiliar ending mixes a second change into the test and the result can no longer be put down to the price alone. Rounding only ever spends the slack you left — it stays inside your band and your price safety limits, it never moves two variations onto the same price or past each other, and where you named an exact figure rather than a range nothing moves at all. Zero-decimal currencies round to whole units, so yen lands on ¥2,000 rather than ¥1,999. Shop max price change is a hard cap, and the band cannot be set past it: with the cap at 16%, typing 30% holds the field at 16% — or −30% at −16% — instead of accepting a number that could never be used. The Products step then says what you entered and offers to raise the cap to cover it in one click, up to 30%, whichever direction was blocked. Raising the cap puts your original number back in the band. A dollar band is capped the same way, converted at the average price of the products you selected. The margin floor above uses catalog margin from unit cost when known, otherwise Default COGS.

Variations are spread across the band instead of bunched near its middle. With a 10–20% band, three variations on a $100 product test $110.99, $114.99 and $119.99; with a −20 to −10% band they test $80, $84.99 and $89.99. Prices that sit only a point or two apart cannot be told apart at realistic store traffic, so spanning the band is what makes the result readable. A single test variation sits mid-band. When AI picks a narrower range for a product, the variations span that range, and a range too narrow to tell apart is widened before it is used.

If a guardrail forces a price outside your band — the margin floor blocking a cut, or max price change trimming a rise — Priceify says how many prices that affected instead of quietly showing a smaller move. If AI is unavailable, or still skips a product after being asked again, the same even spread fills the gap, and if the request fails entirely the wizard applies that spread locally inside the same shop cap so the table is not left empty. Whenever a price on the table came from that spread rather than from the model, the banner says so and says how many — a filled-in table never claims to be AI work that it is not.

One click on Suggest asks about every product you selected. Variants of one product — sizes, colours — are asked about once, as that product, and the range that comes back is used for each of them from its own price. Products go 20 to a request, and the requests run side by side, so 100 products take about as long as 20. For each product the request carries its title, product type, current price and currency, its margin percent, how many units it sold in the last 30 days and whether that figure was measured, a revenue level (low, medium or high, not the amount), its product page visits per day, its opportunity score, how many variants it has, and Priceify’s own labels for its price point, traffic, margin and likely direction. Alongside that go how many test variations you are running — a count, not their names — the min–max band you typed, the metric the test is optimising, and two numbers from Settings: your max price change percent and your minimum margin percent. That is the whole payload.

Two of those fields exist to stop the model drawing the wrong conclusion from a blank. A product with no recorded cost has no margin percent, and that is a statement rather than a gap: it means nobody has measured this product’s headroom, so the model is told to stay conservative instead of assuming the margin is fine. And zero units sold used to mean either "this product sells nothing" or "no order covering it was read" — two situations calling for opposite treatment — so the request now says which of the two it is.

Nothing about a shopper is included: no customer names, emails, addresses, order records or sessions — the visit figure is a daily count for the product page, not a record of anyone. Your shop domain is not sent either, and neither are Shopify product or variant ids — products are numbered by their position in the request, and the reply refers to them by that number. Priceify does not keep the request or the reply: there is no cache on price suggestions, so clicking Suggest twice asks twice and a suggestion is never reused for another shop. OpenAI does not train on data sent through its API, and keeps it for up to 30 days for abuse monitoring.

The instructions are short and specific. The model is told to return strict JSON and nothing else; to give one range per product — a low and a high percent change, where a negative lowers the price — rather than a price per variation; to keep both ends inside your min–max band and never further from the current price than your max price change, in either direction; to leave enough distance between the two ends that the variations can be told apart at real traffic; to use a wider range where sales are light or unmeasured and a narrower one where they are heavy; to stay close to the current price where margin is thin, and where no cost has been recorded at all; and to weigh the price point, since a considered purchase carries a larger increase than an impulse one. Where your band allows both directions it is told to choose one per product, not to assume higher is better, and never to propose a cut on a thin or unrecorded margin. It is also asked for the single change it expects to do best on your metric; with one test variation, that is the price tested. Beyond your shop’s numbers it may use what it knows about the kind of product — what shoppers usually pay, how price-sensitive the category is, which price points look normal — but it is told it has no live market data, must never quote or invent competitor prices, and must let your measured sales win where the two disagree. It is asked for a one-sentence summary, which is the line you read back on the Products step when one request covered every product.

It is deliberately not asked to place the individual variations. That is a question about how much traffic is needed to tell two prices apart, which is arithmetic Priceify can do exactly, and asking the model for it produced a worse answer than the even spread while costing a request to get it.

The reply is checked before it reaches you rather than trusted. A number that is not a product in the request is discarded. A range reaching outside your band is pulled back inside it; one returned back to front is read the right way round; one too narrow to resolve is widened; one that is not numbers at all is dropped and the even spread fills in. A minus sign is taken at face value as a price cut, not corrected away. Every price is then rebuilt from your own catalogue price and re-clamped against your max price change and your margin floor, so a suggestion cannot exceed your limits in either direction even if the model ignored them. Only after that does it become a price in the table — and you can still edit any cell before launch.

Each request is given 20 seconds. Products a reply leaves out, or that a failed request never answered, are asked about once more in smaller requests, and the whole click finishes within about 40 seconds. Any product still unanswered then takes the even band spread, and the banner says how many. Requests for more than 500 products are refused outright rather than accepted and half-answered. AI settings themselves are operational rather than merchant-facing: which model is used, and whether a key is configured at all, is set on the server, and with no key configured Suggest still works — it just always uses the even spread.

Suggest is not the only place a model is asked something. When you open the product picker, the top 20 products by opportunity score can also be ranked by AI, which is what orders that list and what pre-ticks up to three products for you. That request carries the same kind of thing and no more: title, current price, currency, margin percent and its strong, healthy, thin or unknown label, 30-day units and whether they were measured, opportunity score, how much sales history backs that row, and a single true-or-false for whether the product’s price changed recently. No Shopify ids, no product tags, no revenue figures, nothing about a shopper. Each product is numbered by its position, exactly as in a price suggestion.

The difference from Suggest is that this one is remembered: a ranking is kept for 12 hours so opening the picker repeatedly does not ask repeatedly. It is stored against the products themselves rather than their position in that day’s list, so adding a product to your catalogue cannot shift one product’s recommendation onto another. Where the model gave a reason, it is printed under the product in the picker — a recommendation you cannot see the reasoning for is just a list that has quietly rearranged itself. If the ranking is unavailable for any reason, the list simply keeps its opportunity-score order and nothing is pre-ticked beyond the top three by that score.

The two settings act in sequence rather than independently. Minimum visitors per variation decides when a result may be calculated at all; the confidence level decides when the calculated result is strong enough to call a winner. Neither one alone will produce a decision.

Confidence is a false-winner budget. At 90% you accept roughly a 1-in-10 chance that a variation is called the winner when it was really no better than the control; at 95% that becomes about 1-in-20. The protection is not free: for the same real lift, 95% needs meaningfully more traffic and more orders, so tests take longer and fewer of them reach a decision. For price testing, 90% is usually the better trade, because a wrong call is reversible — you can revert the price — while a test that never finishes teaches you nothing.

Internally the setting is stored as confidence (0.90), and the maths uses its complement as the significance level, alpha (0.10). At 95% the alpha is 0.05. When a test has more than one challenger, that alpha is divided across the challenger-versus-control comparisons, so a three-variation test demands stronger evidence per comparison than a two-variation test. Running several variations therefore costs traffic; it does not quietly raise your false-winner risk.

The percentage shown on a running test is not this setting. It is the current strength of evidence, calculated as one minus the p-value of the sequential test, and it moves as orders arrive. So a test set to 90% may read 62% one day and 91% the next. The setting is the line that reading has to cross. Until the sample floors are met, no reading is shown at all: the test reports what it is still waiting for instead of a percentage, because a confidence figure drawn from a handful of orders is not merely imprecise, it is wrong.

Because the evidence is sequential rather than fixed-horizon, you may look at a running test as often as you like without weakening the guarantee. A conventional t-test or z-test assumes you look once, at a sample size fixed in advance, and loses its false-positive protection if you stop the moment the number looks good. That is the trap sequential testing is built to avoid, and it is why there is no penalty for checking daily.

Reaching your confidence level is what calls a winner, but it is not on its own what lets Priceify write a price to your catalog unattended. Automatic writes additionally require a conversion-rate goal, confirmation from the exact conversion test rather than the directional one, and 14 days of outcome maturity so refunds and cancellations have landed. Revenue-per-visitor goals always wait for your review.

Two things confidence does not mean. It is not the probability that the variation is better — it is the probability of seeing evidence this strong if the variation were in truth no different. And it says nothing about how much better: a 95% result on a +1% lift is a reliable finding about a difference too small to matter commercially. Read the confidence figure to decide whether the difference is real, and the lift to decide whether it is worth having.

A running test keeps the confidence level it launched with. Changing this setting applies to tests you create from then on, which is what keeps a test that is already collecting from being judged against a bar that moved underneath it.

Set it once and it applies to every test — Create no longer asks for it. The floor is per variation, and it is measured against the variation with the fewest visitors, not against the total across the test. A two-variation test at 5,000 needs 5,000 in each arm, so 10,000 visitors overall — and if a 50/50 split has drifted, or one arm is a smaller audience, the slower arm holds the whole test. That is deliberate. A comparison is only as strong as its weaker side, so calling a result off a well-populated control and a thin challenger would be reading noise.

While a test is below the floor it tells you which floor is binding and how far the slowest variation has got — for example, waiting for 5,000 visitors per variation, lowest variation has 3,180. The Confidence figure reads as a dash rather than a number during this period. Seeing a percentage there would invite a decision the evidence cannot yet support, which is the single most common way a price test is called wrong.

Visitors are not the only floor, because visitors are not the unit the decision is made in. A price test compares conversion rates and revenue per visitor, and both are driven by order counts. So a second floor requires 100 conversions in every variation, and both floors must be met. 5,000 visitors sounds substantial, but at a 0.4% conversion rate it is 20 orders, and at 20 orders a +40% lift can appear and then evaporate as the test continues — regression toward the mean, not a price effect. Priceify never calls a result on fewer than 10 conversions per variation whatever else is configured.

Setting the minimum very low does not buy you faster answers. The conversion floor still applies, and the sequential evidence still has to reach your confidence level, so a low visitor floor mostly just moves the point at which the waiting message switches from counting visitors to counting orders. Setting it very high has the opposite risk: a test can be configured so that it will not plausibly finish, which is why Review quotes a feasible collection window and flags the cases it cannot support.

The floor is not the same thing as the planning reference, and the two answer different questions. The floor is the earliest a result may be read. The planning reference is the sample the statistics actually expect to need, calculated per product from its own conversion rate, the 10% target lift, your confidence level, 80% power, and the number of challenger comparisons. A product whose planning reference is far above your floor will usually keep collecting well past it; a product with strong traffic may clear both quickly.

Target lift and power are the two planning inputs you do not choose. Target lift is fixed at 10% — the smallest relative conversion improvement the planner sizes for, and the width it also uses to calibrate sequential evidence. Power is fixed at 80%, the chance of detecting a lift that size when it is real. Neither is a promise about your result: a test can find a much larger lift, or none. They set how much traffic the plan expects to need, which is why Review’s timeline moves when a product’s own conversion rate does but not when your confidence level is the only thing you changed.

Review shows a whole-week collection range only when current traffic can support a practical 2–8 week test. Longer calculations are labeled not feasible and replaced with the eligible visitors/day needed to reach the selected minimum by 8 weeks. When orders accumulate more slowly than visitors, the window is quoted from the conversion floor and says so.

For a new store without enough measured product traffic, shop-level traffic is only a low-confidence planning prior. Broadening the audience or raising test allocation on the Audience step will shorten collection, but neither lowers your minimum sample or invents a shorter statistically valid timeline.

A running test keeps the floor it launched with, so raising or lowering this setting never changes what an in-flight test is waiting for. A follow-up round queued after a winner is applied is the exception, and it applies to both settings: because it is a new test you review and launch rather than a continuation, it takes the minimum sample and confidence level in force at that point. What it does carry over from the previous round is what that round measured about the product — its conversion rate and baseline — since those are observations rather than preferences.

No winner is called until every variation has reached this many conversions, however many visitors it has seen. It sits alongside minimum visitors per variation: a result needs both the visitors and the conversions.

Visitors are the wrong unit for the decision. A price test compares conversion rates and revenue per visitor, and both are driven by order counts. 5,000 visitors per variation sounds substantial, but at a 0.4% conversion rate that is 20 orders — and at 20 orders a +40% lift can appear and then vanish as the test continues. That is regression toward the mean, not a price effect.

The floor is also what makes the statistics valid rather than merely tidy. The confidence figure comes from a normal approximation whose variance estimate needs a minimum number of conversions per arm; below roughly 10 the number is not conservative, it is wrong. Priceify therefore refuses to read a result under 10 conversions per variation under any circumstances, and sits its own floor at 100.

This is not a substitute for planning. The required sample still comes from the product’s conversion rate, the target lift, your confidence level, and power — a flat conversion count cannot replace that calculation. The floor exists to stop an early sequential call from being made on a handful of orders.

It sits at 100, which is what 5,000 visitors produces at the 2% baseline the planner assumes, so it and the default minimum visitors per variation describe the same test. Review folds this floor into its timeline: when conversions take longer to accumulate than visitors, the collection window is quoted from the conversion floor and says so. There is no field for it in Results settings, because it is a validity floor rather than a preference — a result read below it would be wrong rather than merely early. It is stamped onto each test at launch alongside the minimum visitors per variation from Results settings.

One metric decides the test. Revenue per visitor is the default and usually the right one for a price test: raising a price often trades a little conversion for more revenue per shopper, and revenue per visitor is the number that tells you whether that trade paid. Conversion rate answers a narrower question — how many shoppers bought — and ignores what they paid, so a price rise can look like a straight loss on it.

The choice also decides how far the statistics can go on their own. Conversion rate is the only metric with an exact sequential boundary behind it, so it is the only one an automatic price write will ever act on. Revenue per visitor is measured against an estimate of order-value spread, which is enough to inform your judgement and not enough to authorise an unattended price change — a revenue-per-visitor winner always waits for you to apply it.

Secondary metrics and custom goals are no longer set on new tests. A test launched with them keeps them, and keeps reporting them, so its history still reads correctly.

Profit per visitor is no longer offered. Cost of goods was taken as one shop-wide percentage rather than per-variant cost, which made the metric revenue per visitor scaled by a constant: it ranked every variation identically while reading like a separate measurement. A test launched on it keeps it, and keeps reporting under that name, so its history still reads correctly.

Classic tests can be read at any time. A fixed-horizon p-value cannot: checking it repeatedly and stopping at the first good-looking moment inflates false positives well past the stated confidence. Priceify therefore reads results with a sequential boundary, which is built to be looked at continuously without that penalty.

Two layers do the work. The directional layer is a mixture-SPRT and covers every metric, including revenue per visitor. It estimates variance from running totals, and value metrics use an average-order-value proxy rather than order-level spread, so it is evidence to weigh rather than a decision to act on unattended.

The confirming layer applies to conversion rate only, and it is exact. Randomised assignment means that if both prices convert equally, any given order came from the challenger with a probability fixed by the traffic split alone — the store’s actual conversion rate drops out of the arithmetic. That turns the order stream into a known coin, so the boundary needs no variance estimate, no normal approximation, and no minimum sample for its own validity.

After the minimum sample and conversion floors, review each product’s evidence, traffic quality, effect size, and guardrail status. Apply winner stays available on the directional read, so manual winner review per product is what releases anything the exact layer has not confirmed. Automatic catalog writes wait for that confirmation as well.

Auto-apply writes a winning price to the Shopify catalog without asking. Because that is expensive to undo, every one of these has to hold: the metric is conversion rate, both sample floors are met, the exact boundary agrees with the directional one on the same winner, the traffic split matches the test’s allocation, no guardrail has been breached, and the test has run at least 14 days.

The 14 days are about time rather than volume. A week carries its own shape — weekday and weekend shoppers do not behave alike — so a result measured over a single week can be a calendar artefact at any sample size. Two full cycles also give recent orders room to be cancelled or refunded before a price is committed.

Revenue-per-visitor results never auto-apply. Their spread depends on order values, which vary far more than a yes-or-no conversion, and Priceify measures that spread with a proxy. A proxy is enough to inform your judgement and not enough to authorise an unattended price change.

Each product decides on its own. One SKU reaching a verdict writes only that SKU’s price; its siblings keep running until their own evidence arrives. A control win ends that product with the catalog price untouched.

Once all of that holds, a review window still runs before anything is written — three days, counted from the moment the product reached a decision and you were emailed about it. Applying a product yourself at any point during the window cancels the automatic write for it.

Automatic writes are off, and Priceify deliberately offers no way to switch them on: a price written to your catalog without a person looking at it is not a default worth making one click away. A store that wants them runs with them enabled at the account level. If yours is one, the Overview tab says so and names the date of the next write, and that same banner carries the switch to turn them off — which leaves every finished product waiting for you to apply it, and takes nothing already written back.

A test covering ten products is ten independent tests. They almost never finish together: a high-traffic SKU can have a confirmed winner in a fortnight while a slower one is still weeks from its sample floor, and a third may be better off on its control price. Ending the whole test to act on the first is a false choice, and waiting for the slowest one costs you the lift you have already measured.

The Overview tab therefore includes Product performance by variation: one row per product with status, decision, and per-variation metrics. Use Apply winner when a product is ready, or Apply ready products when several are ready at once. Each row shows why the product is in that state; opening a product shows the per-variation numbers and the evidence behind the call.

Apply on a row writes that one product’s price and stops that one test. Apply all ready does the same for every finished product in one action, skipping anything still collecting or blocked, and reports separately on any that failed. A control win or a winning offer has no catalog price to write, so those rows finish the product instead. Either way the rest of the test keeps running.

A product the revenue guardrail stopped never gets Apply winner on its row. The guardrail fires because a variation lost money against control, so applying that price would act on the exact reading the guardrail rejected. Those rows say what the drop was and against which limit, and they stay on their original price — nothing was written to your catalog.

You are emailed the first time each product reaches a decision, at your store’s Shopify contact address. Products that cross over together are batched into one message, and each product is only ever mentioned once, so a slow-finishing test does not turn into a mailing list. If a message cannot be sent the products stay queued for the next attempt rather than being silently dropped.

A finished round tells you something about the product’s price sensitivity, and the useful next question is usually narrower than the first one: if +10% won, is +15% better still? Priceify therefore queues a follow-up test for a product that finished a round, seeded from what that round measured.

It arrives as a draft, and nothing about it is automatic beyond the drafting. It appears on your tests list for you to open, adjust the prices in, and launch — or delete. No price reaches your catalog because a round rolled over, and no traffic is assigned to a follow-up you have not launched.

Because a follow-up is a new test rather than a continuation, it takes the confidence level and minimum visitors per variation in force when you launch it, not the ones its parent ran with. What it does inherit is what the parent measured about the product — its conversion rate and baseline — since those are observations rather than preferences.

Each product may go three rounds. The cap is there because iterating on a price forever is a way of eventually finding a winner by chance rather than by effect, and because a product whose third round is still inconclusive is telling you its price is not the lever.

On the Products step, set one offer per test variation. Control stays at the catalog price with no discount so you can measure the offer against the current price.

Assigned shoppers see a sale cutout on the product page: catalog price struck through, the offer price beside it, and the offer message — or the offer amount if you left the message empty — under that cutout. Checkout applies the discount through the Priceify checkout function.

Offer tests need Checkout pricing functions on Store setup. Price tests still need Theme connection and a mapped product-page price location.

Each row has three parts. Surface is where on the store the price appears — product page, collection page, cart, search results, home page, recommendations, quick view, any page, or one specific URL. Role is which price on that surface: the regular price, the struck-through compare-at price, a unit price, and so on. Selector is the CSS selector that finds that price in your theme’s markup. Save applies the table to every price test on the shop; a test already running picks it up on the next page view.

Only the product page regular price is genuinely required. Every other surface is optional, and leaving one unmapped means Priceify does not touch prices there — it does not guess. That is the safe default, but it does mean a shopper can see the test price on the product page and the catalog price on a collection card, so map the surfaces where your prices are visible together.

Start with Auto-detect prices. It reads your theme’s price templates, verifies each candidate against your live storefront, and saves automatically when the product-page regular price and theme confidence pass checks. Otherwise you review matched rows, save, and use Pick on site for gaps. Selectors are never invented: anything not found on a real page stays unmatched. Pick is for custom sections, app blocks, or bundle widgets — click the price in preview to capture a selector.

Specific URL is for a page that is not a page type. Surfaces are otherwise recognised from the path, so /products/ is a product page and /collections/ a collection page, but a hand-built landing page has no such signature: every /pages/ URL looks alike. Choosing Specific URL replaces the Role column with a page URL box, and that row then applies on that page only. Paste the URL from your address bar; the query string is ignored, so a link carrying campaign parameters still matches, and so does the same page in another language.

A Specific URL row is deliberately narrow. It cannot stand in for the product page — the readiness check still reports the product page as unmapped until a product page row exists — and it is pinned to the regular price, because a page is not a kind of price. Two rows may share a selector as long as they name different pages, which is what lets one theme class serve several landing pages.

A row is only as good as its selector. Priceify writes the price text into the node the selector finds, so a selector that matches a whole price block rather than the amount inside it can flatten the surrounding markup; the painter resolves down to the amount where it can. It also refuses to paint a compare-at node from a regular-price row, so a struck-through price is never quietly rewritten as the live one. If a row’s selector may not target a price at all, the table says so under the table rather than waiting for you to find out on the storefront.

Themes change. A theme update, or switching theme entirely, can rename the classes these selectors depend on, and a stale selector paints nothing rather than painting something wrong. Re-run Auto-detect prices after a theme change and check Store setup readiness, which reports a missing product page price location as a blocking gap.

Use the same snippet bodies you would in the visual editor: CSS selectors and declarations, or JavaScript statements—not full HTML script or style tags (those are stripped if pasted).

JavaScript is compiled before save; fix any syntax error shown under the field. CSS checks for balanced braces.

Turn a snippet off with Enabled without deleting it. Empty snippets do nothing on the storefront.