Email marketing for PrestaShop: consent, recovery and order messages

What we would do

We would start with the shop you already run and the message you need next. Keep a working sender and platform unless a missing capability or a reproducible fault justifies changing them. Check your PrestaShop and PHP releases, installed modules, checkout and theme, consent records, order states, integrations, languages and markets. Agree who will approve campaigns, answer replies and investigate failures.

If order confirmations are unreliable, repair that sending path first. If you have a permitted list but no dependable purchase events, start with a welcome message or a reviewed newsletter. Choose cart recovery only when identity, eligibility, restoration and purchase suppression can be demonstrated. A larger catalogue or audience does not by itself justify a more complex platform.

Make a justified connector or sender change on an isolated staging copy with the live theme, modules and relevant data. Disable customer sends, external marketing jobs and fulfilment exports before exercising it; a shop mail catcher cannot intercept a separate platform's API sends. Use controlled test contacts and a test account where supported. Rehearse subscription, purchase, withdrawal and retry cases before planning the live switch, with the previous configuration and reversal steps recorded.

If you want the selected module configured and its agreed journey checked, the PrestaShop Module Installation & Configuration Service covers one existing module; licences, additional modules and development are separate.

Separate operational mail from marketing

Email lets you maintain a portable audience, subject to permission, provider terms and delivery controls. It still depends on senders, mailbox providers and reputation. It is not automatically your cheapest or highest-return channel.

PrestaShop sends operational messages such as account and password emails, order confirmations and status notifications. The newsletter collection module does not provide a campaign composer, a segmentation engine or the multi-step marketing flows described here. Those need a suitable extension, external platform or custom integration.

Choose one useful message and prove its data and delivery path before expanding. Coordinate newsletters, loyalty offers, referrals and support so the same person does not receive contradictory or excessive messages. Review your checkout separately if unexpected costs or technical problems cause abandonment.

Understand newsletter collection and stored records

Module versions matter independently of the shop version. Legacy PrestaShop 1.6 commonly uses blocknewsletter and a database table whose suffix is newsletter. Later installations use ps_emailsubscription, with a guest table whose suffix is emailsubscription. Inspect the installed module and schema before exporting.

With the standard ps_ prefix, ps_ plus emailsubscription is ps_emailsubscription. That table name is valid; do not add another ps_ merely because the module has that name.

Guest subscribers and registered customers can be stored separately. Registered newsletter status is on the customer record. The guest table can hold the email, active state, subscription date, registration IP, referral information and shop context. Its referrer can come from connection data and is not a dependable record of the form page.

The ps_emailsubscription export can include registered customers as well as guest subscribers, depending on its filters. A custom exporter or connector must also cover the relevant sources, shops and subscription states. Do not assume the native export is guest-only or that either source represents half your list.

This read-only example uses the standard prefix and example shop ID 1. Adapt both to your installation and protect exported personal data:

SELECT id, email, active, newsletter_date_add,
       ip_registration_newsletter, http_referer
FROM ps_emailsubscription
WHERE id_shop = 1
ORDER BY newsletter_date_add DESC
LIMIT 50;

For ps_emailsubscription on modern shops, go to Modules > Module Manager and open Configure: inspect the verification email, the post-subscription confirmation, any welcome voucher and the export filters. Check the installed module's documentation for release-specific behaviour. Verification asks the subscriber to click before activation; confirmation is a later acknowledgement. In the ps_emailsubscription 2.7.1 guest activation path, activation sets active=1 without recording a separate confirmation timestamp. An inactive row is not permission to send.

The official module source documents its table and mixed customer/guest export. The module is an address-collection tool, not the campaign sender.

Record permission and honour every withdrawal

Make a marketing choice clear and separate from placing an order. A consent checkbox should start unticked. State who will send, what the subscriber will receive, an honest indication of frequency and how to stop. Link the relevant privacy information.

Retain the wording or form version, source, date, method and relevant confirmation records. A newsletter Boolean, IP or subscription date is an input, not complete proof of valid consent. Double opt-in can strengthen confirmation of address control; it does not preserve all those records automatically or establish compliance by itself.

Do not assume an abandoned-cart reminder is transactional merely because it mentions a cart or contains no discount. Check applicable electronic-marketing rules as well as the basis for processing personal data. In the UK, the ICO guidance describes consent and a limited soft opt-in with conditions, including collection during a sale or negotiations for similar products and opt-out opportunities at collection and in every message. A GDPR legitimate-interest argument alone does not remove those rules.

Maintain channel-specific email, SMS and other permissions even when one platform stores them on a shared profile. A phone number supplied for delivery is not marketing-SMS consent. Apply the relevant tracking and browser-permission requirements before collecting behavioural or push signals.

Unsubscription is an integration event

1. Make the message's unsubscribe route easy to use.
2. Update the sender's suppression state promptly.
3. Propagate the withdrawal to every relevant connected audience and shop record.
4. Keep a minimised durable suppression record so a later CSV, retry or backfill cannot re-subscribe the address.
5. Test withdrawal from both the storefront and the sending platform.

In ps_emailsubscription 2.7.1, front-office guest unsubscribe deletes its row; an administrative action can deactivate it instead. Registered customers have their newsletter state updated. Do not rely on a deleted subscription row as your only record of a withdrawal.

