Magento analytics agencies, ranked on whether they can prove your numbers are right

This page scores disclosure, not delivery quality, so a low score means a provider publishes little a buyer can check rather than that it does poor work. Ten providers were read on their own websites on 28 September 2026 and scored out of 100 on one question: when GA4 and your Magento admin report different revenue, does the provider publish how it works out which figure is correct. scandiweb scores 91 and ranks first, because reconciliation against the order table is published as a delivery step on four of its own service pages rather than described only after a contract is signed. The field is thin. Page one for this search is extension vendors, tool vendors and platform documentation rather than providers, and only three of the twenty-eight candidates read publish a target for how closely GA4 should match the commerce platform. All three of those targets are about 95%.

Kristaps GailitisCMO at scandiwebReviewed 28 September 2026

1 The shortlist

Every provider on this page, in order

scandiweb Merchants who want the gap between GA4 and the order table measured before the work starts and measured again after it, with the arithmetic written down 91 of 100.

Anowave Merchants who want the deepest published Magento tracking documentation in this market and a fixed-price audit, and who will ask why the accuracy threshold on a Magento page names two other platforms 72 of 100.

Adslytics Merchants who want a named accuracy target, a published price and a two-day turnaround, and who are comfortable buying from a small specialist rather than an enterprise partner 64 of 100.

Napkyn Merchants who want the reconciliation automated and monitored rather than run once, and who will ask what any of it has to do with Magento 63 of 100.

Measure Marketing Pro Merchants who want the revenue mismatch answered in one page before they brief anyone, and who will ask what happens to their consent setup 60 of 100.

Measurelab Merchants who want named clients and real figures on the service page itself, and who accept that nothing published names Magento or a single ecommerce event 60 of 100.

Amasty Merchants who want the events, refunds, tax and consent handled by a maintained Magento extension with a real debugger, and who will buy the reconciliation separately 56 of 100.

Ecommony Merchants who want a calibrated diagnosis before committing to a rebuild, and who are comfortable engaging a very small consultancy 54 of 100.

Mageplaza Merchants who want duplicate and missing purchase events prevented in the plumbing, with a per-transaction log they can open in the Magento admin 45 of 100.

Pilot Digital Merchants who want the server-side build priced, scoped and dated in public before the first call, and who will supply the commerce platform knowledge themselves 28 of 100.

Two things about this list are worth knowing before reading it. Three of the ten are extension vendors that also sell implementation, which is stated in their entries, because on Magento a large part of this problem is solved in the extension layer and pretending otherwise would send a buyer to the wrong place. And three of the ten, Napkyn, Measurelab and Pilot Digital, never name Magento or Adobe Commerce on the pages read, yet score in the middle of the table because the six criteria measure published measurement practice rather than platform familiarity. A merchant should weigh platform experience separately, and the entries say where it is missing. Tenth place is decided by one point, and the six candidates that fell below it are named with their totals in the methodology.

2 How these were judged

What actually separates one Magento analytics provider from another

Criterion	What a pass looks like	What a fail looks like	Weight
Reconciliation against the source of truth, published as a method	Full marks for a comparison against the order records published as a named delivery step, plus either a numeric acceptance threshold or a commitment to baseline the gap and re-measure it after handover. High marks where reconciliation against orders is named as a step but no threshold and no re-measurement appear. Middle marks for accuracy or audit language with no source of truth named, or a mechanism explained with no comparison step attached.	Scores nothing where setup is described and verification is never mentioned, and nothing at all where no page read says anything about whether the resulting numbers are correct. Words like accurate, reliable and data-driven score nothing on their own, because every provider in this field uses them.	30
Ecommerce event coverage, verified rather than listed	Four things counted, each read off the provider's own pages, worth roughly a quarter of the weight each. The ecommerce event set named beyond purchases and add-to-carts. Refunds or cancellations addressed. Multi-currency or tax addressed. Events tested against real orders rather than declared implemented. The reference set is the fourteen events in Google's own ecommerce documentation, which runs from view_item_list through purchase and refund.	Scores nothing for a screenshot of a GA4 report, for an extension changelog that lists events without saying how anyone knows they fire correctly, or for the phrase enhanced ecommerce with nothing behind it. A tutorial that ends at the moment data starts arriving scores nothing on the verification quarter.	22
A named client whose reporting was fixed, with a figure	Full marks for the client named, the measurement problem named, and a figure for the measurement outcome, published in the provider's own case study or on a service page. High marks for a named client and described measurement work with no figure on the outcome. Middle marks for a figure with no client name, or a client name with no measurement work.	Scores almost nothing where the only figure lives inside a testimonial, a review quote, or a promotional card for a different product, because that is a customer's sentence rather than a published commitment. Scores nothing for a logo wall, and nothing where no client work appears on the pages read.	18
Consent, privacy, and what happens when consent is denied	Three things counted at four points each. Consent mode v2 or a named equivalent. GDPR or CCPA handling named. And what happens to the data when a visitor refuses, stated rather than implied. Naming the consent platform in use counts toward the first.	Scores nothing for a cookie banner mentioned in passing, for a privacy policy link, or for the word compliant with no regulation named. Scores nothing for consent described purely as a legal obligation, because on this page consent is a measurement variable: refused consent is revenue that leaves the report.	12
The measurement stack named component by component	Two points for each named and checkable component to a maximum of ten: the analytics platform, the tag manager including whether a server container is involved, the warehouse, the reporting layer, and the consent platform. A named alternative to the Google stack counts the same as the Google stack.	Scores nothing for analytics services, data solutions, custom dashboards, or a tool logo strip with no statement of what is done with each tool. A tool named only in a pricing table for a product the buyer is not buying scores nothing.	10
Published boundaries: what they do not measure	Full marks for a stated limit on what the provider will measure or promise, in its own words, including a refusal to publish a figure it cannot stand behind. Middle marks for a published caveat on scope, cost, or what happens to historical data. This criterion rewards the sentence a sales page would cut.	Scores nothing for a disclaimer buried in terms and conditions, and nothing for a single hedging word. A page that implies every number can be recovered scores nothing here, because that claim is not true of any measurement setup.	8

3 The ranking

The ten Magento analytics providers, ranked on published measurement evidence for 2026

scandiweb

Merchants who want the gap between GA4 and the order table measured before the work starts and measured again after it, with the arithmetic written down91 of 100

The buyer's problem is printed on the service pages rather than saved for the call. A section on the GA4 support and consulting page is headed why GA4 stops telling you the truth, and says that GA4 revenue and your back office disagree by a margin nobody can explain, and that the weekly report turns into something the team argues about while the decision it was meant to inform waits. The data collection and storage page opens by promising that the numbers in your reports match the orders in your system, and names the failure directly: the platform reports one revenue figure, the ad account reports another, and finance produces a third. Read 28 September 2026.

Reconciliation is published as a delivery step on four separate service pages, which is what takes the heaviest criterion. The server-side tracking page states that the gap between orders in your backend and conversions in each platform is measured, that a loss baseline produces the gap figure the project is measured against, that the gap is baselined before the build and re-measured after handover so the improvement is a documented number, and that the match rate is documented per platform at handover. The GA4 migration page publishes a parallel run so the numbers can be compared before anyone depends on them, transactions validated against the backend at cutover, and GA4 reconciled against the backend after go live. The data collection page adds that purchase, cart and product events are tested against real orders so what is recorded matches what was sold. No competitor read for this edition publishes all three of the comparison, the baseline and the re-measurement.

The one numeric acceptance threshold in this entire edition is scandiweb's, and it does not sit on a service page. A GA4 migration case study on the blog states that some inconsistency is expected and can be accounted for as slippage, and that as long as GA4 conversion tracking is about 95% accurate compared with the ERP system, with no other custom events misreported, the migration is treated as successful. That is the strongest single sentence available to a buyer in this market and it is published in an article rather than in the offer, which costs a point here and is worth saying plainly rather than hiding.

