智能发送
利用 Apps in Toss 的智能发送，可以通过推送·通知消息有效实现吸引新用户、提升留存、促进服务使用等目标。
什么是智能发送
智能发送是一种同时考虑发送对象（细分人群）和发送时机，并自动进行优化的推送·通知发送工具。它并非简单的一次性发送，而是由 AI 预测以下两项内容，自动运营活动。
服务高参与度用户：利用所设细分人群的 pCTR（预计点击率）预测服务高参与度用户。
点击可能性较高的发送时间：利用用户的使用模式，预测更容易发生点击的时段。
运作方式
1）测试发送
这不是合作方的测试，而是内部为 AI 学习进行的自动发送。
基于 pCTR 预测服务高参与度用户。
根据预测结果，探索最佳用户和发送时机。
测试发送最多可能进行 7 天。
满足 25 次点击或发送 2,500 条中的任一条件后，将立即开始正式发送。
2）正式发送
反映测试结果，自动优化活动后进行发送。
推送和通知的概念
推送：即使未打开应用也能收到的操作系统（OS）通知。会同时显示应用名称和徽标。
通知：点击 Toss 应用右上角的铃铛图标时，可查看的应用内消息。
消息类型
可根据消息内容，选择发送营销消息或功能性消息。
营销消息： 如折扣、活动、新商品介绍等以营销为目的的消息。
功能性消息： 如订单、付款、配送、发布帖子等传达服务使用过程中产生的必要信息的消息。
若包含引导购买、引导使用服务、权益介绍、留存目的等营销元素，则无法作为功能性消息发送。
如果在烦恼消息文案 UX 写作文档和以下消息编写指南。
智能发送的优点
可自动向用户传达真正必要的消息。
从功能性通知到营销消息，都可按目的灵活使用。
即使用户未打开迷你应用，也能避免错过重要信息。
通过恰当时机的消息，可自然延续服务使用流程。
可根据发送结果不断改进消息内容。
请务必参考
如需发送推送·通知，需要审核消息模板文案。（营销消息将自动审核。）
编写推送内容后，会自动反映到通知消息中。
每个工作区（商家）最多可发送 10 万条。
若功能性消息中包含引导使用服务、权益介绍、留存等广告目的的内容，则必须作为营销消息发送。
如需发送功能性消息，必须事先获得用户同意接收该目的通知。
建议提供用户可取消接收通知的功能，并清晰说明取消方法。
在控制台中设置
访问方法：Apps in Toss 控制台 → 选择工作区 → 选择迷你应用 → 在左侧菜单中选择“智能发送”
1. 营销活动
营销活动由两种目的的分组构成。
引导新用户进入：引导尚未使用过迷你应用的用户首次进入。默认对象为所有尚未使用过迷你应用的用户。如需进一步缩小对象范围，可添加条件。
引导再次访问：引导近期使用减少的用户再次访问。默认对象为所有近期使用减少的用户。如需进一步缩小对象范围，可添加条件。
素材
每个分组最多可登记 2 个素材（A 方案、B 方案）。
营销活动无法使用动态变量（例如：
#{姓名},#{金额}等在发送时替换的值）。详细编写方法请参考消息编写指南。
点击后跳转页面的 URL
请输入点击推送或通知后跳转的 URL。
同一活动中无法为不同素材设置不同 URL。如需使用不同 URL，必须新建活动。
请务必确认是否能够正常访问。
发送时机
选择开始发送的时间点。
登记后立即发送：审核通过后立即开始发送。
设置发送期间：指定开始日期和结束日期。若要在没有结束日期的情况下持续发送，可选择“无结束日期”。
发送对象
可在默认对象中添加条件，以调整发送范围。
要包含的用户：向满足所设全部条件的用户发送。
要排除的用户：将满足所设全部条件的用户从发送对象中排除。
但对于引导再次访问发送，发送开始日前 30 天内的用户数须达到 100 人以上，才可发送。
2. 功能性活动
功能性活动是传达服务使用所必需信息的消息。应是收件人请求的信息，或为履行服务所必需的消息。若包含引导使用服务、权益介绍、留存等广告目的的内容，则必须作为营销活动发送。
2-1. 通过 API 直接发送
可在合作方服务器中按所需时间发送。
可在合作方服务器中按所需时间发送。发送 API 的详细规范可在“发送功能性消息”文档中查看。
活动标题：请起一个便于了解该活动以何种目的发送的名称。
标题：请在 7 个字符以内（含空格）使用名词形式编写。若使用“~하기”的形式，可能被误解为意在引导用户行为。
内容：请在 25 个字符以内（含空格）使用“~요.”体编写。变量按 2 个字符计算。通过 API 发送时，变量需自行开发。
跳转 URL：请设置点击推送或通知后跳转的页面。请务必确认能否访问。
发送代码：请输入发送代码，以便合作方服务器能够调用此消息。必须
{appName}-开头。通知同意文案：若在文案审核中被判定需要通知同意文案而驳回，请务必配置通知同意文案后请求重新审核。
2-2. 请求 Toss 发送
可选择一次性发送或定期发送。
无需服务器，即可选择一次性发送或定期发送。
活动标题：请起一个便于了解该活动以何种目的发送的名称。
标题：请在 7 个字符以内（含空格）使用名词形式编写。
内容：请在 25 个字符以内（含空格）使用“~요.”体编写。向 Toss 请求发送时，仅可使用姓名变量。变量按 2 个字符计算。
跳转 URL：请设置点击推送或通知后跳转的页面。请务必确认能否访问。
通知同意文案：请求 Toss 发送的情况下，必须提供通知同意文案。
发送类型：可在一次性发送和定期发送中选择。
一次性发送：指定特定日期和时间，仅发送一次。
定期发送：可设置重复发送周期。（每日：每天在指定时间发送／每周：选择所需星期和时间发送）设置开始日期和结束日期后，若选择“无结束日期”，将持续发送直至手动停止。
通知同意文案
发送功能性消息时，可能需要通知同意文案。通知同意文案是让用户能够在使用服务过程中同意接收通知的说明文案。若获得用户同意在特定时间接收通知，则必须使用通知同意文案。
若消息需要通知同意文案却未登记同意文案，则无法保存功能性消息模板。
设置通知同意文案
通知同意文案名称：请起一个让人能了解此同意文案会用于迷你应用服务中何种情况的名称。
通知发送时机：请填写同意后何时发送。
通过 API 发送的情况：请填写何时发送。（例如：收藏商品价格下降时、同意每天接收天气通知时、服务内被停用的功能重新启用时等）
请求 Toss 发送的情况：请明确填写何时发送及发送时机。（例如：每周二下午 5 点通知次日天气时等）
通知发送方式
满足特定条件：请填写满足何种条件时发送通知。（例如：收藏商品降价、被停用的功能重新启用等）
固定星期和时间：请填写发送周期和类型。（例如：每日天气通知、签到通知等）
如需在迷你应用中向用户展示通知接收同意 UI，请参考 请求通知同意文案文档。
消息编写指南
请抱着第一次向所有使用 Toss 的用户介绍我的应用的心态编写。用户会在名为“Toss”的金融应用语境中接收此推送。请确保消息呈现出 Toss 的风格，并能被自然理解。
基本规则
所有推送·通知均使用“해요体”。正文使用句子形式（“~요.”），并在句末加句号。这是为保持一致语调的规则。
句号仅用于正文。标题不使用句号。
标题使用“~하기”或名词形式。（功能性消息使用名词形式。）
不可使用“Toss + 服务名称”的编写方式。
标题最多 7 个字符、正文最多 25 个字符（含空格）。这是即使放大字体也不会被截断的标准。（在 Android 中，大于等于 1.3 倍的大字体占整体的 24%。）
请务必检查拼写和空格。
1）标题和内容必须自然衔接。
2）标题本身必须是完整的词语或句子。
3）游戏服务需明确标示为“游戏”。
用户应在点击前知道是否为游戏。若只使用服务名称或游戏内术语，用户可能无法了解。
不好的 示例：[竞争拼图] 拼拼图，也装饰我的家。
好的示例：[拼图游戏] 拼拼图，也装饰我的家。
4）不可使用以下表达。
仅部分人能理解的黑话·梗·流行语
特定人物姓名
不好的 示例：[我的理想型] 是张员瑛，还是安宥真？
好的示例：[理想型世界杯] 在 Toss 选择更接近理想型的偶像吧。
夸张的广告性表达
广告性表达：立即！、超特价！、史无前例、紧急！、超值
制造焦虑：错过会后悔、现在不做就没机会了
过多符号：感叹号、表情符号
刺激性题材
请避免政治、犯罪、死亡等敏感题材。
不要制造焦虑。请勿使用暗示错过会后悔的语气或让用户过度不安的词语。请仅冷静传达情况。
省略空格
不要为了凑字符数而省略空格。
不好的 示例：[我的打字准确度] 闭眼挑战输入句子吧
好的示例：[我的打字实力] 在 Toss 试试闭眼输入句子的测试吧。
别扭的表达
虽然语法上没有错误，但不自然的表达。朗读出来很快就能察觉。
不好的 示例：[我的小说] 也试试选择其他类型吧。Toss 免费。→ 缺少助词而显得别扭，会被理解为使用“Toss”服务是免费的。
好的示例：[我的小说] 可在 Toss 免费创作。
5）使用游戏类型时请参考以下内容。
不可使用从特定游戏名称衍生的类型。（例如：Roguelike、Metroidvania、Soulslike、Vampire Survivors-like 等）
请使用用户可直观理解的类型名称。
放置类 RPG
放置类游戏或 RPG 游戏
休闲 MMORPG
休闲游戏
开放世界动作
动作游戏
三消拼图
拼图游戏
回合制策略 RPG
策略游戏或 RPG 游戏
2D 横向卷轴动作
动作游戏