Last reviewed June 2026 — the native ps_emailsubscription behaviour, table columns and double opt-in toggle described here are current for PrestaShop 1.7, 8.x and 9.x.
Your PrestaShop store almost certainly has a newsletter box in the footer already. It collects email addresses into a database table you've probably never opened. That's the trap: a sign-up form is not an email list. A list is an asset you own and can re-reach for free, while social followers are an audience you rent from Meta or Google and pay to reach again. The difference between the two is everything you do before the address lands in your database — how you ask, where you ask, and whether the consent behind it will survive a GDPR complaint.
This guide is specifically about growing the list the right way on PrestaShop: what the native ps_emailsubscription module records (and where), how to make collection genuinely GDPR-defensible, and the capture points across a PrestaShop store that actually move sign-up numbers. It deliberately stops at the database. Choosing a sending platform, segmenting the people you've collected, and the automated sequences you send them are their own jobs, and each has its own guide — linked at the points where you'd otherwise be tempted to skip ahead.
What ps_emailsubscription actually does — and where the data lives

PrestaShop ships with a native newsletter module, ps_emailsubscription, that renders the footer sign-up field via the displayFooterBefore hook and adds the registration-form checkbox via additionalCustomerFormFields. It's a collection tool, not a marketing tool, and knowing exactly what it stores saves you from migrating bad data later.
- Guest sign-ups (someone who isn't a registered customer) land in the ps_emailsubscription table — with the email, the newsletter_date_add, the ip_registration_newsletter, the http_referer (the page the sign-up came from), and an active flag.
- Registered customers are different: their opt-in is the newsletter column (plus newsletter_date_add and ip_registration_newsletter) on the ps_customer row, not the subscription table. So your real list is split across two tables — a detail that manual or custom CSV exports and weaker connectors often miss, dropping one source unless they're explicitly configured to read both.
- There's no default Customers → Newsletter menu — instead the list of guest subscribers and the CSV export live inside the module: Modules → Module Manager → ps_emailsubscription → Configure. There you toggle the verification (double opt-in) email and the post-subscription confirmation email, and set the welcome voucher (if any).
[SCREENSHOT: ps_emailsubscription Configure screen in the back office, showing the verification-email toggle, the confirmation-email toggle, and the Welcome voucher code field]
What it deliberately does not do: send campaigns, render templates, or track opens and clicks. It can, however, run a true confirmed (double) opt-in flow — that's the "verification email" toggle in its Configure screen, which we'll come back to. Note the module's two distinct emails: the verification email is the consent gate (the subscriber must click a link before they go active), while the separate confirmation email is just a post-subscription welcome message. For everything past collection — the platform that actually sends, and how to pick one (Mailchimp, Brevo, Klaviyo, Omnisend, ActiveCampaign) — start at email marketing for online stores, which routes to each platform guide.
Collect it so it survives a GDPR complaint
If you sell to anyone in the EU — and a PrestaShop store almost always does — the way you capture consent is the part most merchants get wrong, because the native module's defaults aren't enough on their own. The penalty ceilings are real (up to 20 million EUR or 4% of global annual turnover, whichever is higher), but the practical risk is more mundane: a list you can't prove consent for is a list a serious sending platform may refuse, and one a single complaint can unravel.
Confirmed (double) opt-in: turn it on, it ships natively
Confirmed opt-in means the subscriber clicks a link in a verification email before they're added as active. It does two things at once: it proves the address is real and belongs to the person, and it strengthens your consent evidence with a timestamp at confirmation. It doesn't, on its own, preserve a separate record of the exact consent wording you displayed — so keep a copy of that wording (and any confirmation evidence) alongside it if you need a complete trail. In Germany it's effectively required; across the rest of the EU it's the defensible default. The good news on PrestaShop: stock ps_emailsubscription already supports this — answer "yes" to "Would you like to send a verification email after subscription?" in the module's Configure screen and the flow flips. The guest is written to the table as active = 0, a tokenised verification email goes out, and only when they click the link does the dedicated verification controller activate them. Leave that toggle off and you get the looser single opt-in instead: the sign-up is marked active immediately, with an optional welcome ("confirmation") email. So the confirmed flow is a setting, not a third-party add-on — turn it on if you're collecting at volume.
Consent wording and the unticked box
A pre-ticked consent box is non-compliant under GDPR — the box must start empty and the visitor must actively tick it. The wording next to it should make four things unambiguous, in plain language:
- What they're signing up for — "marketing emails", "our newsletter" — not buried in legalese.
- Roughly how often — "a few times a month" sets an honest expectation and lowers later unsubscribes.
- Who's sending — your store / company name, not a generic "we".
- How to leave — "unsubscribe any time", with a link to your privacy policy visible near the form.
PrestaShop's own GDPR module (psgdpr) ties into consent surfaces and the data-access/export requests a subscriber can make; if you offer account-based sign-up, make sure the newsletter checkbox and the psgdpr consent are consistent rather than contradicting each other.
Record of consent — what to keep
GDPR expects you to show when and how each person consented. The native table already captures the date (newsletter_date_add), the IP (ip_registration_newsletter) and even the source page (http_referer) for guest sign-ups — so the raw consent record is more complete than most merchants realise. What it doesn't store is the precise wording shown at the time, which is why a screenshot or versioned copy of your consent text is worth keeping alongside it. When you graduate to a real sending platform, that platform should store the timestamp, IP and source automatically too — but the cleaner your PrestaShop-side capture is, the less you'll fight your data on migration day.
You can audit what you're actually holding in Advanced Parameters → Database → SQL Manager, which runs read-only queries — no risk to your data. This pulls your most recent guest subscribers with the consent fields the table records, so you can spot rows missing an IP or referer before you ever migrate:
SELECT id,
email,
active,
newsletter_date_add,
ip_registration_newsletter,
http_referer
FROM ps_emailsubscription
ORDER BY newsletter_date_add DESC
LIMIT 50;
An active value of 0 here means a subscriber who started double opt-in but never clicked the verification link — do not import those into a sending platform as if they confirmed.
Where to ask: the capture points that actually move the number
Most stores have exactly one capture point — the footer — and then wonder why the list grows slowly. The footer is the floor, not the strategy. Each of these reaches a different visitor at a different moment of intent, and they stack. (Treat the percentages below as widely-cited directional ranges, not guarantees — your real numbers depend on traffic quality and offer; measure them on your own store.)
| Capture point | Visitor it catches | Typical sign-up rate | PrestaShop note |
|---|---|---|---|
| Footer form | Already-interested, scrolled to the bottom | Low (often well under 1%) | Native ps_emailsubscription; no incentive, no friction — keep it, don't rely on it. |
| Incentivised pop-up | First-time / cold browser | Highest of the on-site methods | A timed/scroll-triggered popup with "10% off your first order" — see the rules below. |
| Checkout opt-in | High-intent buyer mid-purchase | Highest quality sign-ups | An unticked checkbox at order; for registered buyers this writes the newsletter flag on ps_customer directly. |
| Account creation | People committing to your store | Solid, warm contacts | The newsletter checkbox on the registration form — keep it unticked to stay compliant. |
| Exit intent (desktop) | Abandoning browser | Modest, but otherwise lost | Last-chance offer as the cursor heads for the close button; desktop only. |
The pop-up is the highest-volume of these, and also the easiest to get penalised for, so it has rules. Wait at least ~30 seconds or until ~50% scroll before it appears; show it once per session, not on every page; make it trivially closable (a large X and click-outside-to-dismiss); never fire it on the checkout — interrupting a buyer mid-purchase is the worst possible trade. On mobile in particular, an interstitial that covers most of the screen is exactly what Google's intrusive-interstitial guidance targets, so keep the mobile version small and dismissible. The mechanics of building one that converts without annoying anyone is its own topic — we cover the timing, the offer and the targeting in PrestaShop popups that actually convert.
The incentive that grows the list without poisoning it
The single biggest lever on sign-up rate is giving people a reason — and "10% off your first order" is the workhorse. But a discount incentive has a tail: it attracts deal-seekers, and if the code is the only reason they joined, they may unsubscribe the moment they've used it. Two things keep the quality up:
- Deliver the code through the verification step, not the form. If the discount only arrives after they click the verification link, you filter out fake and throwaway addresses and reinforce the opt-in at the same time. PrestaShop's native module sends the voucher (the Welcome voucher code field in its Configure screen) once the subscription completes — so with the verification email enabled, the code lands only after they've confirmed, rather than on submit.
- Match the incentive to the audience. A pop-up offer to a cold first-time visitor and a checkout opt-in to a committed buyer are not the same person; the buyer often needs no discount at all, just a clear "keep me posted on offers" box. Spending margin on people who'd have bought anyway is the quiet cost of a one-size incentive.
List hygiene starts at collection, not at clean-up
The reflex is to "clean the list later". The cheaper move is to not let bad data in. Confirmed opt-in already strips out typos and fake addresses at the door. Beyond that, two PrestaShop-specific habits keep the asset healthy:
- Don't let the two tables drift. Because guest subscribers live in ps_emailsubscription and customer opt-ins live on ps_customer, an export that only reads one of them silently loses half your list. When you sync to a sending platform, confirm it pulls both — or you'll be marketing to strangers and ignoring your actual customers.
- Respect the
activeflag and unsubscribes. An unsubscribe flips active to 0 (or clears the customer's newsletter flag); never re-import those addresses back into a "fresh" list. Re-mailing people who left is how a domain earns spam complaints — and complaints, not list size, are what wreck deliverability.
Deliverability is a sending-side discipline (SPF, DKIM and DMARC on your domain, a sensible sending reputation, list cleaning over time), and it properly belongs with whichever platform you choose to send from — covered in the email marketing channel guide rather than here. The point worth keeping at collection time: a smaller list of people who actively confirmed they want to hear from you will out-deliver and out-earn a big list of scraped or half-consented addresses, every time.
What to do once you've got a list (and where to go next)
Growing the list is step one; the value comes from what you do with it — and each of those is a deliberate hand-off, not an afterthought you cram into this page:
- Pick a sending platform. The native module can't send campaigns, so the next decision is which tool does. Compare them in email marketing for online stores, then go deep on the one that fits: Mailchimp for simple stores, Klaviyo for advanced segmentation and SMS, Omnisend for multi-channel, or ActiveCampaign when you need serious automation.
- Welcome the new subscriber. The most valuable email a fresh sign-up gets is the first one. What to send right after the opt-in — and after a purchase — is its own playbook: post-purchase emails.
- Re-engage the ones who go quiet. Every list develops dead weight; winning back lapsed subscribers (rather than just deleting them) is covered in win-back emails.
- Turn subscribers into advocates. A grown list is also a referral engine — your happiest contacts can bring you their friends, as in referral programs.
Email is still the channel you own outright, and the list is the asset under it. But the asset is only as good as the consent it's built on. Get the collection right on PrestaShop — know where the data sits, confirm the opt-in, ask in more than one place, and incentivise without poisoning — and everything you build on top of it, from your first welcome email to your sending reputation a year from now, starts on solid ground instead of a footer box nobody checks.
Frequently asked questions
How do I see and export my newsletter subscribers in PrestaShop?
Go to Modules → Module Manager, find ps_emailsubscription and click Configure. The guest-subscriber list and the CSV export button live inside that screen, not under a Customers menu. Remember that export covers only the ps_emailsubscription table (guests). Customer opt-ins are flagged on ps_customer.newsletter and are exported separately from Customers → Customers or via SQL Manager.
Is a pre-ticked newsletter checkbox legal under GDPR?
No. Consent must be a clear, affirmative action, so the box has to start empty and the visitor must tick it themselves. This applies to the registration-form checkbox and any checkout opt-in. PrestaShop's newsletter checkbox ships unticked by default — don't override that to pre-tick it.
What's the difference between the verification email and the confirmation email?
They're two separate emails in ps_emailsubscription. The verification email is the double opt-in gate: the subscriber stays inactive (active = 0) until they click its link. The confirmation email is just a welcome message sent after a successful subscription. You can run either or both; for GDPR-defensible collection, enable the verification email.
Can I import an old list of email addresses into PrestaShop?
You can technically import addresses into ps_emailsubscription, but only do it for contacts you have provable, GDPR-valid consent for. Importing a bought or scraped list, or re-adding people who previously unsubscribed, will draw spam complaints and damage the sending reputation of your domain — which then hurts even your transactional order emails. When in doubt, leave them out.
Why is my footer newsletter form collecting almost no sign-ups?
That's normal — the footer is the lowest-intent capture point, usually well under 1% of visitors, because it offers no incentive and sits where few people scroll. It's worth keeping, but the list grows when you add the other capture points: an incentivised pop-up for cold visitors, an unticked opt-in at checkout for buyers, and the registration-form checkbox. Each catches a different visitor, and together they stack.
Comments
No comments yet. Be the first!
Be the first to ask a question or share useful feedback.
Leave a comment
Share a question, an installation detail, or feedback that could help another reader.