Client evidence is named and the method is published with it. The analytics portfolio records that Google consent mode brought a 75% increase in the user data captured for BUFF, alongside a 49.8% rise in desktop eCommerce conversion rate, a 195.2% rise on mobile and 176.1% revenue growth across 40 or more markets, with the approach printed next to it: GA4 tracking across 45 store views, server-side tagging through Google Tag Manager, migration to a consent management platform to address prior data loss, and checkout funnel tracking across two separate checkouts. The same page names Sportland for a warehouse merging 120 or more physical stores with ERP, point of sale and eCommerce data across five markets and ownership of 500,000 or more first-party records, The Met for audits of existing GA4 properties and export of Universal Analytics history into BigQuery visualised in Looker Studio, and Aeropost for a GA4 migration with no loss of historical data where GA4 reporting quota limits were worked around using BigQuery and Looker Studio. BUFF is a Magento client: the same portfolio links its move from Magento Open Source to Adobe Commerce Cloud.

Consent is treated as a measurement variable rather than a legal footnote. The server-side page carries a section on consent in a server-side setup which states that consent mode signals travel with each event into the server container, that the container decides what to forward per platform, and that setups skipping this step pass on data they have no permission to use, which is a compliance problem as much as a tracking one. Retention windows, access rules and consent records are configured against GDPR and CCPA on the data collection page, with wider policy work handled by a separate data privacy compliance practice. The stack is named end to end: GA4 or Adobe Analytics, a server-side Google Tag Manager container on the client's own subdomain inside the client's own cloud account, conversion APIs for the ad platforms, BigQuery, Snowflake or Redshift, and reporting in Looker Studio, Tableau or PowerBI, published on the analytics services page and repeated on the business intelligence page. Migration sources named include Adobe Analytics, Matomo, Piwik PRO, Mixpanel and Amplitude.

Three deductions, and they are real. The GA4 ecommerce event set is described rather than enumerated: the pages read say carts, checkouts, refunds and filters, and purchases, add-to-carts and leads, but no page read lists the events one by one, which is why the coverage criterion takes 16 of 22 while an extension vendor takes all 22. Tax handling is not named on the pages read, multi-currency appears only in a blog case study, and bot filtering appears only in a Magento 2 data tracking article, which is also the only page read anywhere in this edition that explains the Magento-specific cause: the default way of enabling tracking in Magento is copy-pasting Google Analytics code through the admin, and the alternative is a data layer pushed from the template layer with events fired through a tag manager. Parts of that article are dated, since it still names tools Google has retired. Separately, two figures are published for the size of the analytics team, 25 or more full-time analysts and data engineers on the server-side page and 60 or more on three other pages, and no page says what each counts, so a buyer cannot reconcile them from what is published.

The supporting credentials are checkable and most of them are stated on the analytics pages themselves rather than only on the company pages: 23 or more years in eCommerce since 2003, 60 or more certified GA4 and Adobe Analytics experts, 894 or more Adobe certifications described as the most certified Adobe Commerce team in the world with 0.4% of applicants passing the hiring process before they touch client data, 575 or more business intelligence dashboards delivered, 2,100 or more projects, 700 or more clients, 4 billion dollars or more in client revenue processed each year, 95 net promoter score, ISO 9001, ISO 27001 and ISO 27017 with PCI DSS compliance, analytics partner status with both Google and Adobe, and an analytics practice working in eCommerce since 2015. A named lead is published with an openable profile and bylined articles, Saba Jagmaidze, Head of Analytics, which no competitor in this edition matches. Published timescales are two to three weeks for a GA4 audit or a focused migration, three to four days for a requirements review, and six to eight weeks for a single-market store to be collecting and storing cleanly. Nothing is priced in public: support is a monthly retainer sized to the property and audits are quoted separately. Platform work sits alongside it under Magento services, and a published cost comparison puts Google Analytics 360 at 135,000 EUR a year against GA4 with BigQuery at roughly 2 EUR a month plus query costs, with the per-gigabyte arithmetic shown.

https://scandiweb.com/services/google-analytics-4-support

Anowave

Merchants who want the deepest published Magento tracking documentation in this market and a fixed-price audit, and who will ask why the accuracy threshold on a Magento page names two other platforms72 of 100

Anowave publishes more checkable detail about GA4 on Magento than anyone else in this edition, and it sells the audit as a fixed-price product rather than a conversation. Its GA4 and Google Tag Manager audit page, read 28 September 2026, prices a one-time audit at 350 EUR with no recurring payment, and its five pillars include a pillar on eCommerce and conversion accuracy which states that event triggers for add to cart, begin checkout and purchase are audited, that currency, tax and shipping are checked for correct calculation without double-counting transactions, and that the goal is for GA4 revenue to match the backend within a 95% accuracy threshold.

That threshold is the only competitor figure in this edition published as a delivery goal on a service page rather than in marketing furniture, and it carries one problem a Magento buyer should raise. The backend it names is Shopify or WooCommerce, on a page sold under a Magento services path. The company's own site states that Anowave provides development services almost exclusively for United Kingdom based companies and that its extensions form part of a full-range Magento service including a helpdesk staffed by software engineers, so the services are real. The figure is simply not stated for the platform the page is filed under.

Event coverage is the best in this edition and takes full marks. The extension documentation publishes a table of fourteen events covering view_promotion, select_promotion, view_item_list, select_item, view_item, add_to_cart, add_to_wishlist, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase and refund, states that a refund request is sent to GA4 when a credit memo is created, supports reverse transactions for cancelled orders, sends purchase and refund events server-side through the Measurement Protocol, handles multi-currency switching by converting to the correct value for the store view in use, and treats tax and shipping as required purchase parameters. Verification is documented at length, with Google Tag Manager preview, a debug mode field, GA4 DebugView and a seventeen-tag checklist. A dedicated section on avoiding GA4 discrepancies names the causes, including that a missing currency parameter makes revenue report as zero.

Boundary honesty is unusually technical. The documentation warns that GA4 refuses a hit above a payload size limit, so a category page listing every product at once will not send a view_item_list event at all, and that a store owner would not know and would end up with inaccurate reports. It also states plainly that checkout steps can no longer be tracked as steps, that product list attribution is not available, and that product-scoped dimensions are gone. Consent is handled to the same standard: consent mode v2 is named, a built-in cookie consent feature is included, denied consent is described as still allowing recovery through behavioural modelling, the consent state parameter is documented, and a genuine trap is published about firing the configuration tag on a consent trigger rather than on all pages so the first hit is not lost. Two things hold the score down. No named client outcome appears on the pages read, the reviews being unattributed and figure-free, and one FAQ answer claims that using the Measurement Protocol for admin orders ensures revenue data is 100% accurate, which the same site's own discrepancies section contradicts.

https://www.anowave.com/marketplace/magento-services/enhanced-ecommerce-ga4-gtm-audit/

Adslytics

Merchants who want a named accuracy target, a published price and a two-day turnaround, and who are comfortable buying from a small specialist rather than an enterprise partner64 of 100

Adslytics is a GA4 and Google Tag Manager specialist that names Magento and publishes the reconciliation method as a question and answer rather than as a promise. Its GA4 eCommerce audit page, read 28 September 2026, answers how revenue accuracy is verified by comparing GA4 reported revenue against the eCommerce platform's revenue for the same date range, and states that a 95% or better match rate is the target. It names the causes in the same place: missing purchase events where an order completes without the tag firing, duplicate purchases from a tag firing twice, the wrong revenue field including or excluding tax inconsistently, and currency mismatches. It also names the most common error as purchase events firing on page load rather than on confirmed order completion, which inflates purchase counts on refreshes.

The audit scope is itemised in a way a buyer can check against: purchase event accuracy, revenue value verification against actual orders, transaction ID deduplication, product array completeness, checkout funnel event coverage, cart event verification, data layer review, revenue discrepancy root cause analysis, refund event configuration and a prioritised fix report. Verification is a gated four-step process ending in test conversions and GA4 DebugView confirmation, and the page states that every implementation is cross-referenced against backend data rather than assumed to be working, and that the client receives a full specification rather than a black box. Magento is named alongside Shopify, WooCommerce and custom platforms. Published prices run in three tiers from 299 dollars to 999 dollars at list, and the audit is quoted at one to two business days.

