Can I use ppctor for read-only Google Ads work? Permissions, approvals and revocation explained

You can use read-only workflows, but the Google Ads grant is broader

You can run audits, ask account questions and request reports without making live Google Ads changes. ppctor still requests the broad Google Ads OAuth scope; it is not a read-only Ads authorization. Supported conversational edits require a separate confirmation, while separately configured scheduled Rules can perform their configured actions.

This distinction matters when you are evaluating a connection for analysis. A read request describes what the app does for that operation. The Google consent screen describes the authorization being granted. A read-only audit does not narrow the underlying scope into a permanent read-only permission.

The right question is therefore both “What access am I granting?” and “What operations will my chosen workflow perform?” Review the scope, selected account, Slack destination and any configured automation. That gives you an accurate picture of the setup before you use it.

A normal request such as “What was purchase ROAS over the last fourteen completed days?” asks for data and an explanation. It does not authorize a budget update, campaign pause or conversion-role change. An audit finding likewise identifies an issue; it does not silently apply every suggested correction.

If your requirement is an authorization that technically permits only Ads reads, the current connection does not provide that narrower grant. Do not mistake an approval workflow for a different OAuth scope. You can instead evaluate whether the app's actual operation controls fit your organization's permitted use.

Separate the scope, account context and requested operation

A scope describes the authorized API capability. Account access describes which provider accounts the signing-in user can reach. The app's selected connection describes which account a particular workflow uses. The requested operation then determines whether it reads data, prepares a proposal or sends a supported live change.

Those layers answer different questions. A broad scope does not make every conversation a write. A channel mapped to one account does not mean the OAuth grant itself is technically limited to that channel. A successful report does not establish that every possible mutation would be valid for the account.

Google's OAuth overview for the Ads API explains using authorization to access user accounts without handling their login credentials. It also describes the provider's access model and additional API requirements. The account relationship remains relevant alongside consent.

Within ppctor, a selected or linked account supplies context for the feature. Before running an audit or posting a report, confirm the intended account and destination. In a multi-account organization, context mistakes can expose the wrong business information even when the authorization itself is valid.

Use the same separation when explaining controls to a colleague. “This audit reads the selected account” is an operation statement. “The grant includes Ads management capability” is a permission statement. “This proposed campaign pause still awaits confirmation” is an execution-state statement.

Keeping these statements separate avoids two misleading extremes: describing the entire product as unable to edit, or assuming every authorized data read automatically changes the account. The actual workflow has specific actions and specific controls.

Review the exact scopes requested at Google sign-in

The current sign-in request includes the identity scopes openid, email and profile, plus the three service scopes below. These are the identifiers used by the connection, not a shortened marketing description of the consent screen.

Service	Requested scope	Current use
Google Ads	https://www.googleapis.com/auth/adwords	Read account data and perform supported authorized Ads operations.
Merchant Center	https://www.googleapis.com/auth/content	Read connected product, issue and supported analysis data.
Google Analytics	https://www.googleapis.com/auth/analytics.readonly	Read linked property information and supported aggregated reports.

Google's scope reference describes the Ads and Shopping permissions broadly. The current Merchant tools read and report data despite that broad permission label. The Analytics scope is explicitly read-only; do not use that fact to characterize the separate Ads scope.

The identity scopes support knowing who signed in. They are not requests for your Google password. The app receives the identity information needed for the session and connection, while authentication itself happens with Google.

Read the actual consent screen for the account you are using. Granted permissions can differ from requested permissions when the user declines an optional scope. The app records relevant granted-scope state so a missing connection capability is not confused with a zero-result report.

A scope name is not a catalogue of every feature implemented by the app. It describes authorization at the provider boundary. Individual tools still have supported targets, account requirements and operation checks. The connection should not be presented as proof that every provider setting is exposed through one universal execution control.

For an internal review, keep this scope list with the selected workflow and current privacy policy. That gives the reviewer exact permission identifiers and an explanation of current use, without asking them to infer behavior from a broad consent label alone.

Understand what sign-in stores and what it does not receive

