# Partner Playbook: complete practice library

> Full machine-readable text of all localized Partner Playbook practices. Content is organized as Markdown and mirrors the public English and Russian article pages.

Site: https://playbook.affpartners.io

Languages: English and Russian

# English practices

The complete English version of the library.

Library URL: https://playbook.affpartners.io/en/

## Product quality

### Find the biggest funnel drop-off

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-funnel/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-funnel/index.md
- **Module:** Product quality
- **Time:** 60 minutes for the first audit

You do not need to master every analytics report at once. Map five clear steps, identify the largest drop-off, and choose one change for the next release.

#### Outcome

A five-step funnel table with one drop-off point, a likely cause, and an owner for the next change.

#### Find one weak spot in the journey, not every problem at once

Think of the user journey as five doors. At every step some people leave. Your task is to see which door loses the most users, understand the likely cause, and fix that first.

#### What you will need

- **Access:** AppMetrica, Firebase, Amplitude, or any report where user actions are visible.
- **Colleague:** An analyst or developer for 15 minutes if you do not know the event names.
- **Period:** The last 14–30 days without major incidents or ad-driven traffic spikes.

#### Terms in plain language

- **Funnel — A sequence of steps leading to an outcome:** Definition: It compares user counts at each step and reveals the largest drop-off. Example: Install → first open → registration → first useful action → return visit.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **ANR — An Android app freeze:** Definition: Android records an ANR when the interface does not respond to the user for too long. Example: The user taps a button, the screen freezes, and Android offers to close the app.

#### When to use it

Registrations or first useful actions are declining, users complain about the journey, and the team does not know what to fix first.

#### Where to get the data

Choose the option the team already has. If analytics is not set up, start with a manual check — the practice will still produce a result.

- **AppMetrica or Firebase**
  - **Source:** Open the “Funnel” report and add: first launch → registration started → registration completed → first useful action → repeat visit.
  - **If access is unavailable:** If the event names are unknown, ask a developer to send the list of events for registration and the first useful action.
- **Spreadsheet or BI report**
  - **Source:** Take the number of users at each step for a single period. Do not mix iOS and Android in the first check.
  - **If access is unavailable:** Five numbers are enough. Do not wait for a perfect dashboard to spot a large drop-off.
- **If there are no events yet**
  - **Source:** Walk the journey on a clean install ten times on iOS and Android. Record errors, delays, and confusing screens.
  - **If access is unavailable:** Write a short technical specification for the events — that will be the first result of the audit.

#### Run your first audit in five steps

1. **Draw the journey.** Write down five steps as simple user actions — no internal screen names or team jargon.
   - **Where to do it:** A sheet of paper, FigJam, or the first column of the final table.
   - **Example:** Install → first launch → registration started → first useful action → repeat visit.
2. **Put five numbers next to the steps.** Record how many unique users reached each step during the same period.
   - **Where to do it:** The “Funnel” report in AppMetrica / Firebase, or an export from an analyst.
   - **Example:** 1,000 launched the app, 820 started registration, 460 completed it.
3. **Calculate the conversion between steps.** Divide the number at the next step by the number at the previous one and multiply by 100%. The lowest percentage is the first candidate to investigate.
   - **Where to do it:** In the table, next to each step.
   - **Example:** 460 ÷ 820 × 100% = 56%. That means 44% of those who started registration did not finish it.
4. **Verify the cause.** Review errors and support tickets, then walk through the step yourself. Do not change the interface until you have ruled out a technical problem.
   - **Where to do it:** Crash reports, support tickets, and a clean install of the app.
   - **Example:** On Android 12 the confirmation code arrives late, and resending it is not explained.
5. **Choose one change.** Record the change, its owner, and the metric you will compare after the release. Do not put several screens into your first experiment.
   - **Where to do it:** A task in the backlog or a short plan for the next release.
   - **Example:** Fix code resending; owner — the Android team; check — registration completion rate after 14 days.

#### Practical examples

- **Long load after registration:** The user created an account but waits 40 seconds for the first screen and closes the app. The priority is speed and a clear loading status — not another form field.
- **Different journeys per platform:** On Android, registration is completed noticeably less often than on iOS. Check the errors of the specific version first, then change the interface.

#### Finished artifact: One table for one team decision

You do not need a big report. Fill in five rows and highlight the one drop-off the team will address in the next release.

| Step | Users | Conversion | What we see |
| --- | --- | --- | --- |
| First launch | 1,000 | — | Starting point |
| Started registration | 820 | 82% | Acceptable drop-off |
| Completed registration | 460 | 56% | Main drop-off point |
| Completed the first useful action | 350 | 76% | Check the hints |
| Returned on D1 | 150 | 43% | Watch after the fix |

Conclusion: check registration on Android first — errors, required fields, and waiting time. Owner: product + Android developer.

#### Checklist before the decision

If an item is missing, log it as a separate task — do not guess.

- [ ] The five steps are named as user actions, not internal screens.
- [ ] Each step has a number for the same period.
- [ ] iOS and Android are checked separately.
- [ ] Technical errors and support requests were reviewed before changing the interface.
- [ ] One change is chosen, with an owner and a review date.

#### How to know the change helped

- **Main signal:** Conversion at the problem step grew compared with the period before the release.
- **Guardrail metric:** Errors, crashes, and support requests at neighboring steps did not grow.
- **Business result:** More users reached the first useful action and FTD without extra pressure.

#### Key rule

FTD is the user's first deposit and the outcome of the whole journey. Make the journey clear and reliable first, then check the business result.

---

### Help users reach their first useful outcome

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-first-value/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-first-value/index.md
- **Module:** Product quality
- **Time:** 90 minutes for the first analysis

The first useful outcome is the moment when someone gets a small, tangible result—not merely opens the app. Find that moment and remove what blocks it in the first session.

#### Outcome

A first-session journey map with one useful outcome, the path to it, unnecessary barriers, and one change for the next release.

#### Show value first, then ask for effort

A new user does not yet trust the app and does not know why they should fill out a profile, enable notifications, or sit through a long onboarding. Let them see real value as early as possible — even if it is just a personalized collection, a saved item, or a first clear result.

#### What you will need

- **Clean install:** A phone without a saved account, plus the previous app version from the store for an honest first pass.
- **Colleague:** Product, support, or design for 20 minutes to check a newcomer's expectations against real questions.
- **Period:** Data on new users for the last 14–30 days without major ad spikes.

#### Terms in plain language

- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.

#### When to use it

New users install the app but do not finish onboarding, do not complete the first useful action, or do not come back the next day.

#### Where to get signals

Do not try to prove perfect causality right away. Combine the numbers with live user questions and a manual walkthrough.

- **First-launch funnel**
  - **Source:** In AppMetrica, Firebase, or another report, build: first launch → onboarding started → onboarding completed → first useful action.
  - **If access is unavailable:** If the event you need does not exist, ask a developer for the closest technical event and file a task for proper tracking.
- **Support and reviews**
  - **Source:** Take the last 20 questions from new users and mark where they did not understand the value, a permission, a condition, or the next step.
  - **If access is unavailable:** If there are few requests, ask three colleagues unfamiliar with the product to go through the first launch and voice their doubts aloud.
- **Manual walkthrough**
  - **Source:** Record the screen, action, time, and the user's question at every step from install to the first result.
  - **If access is unavailable:** Even without analytics you will get a list of barriers and can pick one safe simplification.

#### Map the path to the first useful outcome

1. **Name one useful result.** Define an action after which a newcomer can honestly say: “Now I understand why I need this app.” Do not treat registration, consent, or a deposit as value in itself.
   - **Where to do it:** At the top of the journey map or in a short team document.
   - **Example:** The user saw a clear collection for their interest and saved one item.
2. **Walk the journey from scratch.** Reinstall the app and record every screen, required field, permission, and wait on the way to the result.
   - **Where to do it:** On a real iOS and Android device, not only in a test build.
   - **Example:** Reaching the collection takes 9 screens, 7 fields, and two permission prompts.
3. **Separate the necessary from the habitual.** For each step ask: is it impossible to show value without it, or is the team simply used to doing it upfront? Move optional requests to after the result.
   - **Where to do it:** In the second and third columns of the journey map.
   - **Example:** The time zone is needed for notifications later, not for the first collection — move the request.
4. **Keep one clear CTA.** Every screen should have one main next step that describes the outcome, not the internal process.
   - **Where to do it:** On key screens before and right after the first useful outcome.
   - **Example:** Instead of “Continue” — “Show my collection”; after the result — “Save collection.”
5. **Choose one simplification.** Fix the change, owner, and metrics before development. Do not mix a shorter form, new copy, and a redesign of every screen in one test.
   - **Where to do it:** In the next release's task and the journey map.
   - **Example:** Move five profile fields to after the first collection; owner — product manager; check after 14 days.

#### Practical examples

- **Before: a survey ahead of the result:** New users went through 9 screens and 7 fields before the first collection. After moving five fields past the result, the path shrank to 4 screens — one barrier changed, not the whole onboarding.
- **After: permission at a clear moment:** The push permission is requested not at first launch but after an item is saved: the app first explains it will report changes to that exact item.

#### Finished artifact: Map of the first useful experience

Capture the current journey in five rows. Do not design a whole new onboarding — pick one barrier to remove first.

| Stage | What happens now | What we change | Done if |
| --- | --- | --- | --- |
| First screen | Three promo slides | Keep one value promise | Clear within 5 seconds |
| Registration | 7 required fields | Keep email and password only | Can continue without a profile |
| Permissions | Push requested immediately | Ask after an item is saved | There is clear context |
| First useful outcome | Collection shown only after a survey | Show a basic collection earlier | Result in the first session |
| Next step | Three identical buttons | One “Save collection” CTA | The action is obvious |

First change: show a basic collection before the full survey. Owner — product + mobile team. Check after 14 days: conversion to the first useful outcome and the median time to reach it.

#### Checklist before development

If the team cannot answer an item, go back to the journey map — you do not need a new interface yet.

- [ ] The first useful outcome is described as a user action, not a business metric.
- [ ] The journey was walked on a clean install on iOS and Android.
- [ ] There is a clear reason for every required field and permission.
- [ ] Before the first useful outcome, every screen has one main CTA.
- [ ] One change is chosen, with an owner, a period, and a check metric.

#### How to know the journey improved

- **Reached the value:** The share of new users who completed the first useful action in their first session.
- **Reached it faster:** The median time and number of screens from first launch to the useful result.
- **Kept the trust:** Errors, early uninstalls, support questions, and D1 did not get worse after the change.

#### Key rule

If the first useful action cannot be described in one sentence, agree on it within the team first — only then change the onboarding.

---

### Prioritize bugs by user impact

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-bugs/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-bugs/index.md
- **Module:** Product quality
- **Time:** 60 minutes for the first analysis

You do not need to be a technical expert to bring order to a bug backlog. For each bug, answer four questions: what is broken, who is affected, how often it happens, and whether a safe workaround exists.

#### Outcome

A table of the five highest-impact bugs with evidence, a workaround, an owner, and a review date.

#### Priority is harm to the user, not how loud the discussion is

A striking visual defect may get a lot of attention, but a broken transaction status, data loss, or a login failure usually matters more. Protect security, money, data, and the key journey first; convenience and appearance come after.

#### What you will need

- **Access:** Crashlytics, AppMetrica, or another error report, plus the current task list in Jira, Linear, or a spreadsheet.
- **Colleagues:** A QA engineer or developer and a support representative for 20 minutes to confirm the technical trail and complaint frequency.
- **Period:** Errors, support requests, and reviews for the last 14 days; note app versions and platforms separately.

#### Terms in plain language

- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **ANR — An Android app freeze:** Definition: Android records an ANR when the interface does not respond to the user for too long. Example: The user taps a button, the screen freezes, and Android offers to close the app.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

The backlog keeps growing, the team argues about urgency, and the latest loud request gets picked up instead of the most dangerous problem.

#### Where to look for evidence

One screenshot does not show the scale. Combine the technical signal, a user report, and the impact on a key action.

- **Crash and ANR reports**
  - **Source:** Look at the number of affected users, the app version, device, stack trace, and repeatability.
  - **If access is unavailable:** If there are no reports, ask a developer to reproduce the problem and save the video, logs, and conditions.
- **Support and reviews**
  - **Source:** Group requests by a single cause: login, status, payment, data loss, blank screen, or a confusing message.
  - **If access is unavailable:** If tags are not set up, manually go through the 30 most recent requests and create five simple categories.
- **Key journey**
  - **Source:** Compare the action's success rate before and after the error appeared: login, registration, saving, verification, or a transaction.
  - **If access is unavailable:** Without analytics, run the journey ten times on the affected version and record the failure rate.

#### Sort out the bug list in five steps

1. **Collect everything into one table.** Merge duplicates from crash reports, QA, support, and reviews. One user problem should be one row.
   - **Where to do it:** Jira, Linear, or a shared table with links to the original signals.
   - **Example:** Three tickets — “endless status,” “transaction stuck,” and “I can't see the result” — are merged into one problem.
2. **Describe the harm in plain words.** Write down what the user cannot do and what they risk losing. Do not leave only an error code in the title.
   - **Where to do it:** In the “user impact” field of each task.
   - **Example:** Not “API 504,” but “after confirming, the user does not see the final status and repeats the action.”
3. **Confirm the scale.** State the number of people affected, the platform, version, frequency, and period. If there is no number, honestly note your confidence level.
   - **Where to do it:** Next to the technical trail and a link to the support requests.
   - **Example:** 84 users in 7 days; Android 12 only; confirmed by 12 support requests and one error cluster.
4. **Assign a priority and a workaround.** Security, money, data, and a blocked key action come first. While the fix is in progress, support must know how to help the user safely.
   - **Where to do it:** In the P0–P3 columns: owner, deadline, and workaround.
   - **Example:** P0; owner — the backend team; deadline — today 18:00; support checks the status by ID.
5. **Close on data, not on release.** After the fix, repeat the scenario and make sure both the technical signal and the user complaints are gone.
   - **Where to do it:** In the task, 24–72 hours after the fix ships.
   - **Example:** The error cluster is gone, 20 test runs pass, and no new requests on the topic for two days.

#### Practical examples

- **P0: transaction status stuck:** The problem hit 84 users in a week: the result is invisible, so people repeat the action. There is a financial and trust risk — an owner and a safe support reply are needed today.
- **P1: empty history on Android 12:** The scale is smaller, but key data is unavailable. The task records the version, a repro video, the temporary restart workaround, and a support-request check 48 hours after the hotfix.

#### Finished artifact: A priority table the whole team understands

Five rows are enough for the first decision. Do not hide the impact behind a technical bug name.

| Problem | Impact and scale | Workaround | Decision |
| --- | --- | --- | --- |
| Transaction status stuck | Money/trust · 84 users | Support checks manually | P0 · fix today |
| Login code not delivered | Blocks login · Android 12 | Resend after 60 seconds | P0 · Android developer |
| Empty history | Data not visible · version 4.2 | Restart the app | P1 · urgent fix |
| Push opens the home screen | Extra step · 11% of taps | Open the section manually | P2 · next release |
| Misaligned icon | Appearance only | Not needed | P3 · design debt |

Rule: P0 blocks or corrupts money, data, security, or the main journey. Every P0 has an owner, a deadline, a message for support, and a way to verify the fix.

#### Prioritization checklist

A critical task should read the same to product, support, and development.

- [ ] The problem is named through the action and the harm to the user.
- [ ] Platform, version, period, and a confirmed scale (or a confidence level) are present.
- [ ] Errors involving money, data, security, and trust are flagged separately.
- [ ] P0/P1 issues have an owner, a deadline, and a safe workaround.
- [ ] It is written down in advance which data will confirm the fix.

#### How to know the fix worked

- **Technical signal:** The specific crash cluster, ANR, or error code disappeared on the affected version.
- **User journey:** The success rate of logins, saves, transactions, or the other broken action recovered.
- **Support and trust:** New requests on the topic stopped, and users who hit the problem received a clear answer.

#### Key rule

A bug is closed not when the code ships, but when users complete the journey again and the data confirms it.

---

### Ship updates without surprises

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-release/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-release/index.md
- **Module:** Product quality
- **Time:** 45 minutes before release

A safe release answers three questions in advance: what will be checked before rollout, who will watch the first signals, and what condition will stop distribution.

#### Outcome

A one-page release card covering affected user journeys, checks, owners, metrics, and stop conditions.

#### A release is a controlled check, not just a Publish button

Even a small change can break login, analytics, or the path from a notification. Before publishing, the team agrees which journeys are affected, who watches the first hours, and which signal means continue, stop, or roll back.

#### What you will need

- **Build:** The release build for iOS and Android, plus the previous version from the store to test the update path.
- **Team:** A release owner, a mobile developer or QA engineer, and a support contact for the observation window.
- **Window:** At least 60 minutes before publishing for checks and the first 2–4 hours after release for monitoring.

#### Terms in plain language

- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **ANR — An Android app freeze:** Definition: Android records an ANR when the interface does not respond to the user for too long. Example: The user taps a button, the screen freezes, and Android offers to close the app.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

Before every update — especially when registration, data storage, notifications, deep links, or a key user journey change.

#### What to open before the release

Collect the links in advance. When a problem hits, the team should not be hunting for the right dashboard or person in chat history.

- **Change list**
  - **Source:** Take the release tasks and translate them into user journeys: login, registration, content, a transaction, notifications, profile.
  - **If access is unavailable:** If there is no change list, ask each developer to state their change and the screen it might affect in one sentence.
- **Stability and events**
  - **Source:** Prepare dashboards for the crash-free rate, ANR, API errors, and key events of the new app version.
  - **If access is unavailable:** Without a dashboard, assign someone to check logs, test accounts, and support requests at 30, 60, and 120 minutes.
- **Reaction channel**
  - **Source:** Specify in advance the chat, the decision owner, and the way to halt the rollout or quickly ship a fix.
  - **If access is unavailable:** If a technical rollback is impossible, write down a safe plan: pause campaigns, disable the feature, or notify users.

#### Prepare the release in five steps

1. **Translate tasks into user journeys.** Do not stop at a list of technical changes. Say what the user will see and which neighboring journey might break.
   - **Where to do it:** At the top of the release card, next to the version.
   - **Example:** Changed authorization → check login, session restore, the update from the old version, and the deep link for a signed-out user.
2. **Check a clean install and the update.** A fresh install and an update from an old version are different scenarios. Run both on iOS and Android with real test accounts.
   - **Where to do it:** In the test build and the store version.
   - **Example:** After updating from 4.2 the user stays signed in; history and settings are preserved.
3. **Walk through the critical actions.** Check login, the first useful action, the key transaction, a notification, and returning from the background. Record the fact, not “should work.”
   - **Where to do it:** In a checklist with the date, device, and the checker's name.
   - **Example:** Android 13: registration passed 10 out of 10 times; the completion event is visible in the report.
4. **Write down the stop conditions.** Before publishing, define the specific signal that stops the rollout. “If things look bad” does not help anyone decide.
   - **Where to do it:** In the last column of the release card.
   - **Example:** We stop if login conversion in the new version is more than 10% below normal or sessions start getting lost.
5. **Assign post-release monitoring.** Name the owner, the check intervals, and the reaction channel. Support must know what changed and what data to attach to requests.
   - **Where to do it:** In the chat and on the release card.
   - **Example:** Checks at 30, 60, and 120 minutes; owner — Maria; support attaches the app version and user ID.

#### Practical examples

- **Before publishing: the update from 4.2:** QA updates the store version and checks the saved session and history. Losing the session or data is a pre-written stop condition, not something to argue about after launch.
- **After publishing: checkpoints:** The release owner watches the crash-free rate, login errors, and key-action conversion at 30, 60, and 120 minutes; support attaches the app version to every new request.

#### Finished artifact: Release control card 4.3

One row per check. The owner, the observed fact, and the stop condition sit right next to it.

| Check | Owner | Expected result | Stop condition |
| --- | --- | --- | --- |
| Update from 4.2 | QA | Session and data preserved | Login or data loss |
| Clean registration | iOS/Android | Code and profile work | Success below 95% in tests |
| Key action | Product manager | Event and result visible | Conversion drop >10% |
| Deep link from push | CRM specialist | The right screen opens | The link lands on an error |
| First 2 hours | Release owner | Crash-free in the normal range | Sharp rise in crash/ANR |

The release owner makes the call. On a stop signal the team halts the rollout, records the time and version, notifies support, and chooses a rollback or an urgent fix.

#### Release checklist

Do not tick items in advance. Every check needs a fact: device, time, result, or a dashboard link.

- [ ] Changes are translated into clear user journeys.
- [ ] A clean install and the update path are tested on iOS and Android.
- [ ] Critical actions, analytics events, and deep links work.
- [ ] Stop conditions and a safe reaction plan are written down for the key metrics.
- [ ] A release owner, monitoring intervals, and a support contact are assigned.

#### What to watch after the release

- **Stability:** The crash-free rate, ANR, and API errors of the new version stay within the normal range.
- **Key journey:** Login, registration, and the main action perform no worse than in the previous version.
- **Live signals:** Support and reviews show no new recurring problem in the first 72 hours.

#### Key rule

If the team does not know who stops the rollout and on which signal, the release is not ready to publish.

---

### Ask for ratings and collect in-app feedback

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-reviews/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-reviews/index.md
- **Module:** Product quality
- **Time:** 75 minutes to set up the foundation

An app-store rating and a problem report serve different needs. Ask for a rating after real value, while keeping a clear way to report a question or bug available to every user.

#### Outcome

A map of two fair journeys: a native rating request after success and an in-app feedback route with a response owner.

#### Do not cherry-pick happy users — create the right moment

A rating request is appropriate after a completed useful action, when the user has already seen the result. It does not replace help, though: the “Report a problem” path must be available to everyone, not only to those who first picked a low score.

#### What you will need

- **Success event:** One confirmed action after which the user got a result: saved, completed, configured, or successfully finished a journey.
- **Response channel:** A support queue, email, or ticketing system with an owner and a clear first-response time.
- **Development:** The native rating prompt on iOS and Android and a short in-app feedback form.

#### Terms in plain language

- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

The team learns about problems only from public reviews, the rating prompt appears at random, and reporting an issue inside the app is hard.

#### How to choose the moment and the form

Start with one successful journey and one request type. Do not try to collect ratings on every screen at once.

- **Useful-action event**
  - **Source:** In analytics, find the moment of a confirmed result and make sure the event fires only after success.
  - **If access is unavailable:** If there is no event, trigger the request only from the confirmed-result screen and file a tracking task.
- **Support themes**
  - **Source:** Group the 30 most recent requests and keep 3–4 clear reasons in the form, plus a free-text comment.
  - **If access is unavailable:** Without history, start with these categories: a problem, unclear how to do something, a suggestion, other.
- **Request context**
  - **Source:** Pass the app version, platform, screen, and error ID automatically — the user should not have to hunt for this data.
  - **If access is unavailable:** If automatic transfer is not possible yet, show the version in the form and let the user attach a screenshot.

#### Set up two honest channels

1. **Choose a confirmed moment of value.** The rating request should follow a successful result — not the first launch, registration, or an attempted action.
   - **Where to do it:** In analytics and on the result confirmation screen.
   - **Example:** After the third successfully saved item, not right after installing the app.
2. **Use the native prompt.** Use the platform's standard dialog, without your own star pre-selection or requests for a specific score.
   - **Where to do it:** In the app, after the success event, with a frequency cap.
   - **Example:** The system decides whether to show the dialog; the app does not promise a bonus for a rating.
3. **Open feedback to everyone.** Add a visible way to report a problem, a confusing step, or an idea — regardless of whether the user saw the rating prompt.
   - **Where to do it:** In the help section and next to errors or critical actions.
   - **Example:** The login error screen has a “Report a problem” option, and the profile has a permanent “Help and feedback” item.
4. **Pass the context automatically.** Attach technical details and a simple category to each request. Do not make users recall the app version or an error code.
   - **Where to do it:** In the ticketing system or support queue.
   - **Example:** Category: login; Android 13; version 4.3; login screen; screenshot attached.
5. **Close the loop.** Set a first-response deadline and group recurring themes weekly. When a problem is fixed, tell the user.
   - **Where to do it:** In the support rules and a short product review.
   - **Example:** Reply within one business day; themes with 5+ requests a week get an owner and a decision.

#### Practical examples

- **A rating request after confirmed value:** After the third successful save, the app calls the platform's native dialog. There is no custom star picker, no bonus promise, and no request for a specific score.
- **Help available at the moment of error:** On the failed login screen, the “Report a problem” button sends the version, platform, screen, and error code to support; a reply is promised within one business day.

#### Finished artifact: Two journeys instead of one trap

Separate rating and help. Each journey has its own moment, action, and owner.

| Journey | Moment | What the user sees | What the team does |
| --- | --- | --- | --- |
| App rating | After the 3rd successful save | Native iOS/Android dialog | Monitors prompts and the rating |
| Error on a screen | The user taps “Report” | Short form + screenshot | Support replies within 1 business day |
| Confusing journey | Help button next to the action | Category + comment | Product clusters themes weekly |
| User idea | The “Help and feedback” section | Free text | The team confirms receipt |

Do not show your own star picker before the system prompt, and do not route users to different channels based on their expected score.

#### Launch checklist

Rating and feedback complement each other; they must not sort users into “good” and “bad.”

- [ ] The rating request is tied to a confirmed useful action.
- [ ] The platform's standard dialog is used, with no star pre-selection.
- [ ] In-app feedback is available to every user.
- [ ] Version, platform, screen, and error are passed automatically or easy to add.
- [ ] Requests have an owner, a first-response deadline, and a weekly theme review.

#### How to know the system works

- **Prompt relevance:** The native dialog appears after success, with no rise in irritation or uninstalls.
- **Signal quality:** In-app requests carry context and cluster into recurring themes the team can act on.
- **Team reaction:** First-response time drops, and repeat requests stop coming for fixed themes.

#### Key rule

Do not beg for five stars and do not hide the path to help: a good rating starts with real value and an honest reaction to problems.

---

## Retention

### Give users a reason to return

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-return/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-return/index.md
- **Module:** Retention
- **Time:** 60 minutes for the first scenario

Retention is not about sending more messages. Users return when something personally useful has changed or when they can easily continue an unfinished action.

#### Outcome

A return-scenario card with its audience, useful trigger, message, deep link, exclusions, and outcome metric.

#### First the reason, then the message

“Come back to the app” describes the team's goal, not the user's benefit. A good scenario starts with an event: a result is ready, a saved item changed, a specific step can be continued, or there is personal progress to see.

#### What you will need

- **Segment:** One clear group: did not finish verification, saved an item, or did not return after the first useful action.
- **Channel:** Push, email, or an in-app banner that can exclude active users and those who already completed the action.
- **Screen:** A working deep link straight to the right step, and a person responsible for testing the scenario.

#### Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.

#### When to use it

Users get their first value or start an important journey but do not come back, while generic messages produce opens without completed actions.

#### Where to find a reason to return

Do not start with the notification copy. First find an unfinished or newly useful action for a specific group.

- **Retention report**
  - **Source:** Check D1/D7 for new users and find a group that got the first useful outcome but did not return, or stopped at one step.
  - **If access is unavailable:** Without a cohort report, take two weeks of users in one journey and compare manually who came back.
- **Events and interests**
  - **Source:** Use only confirmed actions: saved an item, started verification, opened a topic, or created a collection.
  - **If access is unavailable:** If there are no events, start with one server-side status the team can reliably update and exclude after completion.
- **The link and exclusions**
  - **Source:** Test the deep link on an installed and a freshly reopened app; exclude recently active users and those who already finished the action.
  - **If access is unavailable:** Until the deep link is ready, use an in-app message or an email with clear manual navigation.

#### Build one useful return scenario

1. **Pick one audience.** Describe people through a confirmed action and a time window, not a broad label like “all inactive.”
   - **Where to do it:** In the segmentation tool and the first row of the scenario card.
   - **Example:** Started verification, did not finish within 24 hours, has not opened the app in the last 12 hours.
2. **Name a real reason.** The reason must exist in the product: saved progress, a new result, a change in a followed item, or a ready next step.
   - **Where to do it:** In the trigger event and the message copy.
   - **Example:** The documents are saved; the user can continue from where they stopped without re-entering anything.
3. **Add exclusions.** Do not message people who already completed the action, returned recently, or received a similar message in another scenario.
   - **Where to do it:** In the segment rules before the send.
   - **Example:** Exclude completion=true, active_last_12h=true, and push_sent_last_48h=true.
4. **Lead straight to the continuation.** After the tap, open the promised screen and the saved step. The home screen makes the user search for their reason all over again.
   - **Where to do it:** In the deep link and the iOS/Android test plan.
   - **Example:** After sign-in, the document upload opens — not the home feed.
5. **Measure the useful action.** Look beyond delivery and opens. The main result is whether the user completed the action they returned for.
   - **Where to do it:** In the report 7–14 days after launch.
   - **Example:** Of 500 who got the message, 130 returned and 74 completed verification; compare with a similar group without the message.

#### Practical examples

- **Continue the saved step:** After 24 hours the message goes only to those who started verification and did not finish. The deep link opens the saved document step; completed and recently active users are excluded.
- **Return to a personal interest:** When a real update lands in a saved collection, the message names it and leads to that collection. Success is viewing the update — not merely opening the app.

#### Finished artifact: First return-scenario card

One scenario — one audience and one reason. Start with a small group so you can judge quality, not send volume.

| Field | Decision | Check |
| --- | --- | --- |
| Audience | Started verification, not finished within 24 hours | Completed and today-active users excluded |
| Reason | The saved step can be continued | The process state is actually saved |
| Message | Continue verification from the document step | No pressure or promises |
| Destination | Deep link to the document upload screen | Works after sign-in on iOS/Android |
| Success | Verification completed within 7 days | Compared with a similar group without the message |

Before launch, run the scenario on a test account: the message arrives once, opens the saved step, and is never sent again after completion.

#### Completed template: Build the return scenario

Fill in three fields — a draft message and launch conditions will appear on the right.

- **Who:** Started verification but did not finish it within 24 hours
- **Why now:** Progress is saved — the document step can be continued
- **What to say:** Continue verification from the saved step whenever it suits you.

