> For the complete documentation index, see [llms.txt](https://developers-apps-in-toss.toss.im/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers-apps-in-toss.toss.im/guide/zh/exposure.md).
# 在 Toss App 中展示
### 精心制作的迷你应用，能够遇见更多用户。
**从 10 月 22 日起，迷你应用的曝光政策将有所变化。** 当你发布迷你应用后，我们会告诉你它会以什么方式向用户曝光，以及要想获得更多曝光需要满足哪些标准。
***
### 1. 已发布迷你应用
通过内部审核并正式发布的应用，都属于“已发布迷你应用”。曝光方式与以往并没有太大差别。可以在 Toss 应用中搜索，或通过分享链接使用，今后还会支持推广广告位。
***
### 2. 推荐迷你应用
即使通过相同流程发布，也有一些应用会被用户更频繁地使用并反复访问。我们会把这样制作精良的应用选为“推荐迷你应用”。一旦成为推荐迷你应用， **就会在迷你应用商店和全部标签页中更频繁地被介绍，并且在搜索结果中优先曝光。**
#### 推荐迷你应用筛选标准
推荐迷你应用需要同时满足 UX·实际使用指标·评论·性能这四项标准。
#### 标准 1. UX 原则
我们会确认用户能否轻松理解并使用应用。请按照五项原则检查登录和通知同意、广告、页面构成等内容。
**1) 请重新思考是否真的需要登录或通知同意**
如果用户首次打开应用时，先弹出登录或通知同意窗口会怎样？用户还不知道这个应用能做什么，就会觉得一上来就被要求登录或授权。在这种情况下，他们很难爽快同意，也更容易流失。
请重新思考登录和通知同意是否真的必要，如果不需要，就大胆去掉。与其不断添加，不如删减，可能是更好的解决方案。
**`制作指南`**
* 在请求登录或通知同意之前，请先让用户体验应用的主要功能。
* 当需要把用户输入的内容保存到账户，或需要调取之前记录时，再请求登录。
* 当用户希望接收新结果或最新消息时，再请求通知同意，并说明他们将会收到哪些通知。
**`检查清单`**
* [ ] 在未登录状态下访问应用时，能先体验主要功能吗？
* [ ] 登录或通知同意窗口是在选择相关功能之后才出现吗？
* [ ] 仅看请求页面就能知道为什么需要登录或通知同意吗？
**2) 告知插屏广告出现的时机，并避免重复展示**
如果每次查看结果时都会出现插屏广告，用户可能会在看到结果前就退出应用。请提前告知广告出现的时机，以及看完广告后能获得什么；如果已经看过一次广告，就直接展示结果。
**`制作指南`**
* 在观看广告之前，先告诉用户会得到什么，再由用户自行选择。
* 在插屏广告出现之前，请通过文案或广告图标提前提示。
* 在用户看过一次广告后，请直接展示结果。
* 只有在有更详细信息或奖励时，才建议用户看额外广告。
**`检查清单`**
* [ ] 在插屏广告出现之前，是否有明确的广告提示标识？
* [ ] 看过一次广告后，是否能不看额外广告就直接查看结果？
* [ ] 额外广告是否只在用户想看更详细信息或奖励时才可选择观看？
**3) 请应用一致且清晰的设计原则**
用户通常不会从头到尾阅读页面，而是先看大字号文字、图片和按钮。如果标题、说明、结果看起来都差不多，就很难知道该先看什么，也会显得完成度不足。请区分信息的重要程度，并统一同一功能的设计。
**`制作指南`**
* 请根据标题、说明、结果的重要程度来设置字号并安排布局。
* 如果是相同功能的按钮和同类卡片，请统一颜色和形状。
* 不要保留示例文案或临时图片。
* 颜色和装饰元素请用于强调标题或结果，而不是单纯装点页面。
* 不要直接照搬其他应用的结构和设计，只改文案和图片。
**`检查清单`**
* [ ] 能一眼看出标题、说明、结果分别在哪里吗？
* [ ] 相同功能的按钮和卡片在不同页面中是否保持一致？
* [ ] 是否没有残留示例文案或临时图片？
* [ ] 背景色和装饰是否比标题或结果更抢眼？
* [ ] 是否没有直接使用其他应用的结构和设计？
**4) 按顺序展示用户需要做的事，并在结束后告知已完成**
如果难以看出需要输入什么信息、该点哪个按钮，即使是简单功能也会显得复杂。如果需要多次输入相同内容，用户可能会在看到结果前就退出应用。请按顺序展示待办事项，并在最后一个操作完成后告诉用户已完成。
**`制作指南`**
* 打开首页时，最先要做的事是否一目了然？
* 输入框和按钮是否按使用顺序排列，并且按钮被点击后会发生什么写得清楚明白？
* 如果需要多次输入相同格式的信息，能否一次输入或一次调用？
* 最后一个操作完成后，是否会出现已完成的文案或页面？
**`检查清单`**
* [ ] 打开应用后，是否能立刻知道该做什么？
* [ ] 每个页面是否都能立刻看出下一步要点哪个按钮或填哪里？
* [ ] 在多次输入相同格式的信息时，能否一次输入或调用？
* [ ] 最后一个操作结束后，是否会出现已完成的文案或页面？
**5) 展示用户期待的结果，并同时说明其含义**
用户会根据应用的标题和介绍来期待会得到什么结果。在结果页面中，请实际展示介绍过的信息，并说明分数或类型分别代表什么。
*※ 像计算器、抽奖器、名言这类没有单独结果页面的应用，不纳入此项评估。*
**`制作指南`**
* 请在应用名称和介绍中写明结果页面上实际能确认到的内容。
* 如果分数、等级、类型等仅凭结果难以理解，请同时显示说明。
* 如果应用会因输入或选择而改变结果，请让修改后的内容反映到结果中。
* 请向用户说明结果变化的原因。
* 如果没有要展示的内容，请说明页面为空的原因。
**`检查清单`**
* [ ] 能在结果页面中确认标题和介绍里写的内容吗？
* [ ] 能理解结果页面上的内容是什么意思吗？
* [ ] 如果应用会因输入或选择而改变结果，修改后的内容是否反映到了结果中？
* [ ] 如果结果因输入或选择而发生变化，能知道为什么会变吗？
* [ ] 即使是没有可展示内容的页面，也能知道为什么是空的吗？
#### 标准 2. 实际使用指标
制作精良的应用，用户回访或完成购买、预约的比例更高。因此，在筛选推荐迷你应用时，我们也会一起查看回访率、转化率等实际使用指标。
* **回访率（留存率）：** 指使用过应用的人中，后来再次访问的人所占的比例。
* **转化率：** 指使用过应用的人中，完成购买、预约等主要行为的人所占的比例。
**1) 按类别的示例**
根据应用类型不同，查看的指标也会不同。例如，eSIM 销售应用会看完成购买的比例，而日常记录应用会看回访率。
| 使用目的 | 主要指标 | 详细说明 |
| ------- | ----- | ---------- |
| eSIM 购买 | 购买转化率 | 访问用户是否完成购买 |
| 清洁预约 | 预约转化率 | 访问用户是否完成预约 |
| 日常记录 | 回访率 | 用户是否持续回访 |
**2) 注册我的迷你应用转化指标**
为了让 Toss 能正确评估我的迷你应用，请在控制台中注册转化指标。你设置的指标会成为计算服务转化率的基准。如果“预约完成”是转化指标，就会计算访问应用的人中有多少百分比最终完成了预约。比如 100 人访问、10 人预约，那么预约转化率就是 10%。
请在下方指南中查看转化指标的注册方法。
{% hint style="info" %}
**详细设置方法**
* 如果想记录应用内行为 → [事件记录指南](https://developers-apps-in-toss.toss.im/guide/analytics/logging)
* 如果想在控制台中设置指标 → [转化指标设置指南](https://developers-apps-in-toss.toss.im/guide/analytics/conversion-metrics)
{% endhint %}
#### 标准 3. 评论
**1) 管理评分**
不仅是评分，评论内容也会反映在推荐迷你应用的筛选中。请向完成购买或预约的用户请求评论，并在控制台的“评分与评论”中查看评分变化。
**2) 查看评论并改进**
我应用的所有评论都可以在控制台的“评分与评论”菜单中查看。如果多个用户提到了相同的不便，请先从那部分开始改进。
#### 标准 4. 性能
我们会确认应用打开是否耗时过长，以及使用过程中是否能正常运行。如果应用一打开就闪退或卡死到无法使用，在评估中会处于劣势。请实际运行应用并亲自体验主要功能，检查是否存在卡顿或错误。
***
### 3. 加速型迷你应用
**在推荐迷你应用中，表现格外出色的应用会被选为“加速型迷你应用”，并获得大力度支持。** 从全部标签页顶部的专属推荐位到 Toss 首页，我们会在最显眼的地方，以最显眼的形式进行介绍。根据 Beta 测试期间测得的数据，预计曝光量将比推荐迷你应用高出 20 倍。
#### 加速型迷你应用筛选标准
**1) 类目内实际使用指标**
我们会确认它的回访率或购买·预约转化率是否与同类应用相比位居前列。
**2) 编辑最终审核**
编辑会亲自使用应用，并直接确认其完成度和实用性。
如果你对新的曝光政策有任何疑问 [请通过 Channel Talk](https://apps-in-toss.channel.io/home?page=https%3A%2F%2Fapps-in-toss.channel.io%2Fworkflows%2F787658)联系我们。为了让制作迷你应用的乐趣延伸为与用户相遇的喜悦，Apps in Toss 团队也会全力以赴。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://developers-apps-in-toss.toss.im/guide/zh/exposure.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