Google handles authentication. ppctor's current callback exchanges the authorization response for tokens and reads the user's profile information. It stores a session containing the necessary identity and token information. It does not ask you to send your Google password in Slack or paste it into an account-connection form.

The session includes an access token, an optional refresh token, name, email, profile image reference, token expiry and relevant granted-scope flags. These serve different purposes: identity establishes the signed-in user, while tokens allow authorized provider calls.

Current writes of session and refresh-token secrets use application-level encryption before storage. The encryption routine refuses to write a secret if its key is missing or malformed. That is a specific credential-storage control; it is not a claim that every saved report is encrypted with the same application routine.

The sign-in session has a seven-day storage lifetime, with active refresh behavior able to save an updated session. Refresh credentials used for background work are stored separately without that same seven-day expiry. Therefore, session expiry must not be described as automatic revocation of all provider access.

The current OAuth request asks for offline access so authorized background features can operate without an open browser session. This supports configured monitoring and reports. It also explains why closing a browser window is not the same as stopping every connected feature.

Treat credentials as service secrets. You do not need to include them in a support message, developer handover or client report. Describe the account and failed feature in readable terms; a raw access or refresh token is unnecessary for an ordinary investigation.

Choose the account context deliberately

The app discovers accounts reachable through the signed-in user's provider access and uses the selected account for relevant workflows. Choosing a different account changes the context of the question or page; it does not change a campaign setting in Google Ads.

An account pairing can also connect an Ads account with a Merchant account. The current pairing endpoint checks that the selected Ads account is reachable and verifies Merchant access where a Merchant account is selected. A pairing is an app configuration, distinct from modifying the product feed.

Not every Ads account needs Merchant Center. An audit or performance question can be relevant to a lead-generation business with no product catalogue. Conversely, Shopping Analysis needs the appropriate Merchant context. The assistant should explain the missing prerequisite rather than run a different account's data.

A Slack account-to-channel link establishes where relevant responses and configured output belong. Verify it before inviting a wider audience to the channel. A correct account pairing and an incorrect Slack destination can still put accurate information in front of the wrong people.

Use account names and contextual descriptions for ordinary output. Internal resource keys may be needed by the application, but they are not a useful substitute for telling the user which account or campaign is involved. Private identifiers should not be added to public examples.

When moving between accounts, check the active selection before asking a new question. A previous thread can contain useful historical context, but that context should not override the account you intend to inspect. Make a change in business context explicit instead of relying on an ambiguous phrase such as “this account.”

For a read-only review, record the selected account and requested feature before starting. This makes the scope reproducible. A colleague can understand that an audit concerned one account rather than every account the signing-in user could potentially reach.

Identify work that reads data without applying a live edit

Account questions, performance reports and audits read supported account evidence. A request for a table or chart changes the presentation of that evidence. It does not authorize a mutation merely because the assistant observes an underperforming campaign.

Policy and broken-link checks inspect relevant states or destinations. Their findings can identify work requiring attention. A finding is not a universal automatic repair, and a saved audit is not proof that every suggested action has been executed.

Merchant product and feed-health tools read catalogue and issue evidence. They can distinguish approval contexts from campaign selection, but the current Merchant implementation does not rewrite products or feeds. A Google Ads listing-inclusion operation is a separate Ads operation, not a Merchant feed edit.

Keyword research reads ideas or historical metrics through its supported provider tool when measured information is requested. Ordinary creative brainstorming can remain conversational. A suggestion for a keyword, headline or description is not a live asset creation.

Configured monitoring can also read data on a schedule. A read-only request in one conversation does not establish that no scheduled feature is active elsewhere in the account. Review the saved monitoring, reporting and Rules configuration separately.

A read may still create app records needed for results, delivery or diagnostics. “No live Ads edit” does not mean “no information is stored.” Understanding that difference is important when the review concerns privacy and retention as well as operational control.

Understand the confirmation boundary for conversational edits

When you ask for a supported live change, the assistant prepares an exact proposal. It identifies the target and action and presents a confirmation. Preparing that proposal is different from sending the mutation to Google Ads.

