How do I set up a product analytics tool for cohort retention tracking across nicotine refill programs?

To set up a product analytics tool for cohort retention tracking across nicotine refill programs, you want to define:

1. What counts as a user
2. What counts as a cohort
3. What counts as retention
4. What events mark refill program behavior
5. How to segment and visualize it

Because this involves nicotine-related products, I’ll keep the guidance focused on product analytics and measurement design rather than any marketing or optimization advice.

1) Define your core entities

At minimum, track these entities:

• User / customer
• Subscription or refill program enrollment
• Order / refill shipment
• Cancellation / churn
• Pause / skip / resume
• Product type / strength / pack size if relevant for analysis
• Acquisition date or first refill date

2) Choose the retention model

For refill programs, the most useful retention definitions are usually:

A. Enrollment retention

A user is retained if they remain active in the refill program after N days/weeks/months.

B. Purchase refill retention

A user is retained if they place another refill order within a specific window.

C. Subscription continuity retention

A user is retained if their subscription is still active, regardless of whether a shipment occurred in that exact period.

Most teams track all three, but the refill-order-based view is often the most actionable.

3) Define the cohort anchor

Pick one consistent anchor date for cohorts. Common choices:

• Program signup date
• First completed order date
• First refill shipment date
• First subscription activation date

For refill programs, the most common is:

• Cohort = users whose first refill order happened in the same week/month

That makes retention easier to compare over time.

4) Instrument the essential events

You’ll want event tracking for at least:

User lifecycle

• user_created
• program_enrolled
• subscription_activated
• subscription_canceled
• subscription_paused
• subscription_resumed

Order lifecycle

• refill_order_created
• refill_order_paid
• refill_order_shipped
• refill_order_delivered
• refill_order_failed
• refill_order_refunded

Optional behavioral/support events

• address_updated
• payment_method_failed
• support_ticket_created

5) Include useful properties on each event

For cohort analysis, properties matter a lot. Add:

• user_id
• subscription_id
• order_id
• cohort_date
• product_sku
• product_category
• nicotine_strength
• refill_frequency
• channel
• country/region
• cancellation_reason
• pause_reason
• order_sequence_number
  Example: first refill = 1, second refill = 2

6) Build the retention table

Your analytics tool should produce a table like:

Cohort Month	Size	Week 1	Week 2	Week 3	Week 4
Jan 2026	1,200	82%	74%	70%	66%
Feb 2026	1,050	84%	76%	71%	—

For refill programs, retention can be measured weekly or monthly depending on expected refill cadence.

7) Handle edge cases carefully

Refill programs often have messy real-world behavior, so define rules for:

• Grace periods: if a refill is late by a few days, is the user still retained?
• Pauses: exclude paused users from active retention, or count them separately
• Failed payments: retained if payment recovers within X days?
• Skipped shipments: count as churn or temporary inactivity?
• Refunds/cancellations: should invalidate retention?
• Multi-product users: cohort by first product, all products, or each product line separately

Write these rules down before reporting.

8) Recommended retention metrics

Track these alongside the cohort chart:

• D1 / D7 / D30 retention if cadence is fast
• Month 1 / Month 2 / Month 3 retention
• Repeat refill rate
• Average number of refills per user
• Time to churn
• Pause rate
• Recovery rate after payment failure
• Cancellation rate by cohort

9) Segment the cohorts

Useful segment splits include:

• Acquisition channel
• Product type / SKU
• Nicotine strength
• New vs returning users
• Region
• Initial refill frequency
• Payment method
• Subscription plan type

This helps identify where retention differs across program variants.

10) Implementation pattern

A simple implementation looks like this:

Data pipeline

• App/backend emits events
• Events go to your analytics tool or warehouse
• Transform events into a clean “user subscription history” table
• Build cohort retention from that table

Example logic

A user is “retained in month 2” if:

• they had a first refill order in cohort month 1, and
• they had at least one successful refill order in month 2, or subscription remained active in month 2, depending on your chosen rule

11) Example event schema

{
  "event_name": "refill_order_paid",
  "user_id": "u_123",
  "subscription_id": "s_456",
  "order_id": "o_789",
  "timestamp": "2026-08-13T12:00:00Z",
  "properties": {
    "product_sku": "sku_001",
    "nicotine_strength": "6mg",
    "refill_frequency": "30_days",
    "cohort_date": "2026-08-01",
    "order_sequence_number": 2
  }
}

12) Practical dashboard layout

Create a dashboard with:

• Cohort retention heatmap
• Retention curve
• Cohort size trend
• Cancellation reasons
• Pause/skip behavior
• Refill order funnel
• Segment comparison filters

13) Tooling options

Common approaches:

• Product analytics tools: Mixpanel, Amplitude, PostHog
• Warehouse-based analytics: BigQuery/Snowflake + dbt + BI tool
• Hybrid: event tool for exploration, warehouse for source of truth

For cohort retention, warehouse-based modeling is often best if you need strict definitions and auditability.

14) Validation checklist

Before trusting the numbers, verify:

• Event timestamps are consistent
• User IDs are stable across devices/systems
• Duplicate orders are deduped
• Canceled/refunded orders are handled correctly
• Cohort assignment is immutable
• Retention windows match business cadence

If you want, I can also help you with one of these next:

1. a sample event taxonomy
2. a SQL query for cohort retention
3. a dashboard spec
4. a warehouse schema for refill tracking