Explain a metric release to the analyst on call
After a mart correction, May net sales changes and analysts need to know which rows moved. Build a synthetic before/after comparison and quantify the delta instead of assuming a target percentage.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Low
- Engineering practice
- Technical communication · Data explainability · Operational handoff
Estimated field mix
- Data engineering80%
- Site reliability20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional marketplace reports daily sales to merchants. Refund joins inflate revenue, merchants close books in different time zones, and backfills compete with nightly loads. All source orders and merchants are synthetic.
Setup prerequisites
- SQL joins and aggregates
- Batch pipelines
- Metric definitions
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- LAKE-102 · Profile source keys before trusting the order feed
- LAKE-101 · Write the daily net-sales contract with worked rows
- LAKE-104 · Assign sales to the merchant's reporting day
- LAKE-105 · Preserve historical merchant plans in revenue breakdowns
- LAKE-103 · Remove the order-line and refund join fan-out
- LAKE-106 · Pick up late refunds in an incremental load
- LAKE-107 · Prevent a backfill from replacing a newer nightly partition
- LAKE-108 · Block publication when revenue fails source reconciliation
Acceptance criteria
- Document metric versions, source cutoff, and affected partitions.
- Break the delta into fan-out, late-refund, and reporting-day effects.
- Provide reproducible comparison queries and previous-manifest restoration steps.
Implementation constraints
- Label measured deltas as results from the synthetic fixture, not expected company impact.
Verification to include
- Reproduce the note's totals from the synthetic fixture created for this project.
- Exercise rollback and confirm the prior version is visible.
Deliverables
- Analyst release note and verified handoff checklist
Rollout and recovery
Ship the note with the generation switch and record any rollback in the incident log.
Value of the work
For the engineer: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases.
For the team: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.