Keep essential order communication separate from marketing suppression. Never treat an audience import, account creation or a newly installed connector as fresh permission. Reject purchased or scraped lists without the required valid permission and provenance.

Offer useful signup opportunities

Test relevant opportunities in the footer, account form, checkout and content pages. A restrained popup can offer another route when it does not obstruct shopping. Each surface needs the same clear permission and working confirmation process.

For popups, test delay, scroll depth and frequency rather than copying a universal 30-second rule. Provide an obvious close control, keep the mobile version usable and avoid interrupting checkout. Google's interstitial guidance explains why obscuring page content can be a problem.

Offer a useful reason to subscribe: buying advice, availability news, new ranges or a margin-tested welcome incentive. If you promise a voucher after confirmation, test the actual verification and confirmation path. Do not assume a shared code is customer-bound or single-use.

Measure completed confirmations by signup surface, not just submitted addresses. Review complaints, duplicates, failed verification messages and later purchases. Compare surfaces using the same definition of a completed signup.

Work through a signup before promoting the form

Suppose a visitor subscribes through the footer, later creates an account with the same address and then changes their newsletter choice. That journey tests more than whether a form displays a success message: it crosses the guest and customer records described above.

1. Use a controlled address with no previous subscription. Record the form wording, language and shop, submit it and inspect the destination record. Where verification is enabled, the address must not enter a marketing send before confirmation.
2. Complete the verification and inspect the active profile and welcome message. If you promised a voucher, check that it arrives through the intended completed-subscription path and that its restrictions match the promise.
3. Create an account using that address. Confirm that the connector reconciles the existing subscriber without a duplicate or any loss of permission evidence. Then withdraw the newsletter choice and check the customer record and the sending platform. Repeat the earlier signup source or run a supported backfill: neither may restore the subscription.
4. Use another test address to place an order with the marketing choice unticked. The purchase must not manufacture a marketing subscription. Keep this result alongside the successful signup before expanding collection surfaces.

Verify the sending transport and authentication

Identify which system sends each message. A module calling PrestaShop mail uses the configured shop transport. An external campaign platform normally uses its own infrastructure. Changing the shop's SMTP settings does not configure every platform.

In Advanced Parameters, E-mail, inspect the selected transport and send a test. The PrestaShop 1.7.8 non-SMTP path uses Swift sendmail transport, while 9.1 uses Symfony SendmailTransport. Calling either path simply PHP mail() is inaccurate. A correctly configured local mail server can authenticate and sign mail; authenticated SMTP alone does not give you domain alignment.

• SPF: authorise the actual envelope senders at the appropriate domain. Publish one SPF policy per domain name and follow the sender's exact records; do not add arbitrary includes to every From domain.
• DKIM: publish the provider's selector records and verify that received messages carry a valid signature.
• DMARC: check that the visible From domain aligns with a passing SPF or DKIM identity. Review legitimate senders and reports before tightening enforcement.

The SPF specification explains record evaluation. Use your sender's authentication instructions, not a copied DNS record with another account's values.

For personal Gmail recipients, Google's sender requirements require SPF or DKIM for all senders and additional authentication, DMARC alignment and unsubscribe provisions for bulk senders around the 5,000-messages-per-day threshold. Marketing and subscribed bulk messages need supported one-click unsubscribe headers and a visible body link. A footer link alone is not the header mechanism.

Separate marketing and transactional streams where it helps operations, but a subdomain does not guarantee reputation isolation. Increase new sending volume deliberately, suppress hard bounces and complaints, and follow each provider's current limits. Do not rely on a fixed warm-up duration or a generic unsubscribe benchmark.

Inspect received headers and provider delivery events. A testing service can reveal configuration issues, but its score does not prove inbox placement. Authentication failure can cause rejection, throttling or filtering; there is no universal spam-by-default rule.

Use native cart visibility and manual recovery correctly

Cart abandonment means a basket did not become an order. The shopper may have left before completing checkout or reaching payment. A fully anonymous cart has no email address you can contact.

Orders, Shopping Carts provides cart inspection in modern back offices. Core can manually email a customer-linked cart with a recovery link. That link can restore the cart. Core does not by itself provide the timed, segmented multi-message marketing sequence below.

This query inventories customer-linked carts updated within an illustrative 30-day window, inactive for at least one hour and with no associated order. It reports item quantity, not monetary cart value or permission to send. Replace the prefix, shop and time windows as needed.

SELECT c.id_cart, c.date_add, c.date_upd, cu.email,
       SUM(cp.quantity) AS items
FROM ps_cart c
JOIN ps_cart_product cp
  ON cp.id_cart = c.id_cart AND cp.id_shop = c.id_shop
JOIN ps_customer cu ON cu.id_customer = c.id_customer
WHERE c.id_shop = 1
  AND cu.deleted = 0 AND cu.email <> ''
  AND c.date_upd >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 1 HOUR)
  AND NOT EXISTS (
    SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart
  )
GROUP BY c.id_cart, c.date_add, c.date_upd, cu.email
ORDER BY c.date_upd DESC;

