Shopify Funnel Report Workflow

Bind and validate the data

Bind each available Shopify store or Google Analytics property to the configured storefront before reading data. Use either source independently; do not require access to the other. When neither is usable, mark analytics-dependent Checks Blocked and name the missing access or evidence. Use aggregate data only. Record the store timezone, exact current window, compatible comparison window, session scope, consent or bot filters, funnel type, route classification, event definitions, source, and known thresholding or reporting delay.

Before interpreting rates, verify the selected source's session/outcome definitions and integrity. For GA4, verify stable route classification and that view_item_list, view_item, add_to_cart, begin_checkout, and historical purchase behavior is directionally consistent with the corresponding customer outcomes. For Shopify-only data, validate its report definitions and coverage; missing GA4 access is not an instrumentation failure. Use only pre-existing purchase data. A missing, duplicated, premature, or materially malformed event blocks the affected rate diagnosis unless another authorized source provides the same scoped metric. Never generate a purchase event.

When optional Google Search Console evidence is available, follow the organic acquisition procedure before reading it. Treat it as supporting acquisition evidence only. Search Console alone cannot supply any of the five on-site rates; retain the Shopify-or-GA4 gate even when search data is available. If Search Console is missing, mismatched, or unavailable through the host's permitted tools, continue the ordinary report and record only the relevant supporting-evidence gap.

Calculate every rate

Before interpretation, record each rate/source/window/segment: store/property, query/authorized report, session definition, event/route order, numerator/denominator, filters, timezone, extraction time and integrity evidence. Keep raw aggregates externally and sources independent. Reuse exact absolute comparison windows/definitions; explain changes rather than equating relative “last week” reports.

Verify same-population numerator sessions and required event order, finite nonnegative counts and a positive denominator. Zero outcomes yield valid 0%; zero denominators yield no rate. Unjoined totals prove no ordered progression. Validate each event independently; valid purchases do not prove cart/checkout integrity. Optional Search Console, repository or second-source gaps cannot invalidate usable primary data.

Return each percentage as 100 × numerator ÷ denominator, with numerator and denominator in Data detail:

• Landing to collection rate: eligible landing sessions that view a collection before ending, divided by eligible landing sessions. Exclude sessions that begin on a collection or product route from this denominator unless the report explicitly treats that route as the landing step.
• Collection to product rate: collection-view sessions that subsequently view a product in the same scoped journey, divided by collection-view sessions.
• Add to cart rate: online-store sessions with at least one cart addition, divided by online-store sessions.
• Reached checkout rate: online-store sessions that reached checkout, divided by online-store sessions.
• Conversion rate: online-store sessions that completed a purchase, divided by online-store sessions.

Use Shopify's maintained analytics field definitions for the three standard store rates. Use GA4 page and recommended commerce events for the two custom progression rates and segmented diagnosis when available. Another source may supply them only if it establishes the same ordered, session-scoped journey; aggregate page views or native store totals cannot reconstruct progression. Block only unavailable rates, retaining supported store rates. Do not mix Shopify and GA4 numerators and denominators into one rate. When both sources expose a rate, return separate Data values with the source dimension and explain expected definition differences instead of forcing them to match.

Always return the aggregate segment as all. Add only decision-relevant segments with enough traffic to interpret responsibly, starting with device, channel, landing or template group, new versus returning, market, and product or collection group. Avoid thin slices and post-hoc segment fishing.

For landing-page trends or supplied experiments, follow the cohort workflow. Reuse these rate definitions and output keys; do not add a second reporting system.

Diagnose material leaks

Compare each rate with its compatible prior window and inspect the path with the largest material, persistent, decision-relevant deterioration—not merely the largest expected percentage drop. Check traffic mix, campaign, catalog, availability, price, discount, market, consent, tracking, outage, and seasonality before attributing a leak.

Use a real browser to reproduce representative affected and comparison paths across mobile and desktop. Inspect landing and navigation clarity, collection discovery, product decisions, add-to-cart success and feedback, cart state and totals, and checkout handoff. Use fictional guest contact and shipping details only when needed to reach payment options, then stop.

Data remain visible whether the Check completes or fails. Fail a Check and create one Issue only when the measured leak and direct target evidence support a specific defect or falsifiable experiment. Analytics alone never proves causation. Each Issue must include one proposed change, one primary step metric, downstream conversion and revenue guardrails, applicable performance/accessibility/error guardrails, an owner, and a decision or exact retest condition. If no responsible action qualifies, complete the Check with Data and no Issue.

Report and complete

Tie each leak/experiment conclusion to actual cells, event integrity, applicable assignment and direct evidence. Explain changed windows, definitions, segments, traffic or tracking corrections. Inaccessible prior metrics or different segments prove no resolution. Keep inconclusive diagnoses separate from rates and supported Issues.

Follow Glue JSON output: save/validate complete JSON and references, then summarize in chat; Glue receives its bare object and handles storage/rendering. Raw evidence supports, not replaces, the report. Omit missing measurements rather than emitting zero. Retain valid route/viewport/window cells as Completed/Data or Fail with a qualifying Issue. Label partial scope and each missing cell/unblock action in detail/artifacts; keep limitationIds empty. Use Blocked with reciprocal Limitations only without valid measurements or an independently supported Issue. Never discard valid cells, attach Data to Blocked or imply unmeasured cells were tested.

Record one terminal Completed, Fail, Blocked, or Not applicable outcome for every selected Check. Completed rates reference their Data; failed Checks reference one supported Issue; blocked Checks reference precise Limitations. Do not generate a Summary or Findings. The report is complete when all five Checks have one terminal outcome (including individually explained blockers), every available rate is returned as normalized Data, contradictions are preserved, and every unavailable rate names the exact missing evidence.