Privacy Policy
Last updated: August 23, 2026
Information We Collect
When you sign in with Google or Apple, we receive your name, email address, and profile photo. We do not access your contacts, calendar, or any other data from your Google or Apple account.
We also collect the preferences you set within Trackly (job functions, locations, job type) and your application tracking data (saved jobs, applied jobs, and notes). If you choose to use trackly Apply, we also process your résumé, application-profile answers, approved-job selections, and value-free workflow status and safety evidence needed to prepare and recover application drafts.
trackly Apply and AI connections
When you connect trackly to a supported AI workspace, the provider receives the requests you make there and sends authorized tool calls to Trackly. Trackly returns only the account and workflow data needed for the requested action. Access is account-bound and can be revoked.
trackly Apply works only on jobs you approve. It can place your résumé and application-profile answers into an employer’s form, but it stops before submission. Employer sites may receive uploaded files or draft form data before you submit; their privacy policies govern data on their systems.
Trackly does not ask for or store employer-site passwords, one-time codes, or CAPTCHA responses. Sensitive answer values are returned only when required for an approved workflow and authorized by you.
How We Use Your Information
- Personalize your job feed based on your preferences and filters
- Send you notifications about new job postings that match your criteria
- Maintain your application tracker across web, iOS, and macOS
- Send daily digest emails if you opt in
- Improve Trackly based on the usage analytics and session recordings described below
Data Sharing
We do not sell or rent your personal information. We share data with service providers that process it on Trackly’s behalf to operate, secure, analyze, and improve the service. When you direct trackly Apply to prepare an application, the relevant résumé, files, and draft answers may also be transmitted to the employer or application-platform provider you selected.
Analytics & Session Recording
Trackly and its service providers collect identified usage analytics and session recordings to operate, debug, and improve the free product. When you are signed in, these records may be linked to your Trackly account.
We record sessions of some Trackly product surfaces. Recordings may capture readable on-screen text and your interactions there. Input values, including passwords, are masked. Request headers and bodies are not recorded.
The existing /onboarding, /profile, /chat, /inbox, /connector, and /settings surfaces are excluded from session recording and product event capture. These routes contain onboarding, application-profile and résumé management, AI prompts and AI-connection readiness, and account settings.
For MCP usage, Trackly may collect granular tool activity, structured job-search usage, selected fields from public results, agent-intent categories, runtime details, outcomes, timing, and sanitized failure details. MCP usage analytics do not include résumé text, profile answers, demographic or work-authorization answers, or application notes. Trackly may still process that information within its systems when needed to provide and optimize your job-search agent; it is not copied into MCP usage analytics.
Before MCP authentication, Trackly may collect anonymous initialization, tool-discovery, and setup-failure activity. After successful authentication, that activity may be associated with the authenticated MCP session.
Before you sign in on the Trackly macOS app, Trackly may collect a limited set of anonymous app-launch, distribution-channel, sign-in-attempt, sign-in-failure, invitation, and access-check lifecycle events. This activity uses a temporary identifier that is not saved or linked to your account, excludes free-form text and identifying data, and stops when you turn off usage analytics.
Visits to our public marketing pages may also be recorded before you sign in. These anonymous recordings are kept separate from authenticated product analytics until you sign in.
Usage analytics are on by default. You can turn off future collection at any time using Share usage analytics in Account Settings. Turning it off takes effect for future capture; traces already collected remain until they expire under the retention periods below. We do not use third-party advertising trackers. Authentication tokens are stored locally on your device.
Policy Updates
We post updates to this policy on this page and revise the “Last updated” date above when it changes.
Data Retention & Deletion
MCP traces and other product analytics events are retained for up to 12 months. Session recordings are retained for 30 days from capture, then deleted.
You can delete your account at any time from Settings. When you delete your account, all associated data (profile, preferences, saved jobs, tracking history, analytics profile, and session recordings) is permanently removed. You can also request deletion of your analytics data and recordings at any time by emailing [email protected].
Chrome Extension: Trackly → 12Twenty
This section applies to the Trackly → 12Twenty Chrome extension, which is distributed as an Unlisted extension on the Chrome Web Store and is used by Berkeley Haas Career Management Center (CMG) administrators to mirror Trackly job postings into the 12Twenty career platform.
What the extension accesses
The extension communicates with exactly two hosts, declared in the extension manifest as host_permissions:
https://closeai.mba/*: the Trackly backend API, used to list new job postings and read their details.https://mba-haas-berkeley.admin.12twenty.com/*: the Berkeley Haas 12Twenty admin tenant, used to look up matching employers, create new employer records when none match, and post job drafts.
Outside the active Berkeley Haas 12Twenty admin tab used for user-initiated actions, the extension does not access any other browser tab, bookmark, history entry, or download. It does not request the cookies permission and cannot read or write the cookie store directly. It does not install a persistent content script.
Chrome Web Store disclosure and permissions
Beyond the two host permissions above, the extension requests the storage permission for its own local settings and workflow state. The scripting permission lets the extension run a packaged function in the active Berkeley Haas 12Twenty admin tab for user-initiated employer lookups and draft creation, so those requests use the administrator’s existing signed-in page context. It does not install a persistent content script or download executable code. It also requests the Chrome identity permission solely to open and complete the optional Trackly Google Sign-In flow through Chrome’s extension redirect. The Chrome identity permission does not grant access to your Google contacts, calendar, or password. The extension does not request the separate identity.email permission.
Google Sign-In shares your name and verified email address with Trackly so Trackly can verify the account you selected, confirm access to this extension, and issue your personal Trackly credential. Trackly does not use the Chrome identity permission for advertising or unrelated browser activity. The use of information received from Google APIs adheres to the Chrome Web Store User Data Policy, including its Limited Use requirements.
Google Sign-In and Trackly credentials
Google Sign-In is optional. Manual trk_ API keys remain fully supported, including for existing installations, and you do not need to switch an existing manual connection to Google. You may also continue to paste and use a manual key on a new installation.
If you choose Google Sign-In, Trackly creates a personal, full-access trk_ API key for this installation. It is a normal Trackly credential that can access the Trackly account data and actions available to a full-access API key; it is not limited to 12Twenty posting. The extension stores that managed key locally in the same credential slot used for manual keys and sends it as a Bearer credential when calling Trackly.
When the extension calls the 12Twenty host, the browser itself attaches any session cookies you already have for that host (the same way any web page makes a credentialed request), so 12Twenty recognizes your already-signed-in admin session. The extension never reads, copies, or stores those cookies and never asks for, stores, or transmits either platform’s password.
What is stored locally
Extension settings and workflow state live in chrome.storage.local on your device. Trackly receives the Google authentication exchange, sanitized support diagnostics, and the Trackly API calls described above. The locally stored items are:
- Your Trackly API key and saved 12Twenty options, including owner, relationship-manager, contact, and posting defaults.
- For a Google-managed connection, locally stored identity and authentication metadata: authentication mode, your Trackly account identifier and verified email address, an installation identifier, and credential schema/version details.
- Draft sessions: the in-progress review queue of jobs you have synced from Trackly but not yet pushed.
- Trackly sync state, including the sync cursor and per-draft preference snapshot references.
- Posted-job history and deduplication safeguards that prevent accidental duplicate work.
- A bounded ledger of employers you created during the current install, used to keep create operations idempotent.
- A small autocomplete cache of recently looked-up employer names. No bundled employer database ships inside the extension package. The cache is populated lazily from 12Twenty’s own autocomplete API as you use it.
- A separate random diagnostics installation identifier, the local sanitized diagnostic event queue, and diagnostic delivery state.
Sanitized support diagnostics
Sanitized support diagnostics are sent to Trackly by default to help diagnose extension failures. You can stop future uploads in Options by turning off Send sanitized diagnostics to Trackly for support. The API key is used only as the authorization header and is not included in the diagnostic payload.
These automatic remote uploads include sanitized operation events, extension version, timestamps and reason, and a separate random diagnostics installation identifier. Events can include bounded job and workflow context such as job title, company and domain, posting and Trackly URLs, salary, location and classification data, draft field values, review messages, and error text. When the Options setting is enabled, uploads also include a sanitized settings summary with feature flags and owner, relationship-manager, and company-default option IDs. They exclude email addresses, passwords, cookies, the Trackly API key, Google identity metadata, authorization codes, and PKCE verifiers. Server-side copies follow the product analytics retention and deletion practices described above.
Switching accounts and local-data boundaries
When Google Sign-In changes the Trackly identity, or the previous identity cannot be confirmed, the extension clears only Trackly-derived drafts (including their preference snapshot references) and sync cursor after the new credential is stored. This prevents one person’s Trackly feed or preferences from carrying into another person’s connection.
Your 12Twenty settings, posted history, employer ledgers, and deduplication safeguards remain on this device. Unrelated local state also remains. Suggested roster setup fills only blank 12Twenty fields after you confirm it; choosing Google Sign-In does not overwrite populated 12Twenty settings.
What is not done
- No third-party analytics, telemetry, or error-reporting SDK. The first-party sanitized support diagnostics described above can be turned off in Options.
- No remote-hosted code. All extension logic ships inside the uploaded
.zipand is what is reviewed by Google. - No targeted advertising. No browsing history collection. No data sold or rented to third parties.
- When you choose Download diagnostics in Options, the extension creates a user-requested local JSON support artifact. This local diagnostic export is distinct from the automatic remote uploads described above. It excludes your email address, installation identifier, API-key prefix, authorization code, PKCE verifier, and the API key itself, and preserves the existing diagnostics format.
- The extension does not see, store, or transmit any 12Twenty student data. It only reads and writes employer records and job postings within the Berkeley Haas tenant your admin session already has access to.
Uninstall & data removal
“Disconnect Google” revokes that managed key before clearing it from this browser. If revocation temporarily fails, the extension keeps the connection so you can retry. A separately warned local-only override can remove the local credential while leaving the managed server key active. Removing a manual API key from this browser does not revoke it on Trackly because a manual key may also be used elsewhere.
Uninstalling the extension removes its locally stored data from Chrome, but uninstalling the extension may not revoke a managed key on Trackly. Use “Disconnect Google” before uninstalling when possible, or revoke the credential through Trackly. Until it is revoked, the server-side managed key may remain active even though it is no longer stored in this browser.
Clearing or changing a Trackly credential does not automatically remove the retained 12Twenty settings and safeguards described above. To remove all local extension state, uninstall the extension through Chrome. Uninstalling still cannot guarantee server-side managed-key revocation, so disconnect Google first when possible.
Contact
Questions about this policy? Reach out at [email protected].