Use date_add instead if you mean carts created during a period. Calculate monetary totals through the appropriate cart-pricing context, including currency, tax, delivery, discounts and shop. A cart-product quantity sum cannot answer that question.

Manual contact may be appropriate for a specific support enquiry or permitted recovery case. Apply the same permission and suppression checks as any corresponding automated message.

Understand native cart links and their security

The native recovery URL uses recover_cart and token_cart. PrestaShop 1.7.8 and 9.1 calculate the token as md5(_COOKIE_KEY_ . 'recover_cart_' . id_cart). The token is not simply the cart ID and is not the cart's secure_key.

The token restores customer authentication as well as the cart context. A customer record is required; a guest customer record differs from a cart with no customer at all. PrestaShop 9.1 also rejects a cart already used for an order. PrestaShop 1.7.8 checks the token, cart and customer but has no equivalent completed-order check in its recovery method. Test completed-order links on your exact release.

This server-side example assumes an already loaded and validated Cart, its associated customer and the correct shop context:

$idCart = (int) $cart->id;
$token = md5(_COOKIE_KEY_ . 'recover_cart_' . $idCart);
$link = Context::getContext()->link->getPageLink(
    'order',
    true,
    (int) $cart->id_lang,
    [
        'step' => 3,
        'recover_cart' => $idCart,
        'token_cart' => $token,
    ],
    false,
    (int) $cart->id_shop
);

This describes the native compatibility mechanism, not a recommendation to design new authentication tokens with MD5. A custom recovery system needs its own secure token, expiry and authorisation design.

Treat a recovery URL as sensitive because it can restore a customer session. Do not expose it in public pages, shared reports or unnecessary third-party tracking. Test the email link in a fresh browser, across the intended language and shop, with both account and guest-customer carts.

Recheck price, availability, shipping and discounts when the shopper returns. Do not promise an old basket total is permanently reserved. Test deleted carts, completed orders and invalid tokens, and verify a connector's recovery mechanism rather than assuming every vendor uses the core route.

Build a recovery flow as a measured experiment

A recovery flow needs cart activity, identity, permission, current products, a functioning recovery link and a purchase event that stops messages. Fix these before activating the flow. A tracking snippet alone is insufficient.

The schedule below is a test hypothesis. All times are measured from the same abandonment event, not from the previous email. You can start with only the first message and test whether more messages add incremental profit.

Possible subjects include "Your cart is ready to review" or "Can we help with your order?" Do not assert that the first message always converts best or that a particular number of messages is optimal.

Segment by actual customer and cart data: first purchase versus repeat purchase, contribution margin, product type, and observed checkout events. An exit at delivery or payment can suggest something to investigate; it does not prove the shopper's reason.

Calculate incentive cost using product margin, payment and fulfilment costs, returns and the shipping subsidy. Include free shipping in that cost. Base any cart-value threshold on these costs and the margin you can afford to spend.

Use Cart Rules for offers with real validity dates, eligibility restrictions and usage limits. For a recipient-specific single-use offer, create a unique code, select the recipient under Limit to a single customer and set both Total available and Total available for each user to 1. Verify whether the selected connector can actually create and synchronise native cart rules; a platform coupon feature does not prove this.

Before every scheduled send, recheck purchase completion, suppression, permission, frequency limits and cart eligibility. Stop the sequence on a qualifying purchase. Do not contact the same person through overlapping cart, browse, SMS and newsletter flows without coordination.

Rehearse a reminder that must stop

A returning customer leaves a coat and a chosen size in the basket, receives a reminder and then buys through a separate browser session. The delayed follow-up must stop even if the customer never clicks the email. Measure that result from the order event and recipient state, rather than treating a tracked link click as proof of purchase.

1. Give the test contact the intended reminder permission and verify the current product, combination, currency and shop in the event. Repeat with reminder permission refused; an address alone must not make that cart eligible.
2. Let the eligible cart enter the flow. Open its message in a fresh session and verify the chosen size, language, current prices, delivery options and discount eligibility.
3. Complete a qualifying purchase without using the message link. Confirm that the mapped purchase event removes pending reminders for that cart or contact according to the agreed policy.
4. Retry an earlier cart event and the purchase event through the supported test mechanism. The retry must not produce a second message, re-open the recovered cart or remove a later withdrawal.
5. Repeat with an expired offer or an unavailable combination. The shopper needs an accurate basket and a usable explanation, rather than a promise that an old price or stock position is reserved.

Also test an order awaiting an offline payment. Decide explicitly whether order placement ends recovery and what separate payment reminder, if any, should follow. An existing unpaid order is not simply another abandoned cart; blindly continuing both flows can ask the customer to place a duplicate order.

Compare actual integrations before comparing platforms

Write down the data each intended flow needs. Contact sync, connected-site loading, viewed-product tracking, cart events, completed orders, refunds and delivery-state updates are distinct capabilities. An integration's name or API-key field proves none of them.

Compare the vendor-maintained connector with any separate MPR module. They may perform different jobs. Do not install two tracking or commerce emitters for the same event without a working deduplication design.

Brevo's vendor plugin documentation describes contact and order synchronisation, activity tracking and sender options; its documented 5.0.36 release is tested up to PrestaShop 9.0, so verify newer combinations separately.

