How We Test and Verify Every Claim
Every price, limit and performance figure on Stack Architect is taken from the vendor's own pricing page or platform documentation, recorded with the date it was checked, re-verified quarterly, and corrected publicly when it turns out to be wrong. Figures that cannot be verified are labelled as unverified rather than quietly estimated.
Last updated: 24 July 2026 · Maintained by Luke Sandelands
Stack Architect exists because most Shopify automation advice is either vendor marketing or untested rehash. So every factual claim on this site follows one rule: if we can't source it or reproduce it, we don't publish it. This page documents exactly what that means.
Where Our Numbers Come From
In order of preference:
- Vendor pricing pages and official documentation. Make.com's plan limits come from Make.com official pricing. Meta CAPI behaviour comes from Meta Conversions API documentation and Events Manager. Competitor prices (Elevar, Triple Whale, Klaviyo, Stape, Littledata) are read from each vendor's own published pricing page. Each record carries the date it was checked and a link to the page it came from where that verification has been done; the rest are shown as unverified. The current state of every record is in our Shopify App Pricing Index.
- Working configurations, built as published. Core solutions like CAPI Shield, Stocky Swap, and Live P&L Automation are written by building the setup step by step and publishing the exact steps that worked — not by summarising vendor docs.
- Platform announcements with dates. Deadline claims (such as Shopify Stocky's shutdown, Meta's one-click CAPI updates, and Klaviyo billing changes) cite official announcements directly. Learn how to replace Klaviyo for free in our Free Klaviyo Replacement Guide.
We do not use: other blogs' figures, AI-generated statistics, or vendor claims we can't check against a pricing page or changelog.
The 20–40% Figure — Retracted, and Why
This figure was retracted on 4 September 2026 and no figure has replaced it. The section is kept here, at its original anchor, as the record of what was claimed and why it is no longer claimed — it was cited from this address, so it should still answer at this address.
What it was: an estimate of purchase-conversion signal lost to browser-only tracking — iOS ATT, Safari ITP and ad blockers — drawn from the five sources listed in our iOS Attribution Gap Benchmark, where every row names its source, URL and date. Those rows are unchanged and still published. What has gone is the single number this site derived from them.
Being straight about its quality: a row counts as primary here when the document it links to is published by the party that originated or measured the fact — the test you can apply yourself by following the link. On that test, of those five sources two are primary: Apple's WebKit documentation on Intelligent Tracking Prevention, which is Apple describing its own browser's behaviour, and AppsFlyer's ATT opt-in data, which AppsFlyer measured on its own panel. Three are secondary: a mobile-commerce statistics blog, a newsletter describing a single unnamed case, and MacRumors' report of Meta CFO David Wehner's ~$10B statement on the 2022 ATT headwind.
That last one is worth naming rather than quietly filing: it is primary in substance and secondary as cited. The claim originates with Meta's own CFO, on Meta's own earnings call, about Meta's own revenue. But the row links a news report of that call rather than the transcript, so following the link lands you on reporting. We count what the link goes to. The mechanism behind the 20–40% figure is well established; the precise magnitude rested partly on secondary reporting, which is why we called it an estimate rather than a measurement. That framing turned out not to be enough — see the retraction entry below.
Revisions to this section. 3 September 2026: a sixth row, citing an industry AI answer library for a 30–40% reduction in Meta attribution accuracy, was removed — an AI answer library is an AI-generated statistic, which the list above says we do not use, and we could not find a primary source for the figure. 4 September 2026: the split stated here was wrong in three ways. It read “three primary” and named Meta's Conversions API documentation as one of them — but those docs are not a row in the benchmark at all. They document how CAPI behaves, they are cited above as vendor documentation, and they contribute no figure to the 20–40% range, so they should never have been counted among its sources. The old split also counted the Wehner row as primary while linking a news report of it, and left the AppsFlyer row off the primary side altogether. Checked row by row against what the benchmark actually contains, the split is two primary and three secondary. Corrected above.
4 September 2026 — the figure itself is retracted. Not corrected, not re-sourced, not widened: withdrawn, from every page, from the JSON-LD, and from the machine-readable export. Checking the rows one at a time, against the claim rather than against each other, three things were true of it. One: no row measured the quantity the headline asserted. The rows measure ATT opt-out rates, the mobile share of Shopify traffic, a cookie lifetime cap and Meta's revenue. Those are inputs to a store's signal loss, not observations of it, and a number assembled from inputs to a quantity is not a measurement of that quantity. Two: exactly one row was even denominated in it — the ~40% attributable-conversion loss without CAPI — and that row is a single documented case, n=1, unnamed, reported at second hand in a newsletter. An upper bound resting on one anecdote is not a bound. Three: the lower bound had no derivation at all. Nothing in any surviving row produces 20%, and we could not reconstruct where it came from. A range whose top is a single case and whose bottom is unattributable is a shape, not an estimate.
There is also a reason no re-derived range would have been right either. Two of the five rows are store variables rather than constants — the mobile/iOS share of a store's traffic, and the rate at which those visitors decline tracking. Signal loss is a function of both, so it is store-specific by construction, and any industry range describes no particular reader. The mechanism is real, well documented, and still stated throughout this site: iOS ATT, Safari ITP, ad blockers and consent rejection remove browser signal, and server-side delivery is not subject to that loss. Only the magnitude is gone, and it is gone because it is yours to measure rather than ours to average. The benchmark now publishes its sourced rows plus a calculator that turns two numbers from your own dashboards into your own gap, and it will publish a first-party figure when enough real submissions exist to compute one.
One caveat we would rather state than bury: AppsFlyer data within our own dataset shows iOS ATT opt-in has risen from the low-20s% at launch to roughly 50% by 2024–25. If that trend holds, browser-side loss was lower by 2026 than when the range was first published, and the estimate overstated it. This was flagged here while the figure was still up, on the reasoning that flagging beat quietly adjusting a number we could not re-measure. Both of those were worse answers than the third one: if a number cannot be re-measured and cannot be re-derived, it should come down. That is what the entry above does.
Annual savings figures are arithmetic, not findings. Where this site shows a yearly saving against a paid app, that number is the vendor's monthly list price multiplied by twelve. It is not a measured outcome, it does not account for annual-billing discounts, negotiated or grandfathered rates, or the tier you would actually land on, and it assumes you replace the tool outright rather than partially. Treat it as the size of the question, not the answer. The per-app monthly prices behind those figures are the sourced part; the multiplication is ours.
We publish no recovery percentage. You will not find a claim on this site that CAPI Shield or any other tool recovers a specific share of lost conversions, because we have no first-party recovery measurement — no store sample, no before/after study. A loss estimate is not a recovery rate, and treating the two as interchangeable is the error this policy exists to prevent. Meta measures the real figure on your own data and calls it Additional Conversions Reported, available in Events Manager and via the Dataset Quality API. That is the number to trust, and it is not ours to give you.
How Often Figures Are Re-Verified
Every pricing and plan-limit figure is re-checked quarterly, and immediately whenever a vendor announces a pricing change. When Make.com updated its pricing structure, we updated every affected page across our Best Free Shopify Apps 2026 Directory. Comparison tables carry a "verified" date; if that date is more than a quarter old, tell us.
What Our "Tested" Badges Mean
A badge like "iOS tested" means the documented setup was confirmed working under that environment on the date shown — not tested once and assumed fine since. Check our benchmark methodology in the Shopify iOS Attribution Gap Benchmark.
How This Site Makes Money — And What That Buys
Stack Architect is funded two ways, both disclosed:
- Affiliate links. Some links to tools we recommend (marked
rel="sponsored"in the page code) pay us a commission at no cost to you. This never changes a recommendation: our core recommendation on most pages is the free tier of a tool, which typically pays little or nothing. - The Complete Kit ($24 one-time). Pre-built versions of the same automations the free guides teach. The free guides are complete on their own — the kit buys time, not access.
Corrections & Feedback
When we get something wrong, we fix the page, update its "last updated" date, and note material corrections in the text. If you spot an error — a stale price, a changed limit, a claim that didn't hold up in your setup — email support@stackarchitect.xyz or read more about our team and mission.
Related App Alternatives
shopify-capi-validator npm package. Certified in Shopify server-side tracking, Meta CAPI, and Google Apps Script engineering.