Measure a promotion’s blast radius before it changes a live price.
PrestaShop already has cart rules and catalogue price rules. The harder job is controlling scope, stacking, contribution, timing and cleanup. Model those decisions, then inspect the exact NP Promo Pro workflow before buying.
- €99
- one-time licence, ex VAT
- 1.0.2
- current self-hosted release
- PS 8 + 9
- published scope; verify exact build on staging
- 7
- shipped back-office and storefront languages
The rule type matters less than the control around it.
Define the catalogue scope
Name the exact shop, category, products, brand, supplier or customer group. An empty or misunderstood scope can touch far more prices than intended.
Set a contribution floor
Calculate the discount against contribution, not only revenue. Choose the minimum amount the merchant is prepared to retain after the promotion.
Model stacking explicitly
Existing specific prices, cart rules, group discounts and other modules can change the effective result. Test the combinations the store actually permits.
Plan the exit before launch
Assign an end time, redemption cap, reviewer and rollback test. Expiry is not enough if generated objects or caches remain after the campaign.
Test the discount against your own contribution floor.
The model applies the primary discount, then an optional stacked percentage to the remaining basket. The redemption cap is a worst-case boundary, not an order forecast.
- Contribution before discount
- €35.00
- Nominal discount per redemption
- €15.00
- Effective sequential discount
- 15.0%
- Share of contribution consumed
- 42.9%
- Contribution after modeled discount
- €20.00
- Buffer above your floor
- €10.00
- Maximum nominal exposure at the cap
- €1,500.00
Planning aid only. Assumes contribution costs do not change and percentage discounts apply sequentially. Excludes VAT, shipping, payment fees, returns, rounding, fixed discounts, gifts, BOGO item mix and legal or accounting treatment. It predicts neither redemptions nor sales lift. Inputs stay in this browser.
Build, preview and account for the generated objects.
1. Scope the rule before it touches a price
Choose the effect, catalogue or customer scope, date window, priority and stacking policy in one workspace. The merchant still owns the economics of the rule.
Open this exact product scene →
2. Preview the catalogue change
Review the intended old and new prices before applying a bulk flash-sale action, then keep the CSV as a bounded record of the planned change.
Open this exact product scene →
3. Account for generated rules and prices
Inspect the application ledger that counts CartRule and SpecificPrice objects created by the module, and test deletion or uninstall on staging.
Open this exact product scene →
Test the places where promotion rules usually surprise the operator.
| Failure point | Published product evidence | Your staging test |
|---|---|---|
| Scope expands unexpectedly | The campaign builder publishes explicit catalogue targeting and a dry-run preview before apply. | Use products that should match and products that must not; compare the preview count and exact list. |
| Discounts stack differently | Priority and stacking policy are visible rule settings; the module does not decide the merchant’s policy. | Exercise one existing specific price, group discount, cart rule and coupon in every allowed combination. |
| Checkout total differs | The workflow exposes the intended catalogue output, not a universal promise about every tax, currency or theme combination. | Verify product, cart, checkout, order and invoice totals for the store’s actual tax, currency and customer groups. |
| Campaign does not exit cleanly | The application ledger identifies the CartRule and SpecificPrice objects generated by the module. | Delete one staging campaign, clear relevant caches and verify prices, cart totals and generated-object counts return to baseline. |
Use native rules when they already cover the operating job.
Stay native for a simple rule
A single voucher, product reduction or catalogue price rule with a small known scope may need no extra module. Document it and test the cart.
Consider a module for an operating system
Multiple campaign types, repeated bulk repricing, shared targeting, dry-run review and generated-object accounting are an operating workflow rather than one rule.
A broader rule engine is useful only when the team can validate it.
Good fit · recurring controlled campaigns
The team repeatedly runs catalogue and cart promotions, has a margin floor and can review a dry-run before applying.
Conditional fit · existing promotion stack
Map every current writer to CartRule and SpecificPrice, then stage overlap and cleanup before replacing anything.
Poor fit · unsupported scope or promised uplift
Release 1.0.2 does not cover geo, currency, language, per-combination or wholesale-base targeting, and no promotion module can guarantee conversion or average-order growth.
Before a campaign reaches production
- Does a PrestaShop discount module guarantee more conversion or a higher average order?
- No. A module can apply and present a promotion, but buyer response depends on demand, products, price perception, traffic, competition and campaign design. Establish a baseline and measure attributable orders without assuming lift.
- Why not use PrestaShop native cart and catalogue price rules?
- Use them when they cover the job. NP Promo Pro is aimed at stores that need catalogue repricing and automatic cart promotions in one workflow, plus shared targeting, dry-run review, confirmation and an application ledger. It should not replace a simpler native setup without a reason.
- What is the difference between a catalogue price edit and a cart promotion?
- Catalogue edits affect the price shown for matched products through SpecificPrice records. Cart promotions evaluate cart conditions and apply CartRule effects such as BOGO, 3×2, a cart-total reduction or free shipping. Test both storefront display and checkout totals.
- What is a safe discount percentage?
- There is no universal safe percentage. Use contribution margin rather than revenue alone, include tax, shipping, payment fees, returns and stacking, choose a merchant-approved floor, and model the maximum nominal exposure before launch.
- Which PrestaShop versions are currently covered?
- NP Promo Pro 1.0.2 publishes a PrestaShop 8 and 9 scope. Because the current public evidence does not name every tested patch release, treat the exact store build, theme, checkout and promotion interactions as a staging gate rather than assuming compatibility.
- How should I validate a campaign before launch?
- Use a staging clone and synthetic carts. Verify in-scope and out-of-scope products, group and currency combinations, taxes, rounding, stacking, start and end time, cache behavior, checkout, order, invoice and campaign deletion. Keep the dry-run export and rollback evidence.
- Are the planner values sent to Neuroplugin?
- No. The calculator runs in the browser and does not send the basket, margin, discount, floor or cap values. With analytics consent, the site may count navigation events such as opening the product experience, not the private inputs.
Open the real promotion control path.
Inspect campaign scope, catalogue preview and the generated-object ledger. The product page keeps price, release identity, current scope limits and installation steps visible.