The MPR Brevo (Sendinblue) Integration provides opted-in contact synchronisation and storefront tracking and can route store email through Brevo. Check its shopping-event coverage, delivery updates and mail-routing settings on your installed release before adding a separate commerce connector.

Use current compatibility matrices for your exact PrestaShop and PHP release. Avoid unsupported claims that one provider is always cheapest, best maintained or simplest to install.

Choose a reviewed shop campaign or a consent-led connector

When your team should review each message

Mail Revolution builds audiences from customer, consent and order rules inside PrestaShop and prepares messages for human approval. Sending starts disabled. You write each language, choose working hours and daily limits, then reviewers approve the exact personalised recipient message. Editing a message cancels its earlier approval, and consent is checked again before delivery.

Use that route when a member of staff should inspect a quotation follow-up or a selected newsletter before it leaves. Personal and newsletter sender profiles serve different purposes: newsletter reports track opens and clicks, while personal messages have neither. Budget the review work as well as sending capacity. An approved campaign is a different operating model from an unattended multi-step cart or win-back flow in an external platform.

When separate newsletter and reminder choices matter

SendPulse Integration keeps consenting contacts current and records newsletter and basket-reminder choices separately. You supply the account access details, choose the address books for each purpose, review confirmation options, reminder delay, cart retention and consent wording by language. Account creation does not subscribe the customer, and delivery starts switched off.

The customer can manage these choices on a dedicated page linked from the account and checkout. Shop withdrawals are queued for SendPulse; scheduled checks bring SendPulse opt-outs back into the module. Before launch, run those jobs and inspect pending work and failures. A saved preference awaiting processing is different from a withdrawal already applied at the sender.

Prepare campaigns and any reminder sequence in SendPulse itself. Basket details feed the reminder flow, and the return link lets the shopper review the saved basket, choose whether to merge or replace the current basket, then confirm restoration. Test both choices with different items already in the browser's cart. This is a different journey from assuming every connector uses the native session-restoring URL.

The module and the external account have separate conditions. Check the account's current sending and automation entitlement, and verify the live connector's purchase-stop behaviour before enabling a reminder flow. Contact synchronisation alone does not establish every event needed for the wider lifecycle campaigns below.

Assess Mailchimp forms, audiences and commerce data

An embedded signup form can collect names, other audience fields and tags as well as email addresses. It does not by itself provide purchase history, product data or cart recovery. Mailchimp's embedded-form guidance describes those configurable fields.

The vendor PrestaShop connector documents customer and order transfer and ecommerce features. Its published PHP range is 5.6 to 8.1. Check the connector release before installing on PHP 8.2 or later, even when your shop supports that runtime. Test product, cart, guest-checkout and purchase-suppression coverage in the chosen connector.

The MPR Mailchimp Integration implements opted-in customer audience sync, connected-site loading and retry handling, rather than full orders/products/carts synchronisation; use its help page for setup.

An audience is an independent dataset within a Mailchimp account, not automatically a separate subscription invoice. Duplicate billable contacts across audiences can count repeatedly. Consider one audience with appropriate tags and segments when it suits your business, while keeping different legal entities or permissions correctly separated.

Build purchase-based segments only after verifying purchase data: recent buyers, one-time buyers, relevant categories or defined historical spending. A newsletter flag alone is not proof of permission for the audience, and it does not sync later withdrawals.

Follow the domain-authentication instructions for your actual account. Do not assume its SPF requirement matches the shop's transactional sender.

Mailchimp's plan documentation lists Free at 250 contacts, 500 monthly sends and 250 daily sends. Confirm the limits shown in your account before budgeting. Automation flows are excluded from Free in the plan comparison, so a multi-step win-back flow needs a suitable plan.

Assess Klaviyo events and channel permissions

Evaluate Klaviyo when you need event-based segments, product and order data, conditional flows or supported multi-channel messaging. Predictive metrics are estimates with data requirements, not assured revenue. A contact-count or average-order-value threshold does not prove that the subscription will pay for itself.

Start with the official PrestaShop integration documentation. It currently lists PrestaShop 1.7.0 through 9.1.x, with additional requirements for checkout SMS collection. It includes onsite events as well as order synchronisation; do not automatically add another script.

Verify identity, permitted tracking, checkout signals and completed-order suppression before activating abandonment messages. Test account and guest-customer checkout, alternative payment methods and customised checkout pages. Inspect the actual synchronisation delay and enabled transactional events.

The separate MPR Klaviyo Integration has browser and cart/confirmation hooks; verify its event coverage and limitations in its help page rather than assuming it is the vendor's full historical commerce connector.

For a custom server integration, use supported date-versioned Events and Profiles APIs. Klaviyo's legacy v1/v2 Track and Identify HTTP APIs retired on 30 June 2024, as documented in its migration FAQ. Supported browser SDK methods are a separate interface. Keep private API keys server-side.

A shared customer profile still has separate email and SMS consent and suppression states. Coordinate flow exits across channels and verify destination support, quiet hours and message charges. Klaviyo also documents WhatsApp Business integration; check its availability and permissions rather than claiming the platform cannot use WhatsApp.

