交易 API 將於 2023 年 5 月 3 日淘汰,並將於 2023 年 6 月 13 日淘汰。詳情請參閱「
對話動作已淘汰」。
設計指南
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
設計對話,引導使用者完成交易流程。我們提供參考範例,協助您在設計自己的交易動作時做為參考。
範例
設計秘訣
確保對話方塊聲音自然且對話,符合一般人說話的方式。
文字轉語音/語音功能的文字不一定與即時通訊泡泡中顯示的文字完全相同。如果即時通訊泡泡是所說的對話的子集,效果相當良好。
問候訪客並吸引他們互動。詢問對方需要的資訊,並提出幾項建議方塊,幫助他們快速上手。
邀請使用者將商品加入購物車前,請先新增運算單元填充並使用 actions.type.TransactionRequirementsCheckResult
版位類型,確認使用者已經為 Google 助理設定付款方式。
請準備好回應與其他行動裝置或網頁體驗相同的語音問題。例如,不在特定尺寸或顏色缺貨時提供類似商品,或邀請使用者註冊,以便在商品補貨時收到通知。
請注意,訂單摘要是根據您透過 API 傳遞的資料建構而成。「透過 Google 付款」標籤可協助使用者瞭解 Google 已成功完成付款程序。
向使用者要求地址資訊等資訊時,請先告知對方您提出要求的原因,以及這對使用者有何助益。
Google 會根據使用者的設定顯示購買授權方法 (無須驗證、密碼或指紋)。我們的風險評估有時會開始額外的驗證步驟,例如確認卡片的 CVV。
付款完成後,請務必傳送收據並完成訂單確認。請務必讓使用者瞭解,您是收單商家,因此我們會傳送有關訂單的所有詳細資料 (而非 Google)。
根據預設,交易可以在有螢幕的途徑 (例如 Android 手機) 或純語音介面 (例如 Google Home) 上執行。
為了盡可能支援純語音交易,請格外謹慎設計良好對話體驗,引導使用者完成完整的交易體驗。
請注意,部分交易意圖可能需要畫面。大部分的這些資訊 (例如新增寄送地址、修正付款問題、帳戶連結) 會自動轉交給手機。如果畫面中有最適合顯示的對話新增內容 (例如製作卡片建構的複合式回應、顯示商家服務條款或隱私權政策),請檢查目前的途徑是否支援 RICH_RESPONSE
或 WEB_LINK
capabilities,如果不需要,請轉移至新途徑。
如果您不想用動作進行純語音交易,可以在動作主控台中依序前往「Deploy」(部署) >「Surface Features」(途徑功能),然後將「Do your Actions requires a screen output」 設為「Yes」,即可將動作專案設為要求特定畫面。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-07-25 (世界標準時間)。
[null,null,["上次更新時間: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**."]]