Как документировать аналитические задачи

Почему документация важна

«Analysis» в голове аналитика — не analysis. Документация — это где knowledge lives.

Без документации:

  • Через месяц вы сами забудете выводы.
  • Другие аналитики будут re-do your work.
  • Stakeholders не будут использовать insights.
  • Knowledge leaves с вами когда смените работу.

С документацией:

  • Analyses становятся company assets.
  • Peer review возможен.
  • Scaling knowledge across team.
  • Building reputation за quality work.

Senior analysts spend 30-40% времени на writing, а не coding.

Types of analytical docs

1. Memos / write-ups. Detailed analysis с findings и recommendations.

2. Runbooks. Операционные инструкции (how to run AB-test, how to deploy dashboard).

3. Research docs. Longer strategic analyses с multiple hypotheses.

4. Experiment documentation. AB-tests — pre-register, run, analyze.

5. Dashboard documentation. Что dashboard показывает, каким образом интерпретировать.

6. Data dictionaries. Definitions tables, columns, metrics.

Разные forms для разных purposes.

Universal structure for memo

Классическая structure good analytical memo:

1. TL;DR.

3-5 bullet points с key findings. Если reader читает только это — они получат core message.

2. Research question.

Что мы пытались answer?

3. Context.

Почему этот analysis важен? Business context.

4. Methodology.

Как мы подошли? Data sources, filters, segments.

5. Findings.

Structured ответы на research questions.

6. Limitations.

Что не знаем? Caveats, data quality issues, alternative interpretations.

7. Recommendations.

Что делать based на findings?

8. Next steps.

Immediate actions, follow-up analysis, ownership.

9. Appendix.

Technical details, SQL, detailed charts.

Пример memo: Retention analysis

# Retention deep-dive: Q1 2026

## TL;DR
- Day-30 retention упал с 28% до 24% за последние 3 месяца.
- Падение driven новым onboarding (flow B, запущен 15 января).
- Drop-off на step 3 в onboarding увеличился с 15% до 28%.
- Рекомендуется rollback на prev flow или hotfix step 3.

## Research question
«Что вызвало падение Day-30 retention в Q1 2026?»

## Context
Business goal — reach 30% Day-30 retention к концу Q2.
Retention — key growth lever. Даже 1pp изменение = $500k annual revenue.

## Methodology
- Data: user_events таблица, 2025-10-01 до 2026-03-31.
- Cohorts: monthly signup cohorts.
- Day-N retention: user active на Day N после signup.
- Active = at least 1 event (login, purchase, browse).

## Findings

### Finding 1: Overall retention падает
[chart: Day-30 retention по monthly cohorts]
From 28% (Oct-Dec 2025) до 24% (Jan-Mar 2026).

### Finding 2: Проблема в new onboarding
A/B analysis flow A vs flow B (запущен 15 Jan):
- Flow A: 28% Day-30 retention
- Flow B: 22% Day-30 retention
- Significant, p < 0.001

### Finding 3: Drop-off на step 3
Flow B step 3 requires phone verification.
- Flow A step 3 completion: 85%
- Flow B step 3 completion: 72%

## Limitations
- Cross-platform effects not isolated.
- Longer-term retention (Day-60, Day-90) still being collected.
- Selection bias in early adopters of flow B.

## Recommendations
1. **Immediate**: rollback flow B к flow A. Expected recovery: +4pp retention.
2. **Short-term**: redesign phone verification step или make optional.
3. **Long-term**: A/B test onboarding variations с focus on step 3.

## Next steps
- Rollback rollout: продлом rollback к @engineer_lead, ETA 2026-04-20.
- New onboarding variations: PM @pm_name, ETA 2026-05-30.
- Follow-up analysis: Day-60 retention когда data available.

## Appendix
[SQL queries, detailed charts, segment breakdowns]

~700 words main content + appendix. Readable в 5 минут.

Experiment documentation

AB-tests — especially critical для documentation.

Pre-experiment:

# Experiment: [name]

## Hypothesis
If we [change], then [metric] will [direction], because [reason].

## Primary metric
[metric, definition]

## Secondary metrics
[list with definitions]

## Guardrails
[metrics that shouldn't regress]

## Expected effect size
[predicted % lift]

## Sample size
[calculated based на MDE, power, baseline]

## Duration
[days, включая potential novelty effects]

## Rollout plan
[stages, % traffic, criteria]

Pre-register prevents p-hacking и post-hoc rationalization.

Post-experiment:

## Results
- [primary metric]: actual lift [value], p=[p-value], CI
- [guardrails]: status
- Segments: [breakdown]

## Decision
[Launch / hold / iterate] based на criteria [defined pre-experiment].

## Learnings
[insights, surprising findings, follow-up questions]

Single doc → entire experiment lifecycle captured.

Writing style

Lead with conclusion. Pyramid principle. Reader knows answer в first paragraph.

Be concrete. «Churn wrote на 5%» > «Churn significantly changed».

Avoid jargon. Use business terminology where possible.

Active voice. «Я измерил X» > «X было измерено».

Short paragraphs. 3-4 sentences max. Easy to scan.

Visualize. Charts вместо lengthy описаний. One chart > 200 words.

Headings matter. Reader scrolls headings. Make them informative: «Mobile retention dropped 20%» > «Retention analysis».

Tooling

Notion. Flexible, collaboration-friendly. Good для living docs.

Confluence. Enterprise standard. Heavy but structured.

Google Docs. Simplest. Good collaboration. Search can be weak.

GitLab / GitHub wiki. Good для technical teams.

Custom внутренние tools. Некоторые компании строят свои (e.g., Dropbox Paper, Slite).

Code notebooks. Jupyter, Hex, Deepnote — analysis + doc в одном. Good для technical audiences.

Выбор depends on organization. Pick один и stick consistently.

Versioning

Analysis документы changing:

  • New data comes in.
  • Methodology refines.
  • Comments от reviewers.

Version control approaches:

1. Date-stamped sections. «Update 2026-04-15: new data changed conclusion».

2. Git-based. Write docs в markdown, track в repo.

3. Tool features. Notion history, Google Docs revision.

4. Separate versions. «Analysis v1», «Analysis v2 after review».

Main идея: reviewers должны видеть что changed, когда, почему.

Peer review

Analyses deserve review.

Reviewer checklist:

  • Research question clearly stated?
  • Methodology sound?
  • Conclusions follow from data?
  • Limitations acknowledged?
  • Recommendations actionable?
  • SQL/code correct (spot check)?

Often 1-on-1 review беfore wider circulation.

Benefits: catches errors, improves writing, builds team knowledge.

Документация — foundational skill для аналитика. В тренажёре Карьерник есть практические задачи на аналитику, case interviews и навыки senior-уровня.

Data dictionaries

Specialized doc type для definitions.

For each metric:

## MRR (Monthly Recurring Revenue)

**Definition:** Sum of all active subscription monthly values.

**SQL:**
```sql
SELECT SUM(monthly_amount)
FROM subscriptions
WHERE status = 'active' AND period = 'monthly';

Annualized: MRR * 12.

Includes:

  • Active monthly subscriptions
  • Annual subscriptions prorated (annual / 12)

Excludes:

  • One-time fees
  • Setup charges
  • Churned subscriptions in current month

Owner: analytics team

Updated: 2026-04-01

Dashboards using: [links]


Single source of truth для metric. Dashboards, queries, memos все reference here.

## Runbooks

Operational docs. «Как запустить weekly retention dashboard refresh».

**Good runbook:**

- Purpose (what this does, why).
- Prerequisites (access, tools).
- Step-by-step instructions с screenshots.
- Troubleshooting common issues.
- Contact если stuck.

Written такой, что newcomer может выполнить без your help.

Hours invested в good runbook saves weeks of confusion.

## Long-term knowledge management

Individual docs — не enough. Need organization.

**Structure принципы:**

**1. Central hub.** Landing page, откуда everything accessible.

**2. Hierarchies.** By team, by topic, by type of doc.

**3. Tagging.** Cross-cutting (topic, team, date).

**4. Search.** Must работать well.

**5. Archive old.** Outdated marked clearly.

**6. Reviews.** Quarterly cleanup.

Без organization — documents выглядят как dumping ground. Useless within months.

## Типичные ошибки

**Writing для себя, не для reader.** Too much detail на questions reader не спросит.

**No TL;DR.** Reader должен scroll и extract. Make them do 10x less work.

**Ignoring limitations.** Pretend analysis is bulletproof. Honest acknowledgments — builds credibility, not destroys.

**Recommendations без priorities.** 10 recommendations → paralysis. Rank them.

**No followup.** Delivered doc, forgotten. Check back в 2-4 weeks — были ли recommendations applied?

**Ignoring readers.** Writing для other analysts когда audience — execs. Adjust language, depth.

## Читайте также

- [Data storytelling](/blog/data-storytelling-dlya-analitika)
- [Stakeholder management](/blog/stakeholder-management-analitik)
- [Первые месяцы на работе](/blog/pervyj-mesyac-na-novoj-rabote-analitik)
- [Карьерный путь аналитика](/blog/kariernyj-put-analitika-dannyh)

## FAQ

### Сколько времени тратить на документирование?

Roughly proportional to analysis time. Quick ad-hoc (1 hour) — short Slack response. Week-long analysis — formal memo.

### Notion или Google Docs?

Depends on company. Notion — richer features, Google Docs — simpler. Pick what team уже uses.

### Writing skills — врождённые?

No. Skill, developed через practice и reading good examples. Start reading quality analytical memos (e.g., Stratechery, Lenny's Newsletter).

### Docs — boring. Can skip?

Can skip = career suicide. Senior analysts recognized за writing. Middle/junior без writing stay there.