Assess Omnisend and diagnose missing activity

Omnisend offers email and SMS through its PrestaShop integration. Each channel needs its own permission and data path. Omnisend also offers web push for supported platforms; check channel eligibility for your commerce integration before planning a push flow. A shared audience does not make every channel available or permitted for every contact.

Follow the vendor's current PrestaShop integration guide to verify contact, product, order and behavioural coverage. It states that behavioural events require identified contacts, such as people who submitted a form or clicked a tracked email link. Anonymous browsing is not automatically visible activity.

1. Check that the full supported integration is installed, not just an API key.
2. Confirm required scripts load under the applicable tracking choice and content-security policy.
3. Confirm the test contact is identified by a supported method.
4. Inspect event arrival and the actual product/cart data.
5. Check flow filters, channel subscription, suppression and frequency rules.
6. Place an order and confirm that pending abandonment messages stop.

Do not assume arbitrary Shipped-versus-Delivered branching is supported. Map only the events the installed connector actually sends. Test refunds, cancellations and different payment methods.

The separate MPR Omnisend Integration sends visits, product views, cart changes and orders to Omnisend; setup takes a Brand ID and an enable switch. Verify the event data and the purchase exit, and add another connector only for product or historical-order synchronisation it does not cover.

Compare current contact, sending and channel limits before budgeting. SMS destinations and message segments can affect cost, and a platform's push feature is not inherently free of subscription costs. Do not select a channel solely because an email was recorded as unopened.

Assess ActiveCampaign automation and commerce coverage

Consider the workflows you will actually build: conditional branches, wait-until steps, goals, custom fields, lead scoring or sales-pipeline stages. A B2B quote process can require different data from a repeat-purchase retail flow.

Define contact fields, tags, product and order events, cart data and optional site activity. Site tracking observes known permitted contacts; it is not an API synchronisation of orders. A connector, middleware workflow or custom Deep Data implementation must provide the commerce data needed by your automations.

The MPR ActiveCampaign Integration provides site tracking and, with your account address and API key as well as the tracking identifier, contact, order and abandoned-cart synchronisation. Use its help page to confirm these and how a completed purchase stops a sequence on your installed release.

Map order placement, payment confirmation, fulfilment, cancellation and refund separately. A bank-transfer or cash-on-delivery order can be placed before payment. Do not replace every Placed Order event with a paid-state trigger, or describe order creation as proof of payment.

Start with one tested flow, then add segments and any scoring or pipeline rules. Prefer confirmed clicks, purchases and relevant sales activity over open-only scoring. Use browsing triggers only after identity and tracking permissions work.

ActiveCampaign's current plan overview separates base marketing plans and add-ons, including enhanced CRM capabilities. Check the actual package for pipeline, sales, scoring, SMS and transactional features. Do not assume an advanced CRM is included merely because you choose a higher email tier.

Map post-purchase messages to real sending paths

Inspect the actual order-state settings under Shop Parameters, Order Settings, Statuses. On PrestaShop 1.6, look under Orders, Statuses. Defaults and customisations differ. PrestaShop 9.1 installation defaults enable email for Preparation in progress, so check it when planning notifications.

Include an accurate summary, next step and monitored support route in confirmations. Do not imply the order is paid merely because a confirmation exists. Payment methods can send additional instructions or notifications.

Mail templates commonly have HTML and text versions under language-specific mails directories, with theme or module-specific paths affecting selection. For example, inspect mails/en/order_conf.html and mails/en/order_conf.txt, then check whether the active theme or module supplies the selected copy. Email-theme generation and translations vary by release. Identify the effective template and language before editing, and keep changes maintainable through updates.

Where available, use International, Translations, Email templates translations; the legacy PrestaShop 1.6 location is Localization, Translations. Change a distinctive line on staging and generate the actual order message in the intended language. If the line is absent, trace template selection and generation before repeatedly editing the core file. Test the text version as well as the HTML.

Available variables depend on the sending code and extension hooks. Standard confirmation shipping totals use {total_shipping}, not a universal {shipping} variable. A tracking path may provide {followup}; verify each template separately.

A useful follow-up asks whether the item arrived and works as expected. A review request should follow sufficient product experience and use a working product-specific form. Intervals such as five to seven or seven to fourteen days are hypotheses to test, not universal best times.

For consumables, estimate a replenishment cycle from actual purchases. For durable goods, offer genuinely compatible accessories such as a camera card or bag. Coordinate other promotions so recent buyers are not put into conflicting flows.

For review collection and its implemented request limitations, see the reviews guide.

Keep delivery promises and support work consistent

Only send a Delivered message from a reliable delivery signal. A named order state or its delivery flag does not by itself prove a parcel reached the customer. If you must estimate delivery, label the estimate accurately and account for delays.

Estimated Delivery Date provides product-page estimates; using a saved order-specific estimate in confirmation or dispatch mail requires additional integration, as described in its help page.

Advanced Order Fulfilment provides internal steps, tasks, routing and notifications. Check how your configured workflow relates to native order states; use its help page for the supported configuration.

Choose the actual dispatch process: label generation, packing check, tracking entry and notification. Record exceptions and customer messages against the order so another staff member can follow them. If a delivery promise changes, give the customer a realistic update and available remedy.