#### Safety and constraints: Do not create pressure

Do not promise income, use fake urgency, or push for a deposit. The message should help continue a useful journey, not force the user back at any cost.

#### Launch checklist

Send the scenario to a test group first and walk the whole path yourself, from message to result.

- [ ] The audience is described by an event and a period, not as “all inactive.”
- [ ] The reason to return actually exists in the product.
- [ ] Users who completed the action, were recently active, or got a similar push are excluded.
- [ ] The deep link opens the promised screen on iOS and Android.
- [ ] The main metric is the completed useful action, not just opening the app.

#### How to know the scenario helps

- **Return:** The share of message recipients who came back within the chosen window.
- **Useful action:** The share of returners who completed the promised journey after the tap.
- **Trust:** Notification opt-outs, complaints, and repeat messages to users who already finished do not grow.

#### Key rule

Do not optimize returns for app opens: success is a useful action after the return, with no rise in complaints and opt-outs.

---

### Build trust before a key action

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-trust/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-trust/index.md
- **Module:** Retention
- **Time:** 75 minutes for the first analysis

Before registration, verification, or a transaction, users often stop because of one specific doubt—not because the button is weak. Answer that doubt at the moment of decision.

#### Outcome

A one-doubt card with the user question, a verified answer, placement in the interface, an owner, and a validation metric.

#### Trust comes from a clear answer, not a promise

A trust moment is a short explanation next to an important action: why the data is needed, what happens after the tap, how long the process takes, and where to go if something breaks. It must be backed by how the product actually behaves.

#### What you will need

- **One screen:** Pick a step with a visible drop-off: registration, document upload, transaction confirmation, or the first deposit.
- **Live questions:** 10–20 support requests, reviews, or cancellation reasons tied to that exact step.
- **Answer verification:** A support representative and the process owner who can confirm the timing, conditions, and a safe help channel.

#### Terms in plain language

- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.

#### When to use it

Users reach an important action but postpone or cancel it, and support keeps answering the same question about conditions, data, or status.

#### Where to find the real doubt

Do not guess the user's fear from a mockup. Connect the drop in the data with the user's words and the actual rules of the process.

- **Drop-offs at the step**
  - **Source:** In the funnel, compare screen opens, taps on the primary button, successful completions, and technical errors.
  - **If access is unavailable:** Without analytics, do ten walkthroughs and ask three new users to say out loud why they are — or are not — ready to continue.
- **Support and cancellations**
  - **Source:** Group the questions: why the data is needed, is it safe, how long it takes, what the conditions are, and what to do on error.
  - **If access is unavailable:** If tags are not set up, manually review the last 20 messages about the chosen step.
- **The real process**
  - **Source:** Verify the answer with the operations team, support, and a legal specialist wherever conditions or personal data are involved.
  - **If access is unavailable:** If the team cannot back a promise, do not publish it — fix the process first or state an honest limitation.

#### Remove one main doubt

1. **Pick one critical screen.** Start with a step where the drop-off is visible and the action requires trust. Do not try to rewrite the whole journey at once.
   - **Where to do it:** The registration, verification, or key-transaction funnel.
   - **Example:** Document upload screen: 1,000 opens, 540 successful submissions, 90 technical errors.
2. **Collect the users' words.** Write down recurring questions without the team's internal phrasing. Each question should sound the way a user asks it.
   - **Where to do it:** Support requests, reviews, cancellations, and walkthrough observations.
   - **Example:** “Who will see the document?”, “How long do I wait?”, “Can I finish later?”
3. **Choose the main doubt.** Weigh frequency, impact on completion, and the risk to trust. Take one question the team can answer honestly.
   - **Where to do it:** In the first row of the doubt map.
   - **Example:** The main question: “what happens to the document after I send it?”
4. **Put the answer next to the action.** Show the timing, the next step, the conditions, or help before the tap — not in a distant help section.
   - **Where to do it:** Above the field, under the CTA, or on the confirmation screen — wherever the question arises.
   - **Example:** Under the button: “Verification usually takes up to 10 minutes. The status will appear on this screen.”
5. **Verify the promise and the effect.** Make sure the product does what the text says. After the release, compare step completion and requests about that doubt.
   - **Where to do it:** On a test account and in the report after 14 days.
   - **Example:** The status really updates, and “how long do I wait” requests dropped from 34 to 12 a week.

#### Practical examples

- **Doubt: what happens to the document:** Above the upload, the team explains the purpose of the check; next to the button — the usual time of up to 10 minutes; after submission — a visible status and a help channel. All four promises are verified against the real process.
- **Doubt: did the transaction complete?:** Instead of a generic “Processing,” the screen shows the stage, the expected time, and a safe action in case of delay. The check: step completion and the number of status requests after 14 days.

#### Finished artifact: A doubt map for one screen

Do not add a generic “You can trust us” block. Give a short, verifiable answer to a specific question at the point of decision.

| User question | Verified answer | Where to show it | Check |
| --- | --- | --- | --- |
| Why is the document needed? | To verify identity; the data is protected | Above the upload field | Agreed with the process owner |
| How long will it take? | Usually up to 10 minutes | Next to the CTA | Verified over 30 days |
| What happens next? | We show the status and send a notification | Below the button | The status really updates |
| What if an error occurs? | You can continue later or contact support | On the error screen | The channel responds |
| Are there any restrictions? | The terms are available before confirming | A link next to the action | The text is readable without searching |

First change: explain the review time and the next step right on the document upload screen. Owner — product + support. Check: step completion and status-related requests after 14 days.

#### Trust checklist

If an answer cannot be backed by the process or data, it must not be used as reassuring copy.

- [ ] One screen and one specific doubt are chosen.
- [ ] The doubt is confirmed by users' words or cancellation reasons.
- [ ] The answer contains a fact: the why, the timing, the next step, the conditions, or help.
- [ ] The text sits next to the action and can be read without opening the help section.
- [ ] The promise is verified by the process owner and tied to an outcome metric.

#### How to know the trust moment helps

- **Step completion:** Conversion of the chosen action grew without extra pressure on the user.
- **Clarity:** Requests and cancellations about the doubt the new text answers went down.
- **Promise reality:** After the release, the timing, statuses, and help channel match what is written.

#### Key rule

Do not mask anxiety with a brighter button: give an honest, verifiable answer where the user makes the decision.

---

### Analyze retention by cohort

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-cohorts/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-cohorts/index.md
- **Module:** Retention
- **Time:** 90 minutes for the first report

An overall retention rate mixes unlike users and rarely explains what to fix. Split people into comparable groups and find one difference tied to a specific experience.

#### Outcome

One cohort table, a meaningful difference between groups, a likely cause, and a change to validate in the next period.

#### A cohort is a group that started the journey together

Think of classes in the same school year: a group started using the app in the same week, so it can be compared with the neighboring week. Then, inside the group, you test one difference — platform, country, or the first useful action.

#### What you will need

- **Report:** AppMetrica, Firebase, Amplitude, or a spreadsheet with each user's first-launch date and later visits.
- **Definitions:** One shared meaning of install, registration, visit, first useful action, and FTD for the whole team.
- **Period:** At least 4–6 full weeks, so the D7 comparison does not include days that have not happened yet.

#### Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Cohort — Users sharing a date or characteristic:** Definition: Cohorts compare similar users without mixing different periods, versions, or markets. Example: Users who installed the app during the same week form a weekly cohort.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

The team sees average retention but cannot tell which group changed, after which release, and which user experience it is tied to.

#### How to build the first report

Start with first-launch weeks and one breakdown. The more segments you add at once, the easier it is to find a random difference with no clear action behind it.

- **Retention report**
  - **Source:** Build weekly cohorts by first launch and show D1, D7, and D30 only for completed periods.
  - **If access is unavailable:** In a spreadsheet, keep the first-launch date and later active days; count whether each user returned after 1, 7, and 30 days.
- **First useful action**
  - **Source:** Split one cohort into those who reached the first useful outcome in their first session and those who did not.
  - **If access is unavailable:** If there is no event, use the closest confirmed result: an item saved, a lesson finished, or successful verification.
- **Change history**
  - **Source:** Put app versions, major releases, and campaigns next to the table — they may explain differences between weeks.
  - **If access is unavailable:** If no changelog exists, rebuild the calendar from store releases and the launch dates of major communications.

#### Build a useful cohort comparison

1. **Fix the start and the return.** Choose one start event — usually first launch or registration — and one definition of an active day. Do not change definitions between groups.
   - **Where to do it:** In the report description above the table.
   - **Example:** Cohort — the week of first launch; return — any useful action, not a technical background open.
2. **Take only full weeks.** Compare only groups whose target day has already passed. You cannot evaluate D30 for users who arrived ten days ago.
   - **Where to do it:** In the report's period filter.
   - **Example:** For D7, take cohorts that completed at least eight days ago.
3. **Add one breakdown.** Pick platform, version, country, or the first useful action. A single breakdown ties the difference to a specific experience.
   - **Where to do it:** In the rows or the filter of the cohort table.
   - **Example:** Compare Android 4.2 with iOS for the same week — not platform × country × source × campaign all at once.
4. **Find a stable difference.** Check the group size and the neighboring weeks. A small gap of 20 users must not become a big product conclusion.
   - **Where to do it:** In the size, D1, and D7 columns.
   - **Example:** D7 for Android 4.2 is 8 percentage points lower three weeks in a row, with more than 500 users per group.
5. **Tie the conclusion to a check.** Write down the likely cause, an owner, and one change or investigation. A report without a next action does not help the product.
   - **Where to do it:** In the last column and the team's task.
   - **Example:** Review the new Android 4.2 onboarding screen; owner — the mobile team; due next week.

#### Practical examples

- **The drop sits in Android 4.2, not everywhere:** D7 is 8 percentage points lower three weeks in a row, with more than 500 users per group; iOS for the same weeks is stable. The decision: review the onboarding changes in 4.2 rather than message everyone.
- **The first useful outcome explains the gap:** Users who got a useful result in their first session show a D7 of 28%; the rest — 5%. The team makes the path to the result more visible and checks the next weekly cohort.

#### Finished artifact: One table — one conclusion

Compare four groups on one attribute first. Do not turn the first report into dozens of filters.

| Cohort / segment | Size | D1 | D7 | Conclusion and action |
| --- | --- | --- | --- | --- |
| Week of June 3–9 · all | 2,400 | 32% | 14% | Baseline |
| Reached the first useful outcome | 1,080 | 51% | 28% | Make the path more visible |
| Did not reach the value | 1,320 | 17% | 5% | Check onboarding |
| Android · version 4.2 | 620 | 24% | 8% | Check release 4.2 |
| iOS · same week | 710 | 35% | 16% | No platform-wide drop |

Conclusion: the problem is concentrated in Android 4.2 and among users without the first useful outcome. The first action is to check that version's onboarding changes — not to send a blast to everyone.

#### Report checklist

Before drawing a conclusion, make sure you compare comparable groups and completed periods.

- [ ] The cohort start and the active day are defined the same way for every row.
- [ ] D1, D7, and D30 are calculated only for completed periods.
- [ ] Every group has a size, and only one main breakdown is used.
- [ ] App versions, releases, and major campaigns are noted alongside.
- [ ] The conclusion ends with one action, an owner, and a check date.

#### How to know the analysis is useful

- **Segment clarity:** The team can name the specific group and the difference, not just the overall retention rate.
- **Repeatability:** The difference shows on a sufficient size and does not vanish when checking neighboring weeks.
- **Decision:** One action is taken, and the next cohort will show whether the chosen journey changed.

#### Key rule

Do not look for the average user: find a specific group, a clear barrier, and one decision the next cohort can test.

---

### Create useful reasons to return

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-content/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-content/index.md
- **Module:** Retention
- **Time:** 90 minutes for the first calendar

Content drives retention when it connects to a user's interest or action—not simply because more items are published. Decide who needs a reason to return and why before choosing the channel.

#### Outcome

A one-week calendar of five return moments with audience, value, destination screen, frequency limit, and action metric.

#### A reason is a useful change for a specific user

A new article is not, by itself, a reason to message everyone. A reason appears when the material matches a saved interest, helps continue a journey, or explains a real change. The user should understand the benefit before opening the message.

#### What you will need

- **Interest signal:** A save, a subscription, a topic view, an unfinished lesson, or another confirmed sign of user interest.
- **Content owner:** An editor, communications specialist, or product manager who checks accuracy, freshness, and the destination screen.
- **Frequency rules:** A shared message limit and exclusions for recently active users or those who already got a similar reason.

#### Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.

#### When to use it

The app sends generic reminders, content is planned separately from user behavior, and there are opens — but useful actions after them do not grow.

#### Where to find useful reasons

Do not start from the holiday calendar. Look for the link between a real change, a user's interest, and an available action in the product.

- **Saves and views**
  - **Source:** See which topics, items, or lessons people save, reread, and finish.
  - **If access is unavailable:** Without events, use search queries, the most visited pages, and a manual list of common interests.
- **Support and search**
  - **Source:** Collect recurring questions and searches with no results — they show which explanation or material is missing.
  - **If access is unavailable:** Once a week, note the five most frequent support questions in a shared table.
- **Product changes**
  - **Source:** Add an updated status, new material, or a feature only if it is relevant to the chosen segment right now.
  - **If access is unavailable:** If personalization is not available, publish the reason in the right section instead of a mass notification.

#### Build a calendar of useful return reasons

1. **Collect real changes.** Write down the statuses, new materials, updates, and unfinished actions that will actually be available next week.
   - **Where to do it:** In the first column of the calendar, with the relevance date.
   - **Example:** A new analysis appeared in a saved topic; a lesson got a follow-up; an application status changed.
2. **Tie the reason to an interest.** Name the confirmed action that puts a user in the audience. Do not stretch the “all users” segment.
   - **Where to do it:** In the message's audience condition.
   - **Example:** Saved the topic or read it twice in 30 days, but has not seen the new material yet.
3. **State one benefit.** Say what the user can learn, continue, compare, or check. The benefit must be clear before the open.
   - **Where to do it:** In the title and the first line of the message.
   - **Example:** “A new analysis appeared in your saved collection” instead of “Don't miss our updates.”
4. **Prepare an exact route.** After the tap, open the material, the saved step, or the right collection. The home screen destroys the context of the reason.
   - **Where to do it:** In the deep link and a test account.
   - **Example:** The message about the analysis opens that analysis inside the saved topic.
5. **Cap competing messages.** Set the frequency and priorities. One user should not get three messages from different teams in one evening.
   - **Where to do it:** In the communications system and the last column of the calendar.
   - **Example:** At most two useful messages a week; service statuses outrank content collections.

#### Practical examples

- **A saved topic update:** The message goes only to those who read or saved the topic within 30 days. It names the new analysis and opens it inside the personal collection — once per event.
- **A weekly digest without overload:** The digest bundles changes only around the user's confirmed interests and skips those who already saw the materials. The shared cap is two useful messages a week.

#### Finished artifact: A one-week calendar of return reasons

Each row answers five questions: who it is for, what changed, what the benefit is, where it leads, and how the frequency is capped.

| Reason and audience | Benefit | Destination | Limit |
| --- | --- | --- | --- |
| A saved topic updated | See the new analysis | Deep link to the collection | Once per event |
| Unfinished lesson | Continue from step 3 | Saved progress | After 48 hours |
| Answer to a frequent question | Understand the condition before acting | Help article | Interested users only |
| Weekly digest | Collect changes by interest | Personal feed | At most once a week |
| New feature | Solve a familiar task faster | Feature screen | Matching segment only |

Before publishing, delete a row if the team cannot name the personal benefit or open the promised screen. Five strong reasons beat twenty generic messages.

#### Reason checklist

Remove a reason from the calendar if even one required item cannot be verified before the send.

- [ ] There is a confirmed interest or an unfinished user action.
- [ ] The benefit is clear before the open and actually available in the product.
- [ ] The deep link leads to the promised material or the saved step.
- [ ] Recently active users and those who already saw the content are excluded.
- [ ] A shared frequency cap and one main action metric are set.

#### How to know the reason is useful

- **Reached the content:** Users opened exactly the promised material or the saved journey.
- **Completed a useful action:** The material was finished, an item saved, a lesson continued, or a status viewed.
- **Kept the trust:** Notification opt-outs, complaints, and ignored follow-up messages did not grow.

#### Key rule

An event becomes a reason only when it is useful to a specific user and leads to a real action.

---

### Run a regular product review

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-review/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-review/index.md
- **Module:** Retention
- **Time:** 60 minutes for the first review

A product review is not a meeting for presenting every number. The team connects changes to outcomes and chooses no more than three next decisions.

#### Outcome

A one-page review record with product health, three changes from the period, one key conclusion, and up to three owned decisions.

#### The meeting exists to shrink the task list

In a single period the team may ship a release, change onboarding, and launch messages. The review answers: what happened to the user experience, which change could have caused it, and what we check next. The outcome is decisions, not a stack of slides.

#### What you will need

- **Participants:** The product manager, an analyst or data owner, a technical representative, support, and a communications specialist.
- **One screen:** 5–7 indicators for quality, the first useful journey, retention, support requests, and communications over time.
- **Rhythm:** Weekly for a fast-changing product or monthly for a stable one; the same comparison period every time.

#### Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

The team ships changes but never returns to their effect; meetings become a numbers report, and the task list only grows.

#### What to prepare before the meeting

Do not collect dozens of dashboards. Bring only the data, changes, and live signals needed for this period's decisions.

- **Health screen**
  - **Source:** Show the crash-free rate, first-journey conversion, FTD, D1/D7, support requests, and message response next to the previous period.
  - **If access is unavailable:** Without a single dashboard, collect seven numbers in a table and note the source, period, and owner of each.
- **Changelog**
  - **Source:** Write down the period's three main releases, experiments, or communications with dates and the expected effect.
  - **If access is unavailable:** If no log was kept, reconstruct the changes from tasks, store versions, and the send calendar.
- **Live signals**
  - **Source:** Add three recurring support or review themes and one concrete example of a user journey.
  - **If access is unavailable:** Ask support to pick five representative requests in advance instead of the general impression that “complaints are up.”

#### Run a product review in 60 minutes

1. **Show the product's health.** Start with 5–7 indicators over time and flag only meaningful changes. Do not discuss every number in turn.
   - **Where to do it:** On one screen with the period, sources, and previous values.
   - **Example:** Crash-free 99.6%, unchanged; first useful outcome +8 p.p.; D7 unchanged; status questions +40%.
2. **Put the changes next to the signals.** Name the three main releases or communications with dates and the expected effect. Do not assign causality without a check.
   - **Where to do it:** In the second column of the record.
   - **Example:** June 3 — onboarding shortened; June 7 — new status screen shipped; June 10 — push route changed.
3. **Add the user's voice.** Show recurring questions and one typical journey. A qualitative signal helps explain what hides behind the metric.
   - **Where to do it:** Next to the matching indicator.
   - **Example:** 12 users ask whether their transaction went through, although there is no technical error.
4. **Choose one main conclusion.** State the problem or opportunity in one sentence. Do not blend quality, retention, and growth into one vague theme.
   - **Where to do it:** In a visible block before the decisions.
   - **Example:** The new screen works technically but does not explain the status — that creates requests and mistrust.
5. **Cap the decisions at three.** Each decision needs an owner, a deadline, and a signal to check at the next review. Explicitly set the other ideas aside.
   - **Where to do it:** In the last column of the record and the task list.
   - **Example:** Add the status — Anna — June 21 — requests on the theme and action completion.

#### Practical examples

- **A signal becomes a decision:** After the new screen the technical indicators are stable, but status questions grew 40%. The conclusion — the process is unclear; the decision — add the status, an owner, and a request check.
- **Three decisions instead of twenty ideas:** The team fixes the push route, explains the transaction status, and checks the next cohort. The remaining ideas are explicitly parked until the next review.

#### Finished artifact: Product review record

Do not transcribe the whole discussion. Record the signal, its link to a change, and a decision that can be checked.

| Signal | What changed | Conclusion | Decision and owner |
| --- | --- | --- | --- |
| Crash-free stable | Release 4.3 | No technical regression | Observe · mobile team |
| First useful outcome +8 p.p. | Shorter onboarding | The change helps | Extend to Android · product |
| D7 flat | New journey live for 2 weeks | The effect has not arrived yet | Check the next cohort · analyst |
| Status questions +40% | New transaction screen | An explanation is missing | Add the status · design + support |
| Pushes opened, action flat | Generic deep link | Context is lost | Fix the route · communications |

Focus of the period: explain the transaction status. No more than three decisions: fix the route, update the status copy, check the next cohort. Everything else stays out of the plan until the next review.

#### Meeting checklist

Do not start the meeting until the data and changes are collected: the group's time should go to decisions.

- [ ] One screen shows 5–7 indicators with trends and a single period.
- [ ] The period's three main changes and their expected effect are named.
- [ ] Support brought recurring themes and concrete examples.
- [ ] One main conclusion is stated without unconfirmed causality.
- [ ] No more than three decisions are made, each with an owner, deadline, and check metric.

#### How to know the review works

- **Decisions completed:** The next meeting starts from the previous agreements and their actual results.
- **Focus kept:** No more than three agreed actions are in progress, and new ideas do not displace them without cause.
- **Experience improves:** The chosen quality, retention, or trust signals move after the decisions are done.

#### Key rule

A good product review shrinks the task list and leaves the team with a few decisions whose effect can be checked.

---

## Push notifications

### Bring users back to a valuable action

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-trigger/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-trigger/index.md
- **Module:** Push notifications
- **Time:** 60 minutes for the first scenario

A good push starts with an event, not with copy: a specific user now has a reason to return. Design one scenario from the send condition through the useful action after the tap.

#### Outcome

A specification for one push trigger: audience, event, delay, exclusions, copy, deep link, and outcome metric.

#### A trigger answers the question “why now?”

A push trigger is a send rule tied to a specific event. For example: the user saved a topic, new material appeared in it, and the message leads straight to it. “We haven't seen you in a while” describes the team's interest, not the user's benefit.

#### What you will need

- **Event:** A confirmed action or change: a save, an unfinished step, a new result, or an update to a personal interest.
- **Tool:** Firebase, OneSignal, Mindbox, or another system where you can set the audience, delay, and exclusions.
- **Route:** A working deep link to the right screen and a target analytics event after the tap.

#### Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to send a push

Trigger the message only when the user has a clear reason to return right now.

- **An unfinished action:** The user started a useful journey and did not reach the result, but the progress was actually saved. Example: “Continue from the document step — your previous data is saved.”
- **New value is available:** Content, a status, or a feature tied to the user's confirmed interest has been released. Example: “A new short analysis appeared in your saved topic.”
- **Personal progress:** The user can see a result or continue toward their goal without searching again. Example: “The verification result is ready — open the status and the next step.”

#### What to check before setup

First make sure the event is reliable, the audience refreshes, and the destination screen works. Pretty copy will not fix a bad trigger.

- **Product events**
  - **Source:** Check when the action's start and completion events arrive and whether users who already got the result can be excluded.
  - **If access is unavailable:** Without events, start with one reliable server-side status and a test group of employees.
- **Send history**
  - **Source:** See which other messages a user might receive around the same time and set a shared cap.
  - **If access is unavailable:** If there is no shared log, collect a one-week calendar of active sends from every team.
- **Deep link and analytics**
  - **Source:** On iOS and Android, walk from a closed app to the promised screen and the useful action.
  - **If access is unavailable:** If the direct route is not ready, do not launch a mass push — use an in-app message on the relevant screen first.

#### Build the first trigger in five steps

1. **Choose a useful action.** Name the result of the return. “Open the app” does not count — viewing a status, continuing a step, or reading material does.
   - **Where to do it:** In the “Success” row of the specification and the analytics event.
   - **Example:** The user read the new analysis at least halfway after tapping the push.
2. **Define the audience by an event.** Set the action and the period that put a user into the scenario. Do not start with the broad “inactive” group.
   - **Where to do it:** In the CRM segment builder.
   - **Example:** Saved a topic in the last 30 days and has not opened the new analysis yet.
3. **Set the moment and the exclusions.** Define the delay after the event and who the message is no longer relevant for. Exclusions are checked before every send.
   - **Where to do it:** In the trigger logic and frequency rules.
   - **Example:** Send after 30 minutes; exclude those who already read it, are active right now, or got a push in the last 24 hours.
4. **Write the benefit and one CTA.** Say what changed and what the user can do. Remove generic calls, pressure, and unverified urgency.
   - **Where to do it:** In the notification title and body.
   - **Example:** “A new analysis appeared in your saved topic. Open the material” instead of “Come back now!”
5. **Check the route to the result.** The push must open the right screen after sign-in and from a closed app. Record the target-action event.
   - **Where to do it:** On test iOS and Android devices.
   - **Example:** The tap opens the new analysis, and at 50% read the content_half_read event fires.

#### Practical examples

- **The matching profile gets it; the excluded one does not:** The user saved the topic and has not read the new analysis — the push arrives once. Those who already read it or received another message today are excluded before the send.
- **The route ends with an action:** The push “A new analysis appeared in your saved topic” opens the material itself. Success is reading at least 50% — not just opening the app.

#### Finished artifact: First push-trigger specification

One card is enough for product, CRM, development, and analytics to read the scenario the same way.

| Field | Decision | How to check |
| --- | --- | --- |
| Audience | Saved a topic in the last 30 days | The segment refreshes daily |
| Trigger | A new analysis appeared in the topic | The event fires once |
| Delay | 30 minutes after publication | The content is already live |
| Exclusions | Already read it or got a push today | Test profiles are excluded |
| Destination | Deep link to the new analysis | The screen opens on iOS/Android |
| Success | The analysis is read to 50% | The event is visible after the tap |

Before launch, check three test profiles: the matching one gets the push, the excluded one does not, and the one who already read it gets no repeat.

#### Completed template: Draft the message

Fill in the card — a working draft of the first push will appear on the right.

- **Who:** Saved a topic in the last 30 days and has not seen the new analysis yet
- **What changed:** New material appeared in the saved topic
- **Push copy:** A new short analysis appeared in your saved topic. Open it whenever it suits you.

#### Safety and constraints: Do not pressure the user

Do not promise income, create fake urgency, or use push as direct pressure to deposit. Trust and timing matter more than a one-off tap.

#### Pre-launch checklist

Run the scenario on three test profiles first, then on a small real group.

- [ ] The user has a confirmed reason to return right now.
- [ ] The audience, delay, and exclusions are described by events and periods.
- [ ] The copy names a real benefit, without income promises or fake urgency.
- [ ] The deep link opens the promised screen on iOS and Android.
- [ ] The main metric is the useful action after the tap, not just the open.

#### How to know the trigger helps

- **Technical quality:** The event fires once, the exclusions work, and the deep link opens the right screen.
- **Useful action:** Push recipients complete the promised journey more often than a comparable group without the message.
- **Trust:** Notification opt-outs, complaints, and repeat messages to users who already finished do not grow.

#### Key rule

A good first trigger is one truthful reason, a precise route, and a useful action after the tap.

---

### Set frequency limits instead of increasing volume

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-frequency/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-frequency/index.md
- **Module:** Push notifications
- **Time:** 75 minutes for the first setup

Users experience every message as one stream, even when different teams send them. Build a shared calendar and rules that prevent repetition and competing pushes.

#### Outcome

A one-page frequency policy with message types, priorities, a shared limit, cooldowns, exceptions, and an owner.

#### The user has one attention budget for all teams

Communications, product, and support may each find their messages useful, but the user receives them all in one feed. A frequency policy decides how many messages are allowed, which matter more, and when the next push must be canceled.

#### What you will need

- **Shared list:** Every service, product, and content message one user can receive in seven days.
- **History:** A send log for test profiles or a sample of real users, with the date, scenario, and result.
- **Owner:** One person who resolves conflicts between teams and regularly reviews opt-outs and complaints.

#### Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.

#### When to use it

Users get several messages a day, teams launch campaigns independently, and notification opt-outs or complaints keep growing.

#### Where to see the real load

Do not count only planned campaigns. Include automatic triggers and service statuses fired by events.

- **Send calendar**
  - **Source:** Collect manual campaigns and automated scenarios from every team into one weekly table.
  - **If access is unavailable:** If there is no shared tool, ask each owner to export the name, audience, moment, and maximum number of sends.
- **User history**
  - **Source:** Find the profiles that receive the most messages and reconstruct their feed hour by hour.
  - **If access is unavailable:** Create three test profiles that match several scenarios at once and watch them for a week.
- **Negative signals**
  - **Source:** Put notification opt-outs, complaints, uninstalls, and support requests next to the number of pushes per user.
  - **If access is unavailable:** If there is no direct link, compare high-load and normal weeks, and add an event for the notification permission being turned off.

#### Set up a safe frequency

1. **Collect every scenario.** Record manual campaigns, automatic triggers, and service statuses. For each, note the maximum frequency per user.
   - **Where to do it:** In the shared communications calendar.
   - **Example:** Verification — up to 2 reminders; new material — 2 a week; the weekly digest — 1 a week.
2. **Rank by user value.** Service statuses and security outrank content reasons. An internal business goal must not raise priority automatically.
   - **Where to do it:** In the policy's priority column.
   - **Example:** The transaction status goes out, and the general digest that day is canceled.
3. **Set a shared cap.** Limit the total number of optional messages and the minimum pause between them. The cap applies on top of each team's own rules.
   - **Where to do it:** In the communication platform settings.
   - **Example:** At most one optional push per 24 hours and three per seven days.
4. **Add mutual exclusions.** After a useful action, a recent visit, or a similar message, the user must leave competing scenarios.
   - **Where to do it:** In the segment conditions before the send.
   - **Example:** Finished the lesson → drop the reminder; got a personal analysis → drop the general digest for 24 hours.
5. **Review the most loaded profiles.** Once a week, look beyond the average at the users with the most messages. That is where the rules clash most often.
   - **Where to do it:** In the messages-per-user report.
   - **Example:** The average is 1.8 pushes, but 4% of users got 7+; an overlap of two triggers was found.

#### Practical examples

- **A service status cancels general content:** The user received an important transaction status. The general digest that day is canceled, and the next optional push is possible only after 24 hours.
- **The average hid an overloaded group:** The average load was 1.8 pushes a week, but 4% of users were getting 7+. After mutual exclusions the shared cap holds and repeat complaints decline.