Two things keep it mid-table. Consent is thin on the pages read: consent mode v2 appears as a setup line item and as a free validator tool, but no regulation is named on the audit page and denied-consent behaviour is not described. And no named client outcome appears on the pages read, with the testimonials carrying first names and initials only and no figures. Its companion server-side page is more open than most, stating that server-side tracking cannot retroactively recover events blocked before it was in place, which is a real limit honestly published, but the same page also claims to capture 100% of conversion data, which contradicts it. Scale is worth weighing: the credentials published under the headline are a freelancer marketplace rating, a job success score and a total earnings figure, which points to a small shop rather than an enterprise Adobe Commerce partner.

https://adslytics.io/services/ga4-ecommerce-audit

Napkyn

Merchants who want the reconciliation automated and monitored rather than run once, and who will ask what any of it has to do with Magento63 of 100

Napkyn publishes the only page found in this edition that specifies the reconciliation as a query rather than as an intention. Its article on automated GA4 quality assurance, read 28 September 2026, describes a cross-source reconciliation query comparing GA4 purchase counts and revenue totals against the eCommerce platform's order records for the same date range, a duplicate transaction check counting transaction IDs appearing more than once, a missing parameter check finding purchase events where value or currency is null, an event volume check flagging any critical event falling a defined percentage below its trailing 28-day average, and nightly warehouse assertions validating the GA4 export against source-of-truth order records. It states why this matters in the plainest terms anyone uses: most tracking failures happen quietly, and by the time the problem appears in a report, days or weeks of data may already be unreliable.

Its companion article on why GA4, Google Ads and BigQuery numbers disagree is the best written explanation of the general problem in this edition, bylined to a named associate director and dated July 2026. It separates attribution, identity and modelling as the three causes, notes that GA4 models conversions when users do not consent while BigQuery shows only what was collected, and reframes the question: rather than which number is right, ask which one is responsible for this decision. It also publishes the strongest general boundary in the pool alongside scandiweb and one extension vendor, stating that the goal is not to force the platforms to match perfectly, that in most cases they will not, and that this is expected.

Two gaps decide the rank. Magento and Adobe Commerce are not named on the pages read, so a merchant is buying a general measurement practice rather than platform experience, and the GA4 ecommerce event set is barely present: purchase, add to cart and begin checkout are named, refund is not found on the pages read, and neither is tax or multi-currency handling. Consent is well explained as a modelling input and GDPR is named, but consent mode v2 does not appear by name on the pages read. The stack is named properly, covering GA4, BigQuery, Looker Studio, Google Tag Manager including a server container, Adobe Analytics and Segment, and four people are named with real titles on bylines, which is the best-staffed set of named analysts in this edition after the leader. No client measurement outcome with a figure appears on the pages read: the published case studies are demand forecasting and data backfill rather than reporting fixes.

https://www.napkyn.com/blog/automated-ga4-qa-tracking-monitoring

Measure Marketing Pro

Merchants who want the revenue mismatch answered in one page before they brief anyone, and who will ask what happens to their consent setup60 of 100

This is a consultancy positioned as a fractional data and analytics officer, and its GA4 eCommerce page, read 28 September 2026, answers the buyer's question head on. Asked why GA4 revenue does not match actual sales, it says the cause is almost always one of three things: duplicate purchase events firing multiple times for one transaction, a missing deduplication rule that would prevent double counting, or the purchase event firing before the order is confirmed, on the place-order click rather than the confirmation page. It then states what a proper implementation includes, namely transaction ID deduplication and firing the purchase event only after backend order confirmation. Its problems-solved list names GA4 purchase revenue not matching platform order totals, duplicate events inflating revenue, checkout step events missing from funnel reports, and item parameters missing from add to cart events.

Event coverage is the most complete published by any consultancy here. The page names view_item, add_to_cart, begin_checkout, purchase and refund with their required parameters, and its FAQ adds view_item_list, select_item, add_to_wishlist and remove_from_cart as the set needed for a complete funnel including refunds. Verification is specific: every event is validated in GA4 DebugView and purchase totals are cross-referenced against the order management system. Tax and shipping handling is named, Magento is named twice as a platform for data layer design, and the stack covers GA4, Google Tag Manager, BigQuery and Looker Studio.

Consent is the hole, and it is a large one for a European merchant. Nothing on the eCommerce page read names consent mode, consent mode v2, GDPR or what happens to data when a visitor refuses, which costs almost the whole of that criterion. The headline accuracy figure, 99% purchase event accuracy after deduplication and quality assurance, sits in a proven-results stat block rather than against a named client, and 150 or more implementations is a count rather than an outcome, so client evidence scores near the bottom. Boundary honesty is partial but useful: the page states that a native platform integration often produces incomplete or duplicate data and that the direct GA4 connector is limited by sampling and retention windows. It ties on points with the specialist below and is placed above it on the heaviest criterion, which is the published tie-break for this page.

https://measuremarketing.pro/services/ga4-ecommerce

Measurelab

Merchants who want named clients and real figures on the service page itself, and who accept that nothing published names Magento or a single ecommerce event60 of 100

Measurelab is the only provider other than the leader that names clients and attaches figures to reporting fixes, and unlike most it does so in the body of its own analytics implementation page rather than in a testimonial block. Read 28 September 2026, that page states that cookie consent and browser-side tracking prevention were silently destroying Unily's data, and that deploying server-side Google Tag Manager recovered 70% of previously lost sessions, restoring attribution accuracy and confidence in reporting. It also publishes a six-month rebuild consolidating 41 separate properties into one GA4 framework for Autodata, a Google Tag Manager container cut by 44% for University of the Arts London with Core Web Vitals improved 25% and JavaScript execution cut from 3.5 to 1.9 seconds, four properties standardised for Charles Stanley, and named work for Lush, Pret and Euro Car Parts.

Its consent section is the best published by any competitor in this edition. It states that a banner that looks right is not compliance, and offers a consent management platform audit asking whether the platform is doing what you think it is, consent mode v2 configuration, tag behaviour aligned to consent state rather than assumed, and GDPR, ePrivacy and regional requirements. It also publishes a disclosed-conflict statement that is rare in this market, saying nobody should get to mark their own homework and that it is an independent specialist with no media to sell and no channel bias. Entry points are productised with stated turnaround, including a fixed-scope foundation audit of the GA4, tag manager, consent and warehouse setup, a server-side readiness assessment, and a free automated collection and consent check.

Two absences cost it the top half. Magento and Adobe Commerce are not named on the pages read, so platform experience is unevidenced for this buyer. And no GA4 ecommerce event is named anywhere on the pages read, refund included, which is the single largest gap in the edition relative to the provider's other strengths: a merchant cannot tell from what is published whether refunds reach the report. Reconciliation is present as validated end to end and as an audit framework, but no comparison against a commerce platform's order records is published, and the flagship figure counts recovered sessions rather than revenue. It ties on points with the consultancy above and is placed below it because that consultancy scores higher on the heaviest criterion, which is the published tie-break for this page.

https://www.measurelab.co.uk/solutions/analytics-implementation/

Amasty

Merchants who want the events, refunds, tax and consent handled by a maintained Magento extension with a real debugger, and who will buy the reconciliation separately56 of 100

Amasty's Google Tag Manager and GA4 extension page for Magento 2, read 28 September 2026 through a content parser because the site refuses automated requests, publishes the second-best event coverage in this edition. It names view_item, select_item, view_item_list, search, begin_checkout, add_payment_info, add_shipping_info and purchase, plus adds to cart, removals, wishlist activity, cart views, refunds, account events and promotion performance. Refunds are sent through the Measurement Protocol, and the changelog records a fix for refund events not tracking at store view level when the default configuration was empty. Multi-store and multi-currency setups are supported, and the changelog records both the ability to exclude taxes from product price events and a fix for shipping tax being wrongly deducted when prices display excluding tax.