For packing, use documents appropriate to the order and recipient. A gift recipient may need a delivery slip rather than an invoice showing prices. A thank-you note or permitted offer is a choice to test, not an assured loyalty effect.

Resolve damaged, wrong or missing deliveries through your support and carrier processes. Do not promise that a failure handled well produces more loyalty than a fault-free order. Record the action, owner and completion so a helpful email corresponds to an actual fix.

Work through a delayed or damaged delivery

An order leaves in separate parcels, but the customer has only received part of it when a satisfaction message becomes due. A generic "enjoy your order" email is misleading here. Keep the shipment facts, support decision and marketing eligibility connected, with a named staff member responsible for the next action.

If your returns process uses the delivery date, pass the supported delivery evidence into that process rather than substituting the order date. Keep estimated and confirmed dates distinguishable in customer messages, and do not automatically restart a promotional sequence merely because a support ticket is closed.

Configure tracking links and avoid duplicate dispatch mail

Two values create the tracking link: the carrier's URL template and the order or shipment's tracking number. The carrier tracking path substitutes the number for @. Use the carrier's current supported URL rather than copying an unchecked example.

1. Check the tracking URL on the carrier under Shipping, Carriers.
2. Save the real tracking number on the intended order-carrier or shipment record.
3. Observe whether that save sends in_transit.
4. Advance the workflow to the genuine dispatch state and observe its configured status email.
5. Open both messages and the customer's account or guest follow-up route to verify working links.

Number-before-status can help the status message include tracking, but it can also produce two messages because tracking-update mail is a separate trigger. Test the selected version, carrier module and workflow, then configure a coherent notification policy.

Use a clear order reference, obvious tracking action, relevant shipment information and a support route. Preserve the correct template variables and test mobile display. Re-saving an unchanged number and updating it to a new one should be tested separately.

Multi-parcel handling is version-dependent. PrestaShop 9.1 includes splitting, item allocation, merging and tracking, with storefront presentation gated by the improved-shipment feature flag. Older workflows and carrier modules differ. Verify the exact release and enabled features instead of assuming core always lacks shipment splitting.

For multiple parcels, tell customers which items belong to each shipment and make each tracking link available. Label-created, dispatched, in-transit and delivered are different events.

If tracking stalls, investigate and update the customer. For a delivered-but-missing report, check the carrier's delivery records and investigate; a scan alone is not a guaranteed chargeback defence. For a return to sender, confirm the address before reshipping. Handle damaged parcels through the applicable remedy and carrier-claim process.

Carrier imports, label tools or supported bulk tracking imports can reduce manual entry. Verify their mail triggers as well as their stored tracking numbers. The shipping guide covers the broader carrier setup.

Read the message as it was sent

If the customer's account now has a correct tracking link but the earlier email is empty, compare the message time with the tracking save. A later field correction does not rewrite an email already delivered. An email containing the tracking number but opening the wrong carrier page points instead to the URL template or the shipment's carrier association. Keep a controlled example of each failure when checking the import or label module.

Resend the right message without cycling statuses

First establish whether the customer needs a status notification, an order confirmation or an invoice. Check the address, language, selected template, provider result and any bounce. A mail log entry does not prove inbox delivery or reading.

In PrestaShop 1.7.8 and 9.1, the native status-history resend action uses an existing history record and sends its configured status email without changing the workflow state or adding a new history row. Modern status updates can reject assignment of the current state again.

Do not cycle statuses to resend mail. State changes can affect stock, including shipped-flag transitions, as well as documents, hooks and other automations. Use a real transition only when the order's workflow should change.

The original order_conf is constructed by a different sending path. A dedicated reconstruction must assemble the right order variables and template; it is not necessarily a replay of the original bytes.

Resend Order Confirmation rebuilds the message from current order/customer data and the current template, leaves status and totals unchanged, records a private note and log, and sends without an invoice attachment. Check the displayed recipient before confirming: it uses the customer's current email address, the order's language and its original shop.

Verify identity and the intended destination before correcting an email address or resending personal order details. After an order edit, ensure the message represents the final data. Check invoices separately rather than assuming every confirmation includes the PDF.

Customers can view their order and available documents through supported account or guest follow-up routes. A customer-facing resend control requires a suitable extension or customisation, with ownership checks, destination controls, abuse limits and activity records.

Test resends in staging with a mail catcher and identifiable test orders. Repeated resending will not fix an authentication or delivery failure. Investigate the sender, then send the required message once.

Define lapse, build a bounded audience and test incentives

Win-back targets a gap since a qualifying purchase, rather than a recently abandoned cart. Define that purchase policy and measure the distribution of repeat-order intervals by customer and product type. Export qualifying orders, sort each customer's purchases chronologically and calculate gaps between consecutive orders. A last-order query alone does not measure those intervals.

A consumable with a roughly monthly cycle may warrant an earlier test than a durable appliance. Fashion can be seasonal. If you try thresholds such as 1.5 or 2 times the usual purchase gap, treat them as test settings and compare the results.

