Welcome popups and purchase notifications in PrestaShop
Plan welcome offers and truthful sales notifications with sensible targeting, dismissal, privacy controls and measurement.
Use a popup for a specific offer or useful message, and make it easy to dismiss. For purchase notifications, distinguish genuine orders from generated content before you publish anything.
What we would do
We would start with the hesitation you need to resolve, then check whether your existing theme or modules already provide a suitable message. The route depends on your checkout, newsletter integration, consent controls, order data, customer groups, languages and markets, and who in your team will maintain the offer. Leave purchase notifications off if the evidence or privacy checks do not support them.
Make the change on a private staging copy with the real theme and module combination, isolated from live customer emails and order exports. Rehearse the display, dismissal and buying journey, then switch on the agreed campaign during a planned live window. Save the previous settings and identify the control that disables the campaign if it obstructs a purchase.
If you want an existing module configured and the affected journey checked, the PrestaShop Module Installation & Configuration Service covers that agreed setup.
Choose the purpose before the popup
Use module or theme code for your promotional popup. The Classic theme also uses modals for product imagery, so a dialog on your shop is not necessarily a promotional campaign.
Separate three jobs: an entry offer asks for an action, a customer-requested dialog supplies information, and a purchase notification displays activity. They need different timing and success measures.
Choose a format from the table, then use its final column as the condition for turning it on.
| Purpose | Possible format | What to protect | Decision before enabling |
|---|---|---|---|
| Newsletter or first-order offer | A restrained welcome card or banner | Access to the page and the offer's margin | Confirm the promised benefit can be delivered and redeemed. |
| Size guide or requested details | A dialog opened by a button | Keyboard access and a clear return to the product | Use an explicit request when the customer needs information while choosing. |
| Cart assistance or related product | A contextual message after an action | The customer's route to payment | Use only if it answers a cart question without delaying payment. |
| Recent purchases | A small dismissible notification | Truthfulness, customer privacy and screen space | Leave off if eligible order records cannot support the message. |
| Seasonal announcement | A dated banner or card | Accurate offer dates and stock | Prefer a banner when the announcement does not need a dialog. |
A popup cannot repair unclear product information, unexpected delivery costs or a broken checkout. Fix those before adding another interruption.
Match triggers to the page and device
A timed trigger waits for a delay; a scroll trigger waits for a page position; a click trigger responds to a request. Desktop exit intent estimates departure from pointer movement. It cannot prove that a customer was about to leave.
Phones do not provide the same cursor signal. Scroll-up, tab changes and time delays are separate heuristics with their own false positives. Do not assume an exit-intent rule has no downside or that one trigger is best for every shop.
Use page and visitor context where your implementation supports it. A first-order offer is a poor match for an established customer, and a category reading aid is different from a cart reminder. Keep promotional overlays off checkout and payment-return pages.
If your Welcome Popup configuration offers a timed delay and all-pages or homepage scope only, it does not supply a general exit, scroll and click campaign selector. Its all-pages option does not automatically exclude checkout. See the Welcome Popup help for setup.
The catalogue describes broader campaign controls, including presets, page and audience rules, scroll and add-to-cart triggers, campaign dates and subscriber handling. Confirm which controls your installed release exposes. Storefront display stays off until the first campaign has been reviewed, so check the review and enablement state before testing. Subscriber recognition and logged-in-customer suppression need their own rules; a dismissal cookie alone does not identify either group.
Make the welcome offer useful and deliver it
Lead with what the customer gets. A first-order discount, genuinely free delivery, a useful buying guide or early access can each be an offer. Choose one that fits your catalogue and margin. Do not claim one format always produces better subscribers.
- State any minimum order, product exclusions and expiry clearly.
- Give the visitor time to understand the store before asking for an email.
- Keep the message brief and the action clear.
- Use a visible close button and neutral dismissal text.
- Check that the offer works on a real eligible order.
A ten-percent discount is a cost, not a conversion result. Measure the order's contribution after the offer, delivery and acquisition costs.
Connect the signup to the intended email flow. If you promise a code or download, test its delivery and redemption. A signup field alone does not confirm an automatic welcome sequence.
A welcome campaign for a technical catalogue
Suppose you sell technical equipment and want qualified subscribers without another discount. Offer a useful selection guide, with a homepage message that explains what it helps the reader choose. Use the existing newsletter system for delivery, rather than assuming the popup sends the guide.
- On staging, choose Homepage only in the simple configuration, or the equivalent explicit campaign rule. Check a direct product landing, cart, checkout and payment return to confirm the message stays absent.
- Set a delay that lets the homepage be read, then compare phone and desktop behaviour. If the message still dominates the page, use an inline signup or banner.
- Submit a test address through the intended consent and confirmation flow. Follow the received link and check that the promised guide is accessible.
- Repeat as an existing subscriber and a logged-in buyer. If suppression is required but unavailable, resolve that integration before launching a new-customer-only claim.
Handle dismissal and storage deliberately
Coordinate your welcome offer, cookie controls, chat and other notifications so they do not stack. Decide which campaign takes priority when several qualify, and suppress competing promotional messages during that visit where supported. Choose a restrained display limit and a cooling-off period based on customer behaviour.
Welcome Popup writes its suppression cookie when an opened popup is dismissed. Showing it is not the same as recording dismissal. Reloading or navigating before dismissal can cause another appearance. A positive cookie duration persists for that many days; zero creates a session cookie.
If dismissal does not persist, close the popup and inspect whether the suppression cookie was written, its expiry and its domain/path scope. Repeat on a later page. Distinguish navigation before dismissal from a rejected write or mismatched scope before increasing the cooling-off period.
sessionStorage is normally limited to the tab's page session. It cannot implement a reliable week-long suppression across closed tabs and later visits. Persistent suppression needs suitable browser or account-side storage.
Changing from cookies to sessionStorage does not bypass consent requirements. Assess the storage purpose and applicable exemption under the ePrivacy storage guidance. Keep essential controls usable when optional storage is refused.
Separate real orders, generated content and timing
Sales Popup has real, generated and mixed modes. Its default is mixed, which can supplement real orders with generated notifications. You must explicitly choose real orders only if the cards claim that actual customers purchased.
Never present a generated name, location, product purchase or timestamp as a real transaction. If you use simulated notifications in a demonstration, label the simulation clearly. For a quiet live shop, use genuine reviews or measured historical sales instead of inventing activity.
Real mode selects recent order records. The display interval is independently configurable; it does not follow the live arrival rate of orders. A notification appearing now is not proof that the order was placed now. Keep any time-ago label true to the underlying order.
Sales Popup's real-order query uses the order's valid flag, positive-price order lines and the selected shop and age window. That does not independently confirm payment settlement or exclude every later refund. Check the actual records and product relevance before displaying them. Exclude test orders; use custom filtering if your purchase claim needs stricter payment, cancellation or refund checks.
For a custom implementation, orders, line items and delivery locations come from the prefixed orders, order_detail and address tables. Use the order's delivery-address relationship, and select only the fields needed.
Use the Sales Popup help for source mode, template, timing and placement configuration.
Trace a notification before trusting it
Suppose a coffee-equipment page shows a grinder purchase. On the private copy, match the displayed product and purchase time to an eligible order, check the selected shop, and inspect the delivery location used by the template. Then review what happens when the source has no eligible orders: keep the notification absent rather than substituting an invented purchase. If a record repeats, its wording must still describe the original purchase time. Category relevance is useful only if the installed implementation actually filters for it: a genuine purchase from an unrelated category offers little reassurance about the product being considered. Keep purchase notifications on the intended browsing pages and exclude cart, checkout and payment-return pages.
Minimise purchase data and handle signup consent
A truthful purchase can still disclose personal data. A name initial, city, product and precise purchase time may identify someone together. Removing a surname does not guarantee anonymity.
The real-order notification data includes a first initial and delivery city. Remove identifying placeholders where they are unnecessary. Consider whether even the product and location reveal a sensitive purchase. Check your lawful basis, transparency information and retention policy before publishing customer activity.
Prefer an aggregate or generic factual message when you cannot justify exposing individual order details. The European Commission's GDPR guidance explains the scope of personal data and your obligations.
For email capture, explain what the person is signing up for, link the privacy information and avoid preselected marketing consent. Keep the signup record and the consent wording used at that time. Test an invalid address and a repeated signup too: the result should be clear without silently changing an existing subscriber's preferences.
A confirmation email can help you check control of the signup address. Choose the confirmation process appropriate to your audience and configure and test the newsletter system's actual flow.
Check hooks, mobile access and performance
A display hook is a markup insertion point. It does not guarantee an unchanged PageSpeed score. PHP still reads settings and renders output; notifications can also make browser requests.
Welcome Popup registers both displayFooter and displayBeforeBodyClosingTag. The first eligible render wins through a duplicate guard. Asset registration is separate, so do not promise that every theme inserts all output at one exact location.
For portable page scoping, use a hook the theme actually renders and explicit controller checks. Do not assume a hook named displayFooterCategory is available everywhere.
Follow Google's interstitial guidance: keep content accessible and prefer a small banner when it serves the purpose. Mandatory interstitials have a specific context. A timer, scroll threshold or login label is not a universal exemption.
- Test a narrow phone viewport, zoom and long translations.
- Keep the close control large enough to operate easily and ensure the popup does not cover the buy button, consent controls or chat.
- Test keyboard opening, focus management, Escape and focus return.
- Respect reduced motion and avoid repetitive screen-reader announcements.
- Measure scripts, requests, layout shift and interaction delays before and after.
- Check empty responses, rejected storage and network failures.
- Change language and customer group, then revisit through the same cache the live shop uses. Check that the message, offer and audience rule still match.
Test the outcome and consider quieter alternatives
Track impressions, actions and dismissals, including how quickly people close the message. Define popup action rate as actions divided by popup views, and record what counts as an action. Follow subscribers and offer recipients through to valid orders.
Compare purchase rate, revenue per visitor, discounts and margin with a control group. Keep assignments stable, and avoid changing several offers or triggers in the same experiment. A before-and-after comparison can be affected by traffic mix, campaigns and seasonality.
Choose sample size and duration from baseline conversion, expected effect and the decision you need to make. Thirty days or a few hundred orders alone cannot guarantee a reliable verdict. Inspect device differences using your own traffic data.
If signups rise while contribution per visitor falls, inspect discount use, order quality and interruption before keeping the campaign. A click on a purchase card may simply divert someone to another product, so notification clicks alone do not establish incremental sales.
If motion adds little, consider genuine review counts, product badges or historical sales totals. Total Products Sold Counter can show recorded demand without a moving notification; choose whether the figure means units, orders or buyers and make its period clear. Use current-viewer counts only when they are actually measured and accurately labelled. A static message can still mislead if its number or scarcity claim is invented.
What to ask your developer or agency
- Which installed release and controls support the requested pages, trigger and audience? Ask for test evidence from this theme and checkout.
- Where is the signup sent, who maintains the delivery flow, and how can staff trace a missing guide or code?
- Which source mode, order filters and template placeholders produce a purchase card? Demonstrate how eligible, unpaid, cancelled, refunded and test orders are handled, what appears when no eligible records remain, and which exclusions use installed settings rather than custom filtering.
- Which settings and consent text were approved for each language, who stops an expired offer, and where are the reversal steps?
After switching on the live campaign, check its scope, dismissal and the buying route again. If it blocks a control, exposes unintended data or delivers the wrong offer, disable it with the agreed control and investigate before re-enabling it.
Questions owners ask
Can I start with a banner and add a popup later?
Yes. Use the less intrusive format as the baseline, then test whether an overlay improves the same business outcome enough to justify its interruption.
Can I publish the staging database to launch the campaign?
Transfer the reviewed campaign settings or use a supported configuration export. Do not overwrite the live database with a staging copy that lacks orders and customer changes received since it was made.
Can I reuse the live newsletter connection on staging?
Use a test list or isolated destination and prevent automated messages reaching real subscribers. Rehearse the delivery flow with controlled addresses, then check the intended live destination at launch.
Do I need a new module when the popup is missing?
First inspect campaign enablement and dates, page eligibility, suppression state and the rendered hook, then check browser errors and cached output. Ask for a reproducible fault before replacing a module.