REPOSITORY CODING · HARD
Repair historical visibility and positive-net retention
Historical reports must select the latest already-visible observation, and fully refunded orders must not activate a cohort member by themselves. Repair both stages.
Longitudinal cohort analyticsCohort retention laboratory
Work through a real codebase.
Choose an environment, investigate the existing implementation and use the tests to check your change. Sign in to open a workspace; execution and Ono usage follow your plan’s allowances.
Task requirements and environments
PySpark · 80 minute session
- Build weekly retention and net-revenue cohorts with native Spark DataFrames/windows/joins. Up to 20 users and 40 observations per table are accepted. User joined/day values are integer epoch days; epoch day zero is Thursday. Cohorts start on Monday, including negative week starts around the epoch. User segments and identities are bounded ASCII strings.
- Each observation has an ID and observed sequence. Select the latest delivery visible at inclusive asOf before deduplicating. Equal-ID/equal-observed conflicting payloads are invalid. Activity and orders name known users; refunds name a known order ID. Exclude events before user registration and after inclusive through.
- Cohort membership is registered users through the report day, partitioned by cohort Monday and segment. Active retention counts distinct users per week from activity or positive-net orders. Sum visible through-day refunds per order, clamp net revenue at zero, and exclude fully refunded orders from active retention unless the user also has activity.
- Return one sorted row per cohort/segment and weeks zero through horizon (0..4). A week is observable only when its last day is <= through. Censored weeks have eligible zero and null active/retentionBps/revenue; completed weeks use the original cohort size and floor(active*10000/cohortSize). Unobserved activity contributes zero, never a missing cohort.
- The application uses real Spark grouping, deduplication windows, joins and aggregations; no external database or service is contacted. Native session resources are bounded and reused across grading fixtures.