This illustrative audience selects customers with a most recent valid order between 60 and 365 days ago in shop 1. Replace the prefix, shop and windows. valid=1 reflects logable-state handling, not universal proof of payment or refund exclusion; inspect your states and add the required payment, cancellation and refund policy before using it.

SELECT c.id_customer, c.firstname, c.lastname, c.email,
       MAX(o.date_add) AS last_order
FROM ps_orders o
JOIN ps_customer c ON c.id_customer = o.id_customer
WHERE o.id_shop = 1
  AND o.valid = 1
  AND c.newsletter = 1 AND c.deleted = 0
GROUP BY c.id_customer, c.firstname, c.lastname, c.email
HAVING MAX(o.date_add) < DATE_SUB(NOW(), INTERVAL 60 DAY)
   AND MAX(o.date_add) >= DATE_SUB(NOW(), INTERVAL 365 DAY)
ORDER BY last_order DESC;

The newsletter flag is a first-pass filter. Apply current permission, suppression and other campaign exclusions before sending. Last visit is not last purchase; use order data rather than inferring lapse from the customer grid.

An example sequence to test

These times are measured from entry and are hypotheses, not a reason to assume that four messages beat one. Stop after a qualifying purchase or withdrawal. Define when to reduce or end marketing for nonresponders; do not mistake automated opens for meaningful engagement.

Possible incentives include a percentage discount, shipping subsidy, gift or loyalty benefit. There is no universal minimum effective discount. Customer-bound codes, real validity dates and total/per-user usage limits help enforce a single-use offer. Verify the actual generation and synchronisation mechanism before promising unique codes at scale.

Segment by product history, recency, measured value and meaningful activity. A durable-goods buyer may need accessories rather than another identical item. Do not assume high historical spending means a large discount is profitable.

Measure a frozen campaign cohort

Save the final recipient IDs and campaign start and end dates. Then count qualifying purchases in that explicit window without retaining the dormancy HAVING clause. This sample uses illustrative cohort IDs and dates, with the same order-policy caveat:

SELECT COUNT(DISTINCT o.id_customer) AS reactivated
FROM ps_orders o
WHERE o.id_shop = 1 AND o.valid = 1
  AND o.date_add >= '2026-10-01 00:00:00'
  AND o.date_add < '2026-11-30 00:00:00'
  AND o.id_customer IN (101, 102, 103);

Divide by the defined cohort size and compare with a randomised holdout where practical. Track later full-price purchases, discounts, shipping subsidies and contribution profit. Use your measured recovery rate when evaluating the campaign.

Separate a lapsed customer from a product reminder

Suppose you sell pet food and durable pet beds. A food buyer who has missed their usual reorder may be a useful replenishment candidate; a bed buyer with the same time since purchase may have no need to buy again. If the food buyer recently bought a bed, their latest customer purchase is recent even though the food purchase is older. Choose whether the rule concerns the customer or a particular product, then inspect the matching order lines before putting that person into a flow.

For a reviewed campaign, save the chosen audience and exclusions before staff approve messages. For a continuous flow, define when a person can enter again after a purchase or a previous attempt. Otherwise a daily eligibility job can keep admitting the same nonresponder and defeat the final-message limit.

Measure value, replenishment and the whole sending path

Historical spending needs a currency and refund policy

Do not sum order-currency amounts as if they shared a currency. One reporting convention converts each order's recorded amount using its recorded conversion rate into the shop's reference-currency basis. If that basis changed over time, normalise explicitly before comparison. Historical paid revenue is not complete lifetime value or profit.

This diagnostic sample groups by customer and shop and flags missing or nonpositive rates. It does not subtract refunds or prove current permission to send:

SELECT o.id_customer, COUNT(*) AS order_count,
       SUM(CASE WHEN o.conversion_rate > 0
                THEN o.total_paid_real / o.conversion_rate END)
           AS historical_paid_base,
       SUM(CASE WHEN o.conversion_rate IS NULL
                     OR o.conversion_rate <= 0 THEN 1 ELSE 0 END)
           AS invalid_rates
FROM ps_orders o
WHERE o.id_shop = 1 AND o.valid = 1
GROUP BY o.id_customer
ORDER BY historical_paid_base DESC;

Do not use a value with invalid rates for ranking. Define paid/completed states, cancellations, partial refunds, taxes, chargebacks and reporting currency before creating a VIP or value segment. Join permission data and current suppression separately.

Use a latest-purchase window for replenishment

A query for every order older than 25 days is an unrestricted historical sample. It does not identify customers whose latest relevant purchase is about 25 days old. Group by customer and target product, take the latest qualifying purchase and use a bounded age range. Match combinations when replenishment depends on the variant.

SELECT o.id_customer, MAX(o.date_add) AS last_product_order
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.id_shop = 1 AND o.valid = 1
  AND od.product_id = 42
GROUP BY o.id_customer
HAVING MAX(o.date_add) >= DATE_SUB(NOW(), INTERVAL 26 DAY)
   AND MAX(o.date_add) < DATE_SUB(NOW(), INTERVAL 25 DAY);

This is an illustrative daily eligibility window, subject to the same order, refund and permission policy. A continuously running flow also needs deduplication, missed-run recovery and purchase suppression. Run heavy reports on an appropriate reporting copy or off-peak; SELECT does not mean cost-free.