The confirmation uses readable target names and actual parent paths where relevant. A keyword belongs under an ad group and campaign; an ad group does not need an invented parent ad group. Each logical operation should appear as a clear step.

The message states that no changes have been made yet and that the proposal expires in fifteen minutes. The Confirm and Execute control authorizes the prepared operation. A normal question about performance does not replace that action with implicit approval.

One confirmation can cover a supported sequence with every action clearly described. If the complete request cannot be prepared safely, ask for smaller reviewed proposals before writing. The assistant should not silently execute only part of a larger request. The user approves the concrete displayed scope, not an undisclosed interpretation.

After confirmation, the flow checks current conditions and verifies the supported result. A visible change-in-progress state acknowledges the click. A successful result clearly marks the operation as executed and verified.

If the provider write was sent but the result cannot be fully verified, the flow reports the uncertainty and does not blindly replay the write. This is an operation-outcome control. It does not narrow the broad OAuth grant, and it should not be described as a guarantee against every possible account incident.

Review separately configured Rules before calling a setup read-only

Scheduled Rules are a distinct workflow. An owner can configure a rule with its intended conditions and actions. When enabled, that configured automation can perform its specified supported operation without a new conversational confirmation for each scheduled occurrence.

This is why the product must not be described as never changing accounts automatically. The correct distinction is between read-only features, confirmation-based conversational edits and deliberately configured automation. Review all three when deciding how the connection will be used.

A scheduled report is different from a Rule that performs an edit. Both can run while the browser is closed, but their effects differ. Identify the feature and configured action rather than infer behavior from the word scheduled.

If your intended operating policy is analysis only, review existing Rules and avoid configuring edit automation. That is an operating choice. It does not create a separate read-only OAuth grant or prove that the provider authorization has been technically reduced.

Record the actual enabled configuration in a team handover. An incoming operator should know which monitoring features only report and which Rules can act. A broad statement that “the Slack bot only answers questions” can conceal an already enabled automation.

When circumstances change, review the rule target and business purpose. A promotion ending or an account handover can make an old configured action inappropriate. Keep the owner's intended automation separate from the assistant's ordinary conversation so responsibility remains clear.

Distinguish Analytics reads, Merchant reads and Ads edits

Google Analytics access uses the read-only Analytics scope. A linked property can supply supported aggregated reporting about traffic, events and revenue. The current feature does not edit the Analytics property configuration through that read-only authorization.

The selected property matters as much as the metric. A valid link to the wrong property can produce a misleading comparison. Confirm the intended property and selected event before comparing a named Ads conversion with Analytics.

Merchant Center authorization has a broader permission label, while the current tools read product, issue and supported analysis data. Do not tell the user that a missing product benchmark was fixed by a Merchant write when no such write path was used.

Product inclusion or exclusion in a Google Ads listing tree belongs to Ads campaign selection. It is not the same as editing the Merchant catalogue item. A current Merchant approval and a campaign inclusion setting answer different parts of product visibility.

Optional granted scope state can affect availability. If the user declined the relevant service scope or has not linked the required property or account, explain the connection needed. Missing access is not evidence that a product or metric has a zero value.

For an access review, list each service, the selected context and the feature being used. That gives a reviewer a clearer picture than applying the word read-only indiscriminately to every connection or assuming every broad permission is exercised by every tool.

Choose the Slack destination with its audience in mind

Slack output is visible to the members of its selected destination. A performance report may contain business-sensitive amounts even when the underlying operation only reads data. Choosing the correct workspace and channel is therefore part of the setup.

Use a destination whose audience is appropriate for the connected account. An agency client channel and an internal operations channel can have different members. Do not assume the person requesting a report is the only person who can see the reply.

The app stores account-to-channel relationships and relevant workspace, channel and user identifiers. Those allow it to route replies and configured output. They are service context, not a reason to expose internal IDs in ordinary messages.

Conversation context helps the assistant understand follow-ups such as “pause that campaign” or “show the same period as a graph.” Context does not turn a prior read into authorization for a new live operation. A supported edit still uses its confirmation flow.