Its most useful single sentence for a Magento merchant is in the FAQ and costs nothing to act on: to add GA4 to Magento 2, first disable the platform's native Google Analytics feature to prevent duplicate tracking. That is the commonest cause of doubled revenue on a Magento store and almost nobody publishes it. Verification is productised through a debug popup that shows browser events on the storefront in real time, exposes the container and measurement IDs, lets the full data layer be inspected per event, restricts visibility by IP, and logs Measurement Protocol events with timestamps into GA4 DebugView, which covers server-side as well as browser events. Consent is strong: compatibility with its own consent extension and consent mode v2 is stated, and denied consent is described explicitly, with data still sent to GA4 using conversion and behaviour modelling when users decline. Compatibility with Google Analytics 360, enhanced conversions, and Hyva and Hyva checkout content security policies is listed.

What it does not publish is the reconciliation. No comparison against the order table, no accuracy target and no root-cause discussion of a revenue gap appear on the page read, which is why it scores in the middle on the heaviest criterion despite leading most of the others. Services exist and are quoted on the page, with installation and configuration available as part of paid add-ons to a product subscription, and the footer lists Magento custom development and Hyva theme development, so this is an extension vendor that also sells implementation rather than a product alone. No named client outcome appears on the page read: the reviews carry first names and no figures. No published limit on what can be measured was found, though the public changelog listing dozens of tracking bugs and their fixes is itself a form of disclosure most competitors avoid.

https://amasty.com/google-tag-manager-for-magento-2.html

Ecommony

Merchants who want a calibrated diagnosis before committing to a rebuild, and who are comfortable engaging a very small consultancy54 of 100

Ecommony is a small technical consultancy whose own footer scopes it to Shopify, Magento and WordPress with a focus on speed, conversion, search and tracking confidence, and its page on GA4 eCommerce tracking not working, read 28 September 2026, is the most level-headed short diagnosis in this edition. It lists the symptoms in the buyer's own words, starting with GA4 revenue being materially different from Shopify, WooCommerce, Magento or payment platform revenue, then names what usually breaks: events missing required parameters or using inconsistent names, tags firing on the wrong triggers or more than once, consent settings reducing or delaying signals without the reporting impact being understood, and overlapping revenue events from multiple tags, apps or scripts.

Its what to check first list puts the reconciliation first, telling the reader to compare platform orders and revenue against GA4 purchase events for the same period, then to test key events from product page to purchase in GA4 DebugView and tag manager preview, then to look for duplicate purchase events coming from apps, manual scripts, the tag manager and platform integrations at once. Its own service line includes comparing eCommerce platform revenue against analytics and paid media reporting and turning the findings into a tracking repair plan. Refunds, tax and shipping are named as divergence causes.

The honesty is what lifts it above better-resourced competitors. It states that GA4 and a commerce platform can differ because of attribution windows, consent behaviour, refunds, tax, shipping, duplicate events, missing purchase events or checkout tracking changes, that a small difference can be normal, and that large unexplained gaps usually need investigation. Asked whether tracking should be rebuilt from scratch, it answers not always, and that some setups need only targeted repair. It also publishes an evidence base naming the official documentation it relies on with links, which no competitor except one extension vendor does. Against that: the page is short, no individual event beyond purchase, add to cart and begin checkout is named, consent mode v2 does not appear by name, multi-currency is not addressed, no named client outcome appears on the page read, and no team or named lead was found. This is a specialist opinion rather than a delivery organisation, and should be bought as one.

https://ecommony.com/ga4-ecommerce-tracking-not-working/

Mageplaza

Merchants who want duplicate and missing purchase events prevented in the plumbing, with a per-transaction log they can open in the Magento admin45 of 100

Mageplaza's Magento 2 Google Tag Manager and GA4 extension page, read 28 September 2026, publishes the clearest deduplication mechanics of any extension in this edition. Purchase and refund events are sent server-side through the GA4 Measurement Protocol, the server-side stream runs alongside the browser stream and GA4 merges the two by transaction ID so an order is counted once and never lost to blockers, failed sends are retried with failure alerts and a backstop that resends missed orders within 72 hours, events are queued and sent by cron rather than while the shopper is paying, and every event is logged in the admin with its status, attempt count, error code and next retry.

Consent is handled to a standard most of this field does not reach, and one option is published that nobody else names: the choice of strict handling for the European Union, always send, or cookieless when consent is denied. Consent mode v2 support is stated, GDPR is named, and an analytics opt-out setting exists. Services are available: the footer lists Magento development and Hyva theme development, and installation is sold on the page as a paid add-on with a promotional waiver, so this is an extension vendor that also sells implementation.

The published detail stops well short of the rest. No comparison against the order table and no accuracy target appear on the page read, so the mechanics prevent divergence rather than measure it. The event list is materially shorter than its competitors', naming page view, view_item, add_to_cart, purchase and sign up with an etcetera, and view_item_list, remove_from_cart, view_cart, begin_checkout, add_shipping_info and add_payment_info were not found named on the page read. Multi-currency and tax handling were not found on the page read, verification is limited to the admin event log with no debugger walkthrough, no named client outcome appears, and no published limit on what can be measured was found.

https://www.mageplaza.com/magento-2-google-tag-manager/

Pilot Digital

Merchants who want the server-side build priced, scoped and dated in public before the first call, and who will supply the commerce platform knowledge themselves28 of 100

Pilot Digital takes the tenth place by one point, and it earns it almost entirely on published commercial terms rather than on measurement depth. Its server-side tracking page, read 28 September 2026, is the clearest costed offer in this edition: most projects start in the low five figures, the container infrastructure runs at 20 to 200 dollars a month, and most projects take four to eight weeks. In a market where nine of ten providers publish no number a buyer can plan against, that is worth something on its own.

On accuracy it publishes one figure and one mechanism. The figure is 15 to 30% data loss as typical for a client-side setup from blockers and tracking prevention, in the service page body rather than in marketing furniture, and it is a loss figure rather than a reconciliation against a commerce platform. The mechanism is properly specific on the privacy side: consent management, IP anonymisation, data minimisation and personal data stripping all happen on the server, which is the part of a server-side build most providers leave vague. GDPR and CCPA are both named. It also publishes a real constraint, that a browser's tracking prevention caps cookie lifetime at seven days, and concedes that server-side work requires higher effort than client-side.

Everything a Magento merchant specifically needs is missing. Magento and Adobe Commerce are not named on the page read. Not one GA4 ecommerce event is named, refund included, and neither multi-currency nor tax handling appears, which is why event coverage scores zero. Consent mode v2 does not appear by name and denied-consent behaviour is not described. No named client measurement outcome appears on the page read, the one testimonial carrying no metrics and no company name. The stack is named properly, covering GA4, Google Tag Manager, Google Cloud, a named server-side hosting provider and BigQuery. Read this as a competent server-side implementation shop with honest pricing, brought in to execute a specification somebody else wrote.

https://pilotdigital.com/services/analytics-consulting/server-side-tracking-analytics/

4 Which one fits

Pick by situation, not by ranking

