PrestaShop Module: Shop Customers on Your Mailing List

Moving shop customers onto a mailing list is a job a PrestaShop module does more quietly and more accurately than a person with a spreadsheet. A CSV export looks like a simple solution. Until you count how many times a month you have to repeat it. A file downloaded on Monday describes the database as it was on Monday, nothing more. By Wednesday some accounts no longer exist, new registrations have come in, someone has withdrawn consent. And you are sending to a snapshot from last week, then wondering about the results.

Why a CSV export from the shop stops being enough

The consequences are predictable. Messages go to addresses that were deleted along with the account. Customers who signed up yesterday get nothing, because they appeared after the export. And at the next import the same people come in a second time, this time with a different spelling of the address, and the list swells with duplicates.

The biggest cost, though, lands outside the spreadsheet. Sending to dead addresses produces hard bounces, and bounces are a signal for the filters. The receiving server sees a sender who does not know their own database. Reputation drops slowly and comes back even more slowly. A few campaigns like that and you land in the promotions folder at providers who used to let you through. A stale database is only one of the reasons messages end up in the spam folder.

You need two things. First, a single source of truth about consent: a place where the contact status is decisive and the other systems adapt to it. Second, a single direction for syncing personal data, so you do not have to guess whether the newer record is the one in the shop or the one on the list. Unsubscribes and bounces flow back, sure, but that is a separate stream. Not a chaos of updates in both directions. Everything else, automation included, gets easier once those two things are sorted out.

What the module transfers from the shop, and when

The integration lives off events. Catch account registration, newsletter sign-up, a placed order, a change of customer data and account deletion. Each of them changes something that matters for sending, so each should have its counterpart on the list side. What you can hook up today without writing your own code is described in the list of available integrations.

Keep the set of fields narrow. In mailing you need:

• email address – normalised, lowercase, no trailing spaces,
• first name – for personalising the subject line and the body,
• language and country – they decide which version of the campaign goes out,
• customer group – wholesale, retail, loyalty programme,
• date and value of the last order – raw material for segments,
• newsletter consent status together with its source and date.

Sensitive data stays where it was created. A mailing system does not need shipping addresses or payment history. The less you take out of the shop, the smaller the problem during an audit and during a possible incident.

Technically, count on incremental sync. Reloading the whole database on every run puts load on the shop, multiplies writes and, along the way, can overwrite fresher statuses with older ones. I have seen it more than once. An incremental run transfers only what has changed since the last one.

Tip: deduplicate by the normalised email address, not by the customer ID. One person can have three accounts in the shop and a single mailbox.

Consent: GDPR and PKE article 398 in shop practice

A shop account is not consent to a newsletter. Neither is an order. Two different legal bases, two different processing purposes, even though the address looks identical in both places.

Consent has to be separate, voluntary and reproducible. Reproducible means that a year later you can show the wording of the clause in force at the moment of sign-up, the date, the source of the sign-up and the IP address. Without that full set you have a contact, but you do not have proof.

PKE article 398 also covers B2B relations. A company address does not release you from the obligation to obtain consent for marketing communication. Wholesale shops often assume the opposite and build a list out of their contractor database. A straight road to complaints.

In practice: a checkbox at registration and in the cart, always unticked by default, with separate wording for the newsletter. Ticking consent to the terms and conditions must not sign anyone up to the list on the side.

The other side of the coin is the unsubscribe. A click on the opt-out link in a message has to come back to the shop and switch consent off there. Because if the status stays only in the mailing system, the next sync will restore the contact, and the person who unsubscribed will get another email. And at that point they usually click not the unsubscribe link, but the spam report button.

Tip: keep the consent log in a separate table, outside the contact list. Cleaning the database must not delete the evidence.

Segmentation on transactional data

The fields the module transfers are entirely enough for sensible segmentation. A first-time buyer gets a different message than a returning one. People inactive for a few months go into their own group. An abandoned cart is a segment with a short shelf life, so it only works on fresh data. And a buyer in a specific category gets an offer tied to what they actually looked at.

Language and country solve multilingual sending. One campaign, several language versions, assignment based on a field from the customer profile. Without it you send in Polish to a recipient who ordered on the German version of the shop, and you manufacture your own unsubscribes.

The rule is simple: a narrower, active segment gives better numbers than a send to the whole database. This is not about saving your sending quota. It is about the fact that filters look at recipient behaviour. Opens and clicks from a small, engaged group build reputation. Silence from a large group ruins it.

