Social Proof — Purchase Notifications & Live Visitors — Complete Guide

Overview

The Social Proof — Purchase Notifications & Live Visitors module adds two reassurance mechanisms to your product pages: discreet recent-purchase notifications (“Marie L. purchased this product 2 h ago”) and a live visitor badge (“12 people are viewing this product”).

Its distinguishing trait is its ethical, GDPR-by-design approach: it only displays orders actually placed in your store and visitors actually present. It never invents anything. Anonymization is applied server-side before anything is sent to the browser, times are rounded, no raw customer data is ever exposed and the module sets no cookies.

Installation

1. In the back office, open Modules > Module Manager.
2. Click Upload a module and select the dfsocialproof.zip file.
3. Installation automatically creates the visitor table and registers the default configuration values.
4. The module is active immediately on product pages with sensible, working defaults.

Configuration

The Configure page is organized in three panels, plus a “Privacy by design” box summarizing the module’s guarantees.

Purchase notifications

• Enable purchase notifications: switch for the first mechanism.
• Time window (hours): only real orders placed within this window are shown (168 h by default, i.e. 7 days). If there are none, nothing is displayed.
• Maximum number of notifications: cap per page load (5 by default).
• Anonymization level: three modes detailed in the next section.
• Order statuses taken into account: multi-select list (Ctrl/Cmd to pick several). Only orders in these statuses generate notifications; by default, your store’s “valid” statuses.

Visitor counter

• Enable the visitor counter: switch for the second mechanism.
• Counting window (minutes): a visitor is counted while active within this window (15 min by default). Records are purged automatically afterwards.
• Minimum visitors to display: below this threshold (3 by default), the badge stays hidden so a lone visitor is never singled out.

Display

• Position: corner where notifications appear (bottom left or bottom right).
• Initial delay (seconds): time before the first notification (4 s by default).
• Interval between notifications (seconds): spacing between two toasts (9 s by default).
• Display duration (seconds): visibility time of each toast (6 s by default).

The three anonymization levels

The chosen level applies to all notifications, and the transformation happens on the server: the browser only receives the final text, never the original data.

• First name + initial: “Marie L. purchased this product”. The most engaging, while remaining non-identifying.
• City only: “A customer from Nice purchased this product”. The city comes from the order’s delivery address.
• Fully anonymous: “Someone purchased this product”. The most cautious, suited to sensitive catalogs.

Rounded relative times

Displayed timestamps (“2 h ago”, “25 min ago”) are deliberately rounded — minutes to the nearest 5 minutes. The goal: prevent re-identifying a customer by cross-referencing the exact time of an order with other information. This is a privacy-by-design choice, not a technical approximation.

How the visitor counter works

Each visitor of a product page is counted through a SHA-256 fingerprint salted with your shop’s secret key (_COOKIE_KEY_). This fingerprint is never displayed, never exposed to the browser, and is only used to deduplicate visits.

• No cookies: the module sets no cookie and no local storage to count.
• Automatic purge: expired records are removed opportunistically from the database, with no cron task to configure.
• Dignity threshold: below the configured minimum, the badge disappears — a lone visitor is never called out as “1 person is viewing this product”.
• Refresh: the counter updates every 60 seconds via a lightweight AJAX request.

Privacy by design and GDPR

• Real orders only: no invented data, ever. Your store’s credibility is preserved and you stay on the right side of consumer law (misleading commercial practices).
• Server-side anonymization: texts arrive in the browser already anonymized and formatted. No raw customer data (full name, email, address) ever travels to the front office.
• Uncached AJAX responses: headers prevent any intermediate storage of the texts.
• Purged fingerprints: the visitor table cleans itself, retention is kept to the strict minimum.
• Zero cookies, zero external resources: nothing to add to your consent banner for this module.

Accessibility and performance

• Toasts announced via polite aria-live for screen readers.
• prefers-reduced-motion respected: animations are disabled if the visitor requests it.
• Dark mode supported automatically.
• Vanilla JS with no jQuery, assets loaded only on the product page: negligible impact on speed.

Technical compatibility

• PrestaShop: 8.0 to 9.x.
• PHP: 7.4 to 8.x.
• Hooks: actionFrontControllerSetMedia (front assets and configuration, product page only) and displayProductAdditionalInfo (visitor badge).
• Multistore and multilingual supported (FR/EN/ES/DE/IT translations included).
• No Composer dependency, no jQuery.

FAQ

Does the module fake purchases or visitors?

No, never. Notifications come only from actually recorded orders, and the counter only counts visitors genuinely present. Without data, the module displays nothing.

What if my store has few orders?

Widen the time window (e.g. 336 h for 14 days): notifications remain true, only the relative timestamp is older. The module will never fill a gap with fake data.

Does the counter set a cookie?

No. It relies on a salted SHA-256 fingerprint computed server-side, never exposed, and purged automatically. No additional consent to collect.

Is it compatible with PrestaShop 9 and multistore?

Yes, from PrestaShop 8.0 to 9.x, with native multistore support.

Troubleshooting

• No notification is displayed: check that orders exist within the time window with one of the selected statuses. This is the module’s normal behavior when there is no real data.
• The visitor counter does not appear: the number of active visitors is probably below the minimum threshold. Lower the threshold or test with several browsers/devices at once.
• Notifications do not reappear: if the visitor dismissed a toast, that choice is remembered for the session. Open a private browsing window to test again.
• The badge does not update: refresh happens every 60 seconds; also check that no aggressive cache blocks the front controller’s AJAX requests.