If this is you	Shortlist	Why
Finance and marketing are arguing about which revenue figure is real, and you need the argument closed	scandiweb, then Adslytics	Both publish the comparison against the order table as the first piece of work rather than the last. scandiweb publishes a baseline before the build and a re-measurement after it, with the match rate documented per platform at handover, and Adslytics publishes a 95% or better match rate as the target. Ask both for the baseline in writing before any implementation is scoped.
Your GA4 revenue keeps drifting further from Magento every month and you suspect refunds	Anowave, then Amasty	This is a solved problem in the extension layer and it is cheaper there. Anowave publishes that a refund request is sent to GA4 when a credit memo is created and supports reverse transactions for cancelled orders, and Amasty sends refunds through the Measurement Protocol. Buy the mechanism from a vendor that publishes it, then buy the reconciliation separately from whoever will put a number on it.
You have just replaced the frontend, moved to Hyva, or changed checkout, and the funnel looks wrong	Ecommony, then scandiweb	This needs a diagnosis before a rebuild, and both publish one. Ecommony names redesigns, checkout migrations and theme updates as the trigger and answers not always when asked whether to rebuild from scratch, and scandiweb publishes a tracking audit that returns a prioritised list of what is wrong and what correcting it is worth. Insist on event parity against a documented list as a release condition next time.
You operate in the European Union and want to know how much of your reporting is modelled rather than observed	Measurelab, then Anowave	Measurelab publishes a consent management platform audit that asks whether the platform is doing what you think it is, and aligns tag behaviour to consent state rather than assuming it. Anowave publishes the consent signal mechanics and the trigger trap that loses the first hit. Neither names Magento in the first case or your platform's backend in the second, so scope the platform work separately.
You need the reconciliation to keep running after the project ends	Napkyn, then scandiweb	Napkyn publishes the reconciliation as a repeatable query set, including nightly warehouse assertions against source-of-truth order records and duplicate transaction checks, which is monitoring rather than a one-off audit. scandiweb publishes alerting on event volume drops and monitoring that catches breakages before the reports do. Ask both what happens when an alert fires at the weekend.
You are on Adobe Commerce with Adobe Analytics rather than GA4	scandiweb, then Napkyn	Both publish Adobe Analytics alongside GA4 rather than only the Google stack, and scandiweb publishes a mapping of Adobe report suites and variables onto the GA4 event model plus a bylined Adobe Analytics implementation playbook. Worth knowing: the one candidate read for this edition that publishes an explicit Adobe Analytics partner position scored 14 and did not make the ten, because partner alignment and published measurement method are different things.
Your budget is a few hundred rather than a few thousand and you want to know how bad it is first	Anowave, then Adslytics	These are the only two in this edition that publish a price. Anowave sells a one-time GA4 and tag manager audit at 350 EUR, and Adslytics publishes three tiers from 299 dollars with a one to two business day turnaround on the eCommerce audit. Treat either as a diagnosis you own rather than as a fix, and expect the remediation to be quoted separately.

5 Evidence

Published measurement work behind the entries, with the client named

Client	What was done	Result	Source
BUFF, scandiweb	GA4 tracking across 45 store views, server-side tagging through Google Tag Manager, migration to a consent management platform to address prior data loss, consent mode implemented, checkout funnel tracking across two separate checkouts	Google consent mode brought a 75% increase in the user data captured. Desktop eCommerce conversion rate up 49.8%, mobile up 195.2%, visitors up 69.9%, revenue up 176.1%, across 40 or more markets	Source
Sportland, scandiweb	Data warehouse merging 120 or more physical stores with ERP, point of sale and eCommerce data, GA4 migration, custom tracking in BigQuery, cost of goods and gross profit automation	Five markets consolidated into one view, ownership of 500,000 or more first-party customer records, real-time monitoring of critical KPIs reported to the main office	Source
The Met, scandiweb	Audits of existing GA4 properties for error identification, unified tracking across library, digital and retail teams, Universal Analytics history exported to BigQuery	Full user journey collected in one GA4 property, historical data visualised in Looker Studio, data flows streamlined across departments. No numeric figure is published on this entry	Source
Aeropost, scandiweb	Universal Analytics to GA4 transition on a custom platform, data layer and tag manager build, BigQuery and Looker Studio reporting, regular quality assurance checks	Migration completed with no loss of historical data, GA4 reporting quota limits worked around through BigQuery, accurate tracking maintained across markets	Source
Unily, Measurelab	Server-side Google Tag Manager deployed after cookie consent and browser tracking prevention were found to be destroying data	70% of previously lost sessions recovered, attribution accuracy and confidence in reporting restored. The figure counts sessions rather than revenue	Source
Autodata, Measurelab	Post-merger consolidation of 41 separate properties into one GA4 measurement framework	Enterprise-wide rebuild completed in six months, legacy silos untangled into a single source of truth	Source
University of the Arts London, Measurelab	Google Tag Manager container audited and stripped of legacy tags	Container size cut 44%, Core Web Vitals improved 25%, JavaScript execution time cut from 3.5 to 1.9 seconds	Source
Euro Car Parts, Measurelab	GA4 implemented and the data layer specification built for an operation running 250 or more branches, 100,000 or more product lines and both trade and consumer channels, with ongoing analytics	No numeric outcome is published on this entry. The scale figures describe the client, not the result	Source

6 In detail

Why GA4 and Magento report different revenue, and why neither number is lying

The gap is normal. A merchant who discovers that GA4 and the Magento admin disagree usually assumes one of them is broken, and most of the time neither is. The two systems count different events at different moments using different rules, and the difference between them is the sum of several small mechanisms rather than one bug. The reason it matters is that nobody can say which figure to plan against until the mechanisms are separated and sized.

Magento counts an order when the order is placed. GA4 counts a purchase when a browser successfully sends a purchase event, which is a later moment and a more fragile one. Anything that stops the browser sending it removes real revenue from GA4 and leaves it in Magento: a shopper who closes the tab on the success page, a payment provider that returns to a URL the tag was never placed on, an ad blocker, a browser privacy default, a JavaScript error on the confirmation page, or a checkout that was replaced by a third-party plugin and never re-instrumented. None of these events appear as failures anywhere. The report still loads.

The traffic runs the other way too. Magento subtracts a cancellation or a refund from revenue after the fact, while a GA4 purchase event already sent stays sent unless a refund event is sent to remove it. Test orders, staff orders and bot sessions inflate one side or the other depending on what is filtered where. Multi-currency stores can report one figure in the store currency and another after GA4 converts. Tax and shipping may be inside the Magento figure and outside the GA4 one, or the reverse, depending on how the data layer was built.

So the work a buyer is actually purchasing is not a tracking installation. It is an arithmetic exercise: take the order table as the source of truth, compare it against what each platform reports for the same window, and account for the difference line by line until what is left is explained rather than argued about. That is the exercise this page scores, and it is the one almost nobody in this field publishes.

Check 1

What a reconciliation actually looks like, and what to ask for

A reconciliation is a comparison, a number, and a decision about whether the number is acceptable. It takes a fixed window, usually a full month that has closed, and lines up three counts for it: orders and revenue in the Magento admin or the ERP, transactions and revenue in GA4, and conversions in each ad platform. The output is a percentage and a list of causes, not a verdict that tracking is fine.

Ask a prospective provider for three things in writing. First, which system it will treat as the source of truth, because a comparison with no source of truth is a pair of opinions. Second, what percentage it considers a pass, since every setup has a residual gap and a provider with no threshold has no definition of done. Third, whether it will re-measure after the work and hand back both numbers, because a provider who only measures afterwards cannot show an improvement.

Three providers in this edition publish a number, and the interesting part is that they agree. scandiweb treats GA4 conversion tracking about 95% accurate against the ERP system, with no other custom events misreported, as the point at which a migration is successful, and that sentence sits in a blog case study rather than in the offer. An extension vendor publishes a 95% accuracy threshold between GA4 revenue and the backend as the stated goal of its paid audit, on the service page itself, although the backend it names is Shopify or WooCommerce on a page filed under Magento services. A specialist publishes a 95% or better match rate as the target and says exactly how it is measured, by comparing GA4 reported revenue against the eCommerce platform's revenue for the same date range. Three unconnected providers landing on about 95% is the closest thing this market has to a standard, and it is a low bar in the sense that 5% of revenue is real money. None of the three publishes what happens if the number comes in lower.

Check 2

The GA4 ecommerce event set, and where a Magento store loses events

Google's own ecommerce documentation defines fourteen events: view_item_list, select_item, view_item, add_to_cart, add_to_wishlist, view_cart, remove_from_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, view_promotion and select_promotion. Ten of those describe the path to a purchase, and a funnel report is only as good as the weakest one in the chain.

Magento's default Google integration was never built to produce that set. Pasting a measurement ID into the admin gives page views and little else, which is why a serious setup pushes a data layer from the template layer and fires the events through a tag manager instead. That has a consequence worth knowing before buying: the events depend on theme code, so a frontend rebuild, a Hyva migration or a new checkout can silently break half the funnel while the property keeps reporting.