Disconnecting Slack removes its active delivery connection. The app parks channel links for seven days so a reconnection to the same workspace can restore eligible links. Parked links are not active destinations and do not reserve the channel.

Review output already posted separately from future access. Revoking a provider grant or disconnecting an integration does not make earlier Slack messages disappear. If the organization needs message removal or a broader data request, handle that through the relevant process rather than assume unlinking erases every copy.

Understand what the AI contributes to the workflow

The assistant interprets the question, selects supported tools when evidence is needed and explains the result. It can also brainstorm or draft content using the established context. Those creative responses do not need to be live provider operations.

When an AI feature is used, the relevant question, conversation context and necessary connected-account data can be sent to the configured model provider for inference. The current privacy policy names the possible providers. Do not assume every account result remains solely inside Slack or Google.

OAuth tokens and passwords are not part of the ordinary model input described by the policy. Credentials are handled by the application for authorized calls. The model's suggestion is not itself an authenticated provider mutation.

Supported account changes use the application's separate operation flow. The model can prepare the intent and targets, while confirmation and execution establish the authorized live action. A confident sentence from the assistant does not bypass the required operation checks.

For a review-only conversation, ask the assistant to explain findings and identify supported next steps. Do not ask it to describe an unverified current setting from general knowledge. Account-specific claims need the relevant read, while a general explanation can use known definitions.

Keep private information out of unnecessary prompts. A request to draft headlines or explain a conversion role usually does not need a customer's contact details. Use the minimum context that answers the question and consult the current policy when reviewing provider processing.

Know which information the app retains to operate

The app stores connection and identity information, selected account relationships and feature configuration. It can also retain audits, observations, reports, conversation records and operation outcomes. These support follow-ups, scheduled work, delivery and diagnosis.

A read-only provider operation can create a saved app result. For example, an audit can be stored so the owner can review its findings later. That storage does not mutate Google Ads, but it still belongs in a privacy and retention review.

Temporary provider-response caching is distinct from saved history. A short cache can make repeated reads efficient, while a saved observation supports a longer reporting feature. Do not describe all account data as an ephemeral cache if the feature deliberately retains records.

Session and refresh-token secrets are stored separately from ordinary report content and use the application encryption control described earlier. Other stored records have their own storage and access controls. Avoid a blanket claim that every field uses the same secret-encryption mechanism.

The current privacy policy explains the processing categories and service providers. Use it as the policy reference alongside this workflow explanation. An article about read-only operations is not a replacement for the full privacy information or an individualized data-handling agreement.

When requesting deletion or a retention clarification, name the records or feature involved. A session, conversation context, saved report and uploaded asset have different lifecycles. Specific questions produce useful answers without requiring the owner to expose unrelated account data.

Review retention by record type instead of one blanket expiry

The current Privacy Policy gives different typical retention periods for different records. Slack conversation context is seven days. Sign-in sessions are stored for up to seven days, while refresh behavior and a new sign-in can create updated session storage.

Questions, AI answers, submitted feedback, tool-run records and operational error logs are normally retained for ninety days. The current log sweep uses a ninety-day cutoff for its owned record types. This is separate from the shorter context needed to continue a Slack thread.

Slack channel links parked after disconnection have a seven-day restoration window for the same workspace. After that window, the parked relationship is eligible for removal by the scheduled sweep. It is not an active destination during the parked period.

Connections, saved monitoring and reporting settings, saved audits and other user-created records remain until removed, account deletion or an applicable feature-specific retention rule. Separately stored refresh credentials do not inherit the browser session's seven-day expiry.

Other feature records have their own lifecycles. The policy describes a thirty-day recovery period for deleted Asset Library files before scheduled permanent removal, and a ninety-day expiry for raw draft instructions and retrieved page facts while structured records can remain longer.

Unresolved delivery or incident reconciliation can require longer-lived records, and legal obligations can apply in individual cases. These boundaries are why “everything expires after seven days” is inaccurate. Review the actual record category and current policy rather than assume one timer governs the whole service.

Revoke authorization through your Google Account

You can review the app's connection and remove its Google authorization through Google Account permissions. Google's third-party connection guidance explains managing these relationships. Select the correct Google identity and the actual ppctor connection.

