Your data, explained.

Google Ads integration: what we access

Ziro Labs operates a read-only reporting integration for its authorised business operators and Google's verification reviewers. It is available through a local reporting client and an isolated website reviewer route. Connecting either route requires your explicit Google OAuth consent and access to the relevant Google Ads account. Visiting ordinary website pages does not connect your Google account or retrieve your Ads data.

The integration can retrieve Google Ads customer and manager account IDs, account names and settings, and the account fields selected in an authorised reporting query. Depending on the query, these include campaign, ad group, ad, keyword and asset information; budgets and bidding settings; search-term, targeting and geographic reporting; and performance measures such as impressions, clicks, costs and conversions. An explicitly requested account-access audit can also return Google Ads user-access information, including email addresses where the API permits it. We request the fields needed for the operator's report, not a copy of the entire account.

We also process OAuth access and refresh credentials to maintain the authorised connection. Technical information can include the selected customer ID, query fields and filters, request timing, API request IDs, and error details. The integration does not request access to Gmail messages, Drive files, contacts, or payment-card details.

The requested OAuth scope is https://www.googleapis.com/auth/adwords. Google does not provide a separate reporting-only OAuth scope for Google Ads. Although Google's permission screen describes broad account access, the installed integration exposes only customer discovery, reporting queries, and resource metadata. It does not expose campaign creation, editing, deletion, billing actions, conversion uploads, or audience-list uploads.

How we use Google Ads data

We use the requested data to identify accessible accounts, answer the operator's reporting questions, explain available reporting fields, and present account and campaign performance. These features help Ziro Labs evaluate the marketing of its own mobile products. We use technical information to diagnose failed requests, maintain the connection, and protect the integration.

We do not sell or rent Google user data, build individual consumer profiles from it, transfer it to data brokers, or use it for unrelated advertising or surveillance. The current integration does not change the source Google Ads account. An operator who wants to change a campaign must use a separately authorised workflow outside this reporting integration.

Who receives Google Ads data

Google authenticates the connection, issues OAuth credentials, and supplies Ads API responses. Requests sent to Google include the credentials and account/query information necessary to authenticate and execute the requested operation.

Ziro Labs' authorised operators and Google's verification reviewers receive the results in their local reporting client or isolated reviewer portal. If an operator uses AI-assisted reporting, the relevant request and selected Google Ads results are also sent to OpenAI, the provider of the AI processing service, to generate the requested answer. Local execution of the MCP process does not mean that AI processing happens only on the device. The reviewer portal and a direct local MCP client operate without sending Ads results to an AI service.

Provider-side handling and retention depend on the selected OpenAI service, account terms, and data controls. Operators must use a configuration that excludes submitted Google user data from general model training before enabling AI-assisted reporting. If this cannot be confirmed, they must use a direct local client instead. We do not put OAuth secrets or developer tokens in prompts or reports.

Support and service providers may process information you deliberately include in a support email or an expressly authorised review artifact. Email providers deliver those messages. Fly.io hosts this website and the isolated reviewer portal. During a reviewer session, Fly.io processes the encrypted session cookie, OAuth credential and requested Google Ads response needed to serve the portal. The portal does not maintain an Ads reporting database. We share only what is necessary for the requested service, and do not publish account reports without separate authorisation.

We may disclose information where a valid legal obligation requires it, or with your explicit consent for a specific purpose. We do not transfer Google user data to third parties for their independent marketing or general-purpose model training. OpenAI's privacy policy and Google's privacy policy describe those providers' responsibilities.

How we protect Google user data

Google authentication and API traffic use HTTPS/TLS. The managed operator workstation uses full-disk encryption and an access-controlled operating-system account. The developer token is stored in macOS Keychain. The local OAuth credential file is outside the source repository and restricted to its owner with file permissions of 0600. Those file permissions restrict access; they are not a substitute for disk encryption.

Credentials are provided to the integration at runtime rather than committed to source control. The local tool version is pinned, and all exposed local and reviewer-portal operations are read-only. The reviewer portal protects its test login with a high-entropy credential, rate limits failed attempts, signs the login session, and encrypts the Google refresh credential inside a secure HTTP-only cookie that expires after eight hours. The portal does not require Google's reviewers to use the production owner's Google credentials or disable the owner's 2FA.