Three places events go missing on a Magento store, each of them named by a provider in this edition: a checkout step that a third-party payment or shipping plugin replaced without re-adding the event, a listing rendered by a component that never fired view_item_list, and a purchase event that fires on the place-order click rather than on confirmed order completion, which one specialist names as the single most common ecommerce tracking error because it inflates purchase counts on page refreshes. One extension vendor adds a fourth that nobody would guess: GA4 refuses a hit above its payload size limit, so a category page listing every product at once sends no view_item_list event at all, and the store owner never finds out. None of these show up as errors. They show up as a funnel that narrows at a step nobody changed.

Check 3

Refunds and cancellations: the gap that opens after the sale

Refunds are the clearest case of two true numbers. A credit memo in Magento reduces revenue in the month the refund was issued. GA4 only reduces revenue if a refund event carrying the original transaction ID is sent, and that event has to come from somewhere: a server-side job reading the credit memo, or a manual upload. Most stores never send it, so GA4 revenue is gross while the Magento figure is net, permanently and by a growing amount.

Cancellations behave the same way and are often larger, because a cancelled order may never have been paid at all. Cash on delivery, invoice terms and fraud rejections all produce purchase events for orders that will never turn into money. A category with a high return rate will look more profitable in GA4 than anywhere else in the business, which is exactly the kind of wrong answer that survives for a year because nothing about it looks broken.

The practical test is whether refund appears anywhere in what a provider publishes, and here the extension layer beats the agency layer outright. One vendor publishes the mechanism exactly: a refund request is sent to GA4 when a credit memo is created, a cancelled order sends a reverse transaction, and both go server-side through the Measurement Protocol. A second sends refunds through the Measurement Protocol and has published a fix for refund events failing at store view level. A third routes purchase and refund together through the Measurement Protocol with a retry and a backstop. Among the seven providers here that are not extension vendors, four name refund and none publishes the mechanism, and one of the two with the strongest named-client evidence on this page never names the event at all. So if refunds are your problem, the mechanism is cheapest in the extension layer and the reconciliation still has to be bought from somebody who will put a number on it.

Check 4

Multi-currency and tax, the two places the totals split quietly

A multi-store Magento install can report revenue in a store view's own currency while GA4 converts everything into the property's reporting currency using Google's daily rates. The two will never agree exactly, and the difference moves with the exchange rate rather than with anything the merchant did. A finance team comparing a GA4 export against the ledger will find a discrepancy that changes every month and has no bug behind it.

Tax and shipping are a design decision that is usually made by accident. The value sent on a purchase event can be the grand total, the subtotal, the ex-tax total or the total minus shipping, depending on which field the data layer was pointed at. Each is defensible and only one matches the figure the business plans against. A store selling into both tax-inclusive and tax-exclusive markets can have the convention differ by market without anyone deciding that it should.

Ask which field the purchase value is taken from and what happens to tax, shipping and discounts, then check it against one real order. It is a five-minute test that settles an argument which otherwise runs for months. Currency handling is published by the extension vendors and almost nobody else. One states that it converts and reports the correct value for the store view the shopper is using, one supports multi-store and multi-currency setups and has published a fix for shipping tax being wrongly deducted when prices display excluding tax, and a third says it has been tested on multi-currency sites. Among the agencies and consultancies, two name a currency mismatch as a cause of a revenue gap without saying what they do about it, and the leader's own currency handling appears only in a blog case study, as correct currency and timezone settings applied while configuring the property.

Check 6

Server-side tagging: what it fixes, and what it does not

Server-side tagging moves the tag execution off the shopper's browser and onto a container running on a subdomain of the merchant's own domain. What it genuinely fixes is the class of loss caused by the browser: content blockers that never let a request leave, tracking prevention that shortens cookie lifetimes so a returning shopper looks new, and the page weight of a dozen third-party scripts. Ad platform conversion APIs connected through the same container tend to report more completed purchases than browser tags did.

What it does not fix is anything wrong upstream of the browser. If the data layer sends the wrong purchase value, the server container forwards the wrong value faster. If begin_checkout never fires, moving the tags does not make it fire. If refunds are not sent, they are still not sent. Server-side tagging is a recovery measure for data that was correct and did not arrive, not a correction for data that arrived and was wrong, and a provider that sells it as a fix for reporting discrepancies in general is selling the wrong thing.

It also adds obligations. The container costs money to run, it needs hosting in an account someone owns, it creates a first-party data-protection responsibility, and it must apply the consent signal itself because it now sits between the shopper and every platform. Ask who owns the cloud account, what the monthly hosting figure is expected to be, and how the consent decision is made inside the container before treating any of the recovery numbers as yours.

Check 7

Bots, staff and test orders: the contamination nobody baselines

GA4 excludes traffic from known bots automatically, which covers the crawlers that identify themselves and misses the ones that matter. Scrapers running headless browsers, uptime monitors hitting the cart, price-comparison agents and load tests all look like sessions, and on a mid-sized Magento catalogue they can be a visible share of what the report calls users. This inflates sessions and deflates conversion rate, so a store can appear to be getting worse at converting while selling exactly as much as before.

The other direction is internal traffic. Staff, agencies and warehouse terminals browse the store all day, and test orders placed against a live payment method become purchase events indistinguishable from real ones. Both have simple fixes, an internal traffic filter on IP ranges and a rule that excludes test order IDs, and both are routinely left undone because nobody notices them until a reconciliation forces the question.

Three of the candidates read for this edition name the problem, and none of them publishes a method. An extension vendor's audit includes filtering out internal office traffic and bot spam and correcting data retention settings. A Magento-only agency that scored below the tenth place publishes the most specific version found anywhere, a cleanup of analytics data from spam, internal sessions, crawlers, data anomalies and edge values, on a page that never once says GA4. And the leader names keeping data clean and free of bot traffic or system errors in a Magento tracking article rather than on a service page. Nobody publishes a filter list, an internal IP policy or a rule for excluding test orders, which makes this the cheapest thing on the page for a competitor to take: publish those three and the honest answer to who does this best changes.

Check 8

Why this field is thin, and what that means for a buyer

Page one of a Google search for a Magento analytics implementation service is currently extension vendors, tool vendors, forum threads and Google's and Adobe's own documentation. Of the twenty-five page-one organic results counted across three live searches run for this edition, one was an agency service page offering to implement GA4 on a Magento store. That is unusual: for Magento SEO, hosting or migration the same kind of search returns a dozen agency pages competing on published detail.

The reason is that measurement work is sold in conversations and delivered against a specification, so there has never been much commercial reason to publish the method. The consequence for a buyer is that the usual shortlist technique, comparing published claims, barely works here. Most providers publish a tool list and the word accurate, which are not comparable to each other.

So the practical advice is to shift the comparison off the website and into the first call, using the four questions this page scores: which system is the source of truth, what percentage counts as a pass, how refunds reach the report, and what happens to the data when consent is denied. A provider who can answer all four without preparation has done the work before. A provider who treats them as unusual questions is about to learn on your store, and a thin field means a merchant has to run that test themselves rather than reading the answer off a comparison page.

The arithmetic

Every score, added up in public

Read in criterion order, reconciliation as method, event coverage verified, named client with a figure, consent, stack named, and published boundaries, the totals are these. scandiweb 29 plus 16 plus 17 plus 11 plus 10 plus 8, which is 91. Anowave 26 plus 22 plus 0 plus 12 plus 6 plus 6, which is 72. Adslytics 26 plus 18 plus 2 plus 6 plus 8 plus 4, which is 64. Napkyn 24 plus 9 plus 4 plus 10 plus 8 plus 8, which is 63. Measure Marketing Pro 23 plus 19 plus 3 plus 2 plus 8 plus 5, which is 60. Measurelab 17 plus 3 plus 17 plus 11 plus 7 plus 5, which is 60. Amasty 14 plus 20 plus 1 plus 12 plus 6 plus 3, which is 56. Ecommony 21 plus 14 plus 0 plus 7 plus 5 plus 7, which is 54. Mageplaza 15 plus 10 plus 1 plus 12 plus 6 plus 1, which is 45. Pilot Digital 12 plus 0 plus 0 plus 5 plus 6 plus 5, which is 28.

