Transaction API 将于 2023 年 5 月 3 日弃用,在此之前,会话操作将于 2023 年 6 月 13 日停用。如需了解详情,请参阅
对话型 Action 停用。
设计准则
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
设计对话以引导用户完成事务流程。我们提供了参考示例,您可以在设计自己的事务性 Action 时参考这些示例。
示例
设计提示
确保对话听起来自然且如真人对话,就像真人说话一样。
TTS/语音朗读的文字不一定要与聊天气泡中显示的文字完全一致。如果聊天气泡是语音对话框的子集,此方法会非常有用。
问候访问者,吸引他们参与互动。询问他们需要什么,然后提供一些建议内容信息卡,帮助他们上手。
在邀请用户将商品添加到购物车之前,请通过添加槽填充并使用 actions.type.TransactionRequirementsCheckResult
槽类型执行后端检查,以确认用户已为 Google 助理设置付款方式。
准备好应对与其他移动或 Web 体验一样的语音问题。例如,在商品缺货时提供类似商品,或邀请用户注册以在商品恢复有货时收到通知。
请注意,订单摘要是根据您通过 API 传递的数据构建的。
“通过 Google 付款”标签有助于用户了解付款是由 Google 协助完成的。
向用户请求信息(例如其地址信息)时,请先让用户了解您提出请求的原因,以及该请求将给用户带来什么好处。
Google 将根据用户的设置提供购买授权方法(无需进行身份验证、密码或指纹)。有时,我们的风险评估会启动额外的身份验证步骤,例如确认银行卡的 CVV。
付款完成后,请务必发送收据和订单确认书。请务必让用户了解您是收单商家,并会跟进有关订单(而非 Google)的所有详细信息。
默认情况下,您可以在带有屏幕的 surface(例如 Android 手机)或仅支持语音的 surface(例如 Google Home)上执行事务。
为了最好地支持纯语音事务,请格外小心,设计出良好的对话体验,引导用户完成完整的交易体验。
请注意,某些交易 intent 可能需要一个屏幕。其中大部分操作(例如,添加新的配送地址、解决付款问题、帐号关联)都将自动发送到手机上。如果对话中有任何最适合显示在屏幕上的内容(例如,针对卡片构建提供丰富的响应、显示商家服务条款或隐私权政策),您应检查当前 surface 是否支持 RICH_RESPONSE
或 WEB_LINK
capabilities,如果不支持,则转移到新 surface。
如果您不想让 Action 支持纯语音事务,则可以将 Actions 项目设置为需要屏幕,方法是在 Actions 控制台中转到 Deploy > Surface capability,并将 Do your Actions required a screen output 设为 Yes。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eDesign conversational transactional flows, similar to natural human interactions, guiding users through the process.\u003c/p\u003e\n"],["\u003cp\u003eUtilize provided examples and design tips to create effective and user-friendly transactional Actions.\u003c/p\u003e\n"],["\u003cp\u003eEnsure clear communication, address potential issues proactively, and inform users about Google's role in payment processing.\u003c/p\u003e\n"],["\u003cp\u003eOptimize for both screen and voice-only interactions by tailoring the conversation and utilizing surface capabilities effectively.\u003c/p\u003e\n"],["\u003cp\u003eCustomize the user experience by enabling or disabling screen requirements based on your Action's functionalities.\u003c/p\u003e\n"]]],[],null,["# Design guidelines\n\nDesign a conversation to guide users through your transactional\nflows. We've provided reference examples that you can use as a guide\nwhen designing your own transactional Actions.\n\nExamples\n--------\n\n[](https://docs.google.com/presentation/d/1Zw-Cg4ODJWpEViJJT_LugxvFv1VeOB7Hw54wNQemrfg) [Shoe store Example](https://docs.google.com/presentation/d/1Zw-Cg4ODJWpEViJJT_LugxvFv1VeOB7Hw54wNQemrfg) \n[](https://docs.google.com/presentation/d/1RBVzklC8n7nPU98lRt1CkzDSFcBlaQf5PWVtlr58OQQ) [Ticketing example](https://docs.google.com/presentation/d/1RBVzklC8n7nPU98lRt1CkzDSFcBlaQf5PWVtlr58OQQ) \n[](https://docs.google.com/presentation/d/1icd64B_mJvba6lmhlfmUy35sejy5n-LsYYkvPXzUXgA) [Flower Shop Example](https://docs.google.com/presentation/d/1icd64B_mJvba6lmhlfmUy35sejy5n-LsYYkvPXzUXgA)\n\nDesign tips\n-----------\n\n- Make sure the dialogs\n [sound natural and conversational](/assistant/conversational/df-asdk/design)\n --- the way a real person would talk.\n\n- The text spoken by your TTS/voice does not have to exactly match the text\n shown in your chat bubbles. It works well if the chat bubbles are a subset\n of the spoken dialog.\n\n- Greet your visitors and get them engaged. Ask what they need and offer a\n few suggestion chips to get them started.\n\n- Before inviting the user to add items to the cart, do a backend check by\n adding slot filling and using the `actions.type.TransactionRequirementsCheckResult`\n slot type to confirm the user has payments set up for their Google Assistant.\n\n- Be prepared to respond to the same issues with voice as with other mobile\n or web experiences. For example, offer a similar item when you're out of a\n certain size or color, or invite users to sign up to be notified when the\n item is back in stock.\n\n- Note that the order summary is built with the data you pass via the API.\n The \"Pay with Google\" label helps users understand that Google facilitated\n the payment.\n\n- When requesting info from your users, like their address info, first let\n them know why you are making the request and how it will benefit them.\n\n- Google will present the purchase authorization method (either no auth\n required, password, or fingerprint) based on the user's settings. Sometimes\n our risk assessment will kick off an additional auth step like confirming\n CVV for a card.\n\n- After the payment is complete, be sure to send a receipt and an order\n confirmation. It's important that users understand that you are the merchant\n of record, and will follow up with all details about the order, not Google.\n\n- By default transactions can be performed on either a surface with a\n screen (such as an Android phone) or a voice-only surface (such as a Google Home).\n\n - To best support voice-only transactions, take extra care to design\n a [good conversational experience](/assistant/conversational/df-asdk/design)\n that walks users through the full transaction experience.\n\n - Note that some transactions intents may require a screen. Most of these\n (e.g. adding a new delivery address, fixing payment issues, account linking)\n will be handed off to the phone automatically. If there are any additions\n to the conversation that are best displayed on a screen\n (e.g. presenting rich responses for card building, displaying a merchant\n ToS or privacy policy), you should check if the current surface supports\n the `RICH_RESPONSE` or `WEB_LINK`\n [capabilities](/assistant/conversational/reference/rest/v1/TopLevel/fulfill#capability),\n and transfer to a new surface if not.\n\n - If you would rather not support voice-only transactions with your\n Action, you can set your Actions project to require a screen by\n navigating to **Deploy \\\u003e Surface capabilities** in the\n [Actions console](https://console.actions.google.com) and setting\n **Do your Actions require a screen output** to **Yes**."]]