Report outcomes with clear denominators

• Operational mail: generation, transport acceptance, delivery/bounce events, customer access and support outcomes.
• Marketing: eligible recipients, delivered messages, meaningful clicks, unsubscribes, complaints and qualifying orders in a stated window.
• Reviews: form visits and completed reviews, rather than email opens alone.
• Profit: incremental purchases after goods, fulfilment, platform and incentive costs.

Apple Mail Privacy Protection can load remote content without a person reading the message. Opens therefore cannot reliably classify an individual's engagement or diagnose a delivery problem by themselves. Attributed platform revenue is also not proof of incremental revenue; compare with a holdout where possible.

Use consistent campaign tags for analytics, without personal data or recovery credentials in tagging fields. Record the attribution window, timezone and currency. Do not compare transactional and promotional open-rate averages as if they represented the same purpose.

End-to-end launch checks

1. Subscribe and confirm a test address through each collection path.
2. Verify the destination profile, permission records and exact event payloads.
3. Test abandonment, the recovery link in a fresh session and purchase suppression.
4. Place orders with different payment methods; inspect confirmation, status and tracking messages.
5. Unsubscribe in the shop and the provider, then run a retry or backfill and confirm suppression survives.
6. Check a cancellation, refund, duplicate event, missing product and failed send.
7. Enable one flow, assign an owner and monitor failures and actual customer outcomes before expanding.

Find the failing step before changing the campaign

Keep a redacted test record with the shop, contact/cart/order identifiers, event name, occurrence time, processing time and sender result. Correlate the same case across systems. Do not put private API keys, recovery credentials or an unnecessary copy of the customer database in a support ticket.

Switch the workflow and hand over its operation

A sender or connector migration needs a data plan as well as a setting change. Map the old and new audience identities, language, shop and permission fields. Decide which historical records are a backfill and which events may start a new flow. Importing an old purchase as if it happened now can send an irrelevant follow-up; importing an old contact as a new subscriber can restart a welcome sequence.

1. Inventory each active message, trigger and sending system. Include module jobs, scheduled commands, platform automations and any ERP or fulfilment service that can emit the same message.
2. Prepare suppression records before enabling contact imports. Record the history cutoff, identifier mapping and treatment of already queued messages, then rehearse with sending disabled.
3. Check the staging boundary explicitly. Isolate its database, disable live schedules and external callbacks, and replace sender credentials or destinations with controlled test equivalents. Verify external platforms as well as shop-generated mail.
4. Run the launch checks above and keep the resulting profiles, message samples and purchase/withdrawal/retry evidence. Verify the actual theme, guest checkout, languages, currencies and multistore contexts you intend to use.
5. Agree the switch window and which emitter stops before its replacement starts. Reconcile changes since the rehearsal, apply the latest withdrawals and exclude stale carts before releasing work.
6. Enable the agreed flow for its defined audience. Watch queue failures, delivery events, duplicate sends and support replies, with a named person able to pause the affected marketing work.

For reversal, record how to pause the scheduler, retries and external flow, including requests the provider has already accepted. Restore the previous configuration while retaining new orders, withdrawals and durable send records. Restoring an old shop database over current trading data can lose those changes. Reconcile what actually sent before releasing pending work through the old route.

What to ask the developer or agency

• Which installed module and platform route supplies each required event, and which parts are browser tracking, contact sync or commerce sync?
• Where is permission evidence held, who applies withdrawals, and what proves that a retry cannot re-subscribe someone?
• What evidence shows that guest purchases, pending payments, refunds and the actual checkout behave as agreed?
• Who owns scheduled jobs and failures, where is the last successful run visible, and how do staff replay a failed job without duplicating a send?
• Which template, language and sender were tested, and where are the configuration export, live-switch steps and reversal instructions?

Have the staff member who will operate the flow demonstrate a failed-job investigation and a pause before handover. Set the next review around actual delivery, complaints, purchases and costs, and repeat the relevant acceptance cases after connector, theme or checkout changes.

Questions owners ask

Should I replace the platform we already use?

Keep it if the installed integration can prove the next required flow and its cost fits your team. A missing event or permission mapping may need a scoped integration repair rather than a platform migration.

Can we keep order emails in PrestaShop and send marketing elsewhere?

Yes. Assign a sender to each message and keep essential order communication separate from marketing suppression. Disable overlapping sends so both systems do not announce the same event.

Does a newsletter opt-in also permit basket reminders?

Check the permission actually collected and the rules for the relevant market. Do not infer reminder permission from an address, an account or an unrelated checkbox. Where choices are separate, enforce them separately.

Can we import an old customer list and start sending?

Only after checking provenance, the applicable permission, confirmation evidence and current suppression. A new connector or audience does not renew permission, and an import must preserve withdrawals.

Does a free connector make the whole workflow free?

The external account, sending or channel charges, setup and ongoing operation remain separate. Include the work of writing messages, reviewing audiences and handling failed jobs when comparing routes.

What should we launch first?

Choose the useful message whose data and sending path you can already prove. Launch it with purchase and withdrawal exits tested, then use the measured result to decide whether another step earns its place.