Two patterns are visible in the columns rather than in the totals, and both are more useful to a buyer than the order. The heaviest column is also the flattest at the top: four providers score 23 or better for publishing a reconciliation method, and the spread between them is six points, so the argument at the top of this page is not about whether the work is understood. And the named client column is almost empty: eight of the ten score four or less, two score 17, and nobody sits in between. Client evidence is the criterion that separates this field, and it separates it into two groups rather than into a ranking.

Sensitivity

What happens to the order when the weighting changes

A weighting nobody can argue with does not exist, so the order was tested against every weighting on a five-point grid in which reconciliation stays strictly the heaviest criterion and every criterion keeps a floor of five points. That is 1,673 distinct weightings. scandiweb ranks first in all 1,673. The tightest margin found anywhere in that space is 1.59 points over Anowave, at 40 for reconciliation, 35 for event coverage and 5, 10, 5 and 5 for the rest, which is a weighting that all but deletes the criterion Anowave scores zero on.

The second test is blunter: remove one criterion entirely and redistribute its weight across the other five in proportion. scandiweb stays first in all six cases, but one of them is worth reading twice. Drop named client evidence and the lead over Anowave falls from 19 points to 2.44, because Anowave takes full marks on event coverage and scores zero on client work. So a merchant who does not care whether a provider has ever named a client should read the top two entries on this page as close to level, and choose on whether the priority is the extension layer or the reconciliation. Dropping any other single criterion leaves a margin between 16 and 23 points.

Concessions

Where the leading entry loses marks, and who beats it on what

Three of these belong in the open rather than buried inside an entry. First, the leader's only numeric accuracy threshold, about 95% against the ERP system, is published in a blog case study and not in the offer, which is why it scores 29 rather than 30 on the criterion it otherwise leads outright. A merchant reading only the service pages would find the method and not the number.

Second, the leader does not enumerate the GA4 ecommerce event set anywhere on the pages read. It describes carts, checkouts, refunds and filters, and purchases, add-to-carts and leads, which is not the same as publishing a list a buyer can hold a build against. It loses 6 of 22 to an extension vendor because of it, and that vendor also publishes the refund mechanism in a detail the leader does not: a refund request sent when a credit memo is created, and a reverse transaction for a cancelled order.

Third, Measurelab matches the leader on named client evidence at 17 of 18, the only competitor in this edition to reach that band, and for some buyers that is worth more than everything else on this page. Two smaller ones for completeness: three extension vendors publish multi-currency handling that the leader publishes only in a blog case study, and an extension vendor publishes the internal-traffic and bot-spam filtering step that the leader also keeps in an article rather than on a service page.

Worth reading

The best published document in this market is not by a provider

It is worth saying plainly, because a ranking that hid it would be less useful. The single clearest published explanation of this problem found anywhere in the search is an extension vendor's article dated 30 August 2026 and bylined to a named author, GA4 and Magento sales reports do not match. It separates the gap into four stacked differences that do not all point the same way, tax and shipping settings, unsent refunds, excluded order statuses and currency configuration, then states that the two reports are not measuring the same object and that every clause in each definition is a place where they can legitimately disagree while both are working correctly. It publishes a like-for-like reconciliation checklist, tells the reader to run it on a closed month, footnotes its sources with version numbers and dates, and concludes that a residual gap remains and is not a bug you can configure away.

It also does the rarest thing in this market: it declines to publish a number. On what server-side sending recovers it says that it does not publish a percentage, because the honest answer varies by store, by traffic mix and by what the consent configuration does, and any single number would be a made-up one. That is the boundaries criterion answered better than any ranked entry manages.

It is not ranked here because no implementation or development service was found on the pages read, so on that evidence it is a product rather than a provider a merchant can hire to do this work. And its own homepage, separately, publishes several absolute accuracy claims of exactly the kind the article warns against, including a 100% conversion capture rate, in marketing furniture rather than in a client case. Both facts are true at once, which is itself the most useful thing in this dataset: the same company publishes the most honest page and some of the least honest claims, on different parts of the same site.

Exclusions

The cut-off, and who was read and left out

Twenty-eight candidates were read and ten ranked, and because tenth place is decided by a single point the cut-off is published so it can be checked. Six further candidates were scored on the same six criteria and fell below it. Rawsoft on 27, which publishes an unusually candid position that a rebuild is recommended only when fixing the existing setup would cost more, and a written statement of work before any engagement, but names no ecommerce event. Aureate Labs on 26, which publishes the most complete tag-management capability list of any agency here, including server-side tagging, consent-aware tagging and Measurement Protocol work, and not one ecommerce specific. Meetanshi on 21, whose extension publishes a fourteen-event table but sells consent mode v2 as a separate product and leaves refund out of that table. Perspective Team on 20, which owns the only dedicated GA4 on Magento agency service page found in the entire search, but whose copy still urges readers to migrate before a deadline that passed in 2023. Onilab on 16, a Magento-only agency whose analytics audit page carries the most specific statement of spam, internal-session and crawler cleanup found anywhere in this edition, on a page that never once says GA4 and that claims to collect 100% of useful data with nothing left out. And Krish TechnoLabs on 14.

Two scored below ten: Bounteous on 5, whose analytics page names no measurement tool at all and states a belief that everything can be measured, and InteractOne on 0, whose analytics page is conversion optimisation and monthly reporting with no measurement tooling named and no published case study about reporting.

Three sites refused automated requests or returned almost no served text, and they are recorded as not checked rather than as publishing nothing: Absolute Web, Human Element and Blue Acorn iCi. Any of them may publish more than the ranked entries do. Two brands in the original candidate list no longer operate their own sites, their domains now redirecting to the agencies that acquired them, so neither can be ranked as itself. Product-only vendors named by providers as infrastructure, platform documentation, support forums, social posts, marketplace listings and individual freelancers were excluded throughout.

7 Methodology

How this was put together

Ten providers were read on their own websites on 28 September 2026 and scored out of 100 across the six weighted criteria published in the table above, with the point ladder for each criterion published alongside it. The ranking is the score order with no adjustment, and the arithmetic for all ten is printed in its own section above so it can be added up by hand.

The weights were fixed before any provider was scored and were not revisited afterwards. Reconciliation carries 30 because it is the entire purchase: a provider who never compares GA4 against the order table cannot tell a merchant which figure is right. Event coverage carries 22 because a revenue total is the sum of purchase events and coverage without verification is the commonest cause of a gap. A named client with a figure carries 18 because it is the only evidence that any of this has been done to a real store. Consent carries 12 because refused consent is revenue that leaves the report. The stack carries 10 because names are checkable and the phrase analytics services is not. Published boundaries carry 8 because a provider who states a limit is telling you the rest is real.

Adobe and Hyva partner tiers are deliberately not scored. Scoring a directory lookup only one company has been put through is not a ranking, and a commerce implementation tier says nothing about whether a GA4 property reconciles. Where a provider publishes a partner level it is reported inside its entry and carries no points. The consequence is stated plainly: the only candidate read for this edition that publishes an explicit Adobe Analytics partner position and an Adobe Commerce Gold Solution Partner level, Krish TechnoLabs, scores 14 and does not make the ten, because nothing on its analytics pages answers a measurement-accuracy question.

Two scoring rules decided more outcomes than any judgement call. The first is where a number lives. A figure inside a testimonial, a review block, an illustrative dashboard graphic, a return-on-investment calculator or a promotional stat band is the seller's marketing rather than a published commitment, and it is scored on the bottom rung however large it is. That rule moved four providers down. The second is that a gap is written as not found on the pages read, never as absent from the site, because nobody has read every page of any of these sites. Pages were fetched as plain requests and read as served text, so nothing here depends on a figure that appears only after JavaScript runs or only inside an image. One provider, Amasty, refuses automated requests, and its page was read through a content parser instead; that is noted in its entry.

Two providers tie on 60. The published tie-break, fixed with the weights, is the heaviest criterion, so Measure Marketing Pro is placed above Measurelab on 23 against 17 for reconciliation as method. The two are otherwise mirror images and the entries say so: one publishes the event set and no consent handling, the other publishes the consent handling and not one event.

8 Questions