Technical logs may include account/query details and errors, so they require the same access restrictions as reports. We minimise recorded data and redact credentials from troubleshooting and review materials. No system can guarantee absolute security; report suspected exposure using the contact address below.

Retention of Google data and credentials

API responses: the local MCP process and reviewer portal handle responses in memory while serving a request. Neither maintains a separate reporting database or runs a scheduled background data sync. A response returned to the local reporting client can become part of that client's task history or a report saved by the operator. The reviewer portal response remains in the reviewer's browser page until it is replaced, closed, or the browser removes it.

Saved reports and task history: the integration does not impose an automatic expiry on these records. They remain until the operator deletes them or Ziro Labs acts on a verified deletion request. Ziro Labs retains its controlled copies only while needed for the requested reporting, support, or a legal obligation. Archiving a task is not deletion. Local logs and backups may contain separately retained copies and must be included in the operator's deletion process.

OAuth credentials: local refresh credentials remain until the connection is removed and the local credential copy is deleted. In the reviewer portal, the refresh credential is encrypted in a secure HTTP-only browser cookie and expires after eight hours; selecting Disconnect or signing out removes it earlier. Access tokens expire according to Google's rules. Revoking a Google grant stops future authorised access but does not automatically erase a local credential file, old reports, or task history. A developer token identifies the API integration and is retained in the hosting provider's secret store while the reviewer integration remains active.

Provider and support records: Google and OpenAI may retain records under their applicable terms, data controls, security requirements, and legal obligations. Their retention is separate from the local MCP process. Support emails are retained while needed to resolve the request and keep any necessary business or legal record. We do not promise that disconnecting the integration immediately removes every provider log or backup.

Revoke access or request deletion

You can revoke the Ziro Labs connection through your Google Account connections. A reviewer can also use the portal's Disconnect or Sign out control to remove the encrypted browser credential. A local operator must remove the local OAuth credential file and, when retiring the integration, its Keychain developer-token entry. Delete saved reports and task histories through the relevant client's deletion controls and remove any separately exported copies. Disconnecting is a separate action from deleting those records.

To request deletion of Google user data controlled by Ziro Labs, email namanmahendra8909@gmail.com with the subject “Google Ads data deletion”. Identify the connection or report so we can locate it; do not send passwords, access tokens, refresh tokens, or developer tokens. We verify that you are authorised, delete the controlled copies that are no longer required, and tell you if a legal retention obligation or a provider-controlled record limits the request.

Deleting integration records does not delete the original campaigns, reports, or account data held by Google Ads. Manage source-account data through Google's own controls. Where records are held in your own AI-service account, also use that provider's deletion controls.

Consent and limited use

Ziro Labs' use and transfer of information received from Google APIs must comply with the Google API Services User Data Policy, including its Limited Use requirements. Google user data is used only for the disclosed reporting and support features. We do not train or fine-tune general-purpose AI or machine-learning models with it, and operators may not enable optional model-improvement uses of that data.

This update makes the Google Ads integration's data flow explicit. Operators must review these disclosures before the next reporting session. If we change the data accessed, recipients, or purpose, we update this policy and obtain consent for the changed use before it begins. The other mobile apps listed on this site retain their separate product-specific policies.

Website privacy

The following sections describe ordinary visits to zirolabs.co. They do not replace the Google Ads integration disclosures above.

What Ziro Labs does not add

Ordinary website pages do not use advertising trackers, behavioural analytics, comment systems, payment forms, or marketing cookies. The isolated Google Ads reviewer route uses an app-login session cookie and, after explicit Google OAuth consent, an encrypted credential cookie. Ziro Labs does not build a visitor profile from ordinary website use.

Hosting and security information

The hosting and content-delivery providers may process limited technical information, such as IP address, browser and device details, requested URL, timing, and security logs. This processing is used to deliver the site, prevent abuse, diagnose failures, and protect the service.

External links

Links to Apple, Google, and other external services open those services. Their privacy policies apply after you follow the link.

Email

If you contact Ziro Labs by email, the message, sender address, and any information you include are processed by the email providers involved. We use that information to respond, provide support, protect users, and keep necessary business records.

Product policies

Visit the support directory to find the privacy policy for each Ziro Labs product. Product policies take priority for data processed inside that product.

Contact

For website or Google Ads integration privacy questions, email namanmahendra8909@gmail.com.