Revocation stops future authorized access through the revoked grant once it takes effect. It is different from simply closing a browser tab. A background feature depends on valid provider access and can no longer rely on a revoked authorization.

Google's OAuth revocation documentation explains that revoking a combined authorization affects its granted scopes and issued credentials, with a possible delay before full effect. Do not assume removing one app connection preserves another service scope from that same authorization.

Before revoking, consider which connected features rely on the grant. Ads reads, Merchant reads and Analytics reads can share the sign-in authorization. If the intention is only to unlink one property or stop one scheduled report, an app-level configuration change may be the relevant operation instead.

Revocation does not delete data already stored by ppctor or messages already posted to Slack. The current privacy policy explicitly distinguishes stopping new API access from removing retained information. Use the relevant deletion request process when that is the desired outcome.

After revocation, verify the connection state in Google and avoid expecting successful fresh account reads. Reconnection requires the appropriate authorization again. A clear handover should record the decision so a colleague does not mistake the resulting access failure for an unexplained reporting defect.

Distinguish logout, unlinking, revocation and data removal

Logging out ends the current app session and clears its browser cookie. The current logout handler does not revoke the separately stored background refresh credential. It should not be presented as a button that removes all Google authorization.

Unlinking an account pairing changes an app relationship. It does not delete the provider account or remove another service's product feed. The current pairing-removal operation is separate from Google's authorization management.

Disconnecting a linked Analytics property removes that app connection and pauses relevant dependent monitoring and reports. It does not edit the property itself through the read-only Analytics scope. Other connected features can have their own independent dependencies.

Disconnecting Slack stops the active workspace connection and parks channel relationships for the restoration window. That is different from removing previously delivered messages. The owner should evaluate future delivery and retained content as separate concerns.

Revoking Google's grant removes provider authorization. Data removal concerns records the service already holds. Neither operation should be described as automatically completing the other. Use the current privacy policy and contact process to request the appropriate data action.

A practical handover can name the exact intention: end this session, stop this report, unlink this property, revoke this Google authorization or request deletion of specified records. Clear wording avoids an operator performing the wrong kind of disconnection and assuming the broader task is complete.

Plan three fictional review-only workflows accurately

Imagine an invented agency, Willow Media, evaluating a retailer's campaign health. The owner reviews the Google scopes, chooses the intended account and links an internal Slack channel. The team runs an audit and discusses findings without approving any live change.

Willow Media records that this session was read-only work, while the underlying Ads authorization remained broad. It separately reviews configured Rules to avoid overlooking existing edit automation. Its handover explains the actual connection and operation boundaries rather than claim the product cannot write.

Now imagine a fictional service business, Oak Repairs, requesting a chart comparing a primary form conversion with a confirmed GA4 event. The team verifies the account and property context, then selects matching dates. The request reads data and creates presentation; it does not change conversion roles.

Oak Repairs notes that the resulting Slack message is visible to the selected channel members and that relevant conversation and reporting records can be retained. Read-only provider work still has an audience and a data lifecycle.

Finally, invented retailer Drift Shop ends its trial workflow. The owner logs out, disconnects the Slack workspace and removes Google's authorization through Account permissions. The team understands that those actions affect different layers and that previously retained records need a separate request if deletion is wanted.

These examples show the useful meaning of read-only work: the selected operations make no live provider edit. They do not invent a narrower OAuth grant, hide configured automation or assume every stored record disappears when the browser closes.

Create an access handover that the next operator can understand

Begin with the signed-in business context and purpose. State which account the workflow uses, which Merchant account or Analytics property is linked where relevant and where Slack results are delivered. Use readable names rather than include private identifiers in an ordinary client summary.

List the exact requested scopes and the current granted service access needed for the feature. Keep the distinction between broad Ads authorization and read-only operations. A new operator should not need to infer permission from the name of an audit command.

Identify active scheduled features. Separate reporting and monitoring from Rules that can perform configured edits. This makes the operating policy visible and avoids a handover that describes only conversational behavior while ignoring background automation.