Questions a merchant asks when the two numbers disagree

Why does GA4 show less revenue than my Magento admin?

Because Magento counts an order the moment it is placed and GA4 counts a purchase only when a browser successfully sends a purchase event, which happens later and can fail. Ad blockers, browser tracking prevention, a JavaScript error on the confirmation page, a payment provider returning to an untagged URL, or a shopper closing the tab before the event fires all remove real revenue from GA4 while leaving it in Magento. None of them look like a failure, because the report still loads.

Why does GA4 sometimes show more revenue than Magento?

Usually refunds and cancellations. Magento subtracts a credit memo from revenue when the refund is issued, while a GA4 purchase event that has already been sent stays sent unless a refund event carrying the original transaction ID is sent to remove it. Most stores never send that event, so GA4 revenue is gross and the Magento figure is net. Test orders, staff orders and duplicate purchase events from a page reload do the same thing on a smaller scale.

What is an acceptable difference between GA4 and Magento revenue?

There is no published industry standard, and a provider that quotes one without measuring your store first is quoting an average rather than your number. The only published threshold found across this edition is scandiweb's, in a blog case study rather than on a service page: GA4 conversion tracking about 95% accurate against the ERP system, with no other custom events misreported, is treated as a successful migration. Treat that as a working benchmark and insist on a measured baseline for your own store before agreeing to any target.

How do I work out which of my two revenue figures is right?

Both are right about what they measure, so the question is which one to plan against. Take a closed month, pull orders and revenue from the Magento admin or the ERP, pull transactions and revenue from GA4 for the same window, then account for the difference line by line: refunds and cancellations, test and staff orders, tax and shipping conventions, currency conversion, and purchase events that never arrived. Plan against the order table, and use GA4 for the behaviour that led to the order rather than for the revenue total.

Who fixes GA4 tracking on a Magento store?

An analytics or measurement team rather than a general Magento development team, though the two have to work together because the data layer lives in the theme. The division of labour worth insisting on is that developers make the store emit the events and an analyst specifies what those events must contain and verifies them against real orders afterwards. A build with no analyst attached produces events that fire and carry the wrong values.

Is it worth paying for a GA4 audit before buying an implementation?

Usually yes, because an audit turns an open-ended project into a priced one. What a useful audit returns is a list of what each broken event is costing, ranked, rather than a report saying tracking could be improved. Two providers on this page publish a price for one: a fixed 350 EUR one-time audit, and three tiers from 299 dollars with a one to two business day turnaround. Published timescales elsewhere run from three to four days for a requirements review to two or three weeks for a full property audit of a multi-market store. Free initial reviews are offered by two more, and they are worth taking on the understanding that a free review is a scoping exercise.

Does server-side tracking fix a revenue discrepancy?

It fixes one class of discrepancy and leaves the others untouched. Moving tags to a server container on your own subdomain recovers data that was correct but never left the browser, so it helps with ad blockers, tracking prevention and short cookie lifetimes. It does nothing about a wrong purchase value, a missing checkout event or unsent refunds, because those are wrong before the browser is involved. Treat it as recovery, not correction.

What does a server-side tagging setup cost to run?

Two costs, and only one of them is the agency. The container runs in a cloud account, usually Google Cloud, and that hosting scales with traffic volume, so it should be sized and quoted before the build rather than discovered afterwards. The second is whatever ongoing support you buy. One provider on this page publishes the numbers: projects starting in the low five figures, container infrastructure at 20 to 200 dollars a month, and four to eight weeks of delivery. The rest commit only to sizing the hosting during an architecture stage so the monthly figure is known before the build. Ask for that projected number in writing, and ask whose account the container will live in.

What happens to my data when a visitor refuses cookies?

With consent mode implemented correctly the tag still loads and sends a restricted signal rather than nothing, and Google fills part of the gap with modelled conversions, so your reports become a mixture of observed and modelled data. With consent mode absent or implemented as a hard block, the visitor disappears from the data entirely and from ad platform optimisation with it. The difference is large: one named client in this edition published a 75% increase in user data captured after consent mode was implemented.

Do I need Google Analytics 360 for a large Magento store?

Rarely, and the arithmetic is publishable. One provider in this edition quotes the enterprise tier from around 50,000 dollars a year on its GA4 support page, and publishes a separate worked comparison putting Google Analytics 360 at 135,000 EUR a year against GA4 with BigQuery at roughly 2 EUR a month plus query costs, with the per-gigabyte breakdown shown. One extension on this page lists compatibility with the enterprise tier, which is the only other mention of it found. The honest reasons to consider it are event volume limits, sampling and data freshness commitments, not reporting quality.

Should I use BigQuery instead of relying on the GA4 interface?

If you need history beyond GA4's retention, row-level detail, or a join between behaviour and margin, returns or ERP data, then yes, because the interface cannot do any of those. The export is the part worth owning: it lands raw events in a warehouse under your own cloud account, which also means your history survives changing agency or reporting tool. Be aware that query cost becomes a line item, and that a warehouse does not improve the accuracy of events that were wrong on arrival.

Can an extension do this instead of an agency?

An extension can produce a data layer, fire the standard event set and, in the best cases here, send refunds from a credit memo and reverse a cancelled order. What it cannot do is decide what your purchase value should contain, reconcile the result against your order table, or tell you which of your numbers to plan against. Three of the providers on this page sell an extension and implementation services together, which is a reasonable combination as long as the verification work is specified separately from the installation. On the evidence read, the extension layer publishes better event and refund handling than the agency layer and the agency layer publishes better reconciliation, so most merchants will buy from both.

How long does a Magento GA4 implementation take?

Published timescales cluster at two to three weeks for a focused GA4 migration or setup, with a requirements and audit stage of three to four days at the front and a longer tail where multiple markets, a point of sale estate or ERP feeds are in scope. One provider publishes six to eight weeks for a single-market store to be collecting and storing cleanly including a warehouse, one publishes four to eight weeks for a server-side build, and one specialist publishes two to five business days for most setups and one to two for an ecommerce tracking audit. Any estimate given before someone has looked at your checkout is a guess.

What should I ask a Magento analytics agency on the first call?

Four questions, and they sort the field quickly. Which system will you treat as the source of truth. What percentage difference do you consider a pass. How will refunds and cancellations reach the report. And what happens to the data when a visitor denies consent. A provider who answers all four without preparation has done this before. Add a fifth if server-side tagging is proposed: whose cloud account will the container run in.

Does a Hyva or frontend rebuild break GA4 tracking?

It can, and it is one of the commonest ways a working setup degrades. The ecommerce events depend on code in the theme layer, so replacing the frontend replaces the thing that emits them. A rebuild that does not carry an explicit tracking scope tends to ship with page views intact and half the funnel missing, which is hard to spot because the property keeps reporting. Make event parity against a documented list a release condition rather than a post-launch fix.

How is a Magento analytics agency different from a Magento SEO agency?

They buy different outcomes. An SEO engagement is judged on visibility and organic revenue, and it consumes analytics as an input. A measurement engagement is judged on whether the numbers the business decides on are correct, and it has no traffic target at all. The overlap is real, because both touch the data layer and both care about the checkout, but a provider whose measurement work only appears inside an SEO or CRO retainer has no separate method to publish and usually no analyst who owns the property.

How can this ranking be checked?

Every entry prints the URL it was read from, the six criteria and their ladders are published in full, and the methodology publishes the arithmetic for all ten so the totals can be added up by hand. It also publishes the tie-break, the result of re-running the ranking under 1,673 different weightings, what happens to the order when each criterion is removed, and the three places the leading entry loses marks. The byline names the author and the organisation the publication belongs to, so a reader can weigh that alongside the evidence rather than instead of it.

Why are there only ten providers on this page?

Because that is how many published something checkable about measurement accuracy. Twenty-eight candidates were read for this edition, drawn from three live searches and from the Magento service and extension market, and most of what page one returns for this query is extension listings, tool vendors, forum threads and platform documentation rather than providers. Where a candidate published nothing that could be scored it was left out rather than ranked low on an empty entry, and the methodology names the ones that were excluded and why.