#### Finished artifact: One-page frequency policy

The rules must be applied before every send — not sit in a document as a recommendation.

| Type | Priority | Limit | Pause and exceptions |
| --- | --- | --- | --- |
| Security and status | 1 · mandatory | Per event | Not blocked by the promo cap |
| Unfinished action | 2 · useful | 1 per scenario | Canceled after completion |
| Personal interest | 3 · useful | Up to 2 a week | 24-hour pause after another push |
| General content | 4 · optional | 1 a week | Not sent to recently active users |
| All optional together | Shared cap | At most 3 a week | At most 1 per 24 hours |

When messages conflict, the one with the higher user value survives. Once a week the rules owner reviews the ten most loaded profiles and the negative signals.

#### Safety and constraints: Do not compensate for a weak scenario with frequency

If a message gives no reason to return, sending it again will not make it more useful. Fix the reason, the copy, or the route first.

#### Frequency checklist

The policy is ready only when the rules can be tested on a specific user profile.

- [ ] One list holds the manual, triggered, and service messages of every team.
- [ ] Messages are prioritized by their value to the user.
- [ ] There is a shared cap and a minimum pause between optional pushes.
- [ ] Users who finished the action, were recently active, or got a similar message are excluded.
- [ ] An owner is assigned for the weekly review of load, opt-outs, and complaints.

#### How to know the frequency became safer

- **Load:** The share of users receiving more than the shared cap per day and week is falling.
- **Trust:** Notification opt-outs and complaints do not grow while useful scenarios keep running.
- **Value:** Target actions per message hold or grow after competing sends are removed.

#### Key rule

When two scenarios collide, send the one with the higher value for the user — not the higher internal business goal.

---

### Lead with value, not pressure

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-value/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-value/index.md
- **Module:** Push notifications
- **Time:** 75 minutes for the revision

A useful push answers three questions honestly: what changed, why it matters to me, and what I can do after tapping. Urgency without evidence and promises without a destination erode trust.

#### Outcome

A review table for five messages covering the original problem, verifiable value, improved copy, and matching destination screen.

#### Fact first, then the benefit and one next step

“Hurry, act now” creates pressure but explains no value. It is better to name the real change — a status is ready, material appeared, progress is saved — and offer one action the user will see after the tap.

#### What you will need

- **Active copy:** An export of recurring and triggered pushes with the audience, send condition, and frequency.
- **Destination screens:** Links or test deep links to verify every promise after the tap.
- **Reviewer:** The product or content owner plus a support representative to check facts, conditions, and clarity.

#### Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.

#### When to use it

The messages are full of generic calls, fear of missing out, deposit pressure, or promises the destination screen does not confirm.

#### How to verify a promise

Do not judge the copy separately from the event and the screen. A message is useful only when the fact is true and the promised result is reachable.

- **Campaign history**
  - **Source:** Take the five most frequent or widest-reach messages and add the send condition, the audience, and the result after the tap.
  - **If access is unavailable:** If there is no export, collect the texts from the team calendar and test notifications on a device.
- **The screen after the tap**
  - **Source:** Walk every deep link and compare the push title with what is actually visible on the first screen.
  - **If access is unavailable:** Without a direct link, write down the manual route and do not promise an action the user cannot reach quickly.
- **Complaints and opt-outs**
  - **Source:** Find the wording that was followed by more opt-outs, complaints, or “what is this message about?” questions.
  - **If access is unavailable:** Show the texts to five colleagues outside the team and ask them to predict the expected screen and action.

#### Rewrite the messages around real value

1. **Collect five active messages.** Start with the widest-reach, most frequent, or most complained-about messages. Add the audience, the trigger, and the destination screen.
   - **Where to do it:** In the communications audit table.
   - **Example:** “Come back now!” — inactive for 7 days — sent daily — home screen.
2. **Name the actual change.** For each push, state what really happened in the data or the product. If nothing changed, there may be no useful reason at all.
   - **Where to do it:** In the “Fact / trigger” column.
   - **Example:** The verification result is ready; material appeared in a saved topic; the application status updated.
3. **State the personal benefit.** Explain what the user can learn, continue, or check. Do not promise income, guaranteed results, or artificial urgency.
   - **Where to do it:** In the title and the first line of the new copy.
   - **Example:** “Your verification result is ready — open the status and the next step.”
4. **Keep one clear CTA.** The message must lead to one action. Several promises and calls blur the choice and mask weak value.
   - **Where to do it:** At the end of the copy and on the destination screen.
   - **Example:** One CTA — “Open the result,” not “Open, explore, and top up.”
5. **Check the copy against the first screen.** After the tap, the user must immediately see what was promised. Test the route from a closed app and after sign-in.
   - **Where to do it:** On test iOS and Android devices.
   - **Example:** The push about the result opens the verification status, not the home feed.

#### Practical examples

- **Before: urgency without a reason:** “Come back now!” led to the home page. After the revision: “Your verification result is ready — open the status and the next step,” with a deep link straight to the result.
- **Before: a promise without the product:** “Don't miss your chance” was replaced with a verifiable fact about new material in a saved topic. If the material is not live yet, the push is not sent.

#### Finished artifact: The “before → after → screen” table

Rewrite five real messages first. Each new wording must be backed by an event and a screen.

| Original copy | Problem | New copy | What opens |
| --- | --- | --- | --- |
| Come back now! | No reason, just pressure | Your verification result is ready | Result screen |
| Don't miss your chance | Unverifiable promise | A new analysis in your saved topic | The new material |
| Top up now | Deposit pressure | Available payment methods changed | Conditions and methods |
| We have an update | No named benefit | You can now continue from the saved step | Saved progress |
| Open the app | No action | Check your updated application status | Status screen |

Red flag: if the screen after the tap does not show what was promised, the copy cannot be “improved” on its own — fix the route or the product result first.

#### Safety and constraints: Write like a product, not an ad

The message should help the user decide, not push them to act at any cost. An unkept promise cannot be fixed with louder wording.

#### Copy checklist

The message is ready when someone unfamiliar with the task can predict the first screen after the tap.

- [ ] A real change that has already happened is named.
- [ ] It is clear why the message applies to this specific user.
- [ ] There is one verifiable benefit and one next step.
- [ ] There are no income promises, deposit pressure, or unverified urgency.
- [ ] The first screen after the deep link confirms the push copy.

#### How to know the copy became more useful

- **Understanding:** After the open, fewer users bounce to the home screen and more reach the promised screen.
- **Action:** Completion of the specific useful action grows — not just the open rate.
- **Trust:** Notification opt-outs, complaints, and negative reviews about pushiness do not grow.

#### Key rule

If you cannot show the value on the first screen after the tap, do not promise it in the push.

---

### Segment scenarios, not just your user base

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-segments/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-segments/index.md
- **Module:** Push notifications
- **Time:** 90 minutes for the first segments

A segment is useful only when it changes a decision: who to message, why now, what to say, or where to send them. Start with three behavioral groups, not dozens of demographic filters.

#### Outcome

A three-segment matrix with precise entry and exit rules, distinct value, message, route, and exclusions.

#### A segment is not a label but a rule for a different scenario

“New,” “active,” and “inactive” are too generic until actions and time windows are attached. A good segment is testable: started the journey within 24 hours, saved a topic within 30 days, completed the action and must no longer get the reminder.

#### What you will need

- **Events:** The date of the last useful action, journey start and completion, a confirmed interest, and notification permission.
- **Segment builder:** A communication system that shows group size and lets you set entry, exit, and mutual-exclusion rules.
- **Test profiles:** At least one profile per segment, plus one for the overlap, to check the rules before launch.

#### Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.

#### When to use it

Mass pushes produce few useful actions, people get irrelevant messages, and the team cannot explain why a given user received one.

#### Which data to use

Take only data that actually changes the message's value or route. Do not collect sensitive attributes without need.

- **Product behavior**
  - **Source:** Use journey completion, how recent the last useful action is, saved interests, and results already viewed.
  - **If access is unavailable:** Without full analytics, start with one reliable server-side status and the last activity date.
- **Size and overlaps**
  - **Source:** Before launch, check the number of users in each group and how many fall into two scenarios at once.
  - **If access is unavailable:** Export the IDs of three simple groups into a table and look for duplicates.
- **Language and availability**
  - **Source:** Check language and country only when the scenario really differs, plus the permission for the channel.
  - **If access is unavailable:** If localization is not ready, limit the launch to one supported audience instead of auto-translating.

#### Build the first segments

1. **Start from behavior.** Describe an action and a time window that show the user's current context. Avoid abstract labels like “loyal” or “dormant.”
   - **Where to do it:** In the communication system's segment conditions.
   - **Example:** Started verification in the last 24 hours and has not finished it yet.
2. **Choose three different scenarios.** Take groups whose return reason and screen actually differ. Do not split the base just to personalize the greeting.
   - **Where to do it:** In the first three rows of the matrix.
   - **Example:** An unfinished journey, an active user with a saved interest, and a long-inactive user with a new relevant reason.
3. **Define entry and exit.** The segment must refresh automatically. After completing the action or losing relevance, the user leaves before the next send.
   - **Where to do it:** In the recalculation rules before launch.
   - **Example:** The completion event removes the user from the reminder immediately.
4. **Give each group its own route.** The difference must go beyond the name. Set a distinct value, copy, and deep link into the right context.
   - **Where to do it:** On each scenario's card.
   - **Example:** The new user continues the journey, the active one opens new material, the inactive one sees only a real change.
5. **Resolve the overlaps.** Decide in advance which message survives when a user matches several rules. Check the overlap on a test profile.
   - **Where to do it:** In the priorities and mutual exclusions.
   - **Example:** A service status outranks a content reason; the second message is held for 24 hours.

#### Practical examples

- **Three groups — three different routes:** The unfinished user continues the saved step, the active one opens new material for their interest, and the long-inactive one hears only about a real update.
- **The overlap is resolved before the send:** The user matches both a service status and a content reason. The more important status survives; the second message is held for 24 hours.

#### Finished artifact: A matrix of three segments

If two rows lead to the same copy and screen, merge them — a separate segment is not needed.

| Segment | Condition | Value and route | Exit / exclusion |
| --- | --- | --- | --- |
| New, journey unfinished | Started the journey <24 h ago, no completion event | Continue the step → saved screen | Exits after completion |
| Active with an interest | Saved a topic <30 days ago | New material → collection | Exclude those who already read it |
| Long inactive | No useful actions for 14 days | A real update only → the change screen | No messages without a new reason |
| Recently active | Useful action <12 h ago | No message needed | Excluded from return pushes |
| Overlap | Matches 2 scenarios | Keep the more useful one | One push, by priority |

Start with three scenarios and one overlap rule. Add a new group only when its moment, value, or screen genuinely differs.

#### Safety and constraints: Do not build segments for their own sake

If a group does not change the moment, the value, or the route, it only complicates the work and multiplies rule errors.

#### Segment checklist

Anyone on the team should be able to explain from the data — not by guessing — why a specific user is in the segment.

- [ ] Entry and exit conditions are described with events and time windows.
- [ ] The segment changes the moment, the value, the copy, or the destination screen.
- [ ] Group sizes are known and the source data is quality-checked.
- [ ] Language, channel availability, and only the necessary attributes are used.
- [ ] Overlapping segments have a priority and one final message.

#### How to know segmentation helps

- **Accuracy:** Test and real profiles land in the expected group and leave it once the action is complete.
- **Value:** The target action after the tap grows in the specific segment compared with the generic message.
- **Risks:** Overlaps, repeat messages, opt-outs, and complaints inside individual groups do not grow.

#### Key rule

Start with three segments and add a new one only when it truly needs a different scenario.

---

### Measure impact after the tap

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-measure/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-measure/index.md
- **Module:** Push notifications
- **Time:** 90 minutes for the first report

An open shows that the copy attracted attention; it does not prove value. Connect the send to the destination screen and target action, then add a comparison and negative signals.

#### Outcome

A report for one scenario covering sends, deliveries, opens, useful actions, a no-push comparison group, and trust impact.

#### A tap is the middle of the journey, not the result

A push can collect many opens with loud copy while people do nothing after the tap or turn notifications off. The report must show the whole chain and answer one question: did the useful action start happening more often because of the message?

#### What you will need

- **Event chain:** Send, delivery, open, the destination screen, and one confirmed useful action.
- **Comparison:** A small random group without the message, or at least a comparable period before launch.
- **Negative signals:** Notification opt-outs, complaints, uninstalls, and repeat opens without the target action.

#### Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Open rate — The share of delivered messages that were opened:** Definition: Shows how many users tapped a delivered message. Open rate alone does not show whether they completed a useful action after the tap. Example: 200 of 1,000 delivered push messages were opened: open rate is 20%.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.

#### When to use it

The team reports delivery and open rate but does not know whether users completed the promised action — or whether it would have happened without the message.

#### Where to assemble the chain

The send platform and product analytics must join by scenario and user. If the join is incomplete, state that as a limitation.

- **Send platform**
  - **Source:** Take the number of eligible users, sends, deliveries, and opens for one campaign ID.
  - **If access is unavailable:** Without an automatic export, export the campaign summary and record the exact send window.
- **Product analytics**
  - **Source:** Count destination-screen opens and the target action within a pre-chosen window after the push.
  - **If access is unavailable:** If the events are not joined, add campaign_id to the deep link and the screen event before the next launch.
- **Trust and control**
  - **Source:** Put opt-outs alongside, plus the results of the group that matched the scenario but randomly received no message.
  - **If access is unavailable:** Without a control group, compare with a similar week and state plainly that causal conclusions are limited.

#### Set up measurement for one scenario

1. **Name one useful action.** Before launch, define the post-tap result and the measurement window. Do not use a generic “app visit.”
   - **Where to do it:** In the scenario specification and the report title.
   - **Example:** Read at least half of the new analysis within 24 hours of delivery.
2. **Join the events into one chain.** Use a single campaign_id and trace the journey from the send platform to the screen and the action in product analytics.
   - **Where to do it:** In the push parameters, the deep link, and the app events.
   - **Example:** Send → delivery → open → screen view → half the material read, all with campaign_id=topic_update_01.
3. **Add a comparable group.** Randomly hold back a small share of the eligible audience. It shows the baseline level of the action.
   - **Where to do it:** In the launch settings and a separate row of the report.
   - **Example:** 10% of the audience gets no push; the action: 3.2% versus 4.9% among recipients.
4. **Put negative signals alongside.** Watch opt-outs and complaints in the same window. A lift in the action does not count as a win if the scenario visibly erodes trust.
   - **Where to do it:** In the last rows of the report.
   - **Example:** Opt-outs at 1% against the usual 0.3% — the scenario needs rework despite the lift.
5. **Make one of three decisions.** Keep, change, or switch off the scenario. Record the reason and the date of the next check.
   - **Where to do it:** In the report conclusion and the communications log.
   - **Example:** Keep the audience, cut the frequency to a single send, and repeat the comparison in two weeks.

#### Practical examples

- **Open rate 20%, action 4.9%:** Of 8,600 delivered pushes, 1,720 were opened, but 420 completed the useful action. The control group came in at 3.2% — there is an incremental effect, but far smaller than the open rate.
- **The lift in actions did not cover the opt-outs:** The target action grew, but opt-outs hit 1% against the usual 0.3%. The decision — reduce the frequency and repeat the test rather than scale right away.

#### Finished artifact: Funnel of one push scenario

The numbers must belong to one audience, one window, and one scenario. Show the comparison next to them, not only the absolute result.

| Step | Users | Conversion | What it means |
| --- | --- | --- | --- |
| Matched the scenario | 10,000 | — | Eligible audience |
| Received the push | 8,600 | 86% | Check permissions and tokens |
| Opened the message | 1,720 | 20% | The copy caught attention |
| Opened the target screen | 1,410 | 82% | The deep link mostly works |
| Completed the action | 420 | 30% | Final conversion: 4.9% of deliveries |
| Turned notifications off | 86 | 1% | Compare with the usual level |

Control group without the push: 3.2% completed the useful action. The +1.7 percentage point difference makes the scenario a candidate to continue — if opt-outs stayed within the usual range.

#### Safety and constraints: Do not optimize for taps alone

Loud copy can collect curiosity opens while eroding trust. Judge the scenario by the whole chain and the negative signals.

#### Report checklist

Every metric must belong to the same scenario, audience, and measurement window.

- [ ] The push has one target action and a pre-defined window.
- [ ] Send, open, screen, and action are joined by a single campaign ID.
- [ ] There is a comparable group without the message, or the comparison limitation is stated plainly.
- [ ] Opt-outs and complaints are shown next to the useful action.
- [ ] The report ends with a decision: keep, change, or switch off the scenario.

#### Which conclusions the team needs

- **Technical funnel:** Delivery, opens, and arrival on the right screen show where the route breaks.
- **Incremental effect:** The difference in the target action between push recipients and a comparable group without the message.
- **Trust:** Opt-outs, complaints, and later retention do not degrade beyond the acceptable level.

#### Key rule

A good report lets you switch off useless pushes as confidently as you scale the genuinely useful ones.

---

## ASO & SEO

### Build a keyword map from real demand

- **Canonical URL:** https://playbook.affpartners.io/en/practices/discoverability-keywords/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/discoverability-keywords/index.md
- **Module:** ASO & SEO
- **Time:** 2 hours for the first map

Keyword research is not a list of words to repeat in a description. It maps the questions people ask in their own language to an honest product answer for each search intent.

#### Outcome

A table of 20–30 queries with search intent, evidence of demand, product fit, priority, and one target page.

#### Look for the task behind the query, not the words

The query “how to check status” means someone needs a clear way to see a result. “Best app” is too generic and rarely tells you what to show. Define the intent first, then choose the real screen or answer page.

#### What you will need

- **Capability list:** The current features, limitations, countries, languages, and useful journeys the product actually supports.
- **User language:** Reviews, support requests, internal search, and the real wording of questions without editorial polish.
- **Answer locations:** A store page, help section, article, or landing page that can be assigned to each priority intent.

#### Terms in plain language

- **Search semantics — A map of search queries and the needs behind them:** Definition: Collects user wording, groups queries by intent, and connects each group to the right product function or page. Example: “Where is my status?” and “check application” share one intent: view a process result.
- **ASO — Improving an app's store page:** Definition: Work on the title, description, screenshots, rating, and queries so the app is easier to find and more convincing to install. Example: Rewrite the first screenshot captions so the value is clear without reading the full description.
- **SEO — Improving website pages for search:** Definition: Useful pages answer real user questions and help people find the product through search engines. Example: One page answers one question, explains constraints, and leads to a relevant app journey.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

The app description is written in internal language, organic traffic is weak, and the team does not know which real questions the store page or site should answer.

#### Where to collect queries

Use several independent sources. Search suggestions show the wording; reviews and support reveal the task behind it.

- **Search suggestions**
  - **Source:** Type the main categories and problems into store search and a search engine; save the natural completions of the phrases.
  - **If access is unavailable:** Without access, collect wording from your site's internal search and new users' questions.
- **Reviews and support**
  - **Source:** Write out the recurring words from 50 reviews and requests: what people want to do, compare, or understand.
  - **If access is unavailable:** Ask support for ten questions they constantly have to translate from the team's internal language.
- **Current pages**
  - **Source:** Match the queries to an existing store page, article, or screen. Mark the queries that have no honest answer yet.
  - **If access is unavailable:** If no suitable page exists, do not stuff the keyword into the description — file a content idea or drop the query.

#### Build a working keyword map

1. **Collect the wording unedited.** Record queries exactly as users type them. Do not replace plain words with internal feature names.
   - **Where to do it:** In the first column of the shared table, together with the source.
   - **Example:** “How to check status,” not the internal name of the status-tracking screen.
2. **Merge queries by intent.** Group synonyms around one task: find a product, do something, solve a problem, compare, or get instructions.
   - **Where to do it:** In the second column and the table's color groups.
   - **Example:** “Where is my status,” “check my application,” “verification status” → one intent: see the result of a process.
3. **Check the product fit.** For each intent, note the real feature, a limitation, or the absence of an answer. A popular but irrelevant query does not become useful.
   - **Where to do it:** In the fit column, confirmed by the product owner.
   - **Example:** The guaranteed-results query is excluded: the product cannot honestly make that promise.
4. **Assign one answer location.** A feature query can lead to the store page, a “how” question to a guide, and a specific problem to help. Do not make pages compete.
   - **Where to do it:** In the destination column.
   - **Example:** “How to pass verification” → a detailed guide; a generic category name → the app page.
5. **Pick the first five queries.** Weigh relevance, how well the wording is confirmed, and how ready the answer is. Start with a small priority set you can genuinely improve.
   - **Where to do it:** In the high-priority filter and the content plan.
   - **Example:** Five queries get page owners and a recheck date for impressions and target actions.

#### Practical examples

- **User language becomes an intent:** “Where is my status,” “check my application,” and “verification status” merge into one task — seeing the result of a process. The answer is an article plus the status screen.
- **A popular but dishonest query is excluded:** A guaranteed-results query may have demand, but it does not match the product. It goes into neither the description nor an SEO page.

#### Finished artifact: A map of queries and answers

One row — one intent and one main answer location. Synonyms are merged, not left competing across several pages.

| Query | Intent | Product fit | Where it leads | Priority |
| --- | --- | --- | --- | --- |
| check status | See the result of a process | Full | Article + status screen | High |
| how to pass verification | Understand the steps and documents | Full | Guide | High |
| learning app | Find a product category | Partial | Store page | Medium |
| guaranteed income | Get a promised result | No fit | Not used | Excluded |
| brand name | Find a specific product | Full | Store page | Defensive |

Next action: take the five high-priority queries, review the quality of the current answer, and assign a page owner. Do not try to fit all 30 queries into one description.

#### Keyword map checklist

The map is ready when each priority row makes clear which user question and which honest answer stand behind the words.

- [ ] Queries come from at least two sources and are stored in the user's language.
- [ ] Synonyms are merged by intent rather than treated as separate topics.
- [ ] Every query maps to a real feature, condition, or useful content.
- [ ] Irrelevant queries and manipulative promises are excluded.
- [ ] The first five queries each have one page, an owner, and a result-check date.

#### How to know the map helps

- **Visibility:** Impressions grow for the chosen relevant queries, not for random broad keywords.
- **Answer:** Users land on the assigned page and find the expected feature or guide.
- **Quality:** Organic installs or target actions grow without hurting activation and trust.

#### Key rule

Do not add keywords for density: every priority query must lead to an honest answer the user will actually find.

---

### Make your app-store page clear and convincing

- **Canonical URL:** https://playbook.affpartners.io/en/practices/discoverability-store/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/discoverability-store/index.md
- **Module:** ASO & SEO
- **Time:** 2 hours for the first storyboard

People make their first decision from the icon, title, and first two screenshots. These elements should quickly show the job the product does, its real interface, and a reason to trust it—without unsupported promises.

#### Outcome

A storyboard for an updated store page with one value promise, five screenshots, trust evidence, and a measurement plan.

#### The first two screenshots should explain the product without the description

A store page works like a storefront: the user does not know the internal features yet and quickly decides whether to keep looking. Show the main task and the result first, then the path, the trust signals, and the extras.

#### What you will need

- **Access:** Page statistics in App Store Connect or Google Play Console, plus the current copy, icon, and screenshots.
- **Current build:** The real interface of the latest version on iOS and Android, including localizations and important limitations.
- **Team:** A product manager, a designer, and someone who can confirm the terms, the trust copy, and the publication plan.

#### Terms in plain language

- **ASO — Improving an app's store page:** Definition: Work on the title, description, screenshots, rating, and queries so the app is easier to find and more convincing to install. Example: Rewrite the first screenshot captions so the value is clear without reading the full description.
- **Search semantics — A map of search queries and the needs behind them:** Definition: Collects user wording, groups queries by intent, and connects each group to the right product function or page. Example: “Where is my status?” and “check application” share one intent: view a process result.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

People view the app page but rarely install; the images show an interface without value, the promises are outdated, or the post-install experience does not match the storefront.

#### What to check before a redesign

Do not start with new graphics. First find where the meaning gets lost: in the promise, the first images, a version mismatch, or missing trust.

- **Store statistics**
  - **Source:** Compare page views, installs, sources, and the differences by country and platform over the last 28–90 days.
  - **If access is unavailable:** Without access, capture the current page, ask the console owner for the key numbers, and do not judge conversion by gut feeling.
- **Reviews and support**
  - **Source:** Write out what users value the app for and what did not match their expectations after install.
  - **If access is unavailable:** Ask five new people to look at the first two screenshots and explain in one sentence what the product does.
- **Current build**
  - **Source:** Check every image and claim against the available interface, terms, and supported countries.
  - **If access is unavailable:** If a feature has not shipped yet, do not show it as available — move it to the next page-update plan.

#### Build a clear store page

1. **State one main value.** Write the task and the result in the user's language. Do not open with a feature list or unproven superiority.
   - **Where to do it:** In the page's promise and the first screenshot.
   - **Example:** “Check your status and next step in one place” instead of “The #1 innovation platform.”
2. **Tie the value to real demand.** Take the priority intent from the keyword map and make sure the product actually answers it.
   - **Where to do it:** In the title, subtitle, and the start of the description — without repeating keywords for density.
   - **Example:** The “check status” query is backed by a real screen and a guide.
3. **Build the screenshot story.** Order the frames from the main value to the result, the path, trust, and extras. One frame — one message.
   - **Where to do it:** In the screenshot storyboard for iOS and Android.
   - **Example:** 1 — task, 2 — result, 3 — action, 4 — terms and help, 5 — personalization.
4. **Show the real interface.** Use current screens and short, specific captions. Do not bury important limitations in fine print.
   - **Where to do it:** In the layouts for every localization and device size.
   - **Example:** The screenshot shows the real status and button the user will see after install.
5. **Change and measure one block at a time.** Record the page version, the date, and the key metric. Do not change the icon, the title, and all screenshots at once if you want to understand the effect.
   - **Where to do it:** In the store page update log.
   - **Example:** Test the first two screenshots for 28 days on Android in one country; watch view → install and activation.

#### Practical examples

- **The first two frames work without the description:** Frame 1 names the task — “Check your status in one place”; frame 2 shows the next step on a real screen. The remaining features do not compete with the main promise.
- **One hypothesis at a time:** The team replaces only the first two screenshots on Android in one country and spends 28 days comparing view → install and the first useful result.

#### Finished artifact: Five-screenshot storyboard

Each frame answers one question and shows a real screen. The first two must work even without the full description.

| Frame | Message | What to show | Why it is needed |
| --- | --- | --- | --- |
| 1 · Main value | Check your status in one place | The real status screen | Explain the task |
| 2 · First result | See the next step right away | Details and the CTA | Show the value |
| 3 · How it works | Save what matters | The save flow | Answer the path question |
| 4 · Trust | Clear terms and help | Terms + support | Reduce doubt |
| 5 · Extras | Tune it to your interest | Personalization | Broaden the picture |

First test: replace only the first two screenshots, keep everything else unchanged, and compare page conversion for one platform and country.

#### Page checklist

Before publishing, open the page on a phone and check it as a new user who knows nothing about the product.

- [ ] The first two screenshots explain the task and the result without the full description.
- [ ] All images match the current interface and localization.
- [ ] There are no guaranteed results, deposit pressure, or unverified comparisons.
- [ ] The important terms and the path to help are visible before install or easy to find.
- [ ] Each change has a version, a date, one main hypothesis, and a measurement plan.

#### How to know the page improved

- **First decision:** View-to-install conversion grows in the chosen country and platform.
- **Promise accuracy:** More new users reach the first result shown on the page after installing.
- **Trust:** Early uninstalls, mismatch complaints, and negative reviews do not grow after the storefront update.

#### Key rule

If a title or image promises more than the product delivers, it hurts both conversion and post-install trust.

---

### Turn app-store reviews into product action

- **Canonical URL:** https://playbook.affpartners.io/en/practices/discoverability-rating/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/discoverability-rating/index.md
- **Module:** ASO & SEO
- **Time:** 60 minutes to set up and 30 minutes per week

A review is a public signal about a specific experience, not merely a brand score. Separate critical issues quickly, respond without arguing, and turn repeated themes into product work.

#### Outcome

One review queue with themes, priority, a safe response template, an owner, and links to product tasks.

#### A public reply is read by more people than its author

A good reply acknowledges the experience, does not argue, and offers a safe next step without personal data. Most importantly, recurring complaints must reach the product owner and come back to the review once fixed.

#### What you will need

- **Access:** App Store and Google Play reviews with the date, platform, country, and app version where available.
- **Reply owner:** A support or community manager with clear response times and escalation rules.
- **Product link:** A shared task queue where a recurring theme can be filed with examples and frequency.

#### Terms in plain language

- **ASO — Improving an app's store page:** Definition: Work on the title, description, screenshots, rating, and queries so the app is easier to find and more convincing to install. Example: Rewrite the first screenshot captions so the value is clear without reading the full description.
- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

Reviews go unanswered, the rating moves for no clear reason, and recurring complaints never reach support, development, or the product owner.

#### How to set up the workflow

Do not reply straight from a notification, without context. First gather the reviews in one place, tag the theme and severity, then choose the right next step.

- **Store consoles**
  - **Source:** Export new reviews daily or weekly with the rating, language, platform, and version where available.
  - **If access is unavailable:** Without an automatic export, keep a shared table and save the link, date, and text of every important review.
- **Support and technical signals**
  - **Source:** Cross-check complaints about login, data, transactions, and crashes against tickets and error reports.
  - **If access is unavailable:** If the link is still manual, post critical reviews to a shared channel with the version and a request to confirm the scale.
- **Product task list**
  - **Source:** For a recurring theme, track the number of reviews, examples, the owner, the status, and the fix version.
  - **If access is unavailable:** If there is no task system, add a “next decision” column and revisit it during the weekly review.

#### Set up the work with store reviews

1. **Build one queue.** Combine reviews from both stores in a table or work tool. Keep the original text, language, date, platform, and version.
   - **Where to do it:** In the shared queue, with a filter for new and untagged reviews.
   - **Example:** Android 4.2 · 1 star · “I can't see my history after the update” · June 12.