Explain how supported conversational changes are approved. Show the proposal, confirmation and verification states in plain language. A team can then distinguish a suggested correction from a completed live operation.

Record retention and removal choices by category. Sessions, context, logs, connections and user-created records have different lifecycles. Include the relevant policy link and revocation route instead of one inaccurate promise that everything is temporary.

Keep the handover current when a connection, audience or workflow changes. It should describe the setup actually in use, not a historical onboarding screenshot. A clear reference reduces repeated permission questions and makes an intentional access change easier to verify.

Give each access decision a responsible owner. Someone should know who can approve an operation, who maintains scheduled configuration and who handles a requested revocation. This keeps a review-only working session understandable when the wider team also uses supported edit features.

Review access when the account or team changes

An account handover is a useful time to review the connected identity and selected destinations. The new owner may have different provider access or a different Slack audience. Do not assume the previous configuration remains appropriate merely because reports still arrive.

Review enabled Rules and scheduled outputs alongside connections. A report destination that was suitable for an internal team may be unsuitable for a client channel. An automated action intended for a promotion may be inappropriate after that promotion ends.

A missing provider grant should produce a clear access explanation. It should not be disguised as an empty performance result. If the organization deliberately revoked access, record that decision so operations staff do not keep treating the refusal as an unexplained service incident.

If a colleague needs to continue analysis, establish the correct authorized connection rather than share the previous owner's token or session cookie. Credentials are not a handover artifact. The useful reference contains account context, workflow configuration and business intent.

Review the current privacy policy when evaluating retained data or model processing. Service configuration can evolve, and the present policy is the appropriate disclosure reference. A prior article snapshot should not be used to invent guarantees about a later feature.

The objective is a specific informed decision: continue these reads, stop this schedule, change this destination or revoke this authorization. A concrete decision is easier to implement and verify than a vague instruction to make the entire integration safer without identifying the intended boundary.

Make the connection decision using the actual controls

For an analysis workflow, verify that your organization accepts the broad Ads scope even though the chosen operations are reads. If a technically narrower authorization is mandatory, the current connection does not satisfy that requirement simply because you plan to run audits only.

Then confirm the account and destination. A precise connection with an appropriate channel audience is central to the usefulness of the workflow. Privacy concerns are not limited to mutations; read results can contain meaningful business information.

Review any configured automation and decide which features should remain enabled. Treat scheduled Rules as explicit owner-configured behavior, not as a hidden extension of ordinary conversation. Keep that decision with the account handover.

Understand the approval path if you later request a supported edit. Preparation, confirmation, execution and verification are distinct stages. A useful result describes exactly which setting changed and which later observation, if any, is still needed.

Finally, know how to stop access and request data removal. Logout, integration disconnection, Google revocation and deletion requests serve different purposes. Choose the operation that matches the intended outcome and verify it at the relevant layer.

The result is an accurate picture of read-only use without an inaccurate read-only-permission claim. You can analyze the account and retain control over supported operations while understanding the broader authorization, configured automation, output audience and data lifecycle.

Frequently asked questions about read-only access

Does an audit change my Google Ads settings?

The audit reads supported evidence and reports findings. A suggested fix is separate from applying it. Supported conversational edits use confirmation; configured Rules have their own deliberate action configuration.

Is the Google Ads OAuth scope read-only?

No. The current connection requests https://www.googleapis.com/auth/adwords, which is broader. Describe your workflow as read-only work when it performs reads, but do not characterize the grant as a narrower read-only Ads permission.

Does logging out stop every background feature?

No. Logout ends the current session. Separately stored refresh credentials and configured features have different lifecycles. Use the appropriate feature controls or revoke authorization when the intention is to stop provider access.

Does revoking Google access erase earlier Slack replies?

No. Revocation concerns future provider access. Previously delivered Slack messages and retained service records need their own handling. Consult the current privacy policy for record categories and data requests.

Where can I review the full data-handling policy?

Read the current Privacy Policy alongside your connection and feature configuration. It explains accessed data, processing providers, typical retention and available controls beyond the narrower question of whether a particular operation edits Google Ads.