How Google Ads script authorization works
What you approve when you authorize a script, who the script acts as, and why authorization sometimes has to be repeated.
Before a script can run, a person has to authorize it. Authorization tells Google that the script may act on the account, and use other Google services, on that person's behalf.
What you are approving
The consent screen lists what the script needs: managing your Google Ads campaigns, and any other services the code uses β Google Sheets, Drive, Gmail, or connecting to external services. Google works this list out from the code it can see in the script.
The script acts as you
A script has no identity of its own. It runs with the access of the user who authorized it:
- It can reach the accounts and spreadsheets that user can reach, and no others.
- Emails it sends come from that user.
- If that user loses access to the account or leaves the organization, the script stops working until someone else authorizes it.
For anything long-lived, authorize with a login that will stay, not a personal one that might disappear.
When you have to authorize again
- The script begins using a service it did not use before.
- The authorizing user's access changed or was revoked.
- Google asks for re-consent after changes to its permissions.
Authorization and the chiliad loader
The loader fetches your code at run time, so Google cannot see which services that code uses. The loader therefore includes a setup() function listing the services detected in your script; it is never called, it exists so the consent screen asks for the right permissions.
If you later add, say, a spreadsheet export to a script that had none, copy the loader again and paste it over the old one, then authorize. Other changes to the code need no action in Google Ads.