2. **Tag the theme and severity.** Flag security, money, data, login, and blocking errors immediately. Group the rest by a clear user theme.
   - **Where to do it:** In the theme and priority columns.
   - **Example:** History loss — high severity; a dark-theme request — a regular wish.
3. **Reply without arguing or promising.** Acknowledge the experience, give a safe next step, and do not ask for personal data in public. Do not promise dates the team has not confirmed.
   - **Where to do it:** In a public reply, in the user's language.
   - **Example:** “We understand — the history is not showing. Please contact us through the in-app support form and include your version; the team will investigate.”
4. **Escalate recurring themes.** Several similar reviews should become one signal with frequency, versions, and an owner — not scattered, unrelated notes.
   - **Where to do it:** In a product task or the weekly review.
   - **Example:** 8 reviews and 14 support requests about empty history on Android 4.2 → one high-priority task.
5. **Close the loop after the fix.** Once the fix is confirmed, update the public reply with the version. Do not ask the user to change the rating.
   - **Where to do it:** In the original review, after verifying the release.
   - **Example:** “The problem is fixed in version 4.3. Thank you for helping us find it.”

#### Practical examples

- **A critical review becomes a task:** Eight reviews and 14 support requests about empty history on Android 4.2 merge into one problem with an owner and an urgent version check.
- **The loop closes in public:** After verifying version 4.3, the team updates the reply: the problem is fixed, thank you for the signal. There is no request to change the rating or post personal data.

#### Finished artifact: Review and escalation queue

One row links the public signal, the safe reply, and the internal team action.

| Review theme | Priority | Public reply | Internal action |
| --- | --- | --- | --- |
| Login does not work | Critical | Acknowledge + safe help channel | Check the version and errors today |
| Status is unclear | High | Explain where to see the status | Collect 5+ examples into a product task |
| Feature request | Regular | Thank without promising | Track the frequency |
| Hard-to-find setting | Regular | Give a short route | Check the navigation |
| Fixed in 4.3 | Loop closing | Report the version and thank them | Watch the new reviews |

Never ask users to post personal or payment details in a review. Move individual cases to a secure support channel.

#### Reply checklist

Before publishing, imagine the reply being read by a new user deciding whether the team can be trusted.

- [ ] Reviews are tagged by theme, platform, version, and severity.
- [ ] The reply acknowledges the experience and does not argue with the user.
- [ ] There are no requests to post personal data and no unconfirmed promises.
- [ ] Every recurring theme is linked to an internal task and an owner.
- [ ] After a fix, the team follows up with the version — without asking to change the rating.

#### How to know the process works

- **Reaction:** The share of meaningful replies grows, and critical reviews get answered faster than before.
- **Product signal:** Recurring themes are merged and owned instead of remaining scattered comments.
- **Loop closing:** After the fix, the theme appears less often in new reviews and support requests.

#### Key rule

Do not ask people to change their rating: fix the problem, confirm the fix, and let users judge the new experience themselves.

---

### Create SEO pages around user tasks

- **Canonical URL:** https://playbook.affpartners.io/en/practices/discoverability-seo/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/discoverability-seo/index.md
- **Module:** ASO & SEO
- **Time:** 3 hours for the first page

A useful SEO page answers one question fully before asking the reader to install the app. It shows conditions, examples, and an honest continuation in the product—not copy written only for keywords.

#### Outcome

A complete plan for the first SEO page: intent, answer structure, evidence, limitations, CTA, in-app route, and update plan.

#### One page — one question — one complete answer

Someone searching “how to set up notifications” needs the steps, the conditions, and a way to check the result. A generic promo page answers nothing and forces them to install the app blind.

#### What you will need

- **One search intent:** A priority question from the keyword map, confirmed by search, support, or reviews.
- **Expert:** The feature owner or a support specialist who will verify the steps, limitations, and freshness of the answer.
- **Publishing and data:** Access to the site, page analytics, and the route to the matching app screen.

#### Terms in plain language

- **SEO — Improving website pages for search:** Definition: Useful pages answer real user questions and help people find the product through search engines. Example: One page answers one question, explains constraints, and leads to a relevant app journey.
- **Search semantics — A map of search queries and the needs behind them:** Definition: Collects user wording, groups queries by intent, and connects each group to the right product function or page. Example: “Where is my status?” and “check application” share one intent: view a process result.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

The site gets almost nothing but brand traffic, frequent questions have no dedicated answer, and the existing pages repeat keywords and lead to the home page.

#### What to collect before writing

First confirm the question and the product's actual answer. The page structure follows the user's task, not the desired keyword density.

- **Keyword map**
  - **Source:** Take one high-priority intent and the combined wording people use to search for it.
  - **If access is unavailable:** Without tools, start with a recurring support question that comes up at least five times a month.
- **Current product**
  - **Source:** Walk the journey on the current version and write down the steps, conditions, errors, and availability by platform and country.
  - **If access is unavailable:** If the feature is changing, do not publish final instructions until the owner and release date are confirmed.
- **Search analytics**
  - **Source:** After publishing, watch impressions, clicks, the page's queries, and actions after reading.
  - **If access is unavailable:** If the tool is not connected yet, at least tag the CTA and deep link with a separate source parameter.

#### Assemble a useful SEO page

1. **Choose one intent.** Take a specific question the product actually solves. Do not combine a guide, a comparison, and a general overview on one page.
   - **Where to do it:** In the outline's title and the primary search intent.
   - **Example:** “How to check an application status” instead of the catch-all “everything about the app.”
2. **Give the short answer immediately.** Explain the result and the key condition in the first paragraphs. The user should not scroll through promo copy to reach the point.
   - **Where to do it:** Under the H1 and in the page summary.
   - **Example:** The status is in the “History” section and updates after processing; the typical time is shown next to it.
3. **Show the path and the limitations.** Add step-by-step actions, real screenshots, availability, timelines, and common errors. Do not hide important conditions behind the CTA.
   - **Where to do it:** In the main body of the page, with the update date.
   - **Example:** Three steps, what to do about a delay, and in which countries the journey is available.
4. **Link to the relevant screen.** Offer to continue exactly the task the reader came with. The app's home screen breaks the context.
   - **Where to do it:** In one main CTA and deep link.
   - **Example:** “Open my status” leads to the history — not the home screen.
5. **Assign an update owner.** Features, conditions, and the interface change. Write down the owner, the review date, and the signals that call for a page review.
   - **Where to do it:** In the content metadata and the editorial calendar.
   - **Example:** Support checks the guide after every release and quarterly against frequent queries.

#### Practical examples

- **The answer is available before the install:** The “How to check status” page immediately explains where the status lives and when it updates, then shows three steps and the limitations — and only then offers to open your own status.
- **The continuation keeps the task:** The “Open my status” CTA leads to the matching screen. If the feature is unavailable in a country, the limitation is visible on the page before the tap.

#### Finished artifact: Outline of the “How to check status” page

The outline states what the user must understand and do in each block of the page.

| Block | Page answer | Backed by | Next step |
| --- | --- | --- | --- |
| Title | How to check an application status | Matches the question | See the answer immediately |
| Short answer | Where the status lives and when it updates | The current product version | Understand without installing |
| Step by step | 3 steps with screenshots | The real interface | Repeat the path |
| Conditions | Timelines, countries, common errors | Confirmed by the owner | Avoid surprises |
| Continuation | Open your status | A working deep link | Go to the right screen |

The user gets the answer at the top of the page. The in-app CTA appears as a convenient continuation — not as a condition for reaching the basic information.

#### Page checklist

The page must stay useful even if the reader never installs the app.

- [ ] One page fully answers one search intent.
- [ ] The short answer sits at the top, not after a promotional intro.
- [ ] The steps, images, timelines, and limitations match the current product.
- [ ] The main CTA and deep link continue the user's original task.
- [ ] The owner, the update date, and the trigger for the next review are set.

#### How to know the page helps

- **Search answer:** Relevant impressions and clicks for the chosen intent grow — not random broad traffic.
- **Page value:** Readers reach the answer, use the steps, and ask support the same basic question less often.
- **Continuation in the product:** Clicks from the site into the app open the right screen and lead to the expected action.

#### Key rule

SEO does not end at the click: the user should get the full answer on the page and a clear continuation of the same task in the app.

---

### Connect search, web, and app with deep links

- **Canonical URL:** https://playbook.affpartners.io/en/practices/discoverability-links/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/discoverability-links/index.md
- **Module:** ASO & SEO
- **Time:** 2 hours for the first route

A deep link is a precise address inside the app. It should preserve the original task after a tap, sign-in, or even a new install, and provide a clear fallback when the destination is unavailable.

#### Outcome

A continuous-journey map and iOS/Android test matrix covering installed, signed-out, not-installed, and outdated-app states.

#### A link should lead to the right room, not just the building

Someone reading a guide about their status expects the tap to open that status. The home screen makes them find the way all over again. A good route remembers the destination through sign-in and offers a safe alternative when the screen is unavailable.

#### What you will need

- **One route:** A specific web page or message, a destination screen in the app, and one expected action.
- **Development:** An iOS and Android developer, or a links owner who knows the supported paths and the sign-in behavior.
- **Testing:** Devices on both platforms, the app installed and uninstalled, test accounts, and analytics events.

#### Terms in plain language

- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **SEO — Improving website pages for search:** Definition: Useful pages answer real user questions and help people find the product through search engines. Example: One page answers one question, explains constraints, and leads to a relevant app journey.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

#### When to use it

Clicks from search, the site, email, or push open the home page, get lost after sign-in or a fresh install, and leave the target action unmeasurable.

#### What to describe before development

First map the behavior for every user state. The same link must not silently dead-end when the app or the screen is missing.

- **Route map**
  - **Source:** Match the source, the promised screen, the required sign-in, and the target action after opening.
  - **If access is unavailable:** Start with the single most important link and write down the expected behavior for the five states by hand.
- **Technical errors**
  - **Source:** Collect successful opens, fallback routes, unknown paths, and the app version for every link.
  - **If access is unavailable:** Without events, keep a manual test log with the device, version, steps, and a video of the error.
- **Taps and actions**
  - **Source:** Join the tap, the destination-screen open, and the completed action with one route identifier.
  - **If access is unavailable:** Add a technical route_id parameter to the link and the screen event before the next launch.

#### Set up a continuous route

1. **Choose one task and screen.** Start with a specific promise and a final result. Do not create a universal “open the app” link.
   - **Where to do it:** In the first row of the route map.
   - **Example:** The “How to check status” article → the specific status screen → the user sees the next step.
2. **Describe the user states.** Write down the behavior when the app is installed, the user is signed out, the version is outdated, or the app is missing.
   - **Where to do it:** In the rows of the test matrix.
   - **Example:** After sign-in the original route ID survives and opens the status, not the home screen.
3. **Add a safe fallback.** If the destination screen is unavailable, show a relevant web page, the store, or help. Do not leave a blank screen and an unexplained error.
   - **Where to do it:** In the link router settings.
   - **Example:** App not installed → the web guide stays available, plus a clear button to the store.
4. **Test on real devices.** Check iOS and Android, cold start, sign-in, an old version, and entry from different sources. Record the actual result for every row.
   - **Where to do it:** On the devices and versions the audience actually uses.
   - **Example:** Android 13 from the browser, iOS 17 from email, and both platforms after signing out.
5. **Join the tap to the outcome.** Pass route_id — the route identifier — and record the destination-screen open, the fallback path, errors, and the target action.
   - **Where to do it:** In the link parameters and analytics events.
   - **Example:** A tap on the site → the app opens → the status is viewed → the next step, with route_id=status_help.

#### Practical examples

- **Sign-in does not erase the destination:** The status link asks the user to sign in, keeps the route_id, and after sign-in opens the promised screen instead of the home page.
- **No app — no dead end:** The user stays on the useful web guide and gets a clear link to the store. After installing, the route continues — or a web alternative opens safely.

#### Finished artifact: Verification matrix for the “Open status” route

Walk every row on iOS and Android. “The app opened” is not enough — the promised screen must appear.

| State | Expected path | Fallback route | Result |
| --- | --- | --- | --- |
| Installed, signed in | Straight to the status screen | Not needed | Check iOS/Android |
| Installed, signed out | Sign-in → status screen | Preserve the destination | The route ID is not lost |
| App not installed | Store page | The web answer stays available | No error shown |
| Outdated version | A supported screen or an update prompt | Web version | No dead end |
| Screen removed | A current alternative | Help section | A “route not found” event |

The scenario is ready when the tap shows the promised screen in every supported state, and route errors land in the report with the version and platform.

#### Deep-link checklist

The link is ready only after the full path is tested — not after one lucky open on the developer's device.

- [ ] There is a specific promised screen and a target action.
- [ ] The original destination survives sign-in and a cold start.
- [ ] There is a fallback for a missing app, an old version, and a removed screen.
- [ ] The link carries no sensitive user data.
- [ ] The tap, screen, errors, and action are joined by the route ID and tested on iOS/Android.

#### How to know the route works

- **Technical success:** The share of taps that opened the promised screen or a correct fallback without an error.
- **Context preserved:** After sign-in or a fresh install, the user continues the original task instead of landing on the home screen.
- **Useful action:** Users complete the action after the tap, while “route not found” errors and back-navigation decline.

#### Key rule

A deep link counts as working only when users reach the promised screen in every supported state — not just in the developer's test.

---

# Практики на русском

Полная русская версия библиотеки.

Library URL: https://playbook.affpartners.io/ru/

## Качество продукта

### Найдите точку, где пользователь теряется

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-funnel/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-funnel/index.md
- **Раздел:** Качество продукта
- **Время:** 60 минут на первый аудит

Не нужно сразу разбираться во всей аналитике. Соберите путь из пяти понятных шагов, найдите самое большое падение и выберите одно изменение для ближайшего релиза.

#### Результат

Таблица с пятью шагами пути, одной точкой потери, вероятной причиной и владельцем следующего изменения.

#### Ищем не весь плохой путь, а одно место

Представьте путь пользователя как пять дверей. На каждом шаге часть людей уходит. Ваша задача — увидеть, у какой двери теряется больше всего пользователей, понять вероятную причину и исправить сначала её.

#### Что понадобится

- **Доступ:** AppMetrica, Firebase, Amplitude или любой отчёт, где видны действия пользователей.
- **Коллега:** Аналитик или разработчик на 15 минут, если вы не знаете названия событий.
- **Период:** Последние 14–30 дней без крупных сбоев и рекламных всплесков.

#### Термины простыми словами

- **Воронка — Последовательность шагов от входа до результата:** Определение: Помогает сравнить число пользователей на каждом шаге и найти место с самым большим падением. Пример: Установка → первый запуск → регистрация → первое полезное действие → повторный визит.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **FTD — Первый депозит пользователя:** Определение: Первый случай, когда зарегистрированный пользователь пополняет счёт. Это бизнес-результат всего пути, а не отдельная кнопка, которую нужно агрессивнее продвигать. Пример: Если регистрацию закончили 100 человек, а первый депозит сделали 24, FTD-конверсия равна 24%.
- **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей.
- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **ANR — Зависание Android-приложения:** Определение: Android фиксирует ANR, когда интерфейс слишком долго не отвечает на действия пользователя. Пример: Пользователь нажал кнопку, экран завис, и Android предложил закрыть приложение.

#### Когда применять

Регистраций или первых полезных действий стало меньше, пользователи жалуются на путь, а команде непонятно, что исправлять первым.

#### Где взять данные

Выберите тот вариант, который уже есть у команды. Если аналитика не настроена, начните с ручной проверки — практика всё равно даст результат.

- **AppMetrica или Firebase**
  - **Источник:** Откройте отчёт «Воронка» и добавьте: первый запуск → начало регистрации → завершение регистрации → первое полезное действие → повторный визит.
  - **Если доступа нет:** Если названия событий неизвестны, попросите разработчика прислать список событий для регистрации и первого полезного действия.
- **Таблица или BI-отчёт**
  - **Источник:** Возьмите количество пользователей на каждом шаге за один период. Не смешивайте iOS и Android в первой проверке.
  - **Если доступа нет:** Достаточно пяти чисел. Не ждите идеального дашборда, чтобы увидеть грубое падение.
- **Если событий ещё нет**
  - **Источник:** Пройдите путь на чистой установке десять раз на iOS и Android. Запишите ошибки, задержки и непонятные экраны.
  - **Если доступа нет:** Создайте короткое техническое задание на события — это и будет первым результатом аудита.

#### Проведите первый аудит за 5 шагов

1. **Нарисуйте путь.** Запишите пять шагов простыми действиями пользователя — без внутренних названий экранов и командных терминов.
   - **Где сделать:** Лист бумаги, FigJam или первая колонка готовой таблицы.
   - **Пример:** Установка → первый запуск → начало регистрации → первое полезное действие → повторный визит.
2. **Поставьте рядом пять чисел.** Укажите, сколько уникальных пользователей дошло до каждого шага за один и тот же период.
   - **Где сделать:** Отчёт «Воронка» в AppMetrica / Firebase или выгрузка от аналитика.
   - **Пример:** 1 000 запустили приложение, 820 начали регистрацию, 460 завершили её.
3. **Посчитайте переход между шагами.** Разделите число на следующем шаге на число на предыдущем и умножьте на 100%. Самый низкий процент — первый кандидат на проверку.
   - **Где сделать:** В таблице рядом с каждым шагом.
   - **Пример:** 460 ÷ 820 × 100% = 56%. Значит, 44% начавших регистрацию её не закончили.
4. **Проверьте причину.** Посмотрите ошибки, обращения в поддержку и пройдите этот шаг вручную. Не меняйте интерфейс, пока не исключили техническую проблему.
   - **Где сделать:** Crash-отчёты, тикеты поддержки и чистая установка приложения.
   - **Пример:** На Android 12 код подтверждения приходит поздно, а повторная отправка не объяснена.
5. **Выберите одно изменение.** Запишите изменение, владельца и метрику, которую сравните после релиза. Не включайте в первый эксперимент сразу несколько экранов.
   - **Где сделать:** Задача в backlog или короткий план ближайшего релиза.
   - **Пример:** Исправить повторную отправку кода; владелец — Android-команда; проверка — конверсия завершения регистрации через 14 дней.

#### Примеры из практики

- **Долгая загрузка после регистрации:** Пользователь создал аккаунт, но 40 секунд ждёт первый экран и закрывает приложение. Приоритет — скорость и понятный статус загрузки, а не ещё одно поле формы.
- **Разный путь на платформах:** На Android регистрация завершается заметно реже, чем на iOS. Сначала проверьте ошибки конкретной версии, затем меняйте интерфейс.

#### Готовый артефакт: Одна таблица для решения команды

Не нужен большой отчёт. Заполните пять строк и выделите одно падение, которое команда проверит в ближайшем релизе.

| Шаг | Пользователи | Конверсия | Что видим |
| --- | --- | --- | --- |
| Первый запуск | 1 000 | — | Точка отсчёта |
| Начали регистрацию | 820 | 82% | Падение допустимое |
| Завершили регистрацию | 460 | 56% | Главная точка потери |
| Сделали первое полезное действие | 350 | 76% | Проверить подсказки |
| Вернулись на D1 | 150 | 43% | Смотреть после исправления |

Вывод: сначала проверяем регистрацию на Android — ошибки, обязательные поля и время ожидания. Владелец: продукт + Android-разработчик.

#### Чек-лист перед решением

Если какого-то пункта нет, зафиксируйте это как отдельную задачу — не угадывайте.

- [ ] Пять шагов названы действиями пользователя, а не экранами команды.
- [ ] Для каждого шага есть число за один и тот же период.
- [ ] iOS и Android проверены отдельно.
- [ ] Технические ошибки и обращения поддержки проверены до изменения интерфейса.
- [ ] Выбрано одно изменение с владельцем и датой проверки.

#### Как понять, что изменение помогло

- **Основной сигнал:** Конверсия проблемного шага выросла по сравнению с периодом до релиза.
- **Защитная метрика:** Не выросли ошибки, вылеты и обращения в поддержку на соседних шагах.
- **Бизнес-результат:** Больше пользователей дошли до первого полезного действия и FTD без дополнительного давления.

#### Главное правило

FTD — первый депозит пользователя и итог всего пути. Сначала сделайте путь понятным и надёжным, затем проверяйте бизнес-результат.

---

### Доведите пользователя до первой ценности

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-first-value/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-first-value/index.md
- **Раздел:** Качество продукта
- **Время:** 90 минут на первый разбор

Первая ценность — это момент, когда человек не просто открыл приложение, а получил маленький полезный результат. Найдите этот момент и уберите всё, что мешает дойти до него в первую сессию.

#### Результат

Карта первого запуска: один полезный результат, путь до него, лишние барьеры и одно изменение для ближайшего релиза.

#### Сначала покажите пользу, потом просите усилие

Новый пользователь ещё не доверяет приложению и не знает, зачем заполнять профиль, включать уведомления или проходить длинный онбординг. Дайте ему увидеть реальную пользу как можно раньше — даже если это только персональная подборка, сохранённый объект или первый понятный результат.

#### Что понадобится

- **Чистая установка:** Телефон без сохранённого аккаунта и старая версия приложения из стора для честного первого прохода.
- **Коллега:** Продукт, поддержка или дизайнер на 20 минут, чтобы сверить ожидания новичка с реальными вопросами.
- **Период:** Данные новых пользователей за последние 14–30 дней без крупных рекламных всплесков.

#### Термины простыми словами

- **CTA — Главное действие, которое предлагается пользователю:** Определение: CTA — это кнопка или ссылка с понятным следующим шагом и ожидаемым результатом. Пример: «Продолжить регистрацию» конкретнее и полезнее, чем «Далее».
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.
- **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей.

#### Когда применять

Новые пользователи устанавливают приложение, но не завершают онбординг, не делают первое полезное действие или не возвращаются на следующий день.

#### Где взять сигналы

Не пытайтесь сразу доказать идеальную причинность. Соедините цифры с живыми вопросами пользователей и ручным прохождением пути.

- **Воронка первого запуска**
  - **Источник:** В AppMetrica, Firebase или другом отчёте соберите: первый запуск → начало онбординга → завершение → первое полезное действие.
  - **Если доступа нет:** Если нужного события нет, попросите разработчика назвать ближайшее техническое событие и заведите задачу на корректную разметку.
- **Поддержка и отзывы**
  - **Источник:** Возьмите 20 последних вопросов новичков и отметьте, где они не поняли пользу, разрешение, условие или следующий шаг.
  - **Если доступа нет:** Если обращений мало, попросите трёх коллег, не знакомых с продуктом, пройти первый запуск и вслух назвать сомнения.
- **Ручной проход**
  - **Источник:** Запишите экран, действие, время и вопрос пользователя на каждом шаге от установки до первого результата.
  - **Если доступа нет:** Даже без аналитики вы получите список барьеров и сможете выбрать одно безопасное упрощение.

#### Соберите путь к первой ценности

1. **Назовите один полезный результат.** Сформулируйте действие, после которого новичок может честно сказать: «Теперь я понимаю, зачем мне это приложение». Не используйте регистрацию, согласие или депозит как ценность сами по себе.
   - **Где сделать:** Верх карты пути или короткий документ команды.
   - **Пример:** Пользователь увидел понятную подборку по своему интересу и сохранил один объект.
2. **Пройдите путь с нуля.** Установите приложение заново и запишите каждый экран, обязательное поле, разрешение и ожидание до результата.
   - **Где сделать:** На реальном iOS- и Android-устройстве, не только в тестовой сборке.
   - **Пример:** До подборки нужно пройти 9 экранов, заполнить 7 полей и дважды подтвердить разрешения.
3. **Отделите необходимое от привычного.** Для каждого шага спросите: без него нельзя показать пользу, или команда просто привыкла делать это сразу? Перенесите необязательные запросы после результата.
   - **Где сделать:** Во второй и третьей колонках карты пути.
   - **Пример:** Часовой пояс нужен для уведомлений позже, но не нужен для первой подборки — переносим запрос.
4. **Оставьте один понятный CTA.** На каждом экране должен быть один главный следующий шаг с описанием результата, а не внутреннего процесса.
   - **Где сделать:** На ключевых экранах до и сразу после первой ценности.
   - **Пример:** Вместо «Продолжить» — «Показать подборку»; после результата — «Сохранить подборку».
5. **Выберите одно упрощение.** Зафиксируйте изменение, владельца и метрики до разработки. Не смешивайте сокращение формы, новые тексты и редизайн всех экранов в одной проверке.
   - **Где сделать:** В задаче ближайшего релиза и карте пути.
   - **Пример:** Перенести пять полей профиля после первой подборки; владелец — менеджер продукта; проверка через 14 дней.

#### Примеры из практики

- **До: анкета раньше результата:** Новый пользователь проходил 9 экранов и заполнял 7 полей до первой подборки. После переноса пяти полей за результат путь сократился до 4 экранов — меняется один барьер, а не весь онбординг.
- **После: разрешение в понятный момент:** Push запрашивается не на первом запуске, а после сохранения объекта: приложение сначала объясняет, что сообщит об изменении именно этого объекта.

#### Готовый артефакт: Карта первого полезного опыта

Соберите текущий путь в пять строк. Не проектируйте новый онбординг целиком — выберите один барьер, который можно убрать первым.

| Этап | Что происходит сейчас | Что меняем | Готово, если |
| --- | --- | --- | --- |
| Первый экран | Три рекламных слайда | Оставляем одно обещание пользы | Понятно за 5 секунд |
| Регистрация | 7 обязательных полей | Оставляем email и пароль | Можно продолжить без профиля |
| Разрешения | Push запрашивается сразу | Просим после сохранения объекта | Есть понятный контекст |
| Первая ценность | Подборка после анкеты | Показываем базовую подборку раньше | Результат в первую сессию |
| Следующий шаг | Три одинаковые кнопки | Один CTA «Сохранить подборку» | Действие очевидно |

Первое изменение: показать базовую подборку до полной анкеты. Владелец — продукт + мобильная команда. Проверка через 14 дней: конверсия в первую ценность и медианное время до неё.

#### Чек-лист перед разработкой

Если команда не может ответить на пункт, вернитесь к карте пути — новый интерфейс пока не нужен.

- [ ] Первый полезный результат описан действием пользователя, а не бизнес-метрикой.
- [ ] Путь пройден на чистой установке iOS и Android.
- [ ] Для каждого обязательного поля и разрешения понятна причина.
- [ ] До первой ценности на каждом экране есть один главный CTA.
- [ ] Выбрано одно изменение с владельцем, периодом и метрикой проверки.

#### Как понять, что путь стал лучше

- **Дошли до ценности:** Доля новых пользователей, совершивших первое полезное действие в первую сессию.
- **Дошли быстрее:** Медианное время и число экранов от первого запуска до полезного результата.
- **Не потеряли доверие:** Ошибки, ранние удаления, вопросы поддержки и D1 не стали хуже после изменения.

#### Главное правило

Если первое полезное действие нельзя назвать одним предложением, сначала договоритесь о нём внутри команды — только потом меняйте онбординг.

---

### Приоритизируйте баги по влиянию на пользователя

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-bugs/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-bugs/index.md
- **Раздел:** Качество продукта
- **Время:** 60 минут на первый разбор

Не нужно быть техническим экспертом, чтобы навести порядок в списке ошибок. Для каждого бага ответьте на четыре вопроса: что сломано, для кого, как часто и есть ли безопасный обходной путь.

#### Результат

Таблица из пяти главных багов с уровнем влияния, подтверждением, обходным путём, владельцем и сроком проверки.

#### Приоритет — это вред пользователю, а не громкость обсуждения

Красивый визуальный дефект может получить много внимания, но ошибка статуса операции, потеря данных или невозможность войти обычно важнее. Сначала защищайте безопасность, деньги, данные и ключевой путь; затем — удобство и внешний вид.

#### Что понадобится

- **Доступ:** Crashlytics, AppMetrica или другой отчёт об ошибках плюс текущий список задач в Jira, Linear или таблице.
- **Коллеги:** QA или разработчик и представитель поддержки на 20 минут для подтверждения технического следа и частоты жалоб.
- **Период:** Ошибки, обращения и отзывы за последние 14 дней; отдельно отметьте версии приложения и платформы.

#### Термины простыми словами

- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **ANR — Зависание Android-приложения:** Определение: Android фиксирует ANR, когда интерфейс слишком долго не отвечает на действия пользователя. Пример: Пользователь нажал кнопку, экран завис, и Android предложил закрыть приложение.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Backlog растёт, команда спорит о срочности, а в работу попадает последний громкий запрос вместо самой опасной проблемы.

#### Где искать подтверждение

Один скриншот ещё не показывает масштаб. Соедините технический сигнал, пользовательское обращение и влияние на ключевое действие.

- **Crash- и ANR-отчёты**
  - **Источник:** Смотрите число затронутых пользователей, версию приложения, устройство, стек ошибки и повторяемость.
  - **Если доступа нет:** Если отчётов нет, попросите разработчика воспроизвести проблему и сохранить видео, логи и условия появления.
- **Поддержка и отзывы**
  - **Источник:** Сгруппируйте обращения по одной причине: вход, статус, платёж, потеря данных, пустой экран или непонятное сообщение.
  - **Если доступа нет:** Если теги не настроены, вручную разберите 30 последних обращений и заведите пять простых категорий.
- **Ключевой сценарий**
  - **Источник:** Сравните успешность действия до и после появления ошибки: вход, регистрация, сохранение, верификация или операция.
  - **Если доступа нет:** Без аналитики проведите десять повторов на затронутой версии и зафиксируйте долю неуспешных попыток.

#### Разберите список ошибок за пять шагов

1. **Соберите всё в одну таблицу.** Объедините дубли из crash-отчётов, QA, поддержки и отзывов. Одна пользовательская проблема должна быть одной строкой.
   - **Где сделать:** Jira, Linear или общая таблица с ссылками на исходные сигналы.
   - **Пример:** Три тикета «бесконечный статус», «операция зависла» и «не вижу результат» объединены в одну проблему.
2. **Опишите вред простыми словами.** Запишите, что не может сделать пользователь и что он рискует потерять. Не оставляйте в названии только код ошибки.
   - **Где сделать:** В поле «Влияние на пользователя» каждой задачи.
   - **Пример:** Не «API 504», а «после подтверждения пользователь не видит итоговый статус и повторяет действие».
