Ecommerce Analytics: Reconcile Store Activity, Revenue, and Retention
The weekly trading meeting has reached an awkward point. The store platform reports sales, Google Analytics reports purchases, and the product dashboard reports active users. All three charts moved, but nobody can say with confidence whether the business improved. Marketing sees traffic that converted. Merchandising sees products that sold. Finance sees discounts, refunds, shipping, and tax changing the money that remains.
That confusion is not a dashboard problem. It is a measurement-design problem. Ecommerce analytics becomes useful only when each number has a declared unit, time window, value definition, and business question. Without those four conditions, adding more charts gives the team more ways to disagree.
My recommendation is to build ecommerce analytics as a connected decision system with three layers: shopping behavior, commercial transactions, and customer retention. Keep the layers separate enough that their numbers retain meaning, then connect them with stable identifiers and explicit definitions. The cost is less apparent simplicity: leaders will have to tolerate more than one legitimate revenue measure and analysts will have to maintain a metric dictionary. The benefit is that a change in a headline number can lead to a specific action instead of a debate over whose dashboard is right.
Start with the decision, not the dashboard
An ecommerce report should answer a decision that someone can make. “How is the store doing?” is too broad because it combines demand, conversion, order economics, product mix, and repeat behavior. “Should we keep the free-shipping offer for another week?” is workable. It requires a declared comparison period and measures such as order count, the sales base used for average order value, discounts, shipping, and returns. It may also require a margin measure that the supplied sources do not define; if that figure is missing, the team should not pretend that sales alone settle the decision.
Begin every recurring report with four statements:
- Decision: the action the report can support, such as changing a promotion, repairing a checkout step, or protecting a customer cohort.
- Unit: the object being counted, such as an event, item, order, user, account, or revenue cohort.
- Period: the dates in which eligibility and outcomes are measured, including any later return window.
- Value rule: the treatment of discounts, returns, shipping, tax, and new-customer revenue.
These statements prevent a common mistake: treating metrics with similar names as interchangeable. One shopper can trigger one add-to-cart event while adding several units. One order can contain several items. One business account can contain several users. One retained revenue cohort can expand even while some customers contract or leave. Each view can be correct because each describes a different object.
The useful question is therefore not “Which number is true?” It is “Which number matches this decision?” A merchandising lead choosing which products to feature needs item-level views and purchases. A conversion lead repairing checkout needs event movement. A commercial lead reviewing promotion quality needs orders, discounts, returns, and an agreed sales base. A subscription operator protecting renewals needs a starting customer cohort and its recurring revenue movements.
Separate shopping activity from order economics
Google Analytics 4 makes the first distinction explicit. Its ecommerce model includes event-scoped measures, which count how many times an ecommerce event fired, and item-scoped measures, which count interactions with the items carried by those events. In Google’s example, adding three units of one shirt and two of another in one action produces one add-to-cart event but five item units added. Google also warns that event-scoped and item-scoped fields are not interchangeable in reports: an item dimension should be paired with an item-scoped measure, not the event-scoped counterpart. Google’s ecommerce metrics documentation explains this difference and covers product views, cart activity, purchases, item revenue, and refunds.
This distinction changes the decisions a funnel can support. Event counts describe actions: how often product views, cart additions, checkout starts, or purchases occurred. Item counts describe merchandise moving through those actions: how many units of a particular product were viewed, added, or purchased. If a cart experiment encourages customers to add more units in a single action, item additions may rise without the event count rising at the same rate. Calling either measure “adds” without its scope hides the result.
Implementation is part of the number, not a technical footnote. GA4’s Ecommerce purchases report depends on ecommerce events such as add_to_cart and purchase sent by the site or app; Google says those ecommerce events are not collected automatically. The item fields are populated from parameters supplied with those events, and missing required parameters can keep an event out of the ecommerce report. The GA4 Ecommerce purchases report documentation makes this dependency clear. A clean-looking chart can therefore reflect an incomplete payload rather than customer behavior.
For that reason, I would use behavioral analytics to locate movement, not to declare booked sales. Track a small path that mirrors the actual store: product viewed, item added, checkout begun, and purchase submitted. Give every event a precise firing rule, and send item identifiers, quantities, prices, and the transaction identifier consistently where the event requires them. Then compare like with like: event to event when examining step completion, item to item when examining product movement.
The commerce platform should answer a different set of questions. Shopify keeps gross sales, discounts, returns or sales reversals, net sales, shipping, tax, and order counts as separate report fields. Its stated formula for average order value is gross sales minus discounts, divided by orders; it also notes that this measure excludes post-order adjustments. Shopify’s analytics field reference documents those definitions. That formula may be appropriate for a Shopify operating report, but it is not a universal law. A finance team can use a different sales base or treatment of returns, so the label “AOV” is incomplete unless the numerator and denominator are named.
Suppose, as an illustrative calculation, a store records 100 orders, $12,000 in gross sales, $1,000 in discounts, $600 in returns, $500 in shipping, and $300 in tax during a declared week. Under Shopify’s documented formula, average order value is ($12,000 minus $1,000) divided by 100, or $110. A return-adjusted operating view based on the visible assumptions would produce $104 per order before shipping and tax. Neither figure is inherently dishonest. The mistake would be placing $110 and $104 under the same unlabeled “AOV” heading or silently switching between them.
This is why the executive scorecard should show commercial components before compressing them. At minimum, place order count beside gross sales, discounts, returns, and the chosen net-sales measure. Show shipping and tax separately when they matter to the decision. If the business wants one average order value, publish the formula next to the metric and keep it stable across periods. A higher average built on heavier discounting or followed by more returns is not the same commercial outcome as a higher average produced by a healthier product mix.
Use product analytics to explain what happened before purchase
Commerce records tell the team what was ordered. Product analytics can explain what customers did before and after that point, but only if the data model is treated carefully. Amplitude distinguishes users, events, event properties, and user properties. An event is an action, an event property describes the action at that moment, and a user property describes the user. Amplitude’s definitions provide the underlying model. In an ecommerce implementation, the distinction might separate “checkout completed” from the payment method attached to that action and the customer’s current segment.
The practical rule is to attach changing transaction context to the event that occurred. Product identifier, quantity, coupon, payment method, and order value describe a particular interaction. A customer tier or region may be useful as a user attribute, but teams still need to decide whether analysis uses the value at event time or the user’s latest known value. If that choice remains implicit, historical segments can appear to change when a profile changes.
Retention requires even sharper definitions. An Amplitude retention analysis needs a starting event, a return event, an eligible user segment or cohort, and a time interpretation. Amplitude’s retention-analysis guide notes that users enter from the starting event in the selected period and that the return event can occur outside that displayed start period. A chart labeled “30-day retention” is therefore not self-explanatory. It must say who started, what behavior counts as returning, and how the return window is read.
For a store, “first purchase” as the start and “any second purchase” as the return can answer a repeat-purchase question. “Account created” followed by “site visited” answers a different and usually weaker question because a visit does not necessarily create customer value. I would choose the smallest return event that represents the commercial behavior the team wants to repeat, then keep softer engagement measures as supporting signals rather than substitutes.
The cost of this choice is slower feedback. A meaningful second purchase may take longer to observe than a return visit. That delay is preferable to optimizing a convenient activity that has no established relationship to another order. If the business genuinely needs an earlier indicator, label it as an intermediate behavior and compare it with later purchasing before treating it as a success measure.
Measure the customer entity that actually buys
User-level analysis works for a store in which one person browses, decides, pays, and returns under a reasonably stable identifier. It is less adequate when several people act for the same organization. Amplitude’s account-level reporting can group individual users under a shared business entity, and its documentation explains that different members can perform different stages of an account journey. The account-level reporting guide also makes clear that the grouping depends on an implemented account or group property.
That changes the funnel. In business purchasing, one employee can explore products, another can request approval, and a third can complete a purchase. Requiring the same user identifier to perform every step can make a functioning account journey look broken. Grouping by account can recover the shared path, but the account identifier must be accurate over time. Membership errors or overwritten relationships can assign an event to the wrong organization.
Account activity also does not automatically identify the payer, buyer, or renewal owner. The analytics model should keep those roles distinct when the business process distinguishes them. I would use user-level reporting for interface and adoption questions, account-level reporting for multi-member progress, and commercial records for the party responsible for the transaction. Forcing all three into one “customer” field creates apparent simplicity at the cost of decisions made about the wrong entity.
Connect purchase behavior to revenue retention without mixing cohorts
For a recurring-revenue commerce model, repeat activity and retained revenue answer different questions. A customer can return to the product while spending less, or use it less while an existing contract remains unchanged. Behavioral retention should explain continued actions. Revenue retention should explain what happened to money from an established cohort.
ChartMogul defines net revenue retention as the ending recurring revenue from customers present at the start, after expansion, contraction, and churn, divided by that cohort’s starting recurring revenue. New-customer recurring revenue is excluded. Gross revenue retention uses the same starting cohort but excludes expansion, concentrating on contraction and churn. ChartMogul’s guide to net and gross retention supplies these formulas, while also representing vendor guidance rather than an accounting standard.
Consider an illustrative monthly cohort that starts with $100,000 in recurring revenue. During the declared period it adds $8,000 from expansion, loses $5,000 through contraction, and loses $7,000 through churn. Net revenue retention is ($100,000 plus $8,000 minus $5,000 minus $7,000) divided by $100,000, or 96%. Gross revenue retention is ($100,000 minus $5,000 minus $7,000) divided by $100,000, or 88%. If entirely new customers add $20,000, that money belongs in a growth view, not in this existing-cohort retention calculation.
The pairing is informative. Net retention shows whether expansion offset losses; gross retention shows the underlying loss before expansion helps. Product retention can then supply possible behavioral context for the same eligible accounts, provided the account mapping and time windows align. None of the three measures replaces the others. A 96% net figure does not reveal whether many small accounts left while a few expanded, and an event-return rate does not establish continued revenue.
For non-subscription retail, net and gross revenue retention may be the wrong instruments because there may be no recurring-revenue base to follow. Use purchase cohorts instead: define customers by a first purchase in a declared period, then observe later orders or sales over an explicit window. Do not borrow subscription terminology if the underlying commercial relationship is a series of independent purchases. The condition that reverses this choice is a real recurring contract or subscription whose expansion, contraction, and churn can be defined consistently.
Build one operating view without forcing one source of truth
The strongest ecommerce analytics setup does not make one tool responsible for every question. It assigns authority by subject. GA4 or a comparable event system describes instrumented shopping actions and item interactions. The commerce platform describes orders and its own sales fields. Product analytics describes user or account behavior and retention. A recurring-revenue system describes movements within a starting revenue cohort.
Connect those systems with a compact set of keys: transaction ID between purchase events and orders, item ID between behavioral events and the product catalog, user ID where identity rules permit it, and account ID where buying is organizational. The key itself does not reconcile different meanings. It merely lets the team compare records. Definitions still need to state whether a purchase event represents an order submitted, payment captured, or another milestone, and whether later refunds revise the reported value.
I would publish a short metric dictionary beside the operating dashboard. Each entry should name the decision owner, unit, formula or qualifying event, source, time basis, and exclusions. “Purchase conversion rate” must declare both numerator and denominator. “Revenue” must say whether discounts, returns, shipping, and tax are included. “Retention” must name the starting event or revenue cohort, the return or ending condition, and the observation window.
When sources disagree, classify the difference before adjusting anything. A scope difference means one report counts events while another counts items or orders. A timing difference means the same activity entered different windows. A value difference means discounts, refunds, shipping, or tax were treated differently. An identity difference means one system grouped activity by user while another grouped it by account or customer. An implementation difference means an event or parameter was missing, duplicated, or mapped incorrectly. Only the last category is automatically a tracking defect; the others may be legitimate views.
The final operating rhythm should move from outcome to explanation to action. Review orders and explicitly defined sales measures first. Use event and item paths to locate where behavior changed. Use customer or account cohorts to determine whether the change lasted. Then assign an action with an owner and a date for review. This sequence keeps ecommerce analytics grounded in commercial results without asking transaction records to explain behavior they never captured.
The central principle is simple: keep unlike units separate, and connect them only for a named decision. Ecommerce analytics earns trust when a leader can trace a number back to the event, item, order, user, account, or revenue cohort it represents. It earns its budget when that clarity changes what the team does next.