A large online pharmacy
An ecommerce healthcare retailer with meaningful order volume, audited alongside a review of its advertising spend. Company name, domain and exact figures have been removed. What’s below is real.
An ecommerce healthcare retailer with meaningful order volume, audited alongside a review of its advertising spend. Company name, domain and exact figures have been removed. What’s below is real.
Purchase events were firing several times for the same completed order for a real proportion of transactions in the audit window. That inflates reported revenue and conversion rate, and it doesn't stay contained to a dashboard: the business's ad platform uses those same figures to decide how much to bid for each click, so bidding decisions had been running on numbers that were overstated for some time.
Two custom fields in the analytics setup appeared to contain identifiable customer information, and both were configured to export to the linked advertising account as audience-targeting data. If those fields genuinely hold real names or account identifiers, sharing that with an ad platform doesn't meet UK or EU privacy law, and breaches the ad platform's own data policies. This needed confirming and, if confirmed, stopping immediately.
A recognised consent management platform was already installed on the site, which is the right foundation. But the container controlling which tags actually respect that consent signal wasn't available for review, so there was no way to confirm the consent tool's decisions were actually reaching the tracking tags. For a pharmacy handling health-adjacent purchases, that's a gap worth closing quickly rather than assuming it's fine.
A small but consistent share of monthly sessions had no recorded landing page, the signature of a session breaking mid-visit, typically where a visitor crosses between what look like two different domains without cross-domain tracking stitching them back together. Developer and staging traffic appearing in hostname reports pointed at the same underlying gap: traffic that shouldn't be counted as real visits wasn't being filtered out.
The default retention window hadn't been changed. Once data ages past two months it's gone permanently, which rules out comparing this year's performance to last year's, or spotting a seasonal pattern that only shows up over a longer window.
Beyond the general privacy question, sharing identified customer data with an ad platform for targeting purposes needs its own, explicit consent from those customers, separate from general analytics consent. This is a distinct legal question from whether the data should be in analytics at all, and it needed its own review.
When customers logged into their account, they were briefly sent to an external login page and back. Analytics treated the return as a brand new session and credited the login provider as the source, discarding whatever channel, a paid ad, an email, organic search, actually brought that customer in. This quietly overstates referral traffic and understates the channels doing the real work.
The advertising account was linked with personalisation switched on, letting visitor data build retargeting audiences. That's only lawful for visitors who've explicitly accepted targeting cookies, and with the consent setup unverifiable, there was no way to confirm personalisation was only activating for the right visitors.
Form submissions and the start of the checkout process were both being recorded as events, but neither was marked as a conversion goal. That means genuine enquiry and purchase-intent activity wasn't showing up in conversion reporting at all, hiding a large part of the picture from anyone trying to measure campaign performance.
Two separate event names, recording at very similar volumes, both looked like they represented completed purchases. Only one of them was set as the actual conversion goal, so the other was being silently ignored in every report, whether it was a duplicate of the same order or a second tracking system running in parallel needed investigating either way.
Staff, developers and any agency working on the site weren't excluded from analytics. Combined with staging and developer traffic already visible in hostname reports, this was inflating visitor and conversion figures by an amount that's impossible to isolate without the filter in place.
Every completed order added its full value to reported revenue, with no corresponding event for refunds or cancellations. For a pharmacy processing returns or cancelled prescriptions, that means reported revenue is the gross amount taken at checkout, not what the business actually retained.
Ecommerce data started at 'add to cart' with nothing recorded before it: no product list views, no individual product views. That removes any visibility into what visitors browse, what they consider, and where interest drops off before anything reaches a cart.
A handful of events used inconsistent capitalisation compared to the rest of the tracking setup. Analytics treats differently-cased versions of the same name as entirely separate events, so if any part of the site used a different casing for the same action, that action's data was being split across multiple rows instead of counted as one.
A handful of tracked events were firing at volumes well below what the rest of the site's activity would suggest. Consistently low counts on an action that should happen often is usually a sign the tracking is only working in some situations rather than firing reliably.
✓The full checkout funnel, from adding to cart through to a completed order, was tracked end to end.
✓Traffic quality was clean: no spam, self-referral or payment-gateway sessions distorting the numbers.
✓A consent management platform was already installed, the right starting point even though its connection to the tags couldn't be confirmed.
✓The advertising account was correctly linked with a data-driven attribution model in place.
This came from a normal two-minute audit, no manual digging. Your first audit is free.
Run a free audit →Duplicate purchase recording is one of the most common conversion-accuracy issues, the purchase event guide covers the related causes, and the consent mode audit guide covers verifying a consent tool is actually connected to your tags. More real audits are at Case studies.
Almost always the confirmation page firing its tracking code more than once for the same order, a refresh, a back-button revisit, or a redirect loop through a payment gateway that lands on the confirmation page twice. The fix is de-duplicating by a unique transaction ID, or moving the event to fire once at the point of order creation rather than on every page load.
Automated bidding systems use conversion volume and value as direct inputs. If half the recorded 'conversions' are duplicates of orders already counted, the bidding algorithm is optimising toward a number that doesn't reflect real revenue, which can mean it bids more aggressively than the real return justifies.
Names, email addresses, phone numbers and any identifier that could reasonably be linked back to a specific person. Custom fields with generic-sounding names can still hold real personal data if that's what a developer chose to populate them with, the field name itself doesn't tell you what's actually inside it, which is exactly why it needs checking rather than assuming.
No. A consent tool captures the visitor's choice, but something else, usually Google Tag Manager, has to actually act on that choice by holding tags back until consent is given. Without reviewing that connection, a site can have a fully compliant-looking cookie banner while every tag fires regardless of what a visitor chose.