3. **Подтвердите масштаб.** Укажите число затронутых людей, платформу, версию, частоту и период. Если числа нет, честно отметьте уровень уверенности.
   - **Где сделать:** Рядом с техническим следом и ссылкой на обращения.
   - **Пример:** 84 пользователя за 7 дней; только Android 12; подтверждено 12 обращениями и одним кластером ошибок.
4. **Назначьте приоритет и обходной путь.** Сначала безопасность, деньги, данные и блокировка ключевого действия. Пока идёт исправление, поддержка должна знать безопасную помощь пользователю.
   - **Где сделать:** В колонках P0–P3, владелец, срок и обходной путь.
   - **Пример:** P0; владелец — серверная команда; срок — сегодня 18:00; поддержка проверяет статус по идентификатору.
5. **Закройте по данным, а не по релизу.** После исправления повторите сценарий и убедитесь, что исчезли технический сигнал и пользовательские жалобы.
   - **Где сделать:** В задаче через 24–72 часа после выпуска исправления.
   - **Пример:** Кластер ошибок не появляется, 20 тестов успешны, новых обращений по теме нет двое суток.

#### Примеры из практики

- **P0: статус операции завис:** Проблема затронула 84 пользователей за неделю: результат не виден, люди повторяют действие. Есть финансовый и доверительный риск — владелец и безопасный ответ поддержки нужны сегодня.
- **P1: пустая история на Android 12:** Масштаб меньше, но ключевые данные недоступны. В задаче фиксируются версия, видео воспроизведения, временный перезапуск и проверка обращений через 48 часов после hotfix.

#### Готовый артефакт: Таблица приоритетов, понятная всей команде

Пять строк достаточно для первого решения. Не прячьте влияние за техническим названием ошибки.

| Проблема | Влияние и масштаб | Обходной путь | Решение |
| --- | --- | --- | --- |
| Статус операции завис | Деньги/доверие · 84 пользователя | Поддержка проверяет вручную | P0 · исправить сегодня |
| Не приходит код входа | Блокирует вход · Android 12 | Повтор через 60 секунд | P0 · Android-разработчик |
| Пустая история | Данные не видны · версия 4.2 | Перезапуск приложения | P1 · срочное исправление |
| Push ведёт на главную | Лишний шаг · 11% переходов | Открыть раздел вручную | P2 · следующий релиз |
| Съехала иконка | Только внешний вид | Не требуется | P3 · дизайн-долг |

Правило: P0 блокирует или искажает деньги, данные, безопасность либо основной путь. У каждого P0 есть владелец, срок, сообщение для поддержки и способ проверить исправление.

#### Чек-лист приоритизации

Критичная задача должна одинаково читаться продуктом, поддержкой и разработкой.

- [ ] Проблема названа через действие и вред пользователю.
- [ ] Есть платформа, версия, период и подтверждённый масштаб либо уровень уверенности.
- [ ] Ошибки денег, данных, безопасности и доверия отмечены отдельно.
- [ ] Для P0/P1 назначены владелец, срок и безопасный обходной путь.
- [ ] Заранее записано, какими данными подтвердится исправление.

#### Как понять, что исправление сработало

- **Технический сигнал:** Исчез конкретный crash-кластер, ANR или код ошибки на затронутой версии.
- **Пользовательский путь:** Восстановилась доля успешных входов, сохранений, операций или другого сломанного действия.
- **Поддержка и доверие:** Новые обращения по теме прекратились, а пользователям с прошлой проблемой дан понятный ответ.

#### Главное правило

Баг закрыт не тогда, когда код опубликован, а когда пользователь снова успешно проходит сценарий и данные это подтверждают.

---

### Выпускайте обновления без сюрпризов

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-release/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-release/index.md
- **Раздел:** Качество продукта
- **Время:** 45 минут перед выпуском

Безопасный релиз — это заранее записанный ответ на три вопроса: что проверяем до публикации, кто смотрит первые сигналы и при каком условии останавливаем распространение.

#### Результат

Одностраничная карточка релиза с затронутыми путями, проверками, владельцами, метриками и стоп-условиями.

#### Релиз — это управляемая проверка, а не кнопка Publish

Даже небольшое изменение может сломать вход, аналитику или переход из уведомления. До публикации команда договаривается, какие пути затронуты, кто отвечает за первые часы и какой сигнал означает: продолжаем, останавливаем или откатываем.

#### Что понадобится

- **Сборка:** Готовая версия на iOS и Android плюс предыдущая версия из стора для проверки обновления.
- **Команда:** Владелец релиза, мобильный разработчик или QA и контакт поддержки на период наблюдения.
- **Окно:** Минимум 60 минут до публикации на проверку и первые 2–4 часа после выпуска на мониторинг.

#### Термины простыми словами

- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **ANR — Зависание Android-приложения:** Определение: Android фиксирует ANR, когда интерфейс слишком долго не отвечает на действия пользователя. Пример: Пользователь нажал кнопку, экран завис, и Android предложил закрыть приложение.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Перед каждым обновлением, особенно если меняются регистрация, хранение данных, уведомления, deep link или ключевой пользовательский сценарий.

#### Что открыть до релиза

Соберите ссылки заранее. В момент проблемы команда не должна искать нужный дашборд или человека в переписке.

- **Список изменений**
  - **Источник:** Возьмите задачи релиза и переведите их в пользовательские пути: вход, регистрация, контент, операция, уведомление, профиль.
  - **Если доступа нет:** Если списка изменений нет, попросите каждого разработчика одним предложением назвать изменение и возможный затронутый экран.
- **Стабильность и события**
  - **Источник:** Подготовьте дашборды crash-free, ANR, ошибок API и ключевых событий для новой версии приложения.
  - **Если доступа нет:** Без дашборда назначьте человека, который проверит логи, тестовые аккаунты и обращения поддержки через 30, 60 и 120 минут.
- **Канал реакции**
  - **Источник:** Заранее укажите чат, владельца решения и способ остановить распространение либо быстро выпустить исправление.
  - **Если доступа нет:** Если технический откат невозможен, запишите безопасный план: остановка кампаний, выключение функции или сообщение пользователю.

#### Подготовьте релиз за пять шагов

1. **Переведите задачи в пользовательские пути.** Не ограничивайтесь списком технических изменений. Назовите, что увидит пользователь и какой соседний сценарий может пострадать.
   - **Где сделать:** В верхней части карточки релиза рядом с версией.
   - **Пример:** Изменили авторизацию → проверяем вход, восстановление сессии, обновление со старой версии и deep link для незалогиненного пользователя.
2. **Проверьте чистую установку и обновление.** Новая установка и переход со старой версии — разные сценарии. Пройдите оба на iOS и Android с реальными тестовыми аккаунтами.
   - **Где сделать:** В тестовой сборке и версии из стора.
   - **Пример:** После обновления с 4.2 пользователь остаётся авторизован, история и настройки сохраняются.
3. **Пройдите критичные действия.** Проверьте вход, первое полезное действие, ключевую операцию, уведомление и возврат из фона. Запишите факт, а не «должно работать».
   - **Где сделать:** В чек-листе с датой, устройством и именем проверившего.
   - **Пример:** Android 13: регистрация пройдена 10 из 10 раз; событие completion видно в отчёте.
4. **Запишите стоп-условия.** До публикации определите конкретный сигнал, при котором распространение нужно остановить. Формулировка «если будет плохо» не помогает принять решение.
   - **Где сделать:** В последней колонке карточки релиза.
   - **Пример:** Останавливаем, если конверсия входа новой версии ниже обычной более чем на 10% или появляется потеря сессии.
5. **Назначьте наблюдение после выпуска.** Укажите владельца, интервалы проверки и канал реакции. Поддержка должна знать, что изменилось и какие данные приложить к обращению.
   - **Где сделать:** В чате и карточке релиза.
   - **Пример:** Проверки через 30, 60, 120 минут; владелец — Мария; поддержка добавляет версию приложения и ID пользователя.

#### Примеры из практики

- **До публикации: обновление с 4.2:** QA обновляет версию из стора, проверяет сохранённую сессию и историю. Потеря входа или данных — заранее записанное стоп-условие, а не повод спорить после запуска.
- **После публикации: контрольные точки:** Release owner смотрит crash-free, ошибки входа и конверсию ключевого действия через 30, 60 и 120 минут; поддержка добавляет версию приложения к каждому новому обращению.

#### Готовый артефакт: Карточка контроля релиза 4.3

Одна строка на проверку. Рядом сразу стоят владелец, факт и условие остановки.

| Проверка | Владелец | Ожидаемый результат | Стоп-условие |
| --- | --- | --- | --- |
| Обновление с 4.2 | QA | Сессия и данные сохранены | Потеря входа или данных |
| Чистая регистрация | iOS/Android | Код и профиль работают | Успех ниже 95% в тестах |
| Ключевое действие | Менеджер продукта | Событие и результат видны | Падение конверсии >10% |
| Deep link из push | CRM-специалист | Открывается нужный экран | Переход ведёт на ошибку |
| Первые 2 часа | Владелец релиза | Crash-free в обычном диапазоне | Резкий рост crash/ANR |

Решение принимает владелец релиза. При стоп-сигнале команда останавливает распространение, фиксирует время и версию, сообщает поддержке и выбирает откат либо срочное исправление.

#### Чек-лист выпуска

Не отмечайте пункт заранее. У каждой проверки должен быть факт: устройство, время, результат или ссылка на дашборд.

- [ ] Изменения переведены в понятные пользовательские пути.
- [ ] Проверены чистая установка и обновление на iOS и Android.
- [ ] Критичные действия, аналитические события и deep link работают.
- [ ] Для ключевых метрик записаны стоп-условия и безопасный план реакции.
- [ ] Назначены владелец релиза, интервалы мониторинга и контакт поддержки.

#### Что смотреть после релиза

- **Стабильность:** Crash-free, ANR и ошибки API новой версии не выходят за обычный диапазон.
- **Ключевой путь:** Вход, регистрация и главное действие проходят не хуже предыдущей версии.
- **Живые сигналы:** Поддержка и отзывы не показывают новый повторяющийся сценарий проблемы в первые 72 часа.

#### Главное правило

Если команда не знает, кто и по какому сигналу остановит распространение, релиз ещё не готов к публикации.

---

### Собирайте оценки и обратную связь внутри приложения

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-reviews/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-reviews/index.md
- **Раздел:** Качество продукта
- **Время:** 75 минут на настройку основы

Оценка в сторе и сообщение о проблеме решают разные задачи. Просите оценить приложение после реальной пользы, а путь сообщить о вопросе или ошибке держите доступным для каждого пользователя.

#### Результат

Карта двух честных сценариев: нативный запрос оценки после успеха и внутренняя обратная связь с владельцем ответа.

#### Не отбирайте довольных — создайте правильный момент

Запрос оценки уместен после завершённого полезного действия, когда человек уже увидел результат. Но он не заменяет помощь: кнопка «Сообщить о проблеме» должна быть доступна всем, а не только тем, кто сначала выбрал низкую оценку.

#### Что понадобится

- **Событие успеха:** Одно подтверждённое действие, после которого пользователь получил результат: сохранил, завершил, настроил или успешно выполнил сценарий.
- **Канал ответа:** Очередь поддержки, email или система обработки обращений с владельцем и понятным сроком первой реакции.
- **Разработка:** Штатный механизм запроса оценки на iOS и Android и короткая внутренняя форма обратной связи.

#### Термины простыми словами

- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **CTA — Главное действие, которое предлагается пользователю:** Определение: CTA — это кнопка или ссылка с понятным следующим шагом и ожидаемым результатом. Пример: «Продолжить регистрацию» конкретнее и полезнее, чем «Далее».
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Команда узнаёт о проблемах только из публичных отзывов, запрос оценки появляется случайно, а пользователю трудно сообщить о вопросе внутри приложения.

#### Как выбрать момент и форму

Начните с одного успешного сценария и одного типа обращения. Не пытайтесь сразу собирать оценки на каждом экране.

- **Событие полезного действия**
  - **Источник:** В аналитике найдите момент подтверждённого результата и проверьте, что событие приходит только после успеха.
  - **Если доступа нет:** Если события нет, запускайте запрос только с экрана подтверждённого результата и добавьте задачу на разметку.
- **Темы поддержки**
  - **Источник:** Сгруппируйте 30 последних обращений и оставьте в форме 3–4 понятные причины плюс свободный комментарий.
  - **Если доступа нет:** Без истории начните с категорий: проблема, непонятно как сделать, предложение, другое.
- **Контекст обращения**
  - **Источник:** Передавайте версию приложения, платформу, экран и ID ошибки автоматически — пользователь не должен искать эти данные.
  - **Если доступа нет:** Если автоматическая передача пока невозможна, покажите версию в форме и дайте возможность приложить скриншот.

#### Настройте два честных канала

1. **Выберите подтверждённый момент пользы.** Запрос оценки должен следовать за успешным результатом, а не за первым запуском, регистрацией или попыткой выполнить действие.
   - **Где сделать:** В аналитике и на экране подтверждения результата.
   - **Пример:** После третьего успешно сохранённого объекта, но не сразу после установки приложения.
2. **Вызовите нативный запрос.** Используйте штатный диалог платформы без собственного предварительного выбора звёзд и просьбы поставить конкретную оценку.
   - **Где сделать:** В приложении после события успеха с ограничением частоты.
   - **Пример:** Система сама решает, показать ли диалог; приложение не обещает бонус за оценку.
3. **Откройте обратную связь для всех.** Добавьте заметный путь сообщить о проблеме, непонятном шаге или идее независимо от того, видел ли пользователь запрос оценки.
   - **Где сделать:** В разделе помощи и рядом с ошибками или критичными действиями.
   - **Пример:** На экране ошибки входа есть «Сообщить о проблеме», а в профиле — постоянный пункт «Помощь и обратная связь».
4. **Передайте контекст автоматически.** Добавьте к обращению технические данные и простую категорию. Не заставляйте пользователя вспоминать версию приложения или код ошибки.
   - **Где сделать:** В системе или очереди поддержки.
   - **Пример:** Категория: вход; Android 13; версия 4.3; экран входа; приложен скриншот.
5. **Замкните обратную связь.** Назначьте срок первой реакции и еженедельно группируйте повторяющиеся темы. Если проблема решена, сообщите пользователю.
   - **Где сделать:** В правилах поддержки и коротком product review.
   - **Пример:** Ответ до одного рабочего дня; темы с 5+ обращениями за неделю получают владельца и решение.

#### Примеры из практики

- **Оценка после подтверждённой пользы:** После третьего успешного сохранения приложение вызывает нативный диалог платформы. Нет собственного выбора звёзд, обещания бонуса или просьбы поставить конкретную оценку.
- **Помощь доступна в момент ошибки:** На экране неуспешного входа кнопка «Сообщить о проблеме» передаёт в поддержку версию, платформу, экран и код ошибки; ответ обещан до одного рабочего дня.

#### Готовый артефакт: Два сценария вместо одной ловушки

Разведите оценку и помощь. У каждого сценария есть свой момент, действие и владелец.

| Сценарий | Момент | Что видит пользователь | Что делает команда |
| --- | --- | --- | --- |
| Оценка приложения | После 3-го успешного сохранения | Нативный диалог iOS/Android | Смотрит показы и рейтинг |
| Ошибка на экране | Пользователь сам нажал «Сообщить» | Короткая форма + скриншот | Support отвечает до 1 рабочего дня |
| Непонятный путь | Кнопка помощи рядом с действием | Категория + комментарий | Product еженедельно группирует темы |
| Идея пользователя | Раздел «Помощь и обратная связь» | Свободный текст | Команда подтверждает получение |

Не показывайте собственный выбор звёзд перед системным запросом и не отправляйте пользователей в разные каналы в зависимости от предполагаемой оценки.

#### Чек-лист запуска

Оценка и обратная связь дополняют друг друга, но не фильтруют пользователей на «хороших» и «плохих».

- [ ] Запрос оценки привязан к подтверждённому полезному действию.
- [ ] Используется штатный диалог платформы без предварительного выбора звёзд.
- [ ] Внутренняя обратная связь доступна всем пользователям.
- [ ] Версия, платформа, экран и ошибка передаются автоматически или легко добавляются.
- [ ] У обращений есть владелец, срок первой реакции и еженедельный разбор тем.

#### Как понять, что система работает

- **Уместность запроса:** Показы нативного диалога происходят после успеха и не сопровождаются ростом раздражения или удалений.
- **Качество сигналов:** Внутренние обращения содержат контекст и собираются в повторяющиеся темы, по которым можно принять решение.
- **Реакция команды:** Снижается время первого ответа, а по исправленным темам перестают приходить повторные обращения.

#### Главное правило

Не просите пять звёзд и не скрывайте путь к помощи: хороший рейтинг начинается с реальной пользы и честной реакции на проблему.

---

## Удержание

### Дайте пользователю причину вернуться

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/retention-return/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/retention-return/index.md
- **Раздел:** Удержание
- **Время:** 60 минут на первый сценарий

Удержание — не частота рассылок. Пользователь возвращается, когда в приложении появилось что-то лично полезное или можно легко продолжить незавершённое действие.

#### Результат

Карточка одного сценария возврата: аудитория, полезный триггер, сообщение, deep link, исключения и метрика результата.

#### Сначала причина, потом сообщение

Фраза «вернитесь в приложение» объясняет цель команды, но не пользу человека. Хороший сценарий начинается с события: появился результат, обновился сохранённый объект, можно продолжить конкретный шаг или увидеть личный прогресс.

#### Что понадобится

- **Сегмент:** Одна понятная группа: не завершили верификацию, сохранили объект или не вернулись после первого полезного действия.
- **Канал:** Push, email или внутренний баннер с возможностью исключить активных и уже завершивших действие пользователей.
- **Экран:** Рабочий deep link прямо в нужный шаг и человек, отвечающий за проверку сценария.

#### Термины простыми словами

- **Retention — Доля пользователей, которые вернулись:** Определение: Показывает, сколько людей снова открыли приложение через определённое время после установки или регистрации. Пример: Если из 100 новых пользователей через 7 дней вернулись 18, D7 retention равен 18%.
- **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.

#### Когда применять

Пользователи получают первую пользу или начинают важный сценарий, но затем не возвращаются, а общие сообщения дают открытия без завершённого действия.

#### Где найти причину для возврата

Не начинайте с текста уведомления. Сначала найдите незавершённое или новое полезное действие для конкретной группы.

- **Отчёт удержания**
  - **Источник:** Посмотрите D1/D7 по новым пользователям и найдите группу, которая получила первую ценность, но не вернулась либо остановилась на одном шаге.
  - **Если доступа нет:** Без когортного отчёта возьмите список пользователей одного сценария за две недели и сравните, кто вернулся вручную.
- **События и интересы**
  - **Источник:** Используйте только подтверждённое действие: сохранил объект, начал верификацию, открыл тему или создал подборку.
  - **Если доступа нет:** Если событий нет, начните с одного серверного статуса, который команда точно умеет обновлять и исключать после завершения.
- **Переход и исключения**
  - **Источник:** Проверьте deep link на установленном и заново открытом приложении; исключите недавно активных и уже завершивших действие.
  - **Если доступа нет:** Пока deep link не готов, используйте сообщение внутри приложения или email с понятной ручной навигацией.

#### Соберите один полезный сценарий возврата

1. **Выберите одну аудиторию.** Опишите людей через подтверждённое действие и период, а не через широкую характеристику вроде «все неактивные».
   - **Где сделать:** В инструменте сегментации и первой строке карточки сценария.
   - **Пример:** Начали верификацию, не завершили за 24 часа, не заходили последние 12 часов.
2. **Назовите реальную причину.** Причина должна существовать в продукте: сохранённый прогресс, новый результат, изменение интересующего объекта или готовый следующий шаг.
   - **Где сделать:** В событии-триггере и тексте сообщения.
   - **Пример:** Документы сохранены, пользователь может продолжить с места остановки без повторного ввода.
3. **Добавьте исключения.** Не отправляйте сообщение тем, кто уже завершил действие, недавно вернулся или получил похожее сообщение по другому сценарию.
   - **Где сделать:** В правилах сегмента перед отправкой.
   - **Пример:** Исключить completion=true, active_last_12h=true и push_sent_last_48h=true.
4. **Ведите прямо в продолжение.** После нажатия откройте обещанный экран и сохранённый шаг. Главный экран заставляет пользователя заново искать причину возврата.
   - **Где сделать:** В deep link и тестовом сценарии iOS/Android.
   - **Пример:** После входа открывается загрузка документа, а не домашняя лента.
5. **Измерьте полезное действие.** Смотрите не только доставку и открытие. Главный результат — завершил ли пользователь то действие, ради которого вернулся.
   - **Где сделать:** В отчёте через 7–14 дней после запуска.
   - **Пример:** Из 500 получивших сообщение 130 вернулись и 74 завершили верификацию; сравниваем с похожей группой без сообщения.

#### Примеры из практики

- **Продолжить сохранённый шаг:** Через 24 часа сообщение получает только тот, кто начал верификацию и не завершил её. Deep link открывает сохранённый шаг документа, а завершившие и недавно активные исключены.
- **Вернуться к личному интересу:** Если в сохранённой подборке появилось реальное обновление, сообщение называет его и ведёт в эту подборку. Успех — просмотр обновления, а не одно открытие приложения.

#### Готовый артефакт: Карточка первого сценария возврата

Один сценарий — одна аудитория и одна причина. Начните с небольшой группы, чтобы увидеть качество, а не объём отправки.

| Поле | Решение | Проверка |
| --- | --- | --- |
| Аудитория | Начали верификацию, но не закончили за 24 часа | Исключаем завершивших и активных сегодня |
| Причина | Можно продолжить с сохранённого шага | Статус процесса действительно сохранён |
| Сообщение | Продолжите верификацию с шага документа | Без давления и обещаний |
| Назначение | Deep link на экран загрузки документа | Работает после входа на iOS/Android |
| Успех | Завершили верификацию за 7 дней | Сравниваем с похожей группой без сообщения |

Перед запуском проверьте сценарий на тестовом аккаунте: сообщение приходит один раз, ведёт в сохранённый шаг и больше не отправляется после завершения.

#### Заполненный шаблон: Соберите сценарий возврата

Заполните три поля — справа появится черновик сообщения и условия запуска.

- **Кому:** Начали верификацию, но не завершили за 24 часа
- **Почему сейчас:** Прогресс сохранён — можно продолжить с шага документа
- **Что сказать:** Продолжите верификацию с сохранённого шага, когда будет удобно.

#### Ограничения и безопасность: Не создавайте давление

Не обещайте доход, не используйте фейковую срочность и не подталкивайте к депозиту. Сообщение должно помогать продолжить полезный сценарий, а не заставлять пользователя вернуться любой ценой.

#### Чек-лист запуска

Отправьте сценарий сначала тестовой группе и пройдите путь самостоятельно от сообщения до результата.

- [ ] Аудитория описана событием и периодом, а не как «все неактивные».
- [ ] Причина для возврата реально существует в продукте.
- [ ] Завершившие действие, недавно активные и получившие похожий push исключены.
- [ ] Deep link открывает обещанный экран на iOS и Android.
- [ ] Главная метрика — завершение полезного действия, а не только открытие приложения.

#### Как понять, что сценарий помогает

- **Возврат:** Доля получивших сообщение, которые вернулись в течение выбранного окна.
- **Полезное действие:** Доля вернувшихся, которые завершили обещанный сценарий после перехода.
- **Доверие:** Не растут отключения уведомлений, жалобы и повторные сообщения уже завершившим действие.

#### Главное правило

Не оптимизируйте возврат ради открытия приложения: успех — это полезное действие после возвращения без роста жалоб и отписок.

---

### Создайте момент доверия перед ключевым действием

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/retention-trust/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/retention-trust/index.md
- **Раздел:** Удержание
- **Время:** 75 минут на первый разбор

Перед регистрацией, верификацией или операцией человек часто останавливается не из-за слабой кнопки, а из-за конкретного сомнения. Ответьте на него прямо в момент решения.

#### Результат

Карточка одного сомнения: вопрос пользователя, подтверждённый ответ, место в интерфейсе, владелец и метрика проверки.

#### Доверие появляется из ясного ответа, а не из обещания

Момент доверия — это короткое объяснение рядом с важным действием: зачем нужны данные, что произойдёт после нажатия, сколько займёт процесс и куда обратиться при проблеме. Оно должно подтверждаться реальной работой продукта.

#### Что понадобится

- **Один экран:** Выберите шаг с заметным отказом: регистрация, загрузка документа, подтверждение операции или первое пополнение.
- **Живые вопросы:** 10–20 обращений, отзывов или причин отмены, относящихся именно к выбранному шагу.
- **Проверка ответа:** Представитель поддержки и владелец процесса, которые подтвердят срок, условия и безопасный канал помощи.

#### Термины простыми словами

- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **FTD — Первый депозит пользователя:** Определение: Первый случай, когда зарегистрированный пользователь пополняет счёт. Это бизнес-результат всего пути, а не отдельная кнопка, которую нужно агрессивнее продвигать. Пример: Если регистрацию закончили 100 человек, а первый депозит сделали 24, FTD-конверсия равна 24%.

#### Когда применять

Пользователи доходят до важного действия, но откладывают или отменяют его, а поддержка регулярно отвечает на один и тот же вопрос об условиях, данных или статусе.

#### Где найти настоящее сомнение

Не угадывайте страх пользователя по макету. Соедините падение в данных с его словами и фактическими правилами процесса.

- **Отказы на шаге**
  - **Источник:** В воронке сравните открытие экрана, нажатие главной кнопки, успешное завершение и техническую ошибку.
  - **Если доступа нет:** Без аналитики проведите десять проходов и попросите трёх новых пользователей вслух объяснить, почему они готовы или не готовы продолжить.
- **Поддержка и отмены**
  - **Источник:** Сгруппируйте вопросы: зачем нужны данные, безопасно ли, сколько ждать, какие условия и что делать при ошибке.
  - **Если доступа нет:** Если теги не настроены, вручную разберите последние 20 сообщений по выбранному сценарию.
- **Реальный процесс**
  - **Источник:** Сверьте ответ с операционной командой, поддержкой и юридическим специалистом там, где речь идёт об условиях или данных.
  - **Если доступа нет:** Если команда не может подтвердить обещание, не публикуйте его — сначала исправьте процесс или сформулируйте честное ограничение.

#### Снимите одно главное сомнение

1. **Выберите один критичный экран.** Начните с шага, где отказ заметен и действие требует доверия. Не пытайтесь одновременно переписать весь путь.
   - **Где сделать:** Воронка регистрации, верификации или ключевой операции.
   - **Пример:** Экран загрузки документа: 1 000 открытий, 540 успешных отправок, 90 технических ошибок.
2. **Соберите слова пользователей.** Выпишите повторяющиеся вопросы без внутренних формулировок команды. Один вопрос должен звучать так, как его задаёт человек.
   - **Где сделать:** Обращения поддержки, отзывы, отмены и наблюдения за прохождением.
   - **Пример:** «Кто увидит документ?», «Сколько ждать?», «Можно закончить позже?».
3. **Выберите главное сомнение.** Оцените частоту, влияние на завершение и риск для доверия. Возьмите один вопрос, на который команда может дать честный ответ.
   - **Где сделать:** В первой строке карты сомнения.
   - **Пример:** Главный вопрос — «что произойдёт с документом после отправки?».
4. **Поставьте ответ рядом с действием.** Покажите срок, следующий шаг, условия или помощь до нажатия, а не в далёком разделе помощи.
   - **Где сделать:** Над полем, под CTA или на экране подтверждения — там, где возникает вопрос.
   - **Пример:** Под кнопкой: «Проверка обычно занимает до 10 минут. Статус появится на этом экране».
5. **Проверьте обещание и эффект.** Убедитесь, что продукт выполняет написанное. После релиза сравните завершение шага и обращения по теме сомнения.
   - **Где сделать:** На тестовом аккаунте и в отчёте через 14 дней.
   - **Пример:** Статус действительно обновляется, а обращения «сколько ждать» снизились с 34 до 12 в неделю.

#### Примеры из практики

- **Сомнение: что будет с документом:** Над загрузкой команда объясняет цель проверки, рядом с кнопкой — обычный срок до 10 минут, после отправки — видимый статус и канал помощи. Все четыре обещания проверены реальным процессом.
- **Сомнение: операция завершилась?:** Вместо общего «В обработке» экран показывает этап, ожидаемый срок и безопасное действие при задержке. Проверка — завершение шага и число обращений о статусе через 14 дней.

#### Готовый артефакт: Карта сомнения на одном экране

Не добавляйте общий блок «Нам можно доверять». Дайте короткий проверяемый ответ на конкретный вопрос в месте решения.

| Вопрос пользователя | Подтверждённый ответ | Где показать | Проверка |
| --- | --- | --- | --- |
| Зачем нужен документ? | Для проверки личности; данные защищены | Над полем загрузки | Согласовано с процессом |
| Сколько это займёт? | Обычно до 10 минут | Рядом с CTA | Сверено за 30 дней |
| Что будет дальше? | Покажем статус и отправим уведомление | Под кнопкой | Статус реально обновляется |
| Если возникнет ошибка? | Можно продолжить позже или написать в поддержку | На экране ошибки | Канал отвечает |
| Есть ли ограничения? | Условия доступны до подтверждения | Ссылка рядом с действием | Текст читается без поиска |

Первое изменение: объяснить срок проверки и следующий шаг прямо на экране загрузки документа. Владелец — продукт + поддержка. Проверка: завершение шага и обращения о статусе через 14 дней.

#### Чек-лист доверия

Если ответ нельзя подтвердить процессом или данными, его нельзя использовать как успокаивающий текст.

- [ ] Выбран один экран и одно конкретное сомнение.
- [ ] Сомнение подтверждено словами пользователей или причинами отмены.
- [ ] Ответ содержит факт: зачем, срок, следующий шаг, условия или помощь.
- [ ] Текст расположен рядом с действием и читается без перехода в раздел помощи.
- [ ] Обещание проверено владельцем процесса и связано с метрикой результата.

