Registering your app
Before you can submit your draft for approval and publishing, you must provide metadata about your app and register it in the Actions console. The following sections describe the information that you need to provide.
Most of this information will be public, and shown to users in the Assistant Directory (both the mobile HQ app and the Web Directory). To add this information click on App information, then click on the Add button.
Enter your app's name. This is how your app will be listed in the Assistant Directory, as well as how users will activate your app textually. Also, use your microphone to say your app's name to help us understand the pronunciation.
If your name is taken and shouldn't be, see the brand verification section.
- Enter details for your app, including descriptions and pronunciations of the app name.
- Provide banner and logo images for your app.
- Optionally enter testing instructions for your app. These are only visible to the review team and will not be seen by users.
- Enter contact information for your app. This is displayed publicly and is provided so users can contact you.
By default, your app is available in all regions as long as the user's device locale is set to an "English" variant (for example, EN-US or EN-GB).
The Actions console lets you control region availability with the Location targeting setting, which specifies the regions your app supports. A device's region is determined by its physical location and not by its locale. Regions are currently set at the country level.
You might want to use location targeting if you have an app that only allows purchases in certain countries or if your app relies on the user physically being in a specific country to use it. However, you should make your app available to as many regions as possible. For instance, if you create an app that teaches users about United States history, you should make the app available to all regions to get the most usage and exposure.
To set location targeting:
- Go to the Overview section of your project in the Actions console.
- In the Location targeting section, specify the regions that your app supports. By default, all regions are supported.
Surface capabilities let you control whether or not users can invoke your app, based on the surface they are using. If users try to invoke your app on an unsupported surface, they receive an error message telling them their device is unsupported.
Your actions can appear on a variety of surfaces that the Assistant supports, such as phones (Android and iOS) and voice-activated speakers.
Account linking is a great way to lets users connect their Google accounts to existing accounts on your service. This allows you to build richer experiences for your users that take advantage of the data they already have in their account on your service. Whether it’s food preferences, existing payment accounts, music preferences, your users should be able to have better experiences in the Google Assistant by linking their accounts.
Once you have added your actions and provided your app's details, you can simulate your draft which allows you to test and see what the user experience will be like on devices like Google Home and the Pixel.
To test, click on Test Draft in the Overview section. This will make a test version of your draft available in the Actions on Google simulator in the console, as well as on your own Actions on Google enabled devices.
To invoke your draft on the simulator, or on your devices, try typing or saying “Talk to APP_NAME, where APP_NAME is the name of your app.
Once you've thoroughly tested your assistant app draft and are happy with the results, you can deploy it to users. To do this, go to the Overview section for your app, and click the Submit Draft For Review button.
This will submit the current draft of your app for review. Our review team will test the app against our policies and if it is approved, it will be available to users.
As updates occur, you'll get emails and you can always track the status by returning to the Overview section of the console.
Learn more about what your deployment status means and how you can update it.
- Under Review: When you submit a new deployment, it goes through an approval process. Reviewers test your actions and verify that you haven't violated any policies. You will receive an email once a review has been completed telling you whether your deployment was approved or not.
Denied: An unapproved status means that your deployment was denied. You should receive an email explaining why your deployment was denied. You can also click Why? next to the Unnaproved status in the console to see the rationale for the denial.
Published: An approved deployment that is active and being served to users. Note that you can unpublish a published version at any point from the console.
Unpublished: An approved deployment that is not currently active and is not being served to users. Note that you can publish an unpublished version at any point from the console without going through review (since it has already been approved).
Published and Unpublished: Publishing and unpublishing take some time to take effect. These intermediate states reflect that your actions are either transitioning from unpublished to published, or vice versa.
Unhealthy: Google will regularly send a request to the endpoint of your MAIN intent, and check that we get an appropriate response. If we detect that your endpoint has gone down or is unresponsive, we will temporarily stop serving your actions to users.
In this case, you will receive an email informing you that your endpoint is unhealthy, and we will also show an Unhealthy status. As soon as we detect that your endpoint is responsive again, we will resume serving your actions to users. You will receive an email if this happens, and your deployment’s status should return to Published.
Taken down: Google may take down your actions if we detect a policy violation after deployment. You will receive an email if this happens, and you will also see a banner in the developer console informing you that your actions have been taken down. You can click Why? to see the rationale, and to see your options for either fixing the policy violation or appealing the decision. Note that some takedowns are final, and cannot be appealed or revoked.
Undoubtedly, over time you'll want to update information or actions in your app and these changes will result in a new version. Each version goes through the same approval process before your app is released to the public.
If you want to make updates, return to the platform you used, make changes to your actions and then update your draft to Actions on Google again. Once all of your changes are ready, click Submit Draft For Review on the app Overview page and a new version will be created. This new version will go through the same review process and if approved, the previous version will be unpublished, updating your app available to users.
Updating App Information
If you want to edit or change any app information specified in the console, just go to the My App card, make the changes, and click Submit. This will deploy your most recent actions and any new changes you have saved, as a new version.
Tracking and Modifying Versions
You can track and get information about your versions on the Overview page. Click the version in the table you want information about.
The table shows the last modified date and the current status of the version. You can make specific changes to the status, depending on the version's current status.
If a version is under review, you can withdraw the version from review.
If a version is published, you can unpublish it.
When a previous version is unpublished, you can Rollback to this version to revert the current app.
Now that your app is available to users, continue on to the Analytics and Health section to see how its doing.