ICDL Digital Marketing (ICDL): Analytics says 38 sales, the payment processor says 15

Likely causes, most probable first

• Duplicate firing. The purchase event fires on the thank-you page, so a refresh, a back-button return or a reopened tab records another conversion. 38 against 15 is a 2.5× inflation, consistent with multiple page loads per buyer.
• Non-purchase events counted as purchases: failed or abandoned payment attempts that still reach a confirmation URL, and test orders placed by the team.
• Refunds and cancellations still counted as conversions.
• Reporting mismatch: different time zones or date ranges between the two systems, or a currency setting difference (15 payments averaging €89 is plausible, so currency is a weaker suspect here but must be checked).

Checks in order

1. Compare transaction or order IDs between GA4 and the payment processor - duplicates show up immediately as repeated IDs.
2. Inspect the trigger for the purchase event: it should fire only once per unique transaction ID, on a page that cannot be reloaded into a second conversion.
3. Exclude internal traffic, office IPs and team test purchases.
4. Reconcile refunds and confirm identical reporting dates and time zones.
5. Then rebuild the number and compare again.

Ordering reason: transaction-ID matching is definitive and takes minutes; the rest is confirmation.

The newsletter is almost certainly inside the 62% Direct figure.

• Links without UTM parameters carry no campaign information. When the referrer is also stripped - which email clients, privacy features, in-app browsers and link shorteners routinely do - the session has no source to attribute and is filed as Direct / none.
• 62% Direct is far too high to be genuine direct traffic for a course seller. Real direct traffic is people typing the address or using a bookmark; it is usually a minority of sessions.
• Therefore the campaign report shows nothing because the tagging failed, not because the newsletter failed. Those are different claims and only one of them is supported by the data.

Checks that would settle it

• Whether any newsletter link carries utm_source / utm_medium / utm_campaign; build them with the campaign URL builder every time.
• Whether a unique landing page or a promo code used only in that email produced redemptions - a code is attribution that survives any browser setting.
• Whether the Direct sessions spike on the send date and decay over the following two days. A spike with that shape is the fingerprint of an email send.

The founder's instinct to distrust the dashboard is right. The conclusion to draw is 'we are not measuring properly', not 'email does not work'.

The principle: separate what is certain from what is inferred, and never present an inflated number as revenue.

1. Money received: €1,340 from 15 payments (payment processor - the trusted source for revenue).
2. Where it came from: reported channel mix is unreliable this month; email and direct traffic are merged inside the 62% Direct figure, so channel-level revenue cannot be stated yet.
3. Known data issues: purchase event double-counts on page refresh (GA4 shows 38, corrected figure is 15); newsletter links were sent untagged. Both are scheduled for fix and the report will be restated.
4. Best current proxy for email performance: redemptions of the June promo code and the Direct-traffic spike on the send date.
5. Decision needed: approve the tracking fix and a unique code per campaign, so next month's report can attribute revenue by channel.

Why this works: line 1 is auditable, line 2 admits the limit instead of filling it with a guess, line 4 gives something usable now, and line 5 turns a reporting failure into an agreed action. Abandoning analytics entirely would leave the founder with anecdotes, which are worse than clearly labelled imperfect data.