#### Как понять, что момент доверия помогает

- **Завершение шага:** Конверсия выбранного действия выросла без дополнительного давления на пользователя.
- **Понятность:** Снизились обращения и отмены по тому сомнению, на которое отвечает новый текст.
- **Реальность обещания:** Сроки, статусы и канал помощи соответствуют написанному после релиза.

#### Главное правило

Не маскируйте тревогу яркой кнопкой: дайте честный проверяемый ответ там, где пользователь принимает решение.

---

### Анализируйте удержание по когортам

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/retention-cohorts/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/retention-cohorts/index.md
- **Раздел:** Удержание
- **Время:** 90 минут на первый отчёт

Общий процент удержания смешивает разных пользователей и редко объясняет, что исправлять. Разделите людей на сравнимые группы и найдите одно отличие, связанное с конкретным опытом.

#### Результат

Одна когортная таблица, заметное отличие между группами, вероятная причина и решение для проверки в следующем периоде.

#### Когорта — это группа, которая начала путь вместе

Представьте классы одного курса: группа начала пользоваться приложением в одну неделю, поэтому её поведение можно сравнивать с соседней неделей. Затем внутри группы проверяют одно различие — платформу, страну или первое полезное действие.

#### Что понадобится

- **Отчёт:** AppMetrica, Firebase, Amplitude или таблица с датой первого запуска и последующими визитами пользователя.
- **Определения:** Одна трактовка установки, регистрации, визита, первого полезного действия и FTD для всей команды.
- **Период:** Минимум 4–6 полных недель, чтобы сравнение D7 не включало ещё не наступившие дни.

#### Термины простыми словами

- **Retention — Доля пользователей, которые вернулись:** Определение: Показывает, сколько людей снова открыли приложение через определённое время после установки или регистрации. Пример: Если из 100 новых пользователей через 7 дней вернулись 18, D7 retention равен 18%.
- **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей.
- **Когорта — Группа пользователей с общей датой или признаком:** Определение: Когорты позволяют сравнивать похожих пользователей, не смешивая разные периоды, версии и рынки. Пример: Пользователи, установившие приложение в одну неделю, — одна недельная когорта.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **FTD — Первый депозит пользователя:** Определение: Первый случай, когда зарегистрированный пользователь пополняет счёт. Это бизнес-результат всего пути, а не отдельная кнопка, которую нужно агрессивнее продвигать. Пример: Если регистрацию закончили 100 человек, а первый депозит сделали 24, FTD-конверсия равна 24%.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Команда видит среднее удержание, но не понимает, какая группа изменилась, после какого релиза и с каким пользовательским опытом это связано.

#### Как собрать первый отчёт

Начните с недель первого запуска и одного разреза. Чем больше сегментов сразу, тем легче найти случайную разницу без понятного действия.

- **Отчёт Retention**
  - **Источник:** Создайте недельные когорты по первому запуску и выведите D1, D7 и D30 только для завершившихся периодов.
  - **Если доступа нет:** В таблице сохраните дату первого запуска и даты следующих активных дней; посчитайте, вернулся ли человек через 1, 7 и 30 дней.
- **Первое полезное действие**
  - **Источник:** Разделите одну когорту на тех, кто получил первую ценность в первую сессию, и тех, кто не получил.
  - **Если доступа нет:** Если события нет, используйте ближайший подтверждённый результат: сохранение объекта, завершение урока или успешную верификацию.
- **История изменений**
  - **Источник:** Поставьте рядом версии приложения, крупные релизы и кампании — они могут объяснить отличие между неделями.
  - **Если доступа нет:** Если журнала изменений нет, соберите календарь релизов из стора и дат запуска основных коммуникаций.

#### Соберите полезное когортное сравнение

1. **Зафиксируйте начало и возврат.** Выберите одно событие начала — обычно первый запуск или регистрация — и одно правило активного дня. Не меняйте определения между группами.
   - **Где сделать:** В описании отчёта над таблицей.
   - **Пример:** Когорта — неделя первого запуска; возврат — любое полезное действие, а не техническое открытие в фоне.
2. **Возьмите полные недели.** Сравнивайте только группы, у которых нужный день уже наступил. Нельзя оценивать D30 для пользователей, пришедших десять дней назад.
   - **Где сделать:** В фильтре периода отчёта.
   - **Пример:** Для D7 берём когорты, завершившиеся не менее восьми дней назад.
3. **Добавьте один разрез.** Выберите платформу, версию, страну или первое полезное действие. Один разрез помогает связать различие с конкретным опытом.
   - **Где сделать:** В строках или фильтре когортной таблицы.
   - **Пример:** Сравниваем Android 4.2 и iOS той же недели, а не сразу платформу × страну × источник × кампанию.
4. **Найдите устойчивое отличие.** Проверьте размер группы и соседние недели. Маленькая разница в 20 пользователях не должна становиться большим продуктовым выводом.
   - **Где сделать:** В колонках размера, D1 и D7.
   - **Пример:** D7 Android 4.2 ниже на 8 п.п. три недели подряд при размере более 500 пользователей.
5. **Свяжите вывод с проверкой.** Запишите вероятную причину, владельца и одно изменение или исследование. Отчёт без следующего действия не помогает продукту.
   - **Где сделать:** В последней колонке и задаче команды.
   - **Пример:** Проверить новый экран онбординга Android 4.2; владелец — мобильная команда; срок — следующая неделя.

#### Примеры из практики

- **Просадка не у всех, а в Android 4.2:** D7 ниже на 8 п.п. три недели подряд при размере более 500 пользователей; iOS той же недели стабилен. Решение — проверить изменения онбординга версии 4.2, а не писать всем.
- **Первая ценность объясняет разницу:** Получившие полезный результат в первую сессию имеют D7 28%, остальные — 5%. Команда делает путь к результату заметнее и проверяет следующую недельную когорту.

#### Готовый артефакт: Одна таблица — один вывод

Сначала сравните четыре группы по одному признаку. Не превращайте первый отчёт в десятки фильтров.

| Когорта / сегмент | Размер | D1 | D7 | Вывод и действие |
| --- | --- | --- | --- | --- |
| Неделя 3–9 июня · все | 2 400 | 32% | 14% | Точка отсчёта |
| Получили первую ценность | 1 080 | 51% | 28% | Сделать путь заметнее |
| Не получили ценность | 1 320 | 17% | 5% | Проверить онбординг |
| Android · версия 4.2 | 620 | 24% | 8% | Проверить релиз 4.2 |
| iOS · та же неделя | 710 | 35% | 16% | Нет общей просадки |

Вывод: проблема сосредоточена в Android 4.2 и у пользователей без первой ценности. Первое действие — проверить изменения онбординга этой версии, а не запускать общую рассылку всем.

#### Чек-лист отчёта

Перед выводом убедитесь, что сравниваете сопоставимые группы и завершившиеся периоды.

- [ ] Начало когорты и активный день определены одинаково для всех строк.
- [ ] D1, D7 и D30 рассчитаны только для завершившихся периодов.
- [ ] Есть размер каждой группы и выбран только один основной разрез.
- [ ] Рядом отмечены версии приложения, релизы и крупные кампании.
- [ ] Вывод заканчивается одним действием, владельцем и датой проверки.

#### Как понять, что анализ полезен

- **Ясность сегмента:** Команда может назвать конкретную группу и отличие, а не только общий процент удержания.
- **Повторяемость:** Отличие видно на достаточном размере и не исчезает при проверке соседних недель.
- **Решение:** По результату принято одно действие, и следующая когорта покажет, изменился ли выбранный сценарий.

#### Главное правило

Не ищите среднего пользователя: найдите конкретную группу, понятный барьер и одно решение, которое можно проверить на следующей когорте.

---

### Создавайте полезные поводы для возвращения

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/retention-content/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/retention-content/index.md
- **Раздел:** Удержание
- **Время:** 90 минут на первый календарь

Контент удерживает не количеством публикаций, а связью с личным интересом и действием пользователя. Сначала определите, кому и зачем нужен повод, затем выбирайте канал.

#### Результат

Недельный календарь из пяти поводов с аудиторией, пользой, экраном назначения, ограничением частоты и метрикой действия.

#### Повод — это полезное изменение для конкретного человека

Новая статья сама по себе ещё не причина писать всем. Повод появляется, если материал отвечает на сохранённый интерес, помогает продолжить путь или объясняет реальное изменение. Пользователь должен понять пользу до открытия сообщения.

#### Что понадобится

- **Сигнал интереса:** Сохранение, подписка, просмотр темы, незавершённый урок или другой подтверждённый интерес пользователя.
- **Владелец контента:** Редактор, специалист по коммуникациям или менеджер продукта, который проверяет точность, срок актуальности и экран назначения.
- **Правила частоты:** Общий лимит сообщений и исключения для недавно активных или уже получивших похожий повод.

#### Термины простыми словами

- **Retention — Доля пользователей, которые вернулись:** Определение: Показывает, сколько людей снова открыли приложение через определённое время после установки или регистрации. Пример: Если из 100 новых пользователей через 7 дней вернулись 18, D7 retention равен 18%.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **CTA — Главное действие, которое предлагается пользователю:** Определение: CTA — это кнопка или ссылка с понятным следующим шагом и ожидаемым результатом. Пример: «Продолжить регистрацию» конкретнее и полезнее, чем «Далее».

#### Когда применять

Приложение отправляет общие напоминания, контент планируется отдельно от поведения пользователя, а переходы есть, но полезные действия после них не растут.

#### Где брать полезные поводы

Не начинайте с календаря праздников. Ищите связь между реальным изменением, интересом пользователя и доступным действием в продукте.

- **Сохранения и просмотры**
  - **Источник:** Посмотрите, какие темы, объекты или уроки люди сохраняют, читают повторно и проходят до конца.
  - **Если доступа нет:** Без событий используйте поисковые запросы, самые посещаемые страницы и ручную подборку частых интересов.
- **Поддержка и поиск**
  - **Источник:** Соберите повторяющиеся вопросы и запросы без результата — они подсказывают, какого объяснения или материала не хватает.
  - **Если доступа нет:** Раз в неделю отмечайте пять самых частых вопросов поддержки в общей таблице.
- **Изменения продукта**
  - **Источник:** Добавляйте обновлённый статус, новый материал или функцию только если они релевантны выбранному сегменту прямо сейчас.
  - **Если доступа нет:** Если персонализация недоступна, публикуйте повод внутри соответствующего раздела, а не отправляйте массовое уведомление.

#### Соберите календарь полезных поводов

1. **Соберите реальные изменения.** Запишите статусы, новые материалы, обновления и незавершённые действия, которые действительно будут доступны на следующей неделе.
   - **Где сделать:** В первом столбце календаря вместе с датой актуальности.
   - **Пример:** В сохранённой теме появился новый разбор; урок получил продолжение; изменился статус заявки.
2. **Привяжите повод к интересу.** Укажите подтверждённое действие, по которому человек относится к аудитории. Не используйте слишком широкий сегмент «все пользователи».
   - **Где сделать:** В условии аудитории сообщения.
   - **Пример:** Сохранял тему или читал её дважды за 30 дней, но ещё не видел новый материал.
3. **Сформулируйте одну пользу.** Ответьте, что пользователь сможет узнать, продолжить, сравнить или проверить. Польза должна быть ясна до открытия.
   - **Где сделать:** В заголовке и первой строке сообщения.
   - **Пример:** «В сохранённой подборке появился новый разбор» вместо «Не пропустите обновления».
4. **Подготовьте точный маршрут.** После нажатия откройте материал, сохранённый шаг или нужную подборку. Главный экран разрушает контекст повода.
   - **Где сделать:** В deep link и тестовом аккаунте.
   - **Пример:** Сообщение о разборе открывает сам разбор внутри сохранённой темы.
5. **Ограничьте конкурирующие поводы.** Задайте частоту и приоритеты. Один пользователь не должен получить три сообщения от разных команд за один вечер.
   - **Где сделать:** В системе коммуникаций и последнем столбце календаря.
   - **Пример:** Максимум два полезных сообщения в неделю; сервисные статусы выше контентных подборок.

#### Примеры из практики

- **Обновление сохранённой темы:** Сообщение получают только читавшие или сохранявшие тему за 30 дней. Оно называет новый разбор и открывает его внутри личной подборки — один раз на событие.
- **Недельный обзор без перегрузки:** Обзор объединяет изменения только по подтверждённым интересам пользователя и не отправляется тем, кто уже видел материалы. Общий лимит — два полезных сообщения в неделю.

#### Готовый артефакт: Календарь поводов на одну неделю

Каждая строка отвечает на пять вопросов: кому, что изменилось, какая польза, куда ведём и как ограничиваем частоту.

| Повод и аудитория | Польза | Назначение | Ограничение |
| --- | --- | --- | --- |
| Обновление сохранённой темы | Увидеть новый разбор | Deep link в подборку | 1 раз на событие |
| Незавершённый урок | Продолжить с шага 3 | Сохранённый прогресс | Через 48 часов |
| Ответ на частый вопрос | Понять условие до действия | Статья помощи | Только заинтересованным |
| Недельный обзор | Собрать изменения по интересам | Личная лента | Не чаще 1 раза в неделю |
| Новая функция | Решить знакомую задачу быстрее | Экран функции | Только подходящему сегменту |

Перед публикацией удалите строку, если команда не может назвать личную пользу или открыть обещанный экран. Пять сильных поводов лучше двадцати общих сообщений.

#### Чек-лист повода

Удалите повод из календаря, если хотя бы один обязательный пункт нельзя проверить до отправки.

- [ ] Есть подтверждённый интерес или незавершённое действие пользователя.
- [ ] Польза понятна до открытия и реально доступна в продукте.
- [ ] Deep link ведёт в обещанный материал или сохранённый шаг.
- [ ] Недавно активные и уже увидевшие контент исключены.
- [ ] Задан общий лимит частоты и главная метрика полезного действия.

#### Как понять, что повод полезен

- **Дошли до содержания:** Пользователи открыли именно обещанный материал или сохранённый сценарий.
- **Сделали полезное действие:** Материал дочитан, объект сохранён, урок продолжен или статус просмотрен.
- **Не потеряли доверие:** Не выросли отключения уведомлений, жалобы и игнорирование следующих сообщений.

#### Главное правило

Событие становится поводом только тогда, когда оно полезно конкретному пользователю и ведёт к реальному действию.

---

### Проводите регулярный продуктовый разбор

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/retention-review/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/retention-review/index.md
- **Раздел:** Удержание
- **Время:** 60 минут на первый разбор

Продуктовый разбор — не встреча для демонстрации всех цифр. Команда связывает изменения с результатом и выбирает не больше трёх следующих решений.

#### Результат

Одностраничный протокол: здоровье продукта, три изменения периода, один главный вывод и до трёх решений с владельцами.

#### Встреча нужна, чтобы уменьшить список задач

За один период команда могла выпустить релиз, изменить онбординг и запустить сообщения. Разбор отвечает: что произошло с опытом пользователя, какое изменение могло повлиять и что проверяем дальше. Итогом становятся решения, а не набор слайдов.

#### Что понадобится

- **Участники:** Менеджер продукта, аналитик или владелец данных, технический представитель, поддержка и специалист по коммуникациям.
- **Один экран:** 5–7 показателей качества, первого полезного пути, удержания, обращений и коммуникаций в динамике.
- **Ритм:** Еженедельно для быстро меняющегося продукта или ежемесячно для стабильного; один и тот же период сравнения.

#### Термины простыми словами

- **Retention — Доля пользователей, которые вернулись:** Определение: Показывает, сколько людей снова открыли приложение через определённое время после установки или регистрации. Пример: Если из 100 новых пользователей через 7 дней вернулись 18, D7 retention равен 18%.
- **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей.
- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **FTD — Первый депозит пользователя:** Определение: Первый случай, когда зарегистрированный пользователь пополняет счёт. Это бизнес-результат всего пути, а не отдельная кнопка, которую нужно агрессивнее продвигать. Пример: Если регистрацию закончили 100 человек, а первый депозит сделали 24, FTD-конверсия равна 24%.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Команда выпускает изменения, но не возвращается к их эффекту; встречи превращаются в отчёт по цифрам, а список задач только растёт.

#### Что подготовить до встречи

Не собирайте десятки дашбордов. Принесите только данные, изменения и живые сигналы, необходимые для решения в этом периоде.

- **Экран здоровья**
  - **Источник:** Покажите crash-free, конверсию первого пути, FTD, D1/D7, обращения и реакцию на сообщения рядом с прошлым периодом.
  - **Если доступа нет:** Без единого дашборда соберите семь чисел в таблице и укажите источник, период и владельца каждого.
- **Журнал изменений**
  - **Источник:** Запишите три главных релиза, эксперимента или коммуникации периода с датами и ожидаемым эффектом.
  - **Если доступа нет:** Если журнал не вёлся, восстановите изменения по задачам, версиям в сторе и календарю отправок.
- **Живые сигналы**
  - **Источник:** Добавьте три повторяющиеся темы поддержки или отзывов и один конкретный пример пользовательского пути.
  - **Если доступа нет:** Попросите поддержку заранее выбрать пять характерных обращений вместо общего впечатления «жалоб стало больше».

#### Проведите продуктовый разбор за 60 минут

1. **Покажите здоровье продукта.** Начните с 5–7 показателей в динамике и отметьте только существенные изменения. Не обсуждайте каждую цифру по очереди.
   - **Где сделать:** На одном экране с периодом, источниками и прошлым значением.
   - **Пример:** Crash-free 99,6% без изменения; первая ценность +8 п.п.; D7 без изменения; вопросы о статусе +40%.
2. **Поставьте рядом изменения.** Назовите три главных релиза или коммуникации с датой и ожидаемым эффектом. Не приписывайте причинность без проверки.
   - **Где сделать:** Во второй колонке протокола.
   - **Пример:** 3 июня сократили онбординг; 7 июня выпустили новый экран статуса; 10 июня изменили push-маршрут.
3. **Добавьте голос пользователя.** Покажите повторяющиеся вопросы и один характерный путь. Качественный сигнал помогает понять, что скрывается за метрикой.
   - **Где сделать:** Рядом с соответствующим показателем.
   - **Пример:** 12 пользователей спрашивают, завершилась ли операция, хотя технической ошибки нет.
4. **Выберите один главный вывод.** Сформулируйте проблему или возможность одним предложением. Не смешивайте качество, удержание и рост в одну абстрактную тему.
   - **Где сделать:** В заметном блоке перед решениями.
   - **Пример:** Новый экран работает технически, но не объясняет статус — это создаёт обращения и недоверие.
5. **Ограничьте решения тремя.** У каждого решения должны быть владелец, срок и сигнал проверки на следующем разборе. Остальные идеи явно отложите.
   - **Где сделать:** В последней колонке протокола и списке задач.
   - **Пример:** Добавить статус — Анна — 21 июня — обращения по теме и завершение действия.

#### Примеры из практики

- **Сигнал превращается в решение:** После нового экрана технические показатели стабильны, но вопросы о статусе выросли на 40%. Вывод — неясный процесс; решение — добавить статус, владельца и проверку обращений.
- **Три решения вместо двадцати идей:** Команда исправляет маршрут push, объясняет статус операции и проверяет следующую когорту. Остальные идеи явно отложены до следующего разбора.

#### Готовый артефакт: Протокол продуктового разбора

Не переписывайте все обсуждения. Зафиксируйте сигнал, связь с изменением и решение, которое можно проверить.

| Сигнал | Что изменилось | Вывод | Решение и владелец |
| --- | --- | --- | --- |
| Crash-free стабилен | Релиз 4.3 | Технического ухудшения нет | Наблюдать · мобильная команда |
| Первая ценность +8 п.п. | Сократили онбординг | Изменение помогает | Расширить на Android · продукт |
| D7 без роста | Новый путь 2 недели | Эффект ещё не дошёл | Проверить следующую когорту · аналитик |
| Вопросы о статусе +40% | Новый экран операции | Не хватает объяснения | Добавить статус · дизайн + поддержка |
| Push открывают, действие не растёт | Общий deep link | Теряется контекст | Исправить маршрут · коммуникации |

Фокус периода: объяснить статус операции. Не больше трёх решений: исправить маршрут, обновить текст статуса, проверить следующую когорту. Остальные идеи остаются вне плана до следующего разбора.

#### Чек-лист встречи

Не начинайте встречу, пока данные и изменения не собраны: время группы должно уходить на решения.

- [ ] На одном экране есть 5–7 показателей с динамикой и единым периодом.
- [ ] Названы три главных изменения периода и их ожидаемый эффект.
- [ ] Поддержка принесла повторяющиеся темы и конкретные примеры.
- [ ] Сформулирован один главный вывод без неподтверждённой причинности.
- [ ] Принято не больше трёх решений с владельцами, сроками и метриками проверки.

#### Как понять, что разбор работает

- **Решения выполнены:** На следующей встрече команда начинает с прошлых договорённостей и фактического результата.
- **Фокус сохраняется:** В работу уходит не больше трёх согласованных действий, а новые идеи не вытесняют их без причины.
- **Опыт улучшается:** Выбранные сигналы качества, удержания или доверия меняются после выполненных решений.

#### Главное правило

Хороший продуктовый разбор уменьшает список задач и оставляет команде несколько решений, эффект которых можно проверить.

---

## Push-уведомления

### Возвращайте пользователя к ценному действию

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/push-trigger/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/push-trigger/index.md
- **Раздел:** Push-уведомления
- **Время:** 60 минут на первый сценарий

Хороший push начинается не с текста, а с события: для конкретного пользователя появилась причина вернуться прямо сейчас. Соберите один сценарий от условия отправки до полезного действия после нажатия.

#### Результат

Спецификация одного push-триггера: аудитория, событие, задержка, исключения, текст, deep link и метрика результата.

#### Триггер отвечает на вопрос «почему сейчас?»

Push-триггер — это правило отправки после конкретного события. Например, пользователь сохранил тему, в ней появился новый материал, и сообщение ведёт прямо к нему. Фраза «мы давно вас не видели» описывает интерес команды, но не пользу человека.

#### Что понадобится

- **Событие:** Подтверждённое действие или изменение: сохранение, незавершённый шаг, новый результат или обновление личного интереса.
- **Инструмент:** Firebase, OneSignal, Mindbox или другая система, где можно задать аудиторию, задержку и исключения.
- **Маршрут:** Рабочий deep link в нужный экран и аналитическое событие полезного действия после перехода.

#### Термины простыми словами

- **Push-уведомление — Короткое сообщение от приложения вне его интерфейса:** Определение: Появляется на устройстве и может вернуть пользователя к конкретному полезному действию. Отправляется только при наличии разрешения. Пример: Сообщение о новом материале в сохранённой теме открывает этот материал по deep link.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **CTA — Главное действие, которое предлагается пользователю:** Определение: CTA — это кнопка или ссылка с понятным следующим шагом и ожидаемым результатом. Пример: «Продолжить регистрацию» конкретнее и полезнее, чем «Далее».
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда стоит отправлять push

Запускайте сообщение только тогда, когда у пользователя появилась понятная причина вернуться именно сейчас.

- **Незавершённое действие:** Пользователь начал полезный сценарий, но не дошёл до результата, а прогресс действительно сохранён. Пример: «Продолжите с шага документа — предыдущие данные сохранены».
- **Появилась новая польза:** Вышел материал, статус или функция, связанные с подтверждённым интересом пользователя. Пример: «В сохранённой теме появился новый короткий разбор».
- **Личный прогресс:** Пользователь может увидеть результат или продолжить свою цель без повторного поиска. Пример: «Готов результат проверки — откройте статус и следующий шаг».

#### Что проверить до настройки

Сначала убедитесь, что событие правдивое, аудитория обновляется, а экран назначения работает. Красивый текст не исправит ошибочный триггер.

- **События продукта**
  - **Источник:** Проверьте, когда приходит событие начала и завершения действия и можно ли исключить тех, кто уже получил результат.
  - **Если доступа нет:** Без событий начните с одного надёжного серверного статуса и тестовой группы сотрудников.
- **История отправок**
  - **Источник:** Посмотрите, какие сообщения пользователь может получить рядом по времени, и задайте общий лимит.
  - **Если доступа нет:** Если единого журнала нет, соберите календарь активных отправок всех команд на одну неделю.
- **Deep link и аналитика**
  - **Источник:** На iOS и Android пройдите путь из закрытого приложения до обещанного экрана и полезного действия.
  - **Если доступа нет:** Если прямой маршрут не готов, не запускайте массовый push — сначала используйте внутреннее сообщение на релевантном экране.

#### Соберите первый триггер за пять шагов

1. **Выберите полезное действие.** Назовите результат после возвращения. «Открыть приложение» не подходит — нужен просмотр статуса, продолжение шага или чтение материала.
   - **Где сделать:** В строке «Успех» спецификации и аналитическом событии.
   - **Пример:** Прочитал новый разбор минимум наполовину после перехода из push.
2. **Опишите аудиторию событием.** Укажите действие и период, по которым пользователь попадает в сценарий. Не начинайте с широкой группы «неактивные».
   - **Где сделать:** В конструкторе сегмента CRM-системы.
   - **Пример:** Сохранил тему за последние 30 дней и ещё не открыл новый разбор.
3. **Задайте момент и исключения.** Определите задержку после события и тех, кому сообщение уже неактуально. Исключения проверяются перед самой отправкой.
   - **Где сделать:** В логике триггера и правилах частоты.
   - **Пример:** Отправить через 30 минут; исключить уже прочитавших, активных сейчас и получивших push за 24 часа.
4. **Напишите пользу и один CTA.** Сообщите, что изменилось и что можно сделать. Уберите общие призывы, давление и неподтверждённую срочность.
   - **Где сделать:** В заголовке и тексте уведомления.
   - **Пример:** «В сохранённой теме появился новый разбор. Откройте материал» вместо «Срочно вернитесь!».
5. **Проверьте маршрут до результата.** Push должен открыть нужный экран после входа и из закрытого приложения. Зафиксируйте событие целевого действия.
   - **Где сделать:** На тестовых iOS- и Android-устройствах.
   - **Пример:** Нажатие открывает новый разбор, а после 50% чтения приходит событие content_half_read.

#### Примеры из практики

- **Подходящий профиль получает, исключённый — нет:** Пользователь сохранил тему и ещё не читал новый разбор — push приходит один раз. Уже прочитавший и получивший другое сообщение сегодня исключаются перед отправкой.
- **Маршрут заканчивается действием:** Push «В сохранённой теме появился новый разбор» открывает сам материал. Успех — чтение минимум 50%, а не только открытие приложения.

#### Готовый артефакт: Спецификация первого push-триггера

Одной карточки достаточно, чтобы продукт, CRM, разработка и аналитика одинаково понимали сценарий.

| Поле | Решение | Как проверить |
| --- | --- | --- |
| Аудитория | Сохранили тему за 30 дней | Сегмент обновляется ежедневно |
| Триггер | В теме появился новый разбор | Событие приходит один раз |
| Задержка | Через 30 минут после публикации | Контент уже доступен |
| Исключения | Уже прочитали или получили push сегодня | Тестовые профили исключаются |
| Назначение | Deep link в новый разбор | iOS/Android открывают экран |
| Успех | Разбор прочитан до 50% | Событие видно после перехода |

Перед запуском проверьте три тестовых профиля: подходящий получает push, исключённый не получает, а уже прочитавший не получает повторное сообщение.

#### Заполненный шаблон: Соберите сообщение

Заполните карточку — справа появится рабочий черновик первого push.

- **Кому:** Сохранили тему за последние 30 дней и ещё не видели новый разбор
- **Что изменилось:** В сохранённой теме появился новый материал
- **Текст push:** В вашей сохранённой теме появился новый короткий разбор. Откройте материал, когда будет удобно.

#### Ограничения и безопасность: Не давите на пользователя

Не обещайте прибыль, не создавайте фейковую срочность и не используйте push как прямое давление на депозит. Доверие и своевременность важнее разового клика.

#### Чек-лист перед запуском

Сначала прогоните сценарий на трёх тестовых профилях, затем запускайте на небольшой реальной группе.

- [ ] У пользователя есть подтверждённая причина вернуться именно сейчас.
- [ ] Аудитория, задержка и исключения описаны событиями и периодами.
- [ ] Текст называет реальную пользу без обещаний дохода и фейковой срочности.
- [ ] Deep link открывает обещанный экран на iOS и Android.
- [ ] Главная метрика — полезное действие после перехода, а не только открытие.

#### Как понять, что триггер помогает

- **Техническое качество:** Событие срабатывает один раз, исключения работают, а deep link открывает нужный экран.
- **Полезное действие:** Получившие push завершают обещанный сценарий чаще сопоставимой группы без сообщения.
- **Доверие:** Не растут отключения уведомлений, жалобы и повторные сообщения уже завершившим действие.

#### Главное правило

Первый хороший триггер — это одна правдивая причина, точный маршрут и полезное действие после перехода.

---

### Настройте частоту, а не увеличивайте объём

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/push-frequency/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/push-frequency/index.md
- **Раздел:** Push-уведомления
- **Время:** 75 минут на первую настройку

Пользователь видит все сообщения как один поток, даже если их отправляют разные команды. Соберите общий календарь и задайте правила, которые защищают человека от повторов и конкурирующих push.

#### Результат

Одностраничная политика частоты: типы сообщений, приоритеты, общий лимит, паузы, исключения и владелец контроля.

#### У пользователя один лимит внимания на все команды

Команды коммуникаций, продукта и поддержки могут считать свои сообщения полезными, но человек получает их в одну ленту. Частотная политика решает, сколько сообщений допустимо, какое важнее и когда следующий push нужно отменить.

#### Что понадобится

- **Общий список:** Все сервисные, продуктовые и контентные сообщения, которые могут прийти одному пользователю за семь дней.
- **История:** Журнал отправок на уровне тестовых профилей или выборка реальных пользователей с датой, сценарием и результатом.
- **Владелец:** Один человек, который согласует конфликты между командами и регулярно проверяет отписки и жалобы.

#### Термины простыми словами

