Rebuild Chewy's Broken Analytics Setup from a Handoff Doc
Objective: Given a real-looking handoff document from a departed analyst at a pet-ecommerce company modeled on Chewy, find every gap against the lesson's five core terms and specify the exact fix for each, then produce a corrected tracking plan a developer could implement without guessing.
The analyst who set up tracking for a pet-products ecommerce site (Chewy's playbook: recurring subscription orders, customer-service-driven retention) left last month with no documentation beyond a two-paragraph handoff email. Numbers in the dashboard don't match what the customer-service team hears from shoppers, and nobody can say why.
Below is the entire handoff doc you were given. Using the lesson's five-term vocabulary as your checklist, find what's missing or wrong, and write the corrected tracking plan a developer could implement without another meeting. --- Hey! Sorry for the short notice. Quick summary of what's set up: - GA4 is installed on the main site and checkout flow. - Session timeout is set to 5 minutes, I shortened it early on to 'get more session data' for a stakeholder report. - Key events: purchase, add_to_cart, product_view, scroll, newsletter_signup, size_guide_click, all six are flagged as key events. - No custom events for 'subscription reorder' or 'chat_with_support' yet, I know those matter but didn't get to it. - Event naming has gotten messy: button_click_pdp_addtocart_v2_mobile, button_click_pdp_addtocart_v3_desktop, and add-to-cart-click are all live at once for basically the same action. Good luck! ---
Before you start
What you'll need
Free path (everything below is enough to finish)
Free at any traffic volume, the entire rebuild runs on the free tier.
Free, sets up the new weekly reorder-rate report referenced in Step 4.
Paid upgrades (optional, faster/deeper)
The free path (GA4 for the fixes, Looker Studio for the new report) is complete on its own. Mixpanel is only worth paying for once the new subscription_reorder event has enough volume to analyze at a cohort level.
An upgrade once the fixed event is live and the team wants deeper cohort behavior on it, never required to write the fix plan.
The process
4 steps
Step 01 of 04
A session groups events from one user in one visit and ends after 30 minutes of inactivity, GA4's default. A shortened timeout chops single visits into multiple sessions.
What's wrong with the 5-minute session timeout, and what should it be changed to?
Procedure
- Read the handoff line: session timeout was manually shortened to 5 minutes 'to get more session data'
- Understand the mechanism: a shorter timeout chops single continuous visits into multiple 'sessions' whenever a shopper pauses more than 5 minutes (comparing subscription plans, reading reviews)
- Specify the fix: revert to the 30-minute GA4 default, and flag that all historical session-count reporting since the change is artificially inflated and should be footnoted or excluded from trend comparisons
Current setting: Session timeout = 5 minutes (non-default, undocumented change) Effect: any shopper who pauses 5-30 minutes mid-visit now generates 2+ 'sessions' instead of 1 Fix: revert to 30-minute GA4 default; annotate the reporting dashboard at the date of the original change so nobody compares pre/post session counts as if they mean the same thing
Healthy
Session timeout at the 30-minute default (or a documented, deliberate exception).
Unhealthy
A shortened timeout inflating session counts, especially dangerous because it makes 'sessions' look like it's growing when it's really the same visits counted multiple times.
What this means
This single misconfiguration alone explains at least part of why the dashboard numbers 'don't match what customer service hears,' session count here isn't a real growth signal, it's an artifact of the 5-minute setting.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| Session count trending up with no matching increase in orders or revenue | Check the session-timeout setting before investigating anything else, this exact pattern is what a too-short timeout produces | 5 min |
Step 02 of 04
Mistake 2: marking every event as a key event makes the conversion rate meaningless, pick 1-3 outcomes per funnel stage.
Of the six events flagged as key events, which ones should actually keep that status, and which two custom events are missing entirely?
Procedure
- List the six currently-flagged key events: purchase, add_to_cart, product_view, scroll, newsletter_signup, size_guide_click
- Sort into real outcomes (tied to revenue or lifecycle) vs. engagement signals
- Specify the two missing custom events the handoff admits were never built: subscription_reorder and chat_with_support, and explain why a subscription-retention business needs both flagged as key events
Keep as key event: purchase (revenue outcome) Un-flag (engagement signals, not outcomes): add_to_cart, product_view, scroll, newsletter_signup, size_guide_click Missing entirely, needs to be built: subscription_reorder (custom event, fires when a recurring order renews), chat_with_support (custom event, fires when a shopper opens a support chat)
Healthy
Key events map to real revenue/lifecycle outcomes; a subscription-driven retention business tracks its reorder event as a key event, not just its first purchase.
Unhealthy
Engagement signals (scroll, product_view) diluting the key-event conversion rate, while the business's actual retention mechanism (reorders) isn't tracked as an event at all.
What this means
The current setup over-counts weak signals as key events while missing the two events (subscription_reorder, chat_with_support) that would actually explain the gap between the dashboard and what customer service hears, support conversations are invisible to analytics entirely right now.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| Customer-service team reporting patterns the dashboard doesn't show | Build the chat_with_support custom event first, it's the direct link between what CS hears and what analytics can see | dev ticket |
| Reorder/retention behavior invisible in the current event set | Build subscription_reorder as a custom key event, the actual outcome-tracking metric for a subscription-retention business | dev ticket |
Step 03 of 04
Every interaction is an event; each can carry up to 25 parameters. Mistake 3: stuffing context into event names instead of using parameters, e.g. button_click_pricing_page_hero_v2_mobile is a reporting nightmare, use event: click with parameters location/page/device instead.
The handoff lists three different event names for what should be one action, 'add to cart.' What's the fix?
Procedure
- List the three live event names for the same action: button_click_pdp_addtocart_v2_mobile, button_click_pdp_addtocart_v3_desktop, add-to-cart-click
- Recognize the pattern from Mistake 3: context (page, version, device) got stuffed into the event name instead of being passed as parameters
- Specify the fix: consolidate to one event name (add_to_cart) with parameters for page and device, and retire the old fragmented names going forward (historical data stays as-is, don't retroactively rewrite it)
Before (3 fragmented events): button_click_pdp_addtocart_v2_mobile, button_click_pdp_addtocart_v3_desktop, add-to-cart-click After (1 event, parameterized): event: add_to_cart, parameters: page = 'pdp', device = 'mobile' | 'desktop'
Healthy
One event name per real action, with page/device/version details passed as filterable parameters instead of baked into the name.
Unhealthy
Multiple near-duplicate event names for the same action, splitting what should be one metric into three, so 'add to cart rate' is undercounted unless someone remembers to sum all three every time.
What this means
Anyone building an add-to-cart report today has to know to sum three differently-named events, and anyone who forgets will silently undercount by two-thirds of the real number. This is the exact reporting nightmare Mistake 3 describes.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| The same user action tracked under multiple event names | Consolidate to one event with parameters going forward; document the change so future reports don't need the pre-fix history to be accurate | dev ticket |
Step 04 of 04
Vanity metrics look good but don't connect to revenue or decisions. Actionable metrics connect directly to outcomes and tell you what to do next.
Once the fixes above ship, what's the one actionable metric this business should report weekly that the current setup can't produce at all today?
Procedure
- Name the metric that becomes possible only after subscription_reorder exists as a key event: reorder rate (subscribers who reorder divided by active subscribers)
- Explain why this is the actionable metric (ties directly to retention revenue) vs. the vanity metrics the old setup was over-reporting (scroll, product_view counts)
- Write the one-line summary for the corrected tracking plan's cover page
New reportable metric (post-fix): Weekly reorder rate = subscription_reorder events / active subscriber count Old vanity numbers retired from the weekly report: scroll count, product_view count (still tracked as regular events, no longer reported as headline numbers)
Healthy
The corrected tracking plan's headline weekly metric is something tied to revenue/retention, not a raw engagement count.
Unhealthy
The corrected plan still leads with scroll or product_view counts out of habit, missing the point of the whole rebuild.
What this means
The entire audit was worth it specifically because it makes weekly reorder rate reportable for the first time, the number that actually explains subscription-business health, and it didn't exist anywhere in the original setup.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| New tracking plan approved but the weekly report template not updated | Update the report template to lead with reorder rate before the next reporting cycle, otherwise the fix ships but the habit doesn't change | 30 min |
Final deliverable
A corrected tracking plan: session-timeout fix, key-event list (kept, dropped, new), the consolidated event-naming scheme, and the one new actionable weekly metric it unlocks.
See a reference example
Fixes: (1) session timeout reverted to the 30-min default, historical session counts since the 5-min change flagged as non-comparable; (2) key events trimmed to purchase only, plus two new custom events built (subscription_reorder, chat_with_support); (3) three fragmented add-to-cart event names consolidated into one parameterized event; (4) new weekly headline metric, reorder rate, replaces scroll and product_view counts in the report template. This mirrors the same discipline Instacart's own funnel relies on: track the actual repeat-purchase behavior a two-sided marketplace depends on, not the loudest available engagement number.
Success criteria
You're done when you can:
- Identifies the 5-minute session timeout as the root cause of inflated/fragmented session counts
- Correctly separates the one legitimate key event (purchase) from the five that should be un-flagged, and names both missing custom events
- Specifies the event-naming consolidation (one event, parameters) rather than just noting the names are 'messy'
- Names reorder rate as the new actionable weekly metric the fix unlocks, tied to the business's actual retention model