Text version of this lessonExpand
Ecommerce analytics is not about building more charts. It is about putting the business problem, evidence, source, owner, action, and review date into one operating table. GA4, Shopify, ad platforms, support, and finance all use different lenses. Analytics becomes useful only when the team aligns the question before debating the move.
Lesson output: business question action table
Start each review with one business question: expensive traffic, low conversion, low AOV, high refunds, weak profit, or weak repeat purchase. Each question needs different evidence, a different owner, and a different action. Do not open every report first. Do not argue about whose number is right before the problem is named.
| Business problem | Evidence first | Next action |
|---|---|---|
| Traffic is expensive | CPM, CTR, CPC, creative performance, audience, UTM, landing page CVR | Check creative, audience, and channel quality first; route to CRO only when site behavior is weak |
| Conversion is low | view_item, add_to_cart, begin_checkout, purchase, device, payment failure, page engagement | Find the largest funnel breakpoint and change one primary friction point |
| Profit is weak | Gross margin, ad spend, shipping, refunds, discounts, channel CPA, contribution profit | Split contribution profit by SKU and channel instead of deciding from total ROAS |
| Repeat purchase is weak | Purchase interval, returning customer revenue, email performance, repeat SKUs, support experience, discount dependency | Improve lifecycle flow, replenishment reminders, bundle recommendations, and customer segmentation |
Completion standard
Each review should output only a few actions. Every action needs evidence, source, owner, review window, success criteria, and a fallback path.
Separate result, process, and diagnostic metrics
Revenue, CTR, CVR, refund rate, and repeat purchase rate do not live on the same layer. Result metrics tell you what happened. Process metrics tell you where the change appeared. Diagnostic metrics tell you what should change next. CTR shows whether creative and audience attract clicks, CPC/CPM show traffic cost, CPA shows cost per order, and ROAS shows revenue return. No single ad metric proves profit.
| Metric layer | Question it answers | Best use |
|---|---|---|
| Result metrics | Did revenue, orders, net profit, payback, or repeat rate improve? | Judge business health, but do not explain causes by themselves |
| Process metrics | Where did sessions, CTR, cart rate, checkout rate, or email click change? | Locate traffic, page, payment, or retention stage |
| Diagnostic metrics | What are the payment failure, refund reason, support theme, fulfillment issue, or page breakpoint? | Assign owner and action, not a global conclusion |
Do not turn the daily report into a metric waterfall
Daily reporting should watch anomalies, weekly reporting should drive trends and actions, and monthly reporting should review structure and strategy. Forty metrics in a daily report makes the team remember almost nothing.
Tools need different jobs: GA4, Shopify, ad platforms, and finance
GA4 is strong for user behavior such as page views, cart events, checkout, and purchase events. Shopify is better for orders, sales, refunds, and customer outcomes. Ad platforms explain spend, clicks, creative, audience, and platform-reported conversions. Finance decides whether the business actually made money.
Shopify says acquisition reports show how visitors come to your store, but they do not show converted sales or order amount. That is why one source report cannot decide ad profit.
| Source | Best answer | Wrong use |
|---|---|---|
| GA4 | Site behavior, funnel health, page performance, channel trends | Treating GA4 revenue as finance profit |
| Shopify Analytics | Orders, sales, products, customers, refunds, regions | Only watching order count without source, refunds, AOV, and profit |
| Ad platforms | Spend, clicks, creative, audience, CPA / ROAS | Using platform ROAS alone to decide profit and budget movement |
| Finance sheet | Gross margin, net profit, costs, cash, refund loss, contribution profit | Only watching total profit without SKU, channel, and fulfillment cost split |
Event contract: align events, parameters, and owners first
Google Analytics ecommerce measurement explains ecommerce events for shopping behavior such as views, cart actions, checkout, purchases, refunds, and promotions. GA4 recommended events also explains that recommended events should be sent with prescribed parameters so reports, audiences, and future integrations have more complete data.
| Event layer | Key parameters | Acceptance rule |
|---|---|---|
| Product discovery | item_id, item_name, item_category, item_list_name | The same item can be recognized across PDP, collection, search, and ads |
| Shopping intent | view_item, add_to_cart, begin_checkout, currency, value | View, cart, and checkout events fire consistently with correct value and currency |
| Revenue facts | purchase, transaction_id, tax, shipping, coupon | Purchase is not duplicated and can reconcile with Shopify / finance records |
| After-sale impact | refund, item_id, reason, order status | Refund and issue data can return to SKU, channel, and page promise |
Analytics action router: turn abnormal metrics into one reviewable action
Do not output a dozen analysis conclusions. Every abnormal metric should become: what evidence to check first, who owns the next move, what action to take, what not to do, and where to write the decision back. This is the lesson's analytics action router.
| Signal | Evidence first | Routed action | Blocked move |
|---|---|---|---|
| Traffic cost rises, but site behavior is stable | CPM, CTR, CPC, UTM, creative angle, audience mix | Route to paid and creative; change hook, audience, or channel segment first | Rebuild the PDP before proving page friction |
| Sessions stable, view_item normal, add_to_cart drops | Event chain, device, heatmap/replay, PDP proof, support doubts | Route to CRO, page, and merch; fix one proof gap that affects cart intent | Raise budget because traffic is stable |
| Orders and revenue rise, but profit falls | Discount, shipping subsidy, refunds, payment fee, fulfillment cost, SKU contribution profit | Route to finance, pricing, merch, and paid; split contribution profit by SKU/channel | Scale from total ROAS or total revenue |
| Refunds and support tickets rise after a campaign | Refund reason, SKU, ad angle, PDP claim, fulfillment status, review themes | Correct the promise, pause risky claims, or limit SKU scale | Treat refund growth as normal order growth noise |
| GA4 purchase / revenue and Shopify orders disagree | transaction_id, purchase count, duplicated tags, timezone, refunds, test orders | Fix the event contract and measurement QA before budget decisions | Move budget from untrusted event data |
| First purchase healthy, repeat revenue weak | Cohort, purchase interval, email flow, product cycle, support satisfaction | Test replenishment reminders, bundle recommendations, or winback | Send one blanket discount to all past buyers |
Weekly reporting is next week's action list
A useful weekly report does not copy every number into one table. It helps the team answer where performance slipped, what deserves more investment, and what the next three moves should be. If a report does not trigger action, it is only a visual archive.
Practical weekly report structure
Analytics action packet
The standard is not building a dashboard. It is a weekly record of business problem, evidence, source, owner, action, review window, and criteria. If the next issue is profit, refunds, ad spend, and contribution profit, go to profit weekly review. If the issue is PDP, cart, checkout, or payment, return to conversion optimization. If the action involves budget migration, return to multichannel advertising.
Suggested format
- Business problem: weak profit, high refunds, low conversion, expensive traffic, or weak repeat.
- Evidence and source: what GA4, Shopify, ad platforms, finance, support, and fulfillment each show.
- Owner and action: one main action, without changing too many variables at once.
- Review window: 3, 7, 14, or 28 days, with success and failure criteria.