2. Information We Collect and Use
We follow the principles of lawfulness, fairness, necessity, and good faith. We process information only as needed to provide product features, perform our contract with you, protect security, respond to your requests, or comply with applicable laws and regulations. Unless the law allows otherwise or the information is necessary for a core feature, you may refuse to provide certain information or disable permissions, but the related feature may not work.
2.1 Chat Recognition and Reply Assistance
SayPilot is a user-triggered chat reply assistant. When you tap the floating assistant, generate reply suggestions, view draft suggestions, or ask SayPilot to review earlier context on a supported chat conversation screen, we may process:
- Currently visible chat text, conversation title, group title, message direction, sender display name, message-type placeholders, and timing or ordering cues.
- Input draft text, reply style, reply intent, banned words, relationship labels you enter for the other person and yourself, group reply targets, and whether an @ mention is needed.
- UI node text, control positions, page state, and basic screen structure, used to decide whether the current page is a supported chat conversation.
- Additional visible messages if you actively trigger history backfill or ask SayPilot to review more context. In that case, the App may briefly scroll the current chat page.
We use this information to understand the current conversation, generate candidate replies, evaluate whether a draft is appropriate, provide conversation summaries, help infer relationship or identity context, improve candidate ranking, and reduce repeated setup.
SayPilot does not send chat messages for you, does not tap a third-party chat app's send button, and does not write generated content into a third-party chat input box on its own.
SayPilot does not obtain chat records by reading third-party chat app databases, private directories, encryption keys, non-public interfaces, hooks, injection, cracking, or protocol emulation. It does not bulk export, sell, or collect chat records for purposes unrelated to reply suggestions.
2.2 Cloud Generation and AI Processing
When you use cloud generation, SayPilot sends the minimum context needed for reply generation to the SayPilot cloud service at https://www.getsaypilot.com over HTTPS. This may include:
- Request ID, request time, app version, request status, context source, and necessary model request metadata.
- Currently visible chat messages, conversation title, input draft, reply settings, group reply target, and local conversation or contact profile summaries you allow for the request.
- Screenshots or screenshot recognition results you allow for that request.
- Generated results, including candidate replies, draft evaluation, conversation summaries, model suggestions, relationship/identity hints, and profile review results.
Before a reply-generation request is sent, SayPilot shows a Pre-send Check that summarizes the selected chat context and reply settings. You can review the selected transcript, confirm generation, or cancel. The confirmation applies only to the current request; it does not enable background chat collection or automatic message sending.
Before building a cloud generation request, SayPilot locally redacts structured text where possible. The redaction replaces high-risk items such as phone numbers, email addresses, verification codes, passwords or passphrases, government ID numbers, passport numbers, bank card numbers, API keys or tokens, payment or transfer account identifiers, and precise address fragments. Redaction does not hide ordinary nicknames, names, relationship terms, or regular chat meaning by default, and it does not change the backend request schema.
The SayPilot backend may call AI model providers enabled in the current cloud routing configuration, or other necessary service providers, to generate reply suggestions, draft evaluations, conversation summaries, and profile review results. Specific provider names, purposes, data types, and regions are described in Appendix 3 of this Policy and the public website version. Model provider secrets should not be embedded in the client app package.
Please note that redaction is not the same as anonymization, and it may not detect or replace every sensitive item. We recommend that you do not intentionally submit passwords, payment verification codes, government ID numbers, bank card numbers, precise locations, contact lists, medical records, children's sensitive information, trade secrets, or other sensitive information unrelated to reply suggestions in chats, drafts, screenshots, or feedback. If you submit another person's personal information, you must make sure you have a lawful basis or authorization to do so.
2.3 Screenshot Recognition and OCR
When you actively trigger screenshot recognition, screenshot fallback, or manual screenshot mode and approve the Android system prompt, SayPilot may process the current screenshot, OCR result, screenshot area, screenshot time, and recognition status. A screenshot may include visible chat content, draft text, or other information shown on the screen.
Screenshot recognition is mainly used when the accessibility service is unavailable, disconnected, or unable to reliably read the current chat page. SayPilot does not continuously record the screen in the background. You may refuse screen capture permission; if you do, accessibility-based text recognition and existing local context may still be available.
If you choose cloud generation and allow screenshots to be included, the original screenshot or screenshot data may be sent to SayPilot cloud services and model providers for the current request, so they can understand the chat content and generate reply suggestions.
The first version does not blur or mask the screenshot image itself. The original screenshot may be used for the current cloud screenshot recognition or multimodal understanding request. Chat text, OCR output, or structured screenshot results returned from cloud recognition are locally redacted where possible before they are used for generation, long-term local memory, or feedback diagnostic export.
2.4 Local Settings, Conversation Memory, and Contact Profiles
To reduce repeated setup and make suggestions more relevant, SayPilot may store the following information on your device:
- Global reply preferences and default switches, plus long-term relationship, reply style, reply language, banned-word, and memory settings for eligible named direct conversations.
- Contact notes, the other person's identity, your identity, conversation summaries, and recent chat summaries for eligible named direct conversations.
- Long-term profile signals, preferences and taboos, interaction profiles, profile evidence, update time, confidence, and similar local profile information for eligible named direct conversations.
- On-device generation history created after you actively trigger generation, including candidate replies from direct or group chats and related context needed to display and review that result.
- Records showing that you acknowledged prominent permission disclosures, screenshot permission disclosures, app cache, temporary screenshot previews, and feedback export caches.
Before conversation memory, AI reply history, profile summaries, profile evidence, draft previews, and conversation previews are saved, the client locally redacts high-risk sensitive fragments where possible.
Reply intent, group reply targets, group reply scope, and whether an @ mention is needed are used only for the current runtime state or generation request. They are not stored as long-term group conversation memory or group contact profiles. Group chats do not create long-term conversation memory or contact profiles. However, group-chat candidate replies and the related context needed to review that result may be stored as separate on-device generation history until you clear local assistant data, newer history replaces the record, or you clear app data or uninstall the App. Generation history is not used as a long-term group profile.
This information is mainly stored in the App's private directory, SharedPreferences, database, or cache. You can clear local assistant data from "Management Center - Help and Feedback - Privacy and Local Data". After clearing, local profiles, conversation memory, default settings, permission confirmation records, and temporary caches will be reset.
Clearing local data does not automatically delete records that have already been sent to the cloud backend, model providers, or feedback handling systems.
2.5 Accounts, Sign-In, and Entitlements
Some cloud generation, quota sync, entitlement records, purchase records, feedback tracking, or cross-device features may require an account. Depending on server-side configuration, SayPilot may support email verification codes, phone verification codes, Google sign-in, Passkeys, or other sign-in methods. The methods actually available are those shown in the App.
When you use account features, we may process account ID, email address, phone number, verification-code request and verification status, necessary identifiers returned by Google sign-in, Passkey registration or sign-in challenges and verification results, login tokens, session status, account creation and login time, registration and sign-in IP addresses, authentication method, entitlement quota, subscription status, and risk-control status.
When an account is first created and during later sign-in or authentication requests, the server may record the public egress IP address it observes and associate the registration IP or recent sign-in IP with the account. We use this information to detect unusual registrations or sign-ins, prevent abuse, protect account security, and perform necessary security audits. The address may be affected by carrier networks, shared networks, VPNs, or proxies and does not represent a precise physical location.
We do not ask you to provide bank card passwords, payment verification codes, or third-party account passwords inside the SayPilot client. Please protect your email, phone number, Google account, Passkey, device unlock method, and other credentials.
2.6 Payments, Memberships, and Purchases
As of the last updated date of this Policy, the public SayPilot Android release offers one or more one-time credit packs and auto-renewing subscriptions through Google Play Billing. Each one-time pack grants the number of credits displayed in the App after successful verification and does not renew automatically. Subscriptions have weekly, monthly, and annual base plans: the weekly plan provides 200 credits each week, and eligible Google Play users may receive a three-day free trial that automatically converts to weekly billing; the monthly plan provides 300 credits each month; and the annual plan is charged yearly and provides 300 credits each month while active. The products actually offered, credit amounts, prices, currency, taxes, free-trial eligibility, and trial-to-paid conversion time are those displayed in the App and Google Play checkout. External payment methods and simulated or test payment features are not offered to ordinary release users.
When you buy, subscribe, restore, receive a refund, cancel, or otherwise manage a Google Play product, we may process product ID and type, base plan ID, offer or trial information, order number, purchase token, payment and acknowledgement status, subscription and auto-renewal status, current billing-period end time, credit amount, refund status, voided-purchase status, restoration result, and payment verification result. We use this information to verify purchases, grant and refresh entitlements, restore purchases, manage the subscription lifecycle, process refunds, and prevent abuse. Sensitive payment credentials such as payment card numbers are normally handled directly by Google Play and are not collected directly inside the SayPilot client.
You can manage or cancel a subscription through an in-app link or the Google Play subscription management page. After cancellation, subscription benefits generally remain available until the end of the current paid or started billing period. Uninstalling the App or deleting your SayPilot account does not automatically cancel a Google Play subscription. Refund eligibility and outcomes are determined under the applicable Google Play refund policy.
2.7 Feedback, Support, and Diagnostics
When you submit feedback, export diagnostic files, attach screenshots, or contact us, we may process the issue description, contact details, device model, system version, app version, permission status, request status, error logs, request IDs, conversation summaries, screenshots, diagnostic files, and communication records you provide.
We use this information to investigate issues, respond to you, improve the product, handle complaints, verify account or data deletion requests, and maintain service security. You may choose not to submit feedback materials, but this may limit our ability to diagnose or resolve the issue.
When you export a feedback diagnostic package or copy diagnostic information, chat text in recognition details, request log summaries, and user notes is locally redacted where possible. Contact details you actively enter are kept so we can reach you. If you choose to attach a recent screenshot, the original screenshot may still contain unredacted screen content; please review it before submission.
2.8 Device, App, and Security Logs
To keep the software and services running securely, troubleshoot issues, measure service quality, and prevent abuse, we may process app version, system version, device model, network request status, cloud API status, crash information, error logs, request latency, request success or failure status, IP address, account login status, quota usage status, and necessary security or risk-control information.
If the first-run rating prompt is configured with a country allowlist, the SayPilot backend may use the public egress IP address observed for the capabilities request to obtain an approximate country code from the configured IP-geolocation service. We use that result only to decide whether to show the first-run rating prompt in that country. This does not use GPS or precise device location, does not require an Android location permission, and does not return the IP address or resolved country to the App. The configured geolocation provider may receive the public IP address. Successful lookups may be cached in backend memory for up to six hours, while failed lookups may be cached for up to five minutes; if the country cannot be resolved, the first-run rating prompt is not shown.
Cloud requests may also carry a randomly generated installation client identifier, a one-way hash of Android ID, and a device fingerprint derived from that hash. The raw Android ID is not sent. These pseudonymous identifiers are used to bind login-verification requests, provide anonymous trials, detect multiple accounts or repeated claims on the same device, perform security and abuse prevention, associate necessary diagnostics, and measure product usage. They may be associated with a SayPilot account after sign-in.
SayPilot does not read contacts, SMS, call logs, precise location, photo library files, passwords, payment verification codes, or content unrelated to reply suggestions for the purpose of generating replies.
SayPilot also does not read third-party chat app local databases, private directories, encryption keys, or non-public interfaces for reply suggestions, and does not use hooks, injection, cracking, or protocol emulation to bypass the normal permission and security boundaries of third-party apps.
2.9 Product Analytics, Advertising Measurement, and Pseudonymous Identifiers
When the configured SayPilot cloud service is available, the Android App automatically reports a limited set of product analytics events. These include first open and app launch events; permission guide, settings-opened, permission-granted, and required-permissions-ready events; and Google Play purchase and subscription funnel events such as paywall views, product/base-plan/offer and price availability, product selection, purchase clicks, purchase-sheet opening, cancellation, errors, trial or subscription status, and verification status. This reporting happens when the App starts or when you use the relevant permission or purchase flow; it does not require a separate submission action for every event.
If you install the App through a source-tagged SayPilot website or Google Play link, the App may use Google Play Install Referrer once during its first run to read allowlisted installation-source information. This may include the source platform (for example, TikTok, YouTube, or the SayPilot website), medium, campaign and content short codes, a one-time random click identifier generated by SayPilot, and source-click and install-begin timestamps supplied by Google Play. This first-party acquisition feature itself does not read the advertising ID, store the complete raw Install Referrer string, or send in-app events back to source platforms such as TikTok or YouTube. The optional Google and Meta advertising-measurement paths described below are separate from that first-party attribution record.
Each event may contain the randomly generated installation client identifier described above, sent as anonymous_id, together with the event name, platform, app version and version code, functional channel or source, first-install source, and limited event metadata. Depending on the event, metadata may include permission type and readiness, source medium/campaign/content short codes, a one-time random click identifier, source-click and install-begin timestamps, product ID and type, base plan ID, credit amount, whether a price was available, Google Play response code, error class, or a shortened error message. The backend hashes the identifier again before storing the analytics event. The identifier is pseudonymous rather than anonymous because it remains stable in the App's private storage and is also used for some account-verification and security functions; while you are signed in, the login session may also associate the event with your SayPilot account ID.
We use these events to measure first opens, permission setup, reply generation, copying, and purchase funnels resulting from different source links; evaluate content promotion and acquisition channels, release quality, and service reliability; troubleshoot failures; and prevent abuse. First-party SayPilot analytics events are not intended to contain chat text, screenshots, contact names, advertising IDs, or precise location. We do not sell this information or use it to provide personalized advertising.
SayPilot also offers optional Firebase Analytics, Google Analytics 4 (GA4), and Google Ads measurement for a limited set of advertising conversions: first open, the first successful reply per installation, the first real paid subscription, subscription renewal, and completed purchases. The only custom business event the Android client actively sends to Firebase is first_reply_generated, at most once per installation. When supported, Firebase and Google Play automatically collect first_open, in_app_purchase, app_store_subscription_convert, and app_store_subscription_renew; the Firebase Analytics SDK may also collect its standard app-lifecycle and engagement events, such as session_start, user_engagement, app_update, and os_update. These SDK-defined lifecycle events are not additional SayPilot business-event mappings and should not be treated as the same business conversion. Permission, copy, ordinary reply, and checkout-funnel events remain in SayPilot's first-party product-analytics path and are not sent to Firebase. When enabled, Google may process a Firebase app-instance identifier; a device or advertising identifier where the device, system, and permission state allow it; app version and lifecycle or engagement state; that first-reply event; and product, price, currency, subscription, and purchase status automatically supplied through Google Play for analytics, advertising attribution, conversion measurement, and campaign optimization. Automatic Firebase screen-view reporting remains disabled. SayPilot does not put chat text, screenshots, contact or group-member names, drafts, reply content, prompts, SayPilot account identifiers, email addresses, phone numbers, stored user IP addresses or country codes, order numbers, raw purchase tokens, Android ID, device fingerprints, or raw error responses into these event parameters. Google may nevertheless process network-transport metadata, including the public IP address from which an SDK or server request connects, under its policies. Advertising personalization and remarketing signals remain disabled, and SayPilot does not display ads in the App.
After advertising measurement is allowed, the Android client may send the Firebase app-instance identifier to the SayPilot backend at low frequency; this installation-level binding does not require signing in to a SayPilot account first. The backend stores that binding in encrypted form solely to export Google Play purchase facts confirmed by backend verification to the same Firebase/GA4 app instance asynchronously. A fixed allowlist maps only paid_subscription_started (the first real paid subscription) and credit_pack_purchased (a credit-pack purchase). Only after the backend strictly matches the corresponding production Google Play order, verifies it as PROCESSED, and accepts its positive actual order total and currency may either event include that actual value and currency for conversion-value and return-on-ad-spend optimization; SayPilot does not substitute a catalog price, client display price, or backend default price. Value resolution and delivery run asynchronously in the backend and do not delay purchase verification, entitlement delivery, or App responses. The server-side event payload does not include your SayPilot account ID, email address, phone number, stored user IP address or country code, order number, purchase token, chat content, screenshot, reply content, or other personal information. The Measurement Protocol request necessarily exposes the SayPilot server's network egress IP to Google. Automatic Google Play/Firebase purchase events and these custom events may describe the same revenue, so they must not be added together or both treated as primary conversions for the same revenue goal. paid_subscription_renewed is not currently enabled; renewal measurement continues to rely on automatic events. The GA4 Measurement Protocol secret is held only on the backend and is unavailable to the client.
When the Meta destination is separately configured and ready, the same advertising-measurement setting may also enable Meta App Events through the Meta Core SDK. On the Android client, SayPilot limits this path to the SDK install ping and the installation-level first_reply_generated event; it does not manually log a Meta lifecycle-activation event. Meta automatic in-app-purchase logging, automatic App Events, codeless debugging, and SDK monitoring remain disabled. Advertiser-ID collection starts disabled and is enabled only after the updated Meta disclosure is effectively allowed and the backend Meta identity is registered, where the device and platform allow it; it is disabled again on withdrawal. Meta's event-and-data-use restriction remains enabled: SayPilot limits use to analytics and conversion measurement and does not use the data for targeting. The client does not report trial, subscription, or purchase events to Meta.
After Meta measurement is allowed, the Android client may send an installation-scoped Meta anonymous app-device GUID to the SayPilot backend at low frequency, without requiring a SayPilot account sign-in. This GUID is separate from the Firebase app-instance identifier and the first-party analytics identifier. The backend stores the GUID in encrypted form and uses an independent bounded outbox containing derived HMAC identifiers, an internal account cleanup/ownership key, allowlisted business semantics, and delivery state. The internal account key never enters Meta's HTTP payload, and the outbox contains no GUID, IP address, raw purchase token, order number, or chat content. It asynchronously maps only trusted Google Play facts to StartTrial for a verified production free-trial start, Subscribe for a verified first real paid subscription, and fb_mobile_purchase for a verified one-time credit-pack purchase. Google Play license-test purchases, one-time products carrying any non-cash purchase marker, and unknown trial/payment classifications are rejected rather than exported. StartTrial carries no monetary value. When the backend strictly matches a paid event to the exact production Google Play order, verifies that the order is PROCESSED, and accepts its positive order total, Subscribe or fb_mobile_purchase may include that actual order value and currency as Meta's _valueToSum and fb_currency parameters for conversion-value and return-on-ad-spend optimization; an unresolved or rejected order remains a count-only event. These Meta values must not be added to Google/Firebase purchase events when calculating SayPilot revenue. The Meta server access token is held only on the backend and is unavailable to the client.
The initial state of advertising measurement depends on the region where the App is used and applicable requirements. In regions where law, regulatory rules, or platform rules require prior consent, measurement remains off until you actively allow it. In other regions, measurement may be initially enabled for the purposes described in this Policy. In a consent-required or unknown region, a choice recorded by an older version whose disclosure named Google only is not valid for the expanded feature: the UI shows the switch off and both Google and Meta remain off until you make a choice under the updated disclosure. You can change the single setting at any time in "Management Center - Help and Feedback - Privacy and Local Data." Turning it off stops subsequent Firebase and Meta business-event logging, resets the local Firebase analytics state, disables the Meta measurement sink, requests deletion or tombstoning of the corresponding backend Firebase and Meta installation bindings, and cancels related server-side conversions that have not started delivery. Events occurring before consent or while measurement is off are not uploaded later. Data already transmitted to or accepted by Google or Meta, and work placed in a provider SDK's private in-memory queue before the switch changed, cannot be recalled by the switch and remains subject to the applicable provider retention, deletion, and conversion controls. SayPilot does not use Meta's lifecycle-tracking activation API; the disabled sink does not create subsequent SayPilot business or lifecycle events. Turning measurement off does not affect SayPilot's core reply features.
When the App first determines this regional initial state, it may request a coarse measurement-requirement classification from the SayPilot backend. The backend may evaluate the public IP address observed for that request. To reduce repeated external lookups, the bounded country resolver may keep an approximate country code in short-lived in-process memory, for about six hours by default, but does not persist that country code as a marketing event. The App receives only one of three states—consent-required region, other region, or unknown—not a specific IP address or country code. The IP address, country code, and three-state classification are not sent to Google or Meta as advertising-measurement event parameters. This is not continuous location or regional tracking. If the lookup fails, cannot make a determination, or returns unknown, measurement defaults to off.
2.10 Updates and Notifications
SayPilot may connect to cloud services to check the app version, update status, official update address, and forced update flags. Notification permission is used when needed to keep the floating assistant, screenshot recognition, or background tasks visibly running, or to show service-related notices.
You can disable notifications in system settings. If you do, some foreground service notices, error messages, or background task status notices may not appear.
2.11 Cases Where Separate Consent May Not Be Required
Where permitted by applicable law, we may process your personal information without separate additional consent in the following situations:
- The processing is necessary to enter into or perform a contract with you.
- The processing is necessary for us to perform legal duties or obligations.
- The processing is necessary to respond to a public health emergency, or to protect an individual's life, health, or property in an emergency.
- The processing is carried out within a reasonable scope for public-interest news reporting, public opinion supervision, or similar activities.
- The processing concerns personal information you have made public yourself, or information that has otherwise been lawfully made public, within a reasonable scope.
- Other situations provided by laws and regulations.