- **Push-уведомление — Короткое сообщение от приложения вне его интерфейса:** Определение: Появляется на устройстве и может вернуть пользователя к конкретному полезному действию. Отправляется только при наличии разрешения. Пример: Сообщение о новом материале в сохранённой теме открывает этот материал по deep link.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.

#### Когда применять

Пользователи получают несколько сообщений за день, разные команды запускают кампании независимо, а отключения уведомлений или жалобы растут.

#### Где увидеть реальную нагрузку

Не складывайте только запланированные кампании. Учитывайте автоматические триггеры и сервисные статусы, которые запускаются событиями.

- **Календарь отправок**
  - **Источник:** Соберите ручные кампании и автоматические сценарии всех команд в одну недельную таблицу.
  - **Если доступа нет:** Если единого инструмента нет, попросите каждого владельца выгрузить название, аудиторию, момент и максимальное число отправок.
- **История пользователя**
  - **Источник:** Найдите профили с наибольшим числом сообщений и восстановите их ленту по часам.
  - **Если доступа нет:** Создайте три тестовых профиля, подходящих сразу под несколько сценариев, и наблюдайте неделю.
- **Негативные сигналы**
  - **Источник:** Смотрите отключения уведомлений, жалобы, удаления и обращения рядом с числом push на человека.
  - **Если доступа нет:** Если прямой связи нет, сравните недели с высокой и обычной нагрузкой и заведите событие отключения разрешения.

#### Настройте безопасную частоту

1. **Соберите все сценарии.** Запишите ручные кампании, автоматические триггеры и сервисные статусы. Для каждого укажите максимальную частоту на одного человека.
   - **Где сделать:** В общем календаре коммуникаций.
   - **Пример:** Верификация — до 2 напоминаний; новый материал — 2 в неделю; общий обзор — 1 в неделю.
2. **Разделите по пользовательской важности.** Сервисный статус и безопасность выше контентного повода. Внутренняя бизнес-цель не должна автоматически повышать приоритет.
   - **Где сделать:** В колонке приоритета политики.
   - **Пример:** Статус операции отправляется, а общий обзор в тот же день отменяется.
3. **Задайте общий лимит.** Ограничьте суммарное число необязательных сообщений и минимальную паузу между ними. Лимит действует поверх правил отдельных команд.
   - **Где сделать:** В настройках коммуникационной платформы.
   - **Пример:** Не более одного необязательного push за 24 часа и трёх за семь дней.
4. **Добавьте взаимные исключения.** После полезного действия, недавнего визита или похожего сообщения человек должен выйти из конкурирующих сценариев.
   - **Где сделать:** В условиях сегментов перед отправкой.
   - **Пример:** Завершил урок → исключить напоминание; получил личный разбор → исключить общий обзор на 24 часа.
5. **Проверяйте самые нагруженные профили.** Раз в неделю смотрите не только среднее, но и пользователей с максимальным числом сообщений. Именно там правила чаще всего конфликтуют.
   - **Где сделать:** В отчёте по сообщениям на пользователя.
   - **Пример:** Среднее — 1,8 push, но 4% пользователей получили 7+; найдено пересечение двух триггеров.

#### Примеры из практики

- **Сервисный статус отменяет общий контент:** Пользователь получил важный статус операции. Общий обзор в тот же день отменяется, а следующий необязательный push возможен только через 24 часа.
- **Среднее скрывало перегруженную группу:** Средняя нагрузка была 1,8 push в неделю, но 4% пользователей получали 7+. После взаимных исключений общий лимит соблюдается и повторные жалобы снижаются.

#### Готовый артефакт: Политика частоты на одну страницу

Правила должны применяться перед каждой отправкой, а не оставаться рекомендацией в документе.

| Тип | Приоритет | Лимит | Пауза и исключения |
| --- | --- | --- | --- |
| Безопасность и статус | 1 · обязательный | По событию | Не блокируется промо-лимитом |
| Незавершённое действие | 2 · полезный | 1 на сценарий | Отмена после завершения |
| Личный интерес | 3 · полезный | До 2 в неделю | Пауза 24 часа после другого push |
| Общий контент | 4 · необязательный | 1 в неделю | Не отправлять недавно активным |
| Все необязательные | Общий лимит | Не более 3 в неделю | Не более 1 за 24 часа |

При конфликте остаётся сообщение с более высокой пользой для пользователя. Владелец правил раз в неделю проверяет десять самых нагруженных профилей и негативные сигналы.

#### Ограничения и безопасность: Не компенсируйте слабый сценарий частотой

Если сообщение не даёт повода вернуться, повторная отправка не сделает его полезнее. Сначала исправьте причину, текст или маршрут.

#### Чек-лист частоты

Политика готова только тогда, когда правила можно проверить на конкретном профиле пользователя.

- [ ] В одном списке есть ручные, триггерные и сервисные сообщения всех команд.
- [ ] У сообщений назначен приоритет по пользе для пользователя.
- [ ] Есть общий лимит и минимальная пауза между необязательными push.
- [ ] Завершившие действие, недавно активные и получившие похожее сообщение исключаются.
- [ ] Назначен владелец еженедельной проверки нагрузки, отписок и жалоб.

#### Как понять, что частота стала безопаснее

- **Нагрузка:** Снижается доля пользователей, которые получают больше общего лимита за день и неделю.
- **Доверие:** Отключения уведомлений и жалобы не растут при сохранении полезных сценариев.
- **Польза:** Целевые действия на одно сообщение сохраняются или растут после удаления конкурирующих отправок.

#### Главное правило

При конфликте двух сценариев отправляйте тот, у которого выше ценность для пользователя, а не выше внутренняя бизнес-цель.

---

### Давайте пользу вместо давления

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/push-value/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/push-value/index.md
- **Раздел:** Push-уведомления
- **Время:** 75 минут на ревизию

Полезный push честно отвечает на три вопроса: что изменилось, почему это относится ко мне и что я смогу сделать после нажатия. Срочность без факта и обещание без экрана назначения разрушают доверие.

#### Результат

Таблица ревизии из пяти сообщений: проблема исходного текста, проверяемая польза, новая формулировка и соответствующий экран.

#### Сначала факт, затем польза и один следующий шаг

Фраза «успейте прямо сейчас» создаёт давление, но не объясняет ценность. Лучше назвать реальное изменение — готов статус, появился материал, сохранён прогресс — и предложить одно действие, которое пользователь увидит после перехода.

#### Что понадобится

- **Активные тексты:** Выгрузка регулярных и триггерных push с аудиторией, условием отправки и частотой.
- **Экраны назначения:** Ссылки или тестовые deep link для проверки каждого обещания после нажатия.
- **Проверяющий:** Владелец продукта или контента и представитель поддержки для проверки фактов, условий и понятности.

#### Термины простыми словами

- **Push-уведомление — Короткое сообщение от приложения вне его интерфейса:** Определение: Появляется на устройстве и может вернуть пользователя к конкретному полезному действию. Отправляется только при наличии разрешения. Пример: Сообщение о новом материале в сохранённой теме открывает этот материал по deep link.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **CTA — Главное действие, которое предлагается пользователю:** Определение: CTA — это кнопка или ссылка с понятным следующим шагом и ожидаемым результатом. Пример: «Продолжить регистрацию» конкретнее и полезнее, чем «Далее».

#### Когда применять

В сообщениях много общих призывов, страха упущенной выгоды, давления на депозит или обещаний, которые не подтверждаются экраном после перехода.

#### Как проверить обещание

Не оценивайте текст отдельно от события и экрана. Сообщение полезно только тогда, когда факт правдив, а обещанный результат доступен.

- **История кампаний**
  - **Источник:** Возьмите пять самых частых или массовых сообщений и добавьте условие отправки, аудиторию и результат после перехода.
  - **Если доступа нет:** Если выгрузки нет, соберите тексты из календаря команды и тестовых уведомлений на устройстве.
- **Экран после нажатия**
  - **Источник:** Пройдите каждый deep link и сравните заголовок push с тем, что реально видно на первом экране.
  - **Если доступа нет:** Без прямой ссылки запишите ручной маршрут и не обещайте действие, до которого пользователь не сможет быстро дойти.
- **Жалобы и отписки**
  - **Источник:** Найдите формулировки, после которых росли отключения, жалобы или вопросы «о чём это сообщение?».
  - **Если доступа нет:** Покажите тексты пяти коллегам вне команды и попросите объяснить ожидаемый экран и действие.

#### Перепишите сообщения через реальную пользу

1. **Соберите пять активных текстов.** Начните с самых массовых, частых или вызывающих жалобы сообщений. Добавьте аудиторию, триггер и экран назначения.
   - **Где сделать:** В таблице ревизии коммуникаций.
   - **Пример:** «Срочно вернитесь!» — неактивные 7 дней — ежедневная отправка — главная страница.
2. **Назовите фактическое изменение.** Для каждого push ответьте, что реально произошло в данных или продукте. Если ничего не изменилось, полезного повода может не быть.
   - **Где сделать:** В колонке «Факт / триггер».
   - **Пример:** Готов результат проверки; появился материал в сохранённой теме; обновился статус заявки.
3. **Сформулируйте личную пользу.** Объясните, что пользователь сможет узнать, продолжить или проверить. Не обещайте доход, гарантированный результат или искусственную срочность.
   - **Где сделать:** В заголовке и первой строке нового текста.
   - **Пример:** «Готов результат проверки — откройте статус и следующий шаг».
4. **Оставьте один понятный CTA.** Сообщение должно вести к одному действию. Несколько обещаний и призывов усложняют выбор и маскируют слабую ценность.
   - **Где сделать:** В конце текста и на экране назначения.
   - **Пример:** Один CTA «Открыть результат», а не «Откройте, изучите и пополните».
5. **Сверьте текст с первым экраном.** После нажатия пользователь сразу должен увидеть обещанное. Проверьте маршрут из закрытого приложения и после входа.
   - **Где сделать:** На тестовых устройствах iOS и Android.
   - **Пример:** Push о результате открывает статус проверки, а не домашнюю ленту.

#### Примеры из практики

- **До: срочность без причины:** «Срочно вернитесь!» ведёт на главную страницу. После ревизии: «Готов результат проверки — откройте статус и следующий шаг» с deep link прямо в результат.
- **До: обещание без продукта:** «Не упустите шанс» заменено на проверяемый факт о новом материале в сохранённой теме. Если материал ещё недоступен, push не отправляется.

#### Готовый артефакт: Таблица «до → после → экран»

Перепишите сначала пять реальных сообщений. Для каждого новая формулировка должна подтверждаться событием и экраном.

| Исходный текст | Проблема | Новый текст | Что откроется |
| --- | --- | --- | --- |
| Срочно вернитесь! | Нет причины и давления | Готов результат проверки | Экран результата |
| Не упустите шанс | Непроверяемое обещание | В сохранённой теме новый разбор | Новый материал |
| Пополните сейчас | Давление на депозит | Изменились доступные способы | Условия и способы |
| У нас обновление | Польза не названа | Теперь можно продолжить с сохранённого шага | Сохранённый прогресс |
| Откройте приложение | Нет действия | Проверьте обновлённый статус заявки | Экран статуса |

Красный флаг: если экран после нажатия не показывает обещанное, текст нельзя «улучшить» отдельно — сначала нужен правильный маршрут или продуктовый результат.

#### Ограничения и безопасность: Пишите как продукт, а не как реклама

Сообщение должно помогать принять решение, а не подталкивать к действию любой ценой. Неподтверждённое обещание нельзя исправить более яркой формулировкой.

#### Чек-лист текста

Сообщение готово, если незнакомый с задачей человек может предсказать первый экран после нажатия.

- [ ] Названо реальное изменение, которое уже произошло.
- [ ] Понятно, почему сообщение относится к конкретному пользователю.
- [ ] Есть одна проверяемая польза и один следующий шаг.
- [ ] Нет обещаний дохода, давления на депозит и неподтверждённой срочности.
- [ ] Первый экран после deep link подтверждает текст push.

#### Как понять, что текст стал полезнее

- **Понимание:** После открытия меньше возвратов на главную и больше переходов к обещанному экрану.
- **Действие:** Растёт завершение конкретного полезного действия, а не только open rate.
- **Доверие:** Не растут отключения уведомлений, жалобы и негативные отзывы о давлении.

#### Главное правило

Если вы не можете показать ценность на первом экране после нажатия, не обещайте её в push.

---

### Сегментируйте сценарии, а не только базу

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/push-segments/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/push-segments/index.md
- **Раздел:** Push-уведомления
- **Время:** 90 минут на первые сегменты

Сегмент полезен только тогда, когда меняет решение: кому писать, почему сейчас, что сказать или куда вести. Начните с трёх групп по поведению, а не с десятков демографических фильтров.

#### Результат

Матрица из трёх сегментов с точными условиями входа и выхода, отдельной пользой, сообщением, маршрутом и исключениями.

#### Сегмент — не ярлык, а правило для другого сценария

«Новые», «активные» и «неактивные» — слишком общие слова, пока не указаны действия и сроки. Хороший сегмент можно проверить: начал путь за 24 часа, сохранил тему за 30 дней, завершил действие и больше не должен получать напоминание.

#### Что понадобится

- **События:** Дата последнего полезного действия, начало и завершение сценария, подтверждённый интерес и разрешение на уведомления.
- **Конструктор сегментов:** Система коммуникаций, где виден размер группы и можно задать условия входа, выхода и взаимные исключения.
- **Тестовые профили:** Минимум по одному профилю на каждый сегмент и пересечение для проверки правил перед запуском.

#### Термины простыми словами

- **Push-уведомление — Короткое сообщение от приложения вне его интерфейса:** Определение: Появляется на устройстве и может вернуть пользователя к конкретному полезному действию. Отправляется только при наличии разрешения. Пример: Сообщение о новом материале в сохранённой теме открывает этот материал по deep link.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.

#### Когда применять

Массовые push дают слабое полезное действие, люди получают неактуальные сообщения, а команда не может объяснить, почему пользователь попал в отправку.

#### Какие данные использовать

Берите только данные, которые действительно меняют пользу или маршрут сообщения. Не собирайте чувствительные признаки без необходимости.

- **Поведение в продукте**
  - **Источник:** Используйте завершённость пути, давность полезного действия, сохранённый интерес и уже просмотренный результат.
  - **Если доступа нет:** Без полной аналитики начните с одного надёжного серверного статуса и даты последней активности.
- **Размер и пересечения**
  - **Источник:** До запуска посмотрите число пользователей в каждой группе и сколько людей попадают сразу в два сценария.
  - **Если доступа нет:** Выгрузите идентификаторы трёх простых групп в таблицу и найдите повторяющиеся значения.
- **Язык и доступность**
  - **Источник:** Проверьте язык, страну только при реальном различии сценария и наличие разрешения на канал.
  - **Если доступа нет:** Если локализация не готова, ограничьте запуск одной поддерживаемой аудиторией вместо автоматического перевода.

#### Соберите первые сегменты

1. **Начните с поведения.** Опишите действие и срок, которые показывают текущий контекст пользователя. Не используйте абстрактное «лояльный» или «спящий».
   - **Где сделать:** В условиях сегмента коммуникационной системы.
   - **Пример:** Начал верификацию за последние 24 часа и ещё не завершил её.
2. **Выберите три разных сценария.** Возьмите группы, для которых действительно отличаются причина возврата и экран. Не дробите базу только ради персонализации обращения.
   - **Где сделать:** В первых трёх строках матрицы.
   - **Пример:** Незавершивший путь, активный с сохранённым интересом, давно неактивный с новым релевантным поводом.
3. **Запишите вход и выход.** Сегмент должен автоматически обновляться. После завершения действия или потери актуальности человек выходит до следующей отправки.
   - **Где сделать:** В правилах пересчёта перед запуском.
   - **Пример:** Событие completion («действие завершено») немедленно исключает пользователя из напоминания.
4. **Дайте каждой группе свой маршрут.** Различие должно быть не только в имени. Настройте отдельную пользу, текст и deep link в нужный контекст.
   - **Где сделать:** В карточке каждого сценария.
   - **Пример:** Новичок продолжает шаг, активный открывает новый материал, неактивный видит только реальное изменение.
5. **Разрешите пересечения.** Заранее определите, какое сообщение останется, если пользователь подходит под несколько правил. Проверяйте пересечение на тестовом профиле.
   - **Где сделать:** В приоритетах и взаимных исключениях.
   - **Пример:** Сервисный статус выше контентного повода; второе сообщение отменяется на 24 часа.

#### Примеры из практики

- **Три группы — три разных маршрута:** Незавершивший продолжает сохранённый шаг, активный открывает новый материал по интересу, давно неактивный получает сообщение только при реальном обновлении.
- **Пересечение решается до отправки:** Пользователь подходит под сервисный статус и контентный повод. Остаётся более важный статус, второе сообщение отменяется на 24 часа.

#### Готовый артефакт: Матрица трёх сегментов

Если две строки приводят к одинаковому тексту и экрану, объедините их — отдельный сегмент не нужен.

| Сегмент | Условие | Польза и маршрут | Выход / исключение |
| --- | --- | --- | --- |
| Новый незавершивший | Начал путь <24 ч, нет события завершения | Продолжить шаг → сохранённый экран | Выход после завершения |
| Активный с интересом | Сохранил тему <30 дней | Новый материал → подборка | Исключить уже прочитавших |
| Давно неактивный | Нет полезных действий 14 дней | Только реальное обновление → экран изменения | Не писать без нового повода |
| Недавно активный | Полезное действие <12 ч | Сообщение не требуется | Исключить из возвратных push |
| Пересечение | Подходит под 2 сценария | Выбрать более полезный | Один push по приоритету |

Начните с трёх сценариев и одного правила пересечения. Добавляйте новую группу только если для неё действительно меняются момент, польза или экран.

#### Ограничения и безопасность: Не собирайте сегменты ради сегментов

Если группа не меняет момент, пользу или маршрут, она только усложняет работу и создаёт больше ошибок в правилах.

#### Чек-лист сегмента

Любой участник команды должен суметь объяснить попадание конкретного пользователя по данным, а не по догадке.

- [ ] Условия входа и выхода описаны событиями и сроками.
- [ ] Сегмент меняет момент, пользу, текст или экран назначения.
- [ ] Есть размер группы и проверка качества исходных данных.
- [ ] Учтены язык, доступность канала и только необходимые признаки.
- [ ] Для пересекающихся сегментов задан приоритет и одно итоговое сообщение.

#### Как понять, что сегментация помогает

- **Точность:** Тестовые и реальные профили попадают в ожидаемую группу и выходят после завершения действия.
- **Польза:** Целевое действие после перехода растёт в конкретном сегменте по сравнению с общим сообщением.
- **Риски:** Не растут пересечения, повторные сообщения, отписки и жалобы внутри отдельных групп.

#### Главное правило

Начните с трёх сегментов и добавляйте новый только тогда, когда для него нужен действительно другой сценарий.

---

### Оценивайте эффект после нажатия

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/push-measure/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/push-measure/index.md
- **Раздел:** Push-уведомления
- **Время:** 90 минут на первый отчёт

Открытие показывает, что текст привлёк внимание, но не доказывает пользу. Свяжите отправку с экраном и целевым действием, добавьте сравнение и негативные сигналы.

#### Результат

Отчёт по одному сценарию: отправка, доставка, открытие, полезное действие, сравнение с группой без push и влияние на доверие.

#### Клик — это середина пути, а не результат

Push может получить много открытий из-за громкого текста, но после перехода люди ничего не делают или отключают уведомления. Поэтому отчёт должен показать всю цепочку и ответить: стало ли полезное действие происходить чаще благодаря сообщению.

#### Что понадобится

- **Цепочка событий:** Отправка, доставка, открытие, экран назначения и одно подтверждённое полезное действие.
- **Сравнение:** Небольшая случайная группа без сообщения или хотя бы сопоставимый период до запуска.
- **Негативные сигналы:** Отключение уведомлений, жалобы, удаления и повторные открытия без целевого действия.

#### Термины простыми словами

- **Push-уведомление — Короткое сообщение от приложения вне его интерфейса:** Определение: Появляется на устройстве и может вернуть пользователя к конкретному полезному действию. Отправляется только при наличии разрешения. Пример: Сообщение о новом материале в сохранённой теме открывает этот материал по deep link.
- **Open rate — Доля доставленных сообщений, которые открыли:** Определение: Показывает, сколько пользователей нажали на доставленное сообщение. Сам по себе open rate не говорит, выполнил ли пользователь полезное действие после перехода. Пример: Из 1 000 доставленных push открыли 200: open rate равен 20%.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Retention — Доля пользователей, которые вернулись:** Определение: Показывает, сколько людей снова открыли приложение через определённое время после установки или регистрации. Пример: Если из 100 новых пользователей через 7 дней вернулись 18, D7 retention равен 18%.

#### Когда применять

Команда показывает доставку и open rate, но не знает, завершили ли пользователи обещанное действие и было бы оно без сообщения.

#### Где собрать цепочку

Данные коммуникационной платформы и продуктовой аналитики должны соединяться по сценарию и пользователю. Если связь неполная, укажите это как ограничение.

- **Платформа отправок**
  - **Источник:** Возьмите число подходящих пользователей, отправок, доставок и открытий по одному идентификатору кампании.
  - **Если доступа нет:** Без автоматической выгрузки экспортируйте итог кампании и зафиксируйте точное окно отправки.
- **Продуктовая аналитика**
  - **Источник:** Посчитайте открытие нужного экрана и целевое действие в течение заранее выбранного окна после push.
  - **Если доступа нет:** Если события не связаны, добавьте идентификатор кампании campaign_id в deep link и событие экрана до следующего запуска.
- **Доверие и контроль**
  - **Источник:** Поставьте рядом отписки и результат группы, которая подходила под сценарий, но случайно не получила сообщение.
  - **Если доступа нет:** Без контрольной группы сравните с похожей неделей и прямо отметьте, что вывод о причинности ограничен.

#### Настройте измерение одного сценария

1. **Назовите одно полезное действие.** До запуска определите результат после перехода и окно измерения. Не используйте общий «визит в приложение».
   - **Где сделать:** В спецификации сценария и названии отчёта.
   - **Пример:** Прочитал новый разбор минимум наполовину в течение 24 часов после доставки.
2. **Свяжите события в цепочку.** Используйте один идентификатор кампании campaign_id и проверьте переход от коммуникационной платформы к экрану и действию в продуктовой аналитике.
   - **Где сделать:** В параметрах push, deep link и событиях приложения.
   - **Пример:** Отправка → доставка → открытие → просмотр → половина материала с campaign_id=topic_update_01.
3. **Добавьте сопоставимую группу.** Случайно оставьте небольшую часть подходящей аудитории без сообщения. Это показывает базовый уровень действия.
   - **Где сделать:** В настройках запуска и отдельной строке отчёта.
   - **Пример:** 10% аудитории не получает push; действие: 3,2% против 4,9% у получивших.
4. **Поставьте рядом негативные сигналы.** Смотрите отключения и жалобы в том же окне. Рост действия не считается победой, если сценарий заметно ухудшает доверие.
   - **Где сделать:** В последних строках отчёта.
   - **Пример:** Отписки 1% при обычном уровне 0,3% — сценарий нужно доработать, несмотря на рост действия.
5. **Примите одно из трёх решений.** Оставьте, измените или выключите сценарий. Запишите основание и дату следующей проверки.
   - **Где сделать:** В выводе отчёта и журнале коммуникаций.
   - **Пример:** Сохранить аудиторию, уменьшить частоту до одного раза и повторить сравнение через две недели.

#### Примеры из практики

- **Открытие 20%, действие 4,9%:** Из 8 600 доставленных push 1 720 открыли, но полезное действие сделали 420. Контрольная группа дала 3,2% — дополнительный эффект есть, но он намного меньше open rate.
- **Рост действия не перекрыл отписки:** Целевое действие выросло, но отключения достигли 1% при обычных 0,3%. Решение — уменьшить частоту и повторить тест, а не сразу масштабировать.

#### Готовый артефакт: Воронка одного push-сценария

Числа должны относиться к одной аудитории, одному окну и одному сценарию. Рядом укажите сравнение, а не только абсолютный результат.

| Шаг | Пользователи | Конверсия | Что это значит |
| --- | --- | --- | --- |
| Подошли под сценарий | 10 000 | — | Целевая аудитория |
| Получили push | 8 600 | 86% | Проверить разрешения и токены |
| Открыли сообщение | 1 720 | 20% | Текст привлёк внимание |
| Открыли нужный экран | 1 410 | 82% | Deep link в основном работает |
| Сделали действие | 420 | 30% | Итоговая конверсия 4,9% от доставки |
| Отключили уведомления | 86 | 1% | Сравнить с обычным уровнем |

Контрольная группа без push: полезное действие сделали 3,2%. Разница +1,7 процентного пункта — кандидат на продолжение, если отписки не вышли за обычный диапазон.

#### Ограничения и безопасность: Не оптимизируйте только клики

Громкий текст может собирать открытия из любопытства и одновременно ухудшать доверие. Решение принимается по всей цепочке и негативным сигналам.

#### Чек-лист отчёта

Все показатели должны относиться к одному сценарию, аудитории и окну измерения.

- [ ] У push есть одно целевое действие и заранее заданное окно.
- [ ] Отправка, открытие, экран и действие связаны одним идентификатором кампании.
- [ ] Есть сопоставимая группа без сообщения или явно указано ограничение сравнения.
- [ ] Отписки и жалобы показаны рядом с полезным действием.
- [ ] Отчёт заканчивается решением: оставить, изменить или выключить сценарий.

#### Какие выводы нужны команде

- **Техническая воронка:** Доставка, открытие и переход на нужный экран показывают, где ломается маршрут.
- **Дополнительный эффект:** Разница целевого действия между получившими push и сопоставимой группой без сообщения.
- **Доверие:** Отключения, жалобы и последующее удержание не ухудшаются сильнее допустимого уровня.

#### Главное правило

Хороший отчёт помогает выключать лишние push так же уверенно, как масштабировать действительно полезные.

---

## ASO и SEO

### Соберите семантику под реальный спрос

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/discoverability-keywords/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/discoverability-keywords/index.md
- **Раздел:** ASO и SEO
- **Время:** 2 часа на первую карту

Семантика — это не список слов для повторения в описании. Это карта вопросов и задач, которые люди формулируют своим языком, плюс подходящий ответ продукта для каждого запроса.

#### Результат

Таблица из 20–30 запросов с намерением пользователя, подтверждением спроса, соответствием продукту, приоритетом и одной целевой страницей.

#### Ищем не слова, а задачу за запросом

Запрос «как проверить статус» означает, что человеку нужен понятный способ увидеть результат. Запрос «лучшее приложение» слишком общий и часто не подсказывает, что показать. Сначала определите намерение, затем выберите реальный экран или страницу-ответ.

#### Что понадобится

- **Список возможностей:** Актуальные функции, ограничения, страны, языки и полезные сценарии, которые продукт действительно поддерживает.
- **Язык пользователей:** Отзывы, обращения, внутренний поиск и реальные формулировки вопросов без редакторской обработки.
- **Точки ответа:** Страница стора, раздел помощи, статья или лендинг, которые можно назначить каждому приоритетному намерению.

#### Термины простыми словами

- **Семантика — Карта поисковых запросов и задач за ними:** Определение: Собирает формулировки пользователей, объединяет их по намерению и связывает с подходящей страницей или функцией продукта. Пример: Запросы «где статус» и «проверить заявку» относятся к одному намерению — увидеть результат процесса.
- **ASO — Улучшение страницы приложения в сторе:** Определение: Работа с названием, описанием, скриншотами, рейтингом и запросами, чтобы приложение легче находили и чаще устанавливали. Пример: Переписать первые подписи на скриншотах так, чтобы польза была понятна без полного описания.
- **SEO — Улучшение страниц сайта для поиска:** Определение: Полезные страницы отвечают на реальные вопросы пользователей и помогают находить продукт через поисковые системы. Пример: Страница отвечает на один вопрос, объясняет условия и ведёт к релевантному сценарию приложения.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Описание приложения написано внутренним языком, органический трафик слабый, а команда не знает, какие реальные вопросы должна закрывать страница стора или сайт.

#### Где собирать запросы

Используйте несколько независимых источников. Подсказка поиска показывает формулировку, а отзывы и поддержка помогают понять задачу за ней.

- **Поисковые подсказки**
  - **Источник:** Введите основные категории и проблемы в поиск стора и поисковика, сохраните естественные продолжения фраз.
  - **Если доступа нет:** Без доступа соберите формулировки из внутреннего поиска сайта и вопросов новых пользователей.
- **Отзывы и поддержка**
  - **Источник:** Выпишите повторяющиеся слова из 50 отзывов и обращений: что люди хотят сделать, сравнить или понять.
  - **Если доступа нет:** Попросите поддержку назвать десять вопросов, которые приходится переформулировать с внутреннего языка команды.
- **Текущие страницы**
  - **Источник:** Сопоставьте запросы с существующей страницей стора, статьёй или экраном. Отметьте запросы, на которые пока нет честного ответа.
  - **Если доступа нет:** Если подходящей страницы нет, не вставляйте ключ в описание — заведите идею контента или исключите запрос.

#### Соберите рабочую карту семантики

1. **Соберите формулировки без редактуры.** Записывайте запросы так, как их вводят пользователи. Не заменяйте простые слова внутренними названиями функций.
   - **Где сделать:** В первой колонке общей таблицы вместе с источником.
   - **Пример:** «Как проверить статус», а не внутреннее название экрана status tracking.
2. **Объедините запросы по намерению.** Сгруппируйте синонимы вокруг одной задачи: найти продукт, выполнить действие, решить проблему, сравнить или получить инструкцию.
   - **Где сделать:** Во второй колонке и цветовых группах таблицы.
   - **Пример:** «Где статус», «проверить заявку», «статус проверки» → намерение увидеть результат процесса.
3. **Проверьте соответствие продукту.** Для каждого намерения укажите реальную функцию, ограничение или отсутствие ответа. Нерелевантный популярный запрос не становится полезным.
   - **Где сделать:** В колонке соответствия с подтверждением владельца продукта.
   - **Пример:** Запрос о гарантированном результате исключается: продукт не может честно дать такое обещание.