Put contacts with no opens for a long time on a separate list. Do not send them the regular newsletter. Prepare a win-back campaign, limited in time, and make the decision after it. Those who do not react are to be switched off. Not moved back into the main sending pool.

Deliverability of shop mail: SPF, DKIM, DMARC and Return-Path

Separate marketing from transactional mail. Order confirmations and password reminders should go out from a different subdomain than the newsletter. If a campaign collects complaints, you do not want it to drag down the emails your shop cannot work without.

The minimum configuration looks like this:

1. SPF with a record for the sending servers, without a bloated list of redirects.
2. DKIM signing the sender domain, with a separate key for the marketing subdomain.
3. DMARC at least at p=none with reports switched on, so you can see who is sending in your name.
4. Return-Path under the control of the sending system – otherwise bounces do not come back and the database has nothing to clean itself with.
5. PTR for the IP addresses, matching the host name given in EHLO.

This is not just good practice any more. The largest providers made it a condition of delivery, and the details are set out in the requirements Gmail and Yahoo place on bulk senders.

We run our own fleet of sending servers, so we will say it straight: warming up a new IP address and a new domain is counted in weeks, not hours. Volume grows gradually, starting with the most engaged recipients.

Blocks at the large mailbox providers do happen. To us as well. There is one way out of them: you reduce volume, clean the database, contact the filter operator and wait. There are no workarounds. The filter judges the sender’s history and the recipients’ reactions, so nobody honest will promise you a way around that judgement.

Handling bounces, unsubscribes and complaints on the shop side

A hard bounce is the end of an address’s life. You switch it off immediately, in the mailing system and in the PrestaShop database. Leaving such a record active means the next campaign will repeat the same mistake.

Treat soft bounces differently. A full mailbox or a temporary server problem is no reason to write off a contact. Count them within a time window and switch the address off after a series, not after the first event.

A complaint from a feedback loop is equivalent to an unsubscribe. No exceptions and no checking whether the person “really meant it”. They clicked the spam report, you stop sending to that address. End of story.

All these statuses have to come back to the shop. Otherwise the next import will revive dead addresses and the whole job starts over.

The order for cleaning the database before the first big send after the module goes live:

1. Delete records without consent or with an unclear sign-up source.
2. Normalise addresses and merge duplicates, keeping the oldest consent date.
3. Switch off addresses that hard bounced earlier.
4. Move contacts with no activity to a separate win-back list.
5. Check domain authentication and send an internal test.

Tip: aim the first campaign after the sync at the freshest segment. Only once the results are clean should you add the rest of the database.

Step-by-step rollout and what is not there yet

The order of work matters. Domain authentication first, then mapping shop fields onto list fields, then a test on a narrow group, and the full sync at the very end. The reverse order ends with the whole database being sent from an unsigned domain. I have seen rollouts like that too.

Run the test on a test account in the shop and go through the whole path: registration, newsletter sign-up, unsubscribe, data change, account deletion. After each step you check the state of the record on the list side. Boring? It is. But if one of the events does not go through, you will find it now, not at ten thousand contacts.

If you are looking for the infrastructure behind sending like this, we describe it on the product page: the MailCraft email marketing platform with its own sending servers.

Honestly about the scope. Some shop integrations are on our roadmap, not in the panel. What we describe above as event mechanics and a two-way flow of statuses is an industry standard and that is how these rollouts are designed. We are not claiming that every element is already a finished button on our side. You can check the current state of the features available in the panel before you decide.

To start with, you can work without the module. An export filtered by consent, an incremental import, deduplication by the normalised address, unsubscribes carried back to the shop by hand. Slower and more laborious, honestly a nuisance, but with the same discipline it is safe.

Summary

Integrating a shop with a mailing list is first of all work on consent and database hygiene. Automation comes later and only cements what you set up beforehand. Including the mistakes.

Keep one source of truth about contact status. Make sure unsubscribes and bounces come back to PrestaShop instead of staying in the sending system. Authenticate the domain before the first campaign, not after the first deliverability problems.

A smaller, clean list works better than a full export of the customer database. That is the arithmetic of sender reputation and you cannot get around it with volume. There is no point in trying.

If you are planning a rollout like this and want to discuss the technical details, write to us. We will tell you what can be done now and what needs work on the shop side. We do not sell inbox guarantees, because nobody honestly can.