4. **Назначьте одно место ответа.** Функциональный запрос может вести на стор-страницу, вопрос «как» — на инструкцию, конкретная проблема — на помощь. Не заставляйте страницы конкурировать.
   - **Где сделать:** В колонке назначения.
   - **Пример:** «Как пройти верификацию» → подробная инструкция; общее название категории → страница приложения.
5. **Выберите первые пять запросов.** Оцените релевантность, подтверждённость формулировки и готовность ответа. Начните с небольшого приоритета, который можно реально улучшить.
   - **Где сделать:** В фильтре высокого приоритета и плане контента.
   - **Пример:** Пять запросов получают владельцев страниц и дату повторной проверки показов и целевых действий.

#### Примеры из практики

- **Язык пользователя становится намерением:** «Где статус», «проверить заявку» и «статус проверки» объединены в одну задачу — увидеть результат процесса. Ответом становится статья и экран статуса.
- **Популярный, но нечестный запрос исключён:** Запрос о гарантированном результате может иметь спрос, но не соответствует продукту. Он не попадает ни в описание, ни в SEO-страницу.

#### Готовый артефакт: Карта запросов и ответов

Одна строка — одно намерение и одно основное место ответа. Синонимы объединяются, а не конкурируют между несколькими страницами.

| Запрос | Намерение | Соответствие продукту | Куда ведём | Приоритет |
| --- | --- | --- | --- | --- |
| проверить статус | Увидеть результат процесса | Полное | Статья + экран статуса | Высокий |
| как пройти верификацию | Понять шаги и документы | Полное | Инструкция | Высокий |
| приложение для обучения | Найти категорию продукта | Частичное | Страница стора | Средний |
| гарантированный доход | Получить обещание результата | Не соответствует | Не используем | Исключить |
| название бренда | Найти конкретный продукт | Полное | Страница стора | Защитный |

Следующее действие: взять пять запросов высокого приоритета, проверить качество текущего ответа и назначить владельца страницы. Не пытайтесь использовать все 30 запросов в одном описании.

#### Чек-лист семантики

Карта готова, если по каждой приоритетной строке понятно, какой пользовательский вопрос и какой честный ответ стоят за словами.

- [ ] Запросы собраны минимум из двух источников и сохранены в языке пользователя.
- [ ] Синонимы объединены по намерению, а не считаются отдельными темами.
- [ ] Каждый запрос соответствует реальной функции, условию или полезному контенту.
- [ ] Нерелевантные и манипулятивные обещания исключены.
- [ ] У пяти первых запросов есть одна страница, владелец и дата проверки результата.

#### Как понять, что карта помогает

- **Видимость:** Растут показы по выбранным релевантным запросам, а не по случайной широкой семантике.
- **Ответ:** Пользователь попадает на назначенную страницу и находит ожидаемую функцию или инструкцию.
- **Качество:** Органические установки или целевые действия растут без ухудшения активации и доверия.

#### Главное правило

Не добавляйте ключи ради плотности: каждый приоритетный запрос должен вести к честному ответу, который пользователь действительно найдёт.

---

### Сделайте страницу приложения понятной и убедительной

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/discoverability-store/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/discoverability-store/index.md
- **Раздел:** ASO и SEO
- **Время:** 2 часа на первый сценарий

Человек принимает первое решение по иконке, заголовку и двум первым скриншотам. Они должны быстро показать задачу продукта, реальный интерфейс и причину доверять — без обещаний, которых приложение не выполняет.

#### Результат

Сценарий обновлённой страницы стора: одно обещание пользы, последовательность из пяти скриншотов, подтверждения доверия и план измерения.

#### Первые два скриншота должны объяснить продукт без описания

Страница стора похожа на витрину: пользователь ещё не знает внутренних функций и быстро решает, стоит ли смотреть дальше. Сначала покажите главную задачу и результат, затем путь, доверие и дополнительные возможности.

#### Что понадобится

- **Доступ:** Статистика страницы в App Store Connect или Google Play Console и текущие тексты, иконка и скриншоты.
- **Актуальная сборка:** Реальный интерфейс последней версии на iOS и Android, включая локализации и важные ограничения.
- **Команда:** Менеджер продукта, дизайнер и человек, который может подтвердить условия, тексты доверия и план публикации.

#### Термины простыми словами

- **ASO — Улучшение страницы приложения в сторе:** Определение: Работа с названием, описанием, скриншотами, рейтингом и запросами, чтобы приложение легче находили и чаще устанавливали. Пример: Переписать первые подписи на скриншотах так, чтобы польза была понятна без полного описания.
- **Семантика — Карта поисковых запросов и задач за ними:** Определение: Собирает формулировки пользователей, объединяет их по намерению и связывает с подходящей страницей или функцией продукта. Пример: Запросы «где статус» и «проверить заявку» относятся к одному намерению — увидеть результат процесса.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Страницу приложения видят, но редко устанавливают; изображения показывают интерфейс без пользы, обещания устарели или опыт после установки не совпадает с витриной.

#### Что проверить перед редизайном

Не начинайте с новой графики. Сначала найдите, где теряется смысл: в обещании, первых изображениях, несоответствии версии или недостатке доверия.

- **Статистика стора**
  - **Источник:** Сравните просмотры страницы, установки, источники и различия по стране и платформе за последние 28–90 дней.
  - **Если доступа нет:** Без доступа зафиксируйте текущую страницу, попросите владельца консоли прислать основные числа и не делайте вывод о конверсии по ощущениям.
- **Отзывы и поддержка**
  - **Источник:** Выпишите, за что пользователи ценят приложение и что не совпало с ожиданием после установки.
  - **Если доступа нет:** Попросите пять новых людей посмотреть первые два скриншота и одним предложением объяснить, что делает продукт.
- **Текущая сборка**
  - **Источник:** Сверьте каждое изображение и утверждение с доступным интерфейсом, условиями и поддерживаемыми странами.
  - **Если доступа нет:** Если функция ещё не выпущена, не показывайте её как доступную — перенесите в план следующего обновления страницы.

#### Соберите понятную страницу стора

1. **Сформулируйте одну главную пользу.** Напишите задачу и результат на языке пользователя. Не начинайте со списка функций или неподтверждённого превосходства.
   - **Где сделать:** В плане страницы и первом скриншоте.
   - **Пример:** «Проверьте статус и следующий шаг в одном месте» вместо «Инновационная платформа №1».
2. **Свяжите пользу с реальным спросом.** Возьмите приоритетное намерение из карты семантики и убедитесь, что продукт действительно отвечает на него.
   - **Где сделать:** В заголовке, подзаголовке и начале описания без повторения ключей ради плотности.
   - **Пример:** Запрос «проверить статус» поддерживается реальным экраном и инструкцией.
3. **Постройте историю скриншотов.** Расположите кадры от главной пользы к результату, пути, доверию и дополнительным возможностям. Один кадр — одно сообщение.
   - **Где сделать:** В сценарии скриншотов для iOS и Android.
   - **Пример:** 1 — задача, 2 — результат, 3 — действие, 4 — условия и помощь, 5 — персонализация.
4. **Покажите настоящий интерфейс.** Используйте актуальные экраны и короткие конкретные подписи. Не скрывайте важные ограничения мелким текстом.
   - **Где сделать:** В макетах каждой локализации и размера устройства.
   - **Пример:** Скриншот показывает реальный статус и кнопку, которые пользователь увидит после установки.
5. **Меняйте и измеряйте по одному блоку.** Зафиксируйте версию страницы, дату и основной показатель. Не меняйте одновременно иконку, заголовок и все скриншоты, если хотите понять эффект.
   - **Где сделать:** В журнале обновлений страницы стора.
   - **Пример:** Тестируем первые два скриншота 28 дней на Android в одной стране; смотрим просмотр → установка и активацию.

#### Примеры из практики

- **Первые два кадра работают без описания:** Кадр 1 называет задачу «Проверьте статус в одном месте», кадр 2 показывает следующий шаг на реальном экране. Остальные функции не конкурируют с главным обещанием.
- **Меняется одна гипотеза:** Команда заменяет только первые два скриншота на Android в одной стране и 28 дней сравнивает просмотр → установку и первый полезный результат.

#### Готовый артефакт: Сценарий пяти скриншотов

Каждый кадр отвечает на один вопрос и показывает реальный экран. Первые два должны работать даже без чтения полного описания.

| Кадр | Сообщение | Что показать | Зачем он нужен |
| --- | --- | --- | --- |
| 1 · Главная польза | Проверьте статус в одном месте | Реальный экран статуса | Объяснить задачу |
| 2 · Первый результат | Увидьте следующий шаг сразу | Детали и CTA | Показать ценность |
| 3 · Как работает | Сохраните важное | Сценарий сохранения | Снять вопрос о пути |
| 4 · Доверие | Понятные условия и помощь | Условия + поддержка | Снизить сомнение |
| 5 · Дополнительно | Настройте под свой интерес | Персонализация | Расширить картину |

Первый тест: заменить только первые два скриншота, сохранить остальные условия и сравнить конверсию страницы по одной платформе и стране.

#### Чек-лист страницы

Перед публикацией откройте страницу на телефоне и проверьте её как новый пользователь, который ничего не знает о продукте.

- [ ] Первые два скриншота объясняют задачу и результат без полного описания.
- [ ] Все изображения соответствуют текущему интерфейсу и локализации.
- [ ] Нет гарантированных результатов, давления на депозит и неподтверждённых сравнений.
- [ ] Важные условия и путь к помощи видны до установки или легко находятся.
- [ ] У изменения есть версия, дата, одна основная гипотеза и план измерения.

#### Как понять, что страница стала лучше

- **Первое решение:** Конверсия просмотра страницы в установку растёт в выбранной стране и платформе.
- **Качество обещания:** Новые пользователи чаще доходят до показанного первого результата после установки.
- **Доверие:** Не растут ранние удаления, жалобы на несоответствие и негативные отзывы после обновления витрины.

#### Главное правило

Если заголовок или изображение обещает больше, чем показывает продукт, это ухудшает и конверсию, и доверие после установки.

---

### Работайте с отзывами в сторах

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/discoverability-rating/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/discoverability-rating/index.md
- **Раздел:** ASO и SEO
- **Время:** 60 минут на настройку и 30 минут в неделю

Отзыв — это публичный сигнал о конкретном опыте, а не просто оценка бренда. Быстро отделяйте критичные проблемы, отвечайте без спора и превращайте повторяющиеся темы в продуктовые решения.

#### Результат

Единая очередь отзывов с темами, приоритетом, безопасным шаблоном ответа, владельцем и связью с задачами продукта.

#### Публичный ответ видит не только автор отзыва

Хороший ответ признаёт опыт, не спорит и даёт безопасный следующий шаг без персональных данных. Но главное — повторяющиеся жалобы должны попасть к владельцу продукта и вернуться в отзыв после исправления.

#### Что понадобится

- **Доступ:** Отзывы App Store и Google Play с датой, платформой, страной и доступной версией приложения.
- **Владелец ответа:** Поддержка или менеджер сообщества с понятным сроком реакции и правилами эскалации.
- **Связь с продуктом:** Общая очередь задач, куда можно передать повторяющуюся тему с примерами и частотой.

#### Термины простыми словами

- **ASO — Улучшение страницы приложения в сторе:** Определение: Работа с названием, описанием, скриншотами, рейтингом и запросами, чтобы приложение легче находили и чаще устанавливали. Пример: Переписать первые подписи на скриншотах так, чтобы польза была понятна без полного описания.
- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Отзывы остаются без ответа, рейтинг меняется без понятной причины, а повторяющиеся жалобы не доходят до поддержки, разработки и владельца продукта.

#### Как собрать рабочий поток

Не отвечайте прямо из уведомления без контекста. Сначала объедините отзывы, отметьте тему и критичность, затем выберите подходящий следующий шаг.

- **Консоли сторов**
  - **Источник:** Раз в день или неделю выгружайте новые отзывы с рейтингом, языком, платформой и версией, если она доступна.
  - **Если доступа нет:** Без автоматической выгрузки ведите общую таблицу и сохраняйте ссылку, дату и текст каждого важного отзыва.
- **Поддержка и технические сигналы**
  - **Источник:** Сверяйте жалобы на вход, данные, операции и вылеты с обращениями и отчётами об ошибках.
  - **Если доступа нет:** Если связь пока ручная, отправляйте критичный отзыв в общий канал с версией и просьбой подтвердить масштаб.
- **Список продуктовых задач**
  - **Источник:** Для повторяющейся темы храните число отзывов, примеры, владельца, статус и версию исправления.
  - **Если доступа нет:** Если системы задач нет, добавьте колонку «следующее решение» и возвращайтесь к ней на еженедельном разборе.

#### Настройте работу со стор-отзывами

1. **Соберите один поток.** Объедините отзывы двух сторов в таблице или рабочем инструменте. Сохраните исходный текст, язык, дату, платформу и версию.
   - **Где сделать:** В общей очереди с фильтром новых и неразобранных отзывов.
   - **Пример:** Android 4.2 · 1 звезда · «после обновления не вижу историю» · 12 июня.
2. **Отметьте тему и критичность.** Сразу выделяйте безопасность, деньги, данные, вход и блокирующие ошибки. Остальные отзывы группируйте по понятной пользовательской теме.
   - **Где сделать:** В колонках темы и приоритета.
   - **Пример:** Потеря истории — высокая критичность; просьба о тёмной теме — обычный запрос.
3. **Ответьте без спора и обещаний.** Признайте опыт, дайте безопасный следующий шаг и не запрашивайте личные данные публично. Не обещайте срок, который команда не подтвердила.
   - **Где сделать:** В публичном ответе на языке пользователя.
   - **Пример:** «Понимаем, что история не отображается. Напишите через форму поддержки в приложении и укажите версию — команда проверит случай».
4. **Передайте повторяющуюся тему.** Несколько похожих отзывов должны стать одним сигналом с частотой, версиями и владельцем, а не отдельными несвязанными сообщениями.
   - **Где сделать:** В продуктовой задаче или еженедельном разборе.
   - **Пример:** 8 отзывов и 14 обращений про пустую историю Android 4.2 → одна задача высокого приоритета.
5. **Вернитесь после исправления.** Когда проблема подтверждённо устранена, обновите публичный ответ и укажите версию. Не просите изменить оценку.
   - **Где сделать:** В исходном отзыве после проверки релиза.
   - **Пример:** «Проблема устранена в версии 4.3. Спасибо, что помогли её обнаружить».

#### Примеры из практики

- **Критичный отзыв становится задачей:** Восемь отзывов и 14 обращений о пустой истории на Android 4.2 объединяются в одну проблему с владельцем и срочной проверкой версии.
- **Цикл закрывается публично:** После проверки версии 4.3 команда обновляет ответ: проблема устранена, спасибо за сигнал. Просьбы изменить оценку и публиковать личные данные нет.

#### Готовый артефакт: Очередь отзывов и эскалаций

Одна строка связывает публичный сигнал, безопасный ответ и внутреннее действие команды.

| Тема отзыва | Приоритет | Публичный ответ | Внутреннее действие |
| --- | --- | --- | --- |
| Не работает вход | Критичный | Признать + безопасный канал помощи | Проверить версию и ошибки сегодня |
| Неясен статус | Высокий | Объяснить, где увидеть статус | Собрать 5+ примеров в продукт |
| Просьба о функции | Обычный | Поблагодарить без обещания | Отметить частоту |
| Сложно найти настройку | Обычный | Дать короткий маршрут | Проверить навигацию |
| Исправлено в 4.3 | Закрытие цикла | Сообщить версию и поблагодарить | Проверить новые отзывы |

Никогда не просите пользователя публиковать личные или платёжные данные в отзыве. Переводите разбор конкретного случая в безопасный канал поддержки.

#### Чек-лист ответа

Перед публикацией представьте, что ответ читает новый пользователь, который решает, можно ли доверять команде.

- [ ] Отзыв размечен по теме, платформе, версии и критичности.
- [ ] Ответ признаёт опыт и не спорит с пользователем.
- [ ] Нет просьбы публиковать личные данные и неподтверждённых обещаний.
- [ ] Повторяющаяся тема связана с внутренней задачей и владельцем.
- [ ] После исправления команда возвращается с проверенной версией без просьбы изменить оценку.

#### Как понять, что процесс работает

- **Реакция:** Растёт доля содержательных ответов, а критичные отзывы получают реакцию быстрее обычных.
- **Продуктовый сигнал:** Повторяющиеся темы объединяются и получают владельца, а не остаются набором отдельных комментариев.
- **Закрытие цикла:** После исправления снижается частота темы в новых отзывах и обращениях.

#### Главное правило

Не просите изменить оценку: сначала решите проблему, подтвердите исправление и дайте пользователю самому пересмотреть опыт.

---

### Создавайте SEO-страницы под задачи пользователя

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/discoverability-seo/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/discoverability-seo/index.md
- **Раздел:** ASO и SEO
- **Время:** 3 часа на первую страницу

Полезная SEO-страница полностью отвечает на один вопрос до предложения установить приложение. Она показывает условия, примеры и честное продолжение в продукте — без текста, написанного только ради ключевых слов.

#### Результат

Готовый план первой SEO-страницы: намерение, структура ответа, подтверждения, ограничения, CTA, маршрут в приложение и план обновления.

#### Одна страница — один вопрос — один полный ответ

Если человек ищет «как настроить уведомления», ему нужна инструкция, условия и способ проверить результат. Общая рекламная страница не отвечает на вопрос и заставляет устанавливать приложение вслепую.

#### Что понадобится

- **Одно намерение:** Приоритетный вопрос из карты семантики с подтверждением в поиске, поддержке или отзывах.
- **Эксперт:** Владелец функции или специалист поддержки, который проверит шаги, ограничения и актуальность ответа.
- **Публикация и данные:** Доступ к сайту, аналитике страницы и маршруту в соответствующий экран приложения.

#### Термины простыми словами

- **SEO — Улучшение страниц сайта для поиска:** Определение: Полезные страницы отвечают на реальные вопросы пользователей и помогают находить продукт через поисковые системы. Пример: Страница отвечает на один вопрос, объясняет условия и ведёт к релевантному сценарию приложения.
- **Семантика — Карта поисковых запросов и задач за ними:** Определение: Собирает формулировки пользователей, объединяет их по намерению и связывает с подходящей страницей или функцией продукта. Пример: Запросы «где статус» и «проверить заявку» относятся к одному намерению — увидеть результат процесса.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **CTA — Главное действие, которое предлагается пользователю:** Определение: CTA — это кнопка или ссылка с понятным следующим шагом и ожидаемым результатом. Пример: «Продолжить регистрацию» конкретнее и полезнее, чем «Далее».
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Сайт получает почти только брендовый трафик, частые вопросы не имеют отдельного ответа, а существующие страницы повторяют ключевые слова и ведут на главную.

#### Что собрать до написания

Сначала подтвердите вопрос и реальный ответ продукта. Структура страницы строится вокруг задачи пользователя, а не вокруг желаемой плотности ключевых слов.

- **Карта семантики**
  - **Источник:** Возьмите одно намерение высокого приоритета и объединённые формулировки, которыми его ищут.
  - **Если доступа нет:** Без инструментов начните с повторяющегося вопроса поддержки, который встречается минимум пять раз в месяц.
- **Текущий продукт**
  - **Источник:** Пройдите сценарий на актуальной версии и запишите шаги, условия, ошибки и доступность по платформам или странам.
  - **Если доступа нет:** Если функция меняется, не публикуйте окончательную инструкцию до подтверждения владельцем и датой выпуска.
- **Поисковая аналитика**
  - **Источник:** После публикации смотрите показы, переходы, запросы страницы и действия после чтения.
  - **Если доступа нет:** Если инструмент ещё не подключён, хотя бы разметьте CTA и deep link отдельным параметром источника.

#### Соберите полезную SEO-страницу

1. **Выберите одно намерение.** Возьмите конкретный вопрос, который продукт действительно решает. Не объединяйте инструкцию, сравнение и общий обзор на одной странице.
   - **Где сделать:** В заголовке плана и основном поисковом намерении.
   - **Пример:** «Как проверить статус заявки» вместо общей темы «всё о приложении».
2. **Дайте короткий ответ сразу.** В первых абзацах объясните результат и ключевое условие. Пользователь не должен прокручивать рекламный текст до сути.
   - **Где сделать:** Под H1 и в кратком резюме страницы.
   - **Пример:** Статус находится в разделе «История» и обновляется после обработки; обычный срок указан рядом.
3. **Покажите путь и ограничения.** Добавьте пошаговые действия, реальные изображения, доступность, сроки и типичные ошибки. Не скрывайте важные условия за CTA.
   - **Где сделать:** В основной части страницы с датой обновления.
   - **Пример:** Три шага, что делать при задержке и в каких странах сценарий доступен.
4. **Свяжите с релевантным экраном.** Предложите продолжить ровно ту задачу, за которой пришёл пользователь. Главная страница приложения разрывает контекст.
   - **Где сделать:** В одном основном CTA и deep link.
   - **Пример:** «Открыть мой статус» ведёт в историю, а не на домашний экран.
5. **Назначьте владельца обновления.** Функции, условия и интерфейс меняются. Запишите владельца, дату проверки и сигналы, по которым страницу нужно пересмотреть.
   - **Где сделать:** В метаданных контента и редакционном календаре.
   - **Пример:** Поддержка проверяет инструкцию после каждого релиза и раз в квартал по частым запросам.

#### Примеры из практики

- **Ответ доступен до установки:** Страница «Как проверить статус» сразу объясняет место и срок обновления, затем показывает три шага, ограничения и только после этого предлагает открыть свой статус.
- **Продолжение сохраняет задачу:** CTA «Открыть мой статус» ведёт на соответствующий экран. Если функция недоступна в стране, ограничение видно на странице до перехода.

#### Готовый артефакт: План страницы «Как проверить статус»

План отвечает, что пользователь должен понять и сделать в каждом блоке страницы.

| Блок | Ответ страницы | Подтверждение | Следующий шаг |
| --- | --- | --- | --- |
| Заголовок | Как проверить статус заявки | Совпадает с вопросом | Сразу увидеть ответ |
| Короткий ответ | Где находится статус и когда обновляется | Текущая версия продукта | Понять без установки |
| Пошагово | 3 шага со скриншотами | Реальный интерфейс | Повторить путь |
| Условия | Сроки, страны, типичные ошибки | Подтверждено владельцем | Избежать сюрпризов |
| Продолжение | Открыть свой статус | Рабочий deep link | Перейти в нужный экран |

Вверху страницы пользователь получает ответ. CTA в приложение появляется как удобное продолжение, а не как условие доступа к основной информации.

#### Чек-лист страницы

Страница должна оставаться полезной, даже если пользователь не устанавливает приложение после чтения.

- [ ] Одна страница полностью отвечает на одно поисковое намерение.
- [ ] Короткий ответ находится в начале, а не после рекламного вступления.
- [ ] Шаги, изображения, сроки и ограничения соответствуют текущему продукту.
- [ ] Основной CTA и deep link продолжают исходную задачу пользователя.
- [ ] Указаны владелец, дата обновления и повод для следующей проверки.

#### Как понять, что страница помогает

- **Поисковый ответ:** Растут релевантные показы и переходы по выбранному намерению, а не случайный широкий трафик.
- **Польза страницы:** Читатели доходят до ответа, используют шаги и реже задают тот же базовый вопрос поддержке.
- **Продолжение в продукте:** Переходы с сайта в приложение открывают нужный экран и приводят к ожидаемому действию.

#### Главное правило

SEO не заканчивается кликом: пользователь должен получить полный ответ на странице и понятное продолжение той же задачи в приложении.

---

### Свяжите поиск, сайт и приложение через deep links

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/discoverability-links/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/discoverability-links/index.md
- **Раздел:** ASO и SEO
- **Время:** 2 часа на первый маршрут

Deep link — это точный адрес внутри приложения. Он должен сохранить исходную задачу после клика, входа и даже новой установки, а при ошибке дать понятный запасной маршрут.

#### Результат

Карта одного непрерывного пути и матрица тестов для iOS/Android: приложение установлено, пользователь не вошёл, приложения нет и версия устарела.

#### Ссылка должна вести в нужную комнату, а не просто в здание

Если человек читает инструкцию о статусе, после клика он ожидает открыть свой статус. Главный экран заставляет снова искать путь. Хороший маршрут помнит назначение после входа и предлагает безопасную альтернативу, если экран недоступен.

#### Что понадобится

- **Один маршрут:** Конкретная веб-страница или сообщение, конечный экран приложения и одно ожидаемое действие.
- **Разработка:** iOS- и Android-разработчик или владелец ссылок, который знает поддерживаемые пути и поведение авторизации.
- **Проверка:** Устройства обеих платформ, установленная и удалённая версия приложения, тестовые аккаунты и события аналитики.

#### Термины простыми словами

- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **SEO — Улучшение страниц сайта для поиска:** Определение: Полезные страницы отвечают на реальные вопросы пользователей и помогают находить продукт через поисковые системы. Пример: Страница отвечает на один вопрос, объясняет условия и ведёт к релевантному сценарию приложения.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

#### Когда применять

Переходы из поиска, сайта, email или push открывают главную страницу, теряются после входа или новой установки и не позволяют измерить целевое действие.

#### Что описать до разработки

Сначала нарисуйте поведение для каждого состояния пользователя. Одна и та же ссылка не может молча вести в тупик, если приложения или экрана нет.

- **Карта маршрутов**
  - **Источник:** Сопоставьте источник, обещанный экран, необходимую авторизацию и целевое действие после открытия.
  - **Если доступа нет:** Начните с одной самой важной ссылки и вручную запишите ожидаемое поведение для пяти состояний.
- **Технические ошибки**
  - **Источник:** Собирайте успешное открытие, запасной маршрут, неизвестный путь и версию приложения по каждой ссылке.
  - **Если доступа нет:** Без событий ведите журнал ручных тестов с устройством, версией, шагами и видео ошибки.
- **Переходы и действия**
  - **Источник:** Свяжите клик, открытие нужного экрана и завершение действия одним идентификатором маршрута.
  - **Если доступа нет:** Добавьте технический параметр route_id («идентификатор маршрута») к ссылке и событию экрана до следующего запуска.

#### Настройте непрерывный маршрут

1. **Выберите одну задачу и экран.** Начните с конкретного обещания и конечного результата. Не создавайте универсальную ссылку «открыть приложение».
   - **Где сделать:** В первой строке карты маршрутов.
   - **Пример:** Статья «Как проверить статус» → экран конкретного статуса → пользователь видит следующий шаг.
2. **Опишите состояния пользователя.** Запишите поведение, если приложение установлено, вход не выполнен, версия устарела или приложения нет.
   - **Где сделать:** В строках матрицы тестирования.
   - **Пример:** После входа исходный идентификатор маршрута сохраняется и открывает статус, а не домашний экран.
3. **Добавьте безопасный запасной путь.** Если конечный экран недоступен, покажите релевантную веб-страницу, стор или помощь. Не оставляйте белый экран и неизвестную ошибку.
   - **Где сделать:** В настройках маршрутизатора ссылок.
   - **Пример:** Нет приложения → веб-инструкция остаётся доступной + понятная кнопка в стор.
4. **Протестируйте на реальных устройствах.** Проверьте iOS и Android, холодный запуск, вход, старую версию и переход из разных источников. Запишите факт по каждой строке.
   - **Где сделать:** На устройствах и версиях, которыми реально пользуется аудитория.
   - **Пример:** Android 13 из браузера, iOS 17 из email, обе платформы после выхода из аккаунта.
5. **Свяжите клик с результатом.** Передавайте route_id — идентификатор маршрута — и фиксируйте открытие нужного экрана, запасной путь, ошибку и целевое действие.
   - **Где сделать:** В параметрах ссылки и событиях аналитики.
   - **Пример:** Клик на сайте → открытие приложения → просмотр статуса → следующий шаг с route_id=status_help.

#### Примеры из практики

- **Вход не стирает назначение:** Ссылка на статус просит авторизоваться, сохраняет route_id и после входа открывает обещанный экран вместо домашней страницы.
- **Нет приложения — нет тупика:** Пользователь остаётся на полезной веб-инструкции и получает понятную ссылку в стор. После установки маршрут можно продолжить или безопасно открыть веб-альтернативу.

#### Готовый артефакт: Матрица проверки маршрута «Открыть статус»

Пройдите каждую строку на iOS и Android. Результат «приложение открылось» недостаточен — нужен обещанный экран.

| Состояние | Ожидаемый путь | Запасной маршрут | Результат |
| --- | --- | --- | --- |
| Установлено, пользователь вошёл | Сразу экран статуса | Не нужен | Проверить iOS/Android |
| Установлено, вход не выполнен | Вход → экран статуса | Сохранить назначение | Не терять идентификатор маршрута |
| Приложения нет | Страница стора | Веб-ответ доступен | Не показывать ошибку |
| Версия устарела | Поддерживаемый экран или обновление | Веб-версия | Не вести в тупик |
| Экран удалён | Актуальная альтернатива | Раздел помощи | Событие «маршрут не найден» |

Сценарий готов, когда после клика пользователь видит обещанный экран во всех поддерживаемых состояниях, а ошибки маршрута попадают в отчёт с версией и платформой.

#### Чек-лист deep link

Ссылка готова только после проверки полного пути, а не одного успешного открытия на устройстве разработчика.

- [ ] Есть конкретный обещанный экран и целевое действие.
- [ ] После входа или холодного запуска исходное назначение сохраняется.
- [ ] Для отсутствующего приложения, старой версии и удалённого экрана есть запасной путь.
- [ ] В ссылке нет чувствительных пользовательских данных.
- [ ] Клик, экран, ошибка и действие связаны идентификатором маршрута и проверены на iOS/Android.

#### Как понять, что маршрут работает

- **Технический успех:** Доля кликов, которые открыли обещанный экран или корректный запасной путь без ошибки.
- **Сохранение контекста:** После входа и новой установки пользователь продолжает исходную задачу, а не попадает на главную.
- **Полезное действие:** Пользователи завершают действие после перехода, а ошибки «маршрут не найден» и возвраты назад снижаются.

#### Главное правило

Deep link считается рабочим только тогда, когда пользователь дошёл до обещанного экрана во всех поддерживаемых состояниях, а не только в тесте разработчика.