Privacy Policy

1. Introduction

Xamtac Consulting LLC operates AI Marketing Dashboard, an agency operations platform for client reporting, CRM, projects, chat, meetings, files, notes, client portals, a marketing library, campaign planning and publishing.

This policy covers our public website, the sign-up and billing flow, the agency console and the client portals we host. Your use of the Service is also governed by our Terms & Conditions. It does not cover the privacy practices of the third-party platforms you connect to the Service, or of the agencies who use the Service to serve their own clients; those are governed by their own policies.

2. Our Role: Business and Service Provider

Where we act for ourselves. For visitors to our website, people who sign up for an account, workspace administrators and the people we market to, we decide how and why information is used. Under United States state privacy laws we are the “business” for that information (a “controller” under similar laws elsewhere), and this policy describes what we do with it.

Where we act for our customers. Most of the information in the Service is Customer Content: the client records, CRM leads, files, messages, notes, form and booking submissions collected through pages our customers publish, and the activity of the portal users they invite. For that information the agency is the business, and we act as its service provider (a “processor”), handling the data on that agency’s instructions in order to provide the Service. We do not use Customer Content for our own advertising, and we do not sell it.

If you are the client of an agency, or a visitor who filled in a form on a page an agency published, contact that agency first about your information. If you contact us instead, we will route your request to the agency and assist it in responding.

3. Information We Collect

Information you provide. Your name, email address, password credentials, company and workspace details, job title, profile photo, and the content you create or upload in the Service (files, notes, messages, tasks, CRM records, campaign material and similar). When you subscribe, our billing and payment providers collect your billing contact, plan and payment details; we receive the subscription and payment status and the billing contact. We do not store full payment card numbers. We also keep the content of support requests you send us.

Information collected automatically. Device and browser information, IP address, approximate location derived from it, pages viewed, referring pages, the actions taken in the product, session identifiers, and error, performance and diagnostic logs. Some of this is collected using cookies and similar technologies, described in Section 7.

Information from platforms our customers connect. At a customer’s direction and with the permissions that customer grants, we retrieve advertising, analytics, search, email and social data from the accounts they connect. Today that is the Google Ads API and the Google Search Console API, along with LinkedIn’s Advertising and Community Management APIs; as further report integrations ship, it will include Google Analytics, the Meta Marketing API, the Microsoft Advertising (Bing) API, Bing Webmaster Tools, Klaviyo and similar reporting integrations. This is usually campaign and performance data rather than information about individuals, and it is stored in that customer’s workspace. What we receive from Google Ads and Google Search Console is described in Section 5A, what we receive from LinkedIn in Section 5B, and the SEO Site Audit, which uses no Google account, in Section 5.

Workspace and employment records. Where an agency uses the Service’s team features, its workspace administrators enter information about their own people: profiles and roles, onboarding documents and signed agreements, time off requests, payslips and payroll details. Bank account and routing numbers entered for payroll are written to an encrypted vault; the product stores and displays only the last four digits and provides no way to read a full number back. This information belongs to the agency, and we handle it on the agency’s behalf.

Communications content. Messages sent in workspace and client chat; video meetings hosted through LiveKit, which may be recorded and transcribed, including by automated transcription; and voice calls placed or received through telephony providers such as Twilio, which may be recorded where the workspace has enabled it. See Section 13.

Submissions to pages our customers publish. Landing pages, forms and booking pages published through the Service collect what the customer asks for, typically a name, email address, phone number, message and campaign attribution parameters, together with the technical information any web request carries. Those submissions are collected on the publishing customer’s behalf and land in that customer’s workspace.

4. How We Use Information

We use information for the following purposes:

• to provide, operate, maintain and secure the Service, including authentication, workspace isolation, backups and abuse prevention;
• to retrieve and present reporting from the platforms a customer connects, and to show sync status and errors;
• to power AI-assisted features such as drafting, summaries, suggestions and transcription (see Section 6);
• to process subscriptions, payments, renewals and invoices through our billing and payment providers;
• to communicate with you about the Service, including service notices, security alerts, billing messages and support responses;
• to market our own product, including sending marketing email you can unsubscribe from at any time, measuring our campaigns, and building and reaching audiences for our advertising (this uses information about our own website visitors and account holders, never our customers’ connected platform data or Customer Content);
• to analyze and improve the Service, understand which features are used and diagnose problems, including through aggregated and de-identified analysis;
• to comply with legal obligations, respond to lawful requests and keep required records; and
• to establish, exercise or defend legal claims and to enforce our Terms.

5. Connected Marketing Platform Data

Data retrieved from a marketing platform a customer connects is used only to provide the Service to that customer’s workspace: to build their reports, power the insights and exports in the product, and show the status of a sync. It is not used for our own advertising, is not combined across customers for any purpose other than operating and securing the Service, and is never sold or shared for cross-context behavioral advertising.

Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

As integrations with the Meta Marketing API and the Microsoft Advertising APIs ship, we will handle data received through them on the same basis, in accordance with those platforms’ terms and developer policies. Unless Section 5A or 5B says otherwise, disconnecting an account stops future syncing; data already retrieved remains in the customer’s workspace until they delete it or their account is terminated. Google Ads and Google Search Console are handled as Section 5A describes, including what Disconnect does and how long the data is kept. LinkedIn is handled as Section 5B describes, including what Unlink and Disconnect do and how long the data is kept.

SEO Site Audit (PageSpeed Insights). The SEO Site Audit does not connect a Google account. When an agency lists a public web page for a client, we send that page’s address to Google’s PageSpeed Insights API, which runs a Lighthouse audit of the page on Google’s infrastructure and returns the results. We store the Lighthouse scores, lab metrics and audit findings, and the Chrome UX Report field data that PageSpeed Insights returns for the page and its site, for up to 400 days. This is public-web data about the pages an agency chooses to list, not Google user data. It is visible to the people who can view that client’s other reports, and it is deleted with the client. Chrome UX Report data is made available by Google under the Creative Commons Attribution 4.0 International License (CC BY 4.0); we reformat it for display in the report.

5A. Google User Data (Google Ads, Google Search Console, Google Analytics, Google Merchant Center and Google Business Profile)

This section describes the information we receive from Google (“Google user data”) when a workspace administrator connects a Google account to Google Ads, Google Search Console, Google Analytics, Google Merchant Center or Google Business Profile in the Service. It covers those five products only; our other integrations are covered by Section 5. It adds to the rest of this policy, and where it is stricter than another section, this section governs Google user data. Google Search Console is described first, then Google Ads, then the other three; “What we do not do” and “When our staff read it, and when we share it” apply to all five.

AI Marketing Dashboard's use of information received from Google APIs will adhere to Google API Services User Data Policy, including the Limited Use requirements.

What we access. The administrator signs in on Google’s own screen and approves two things: identification of the Google account (the openid and email permissions) and read-only access to Search Console data (https://www.googleapis.com/auth/webmasters.readonly). Read-only means we can view that data and cannot add, change or delete anything in Search Console, such as properties, users, sitemaps or settings. We request no other Google permission for Search Console.

What we store. From Google we store:

• the Google account’s email address, which is shown as the label of the connection, and a one-way hash of Google’s identifier for the account (the identifier itself is not kept), which can be used to tell whether two connections belong to the same Google account;
• the list of Search Console properties the account can see, with the account’s permission level on each;
• for each property an administrator links to a client: daily web-search totals (clicks, impressions and average position) and, for each day, its top queries, pages, countries and devices, each with clicks, impressions and average position. We store only days that Google has finalized;
• a technical log of each sync: the property, the dates covered, when it ran, how many rows it returned and whether it succeeded;
• a record that the administrator acknowledged the notice shown before connecting: which version of it, who acknowledged it and when; and
• the refresh token Google issues, which lets us keep reading after the administrator has left the page (see “How it is stored and protected”).

Why we use it. Only to build and refresh the Search Console report for the client the property is linked to, including that report’s CSV export, and to show the status of a sync. We use it for no other purpose.

How it is stored and protected. Search Console data is stored in our database with the other data of the workspace that connected the account, and is isolated from other workspaces by rules enforced in the database (Section 10). The refresh token is stored encrypted in a secrets vault. It is never displayed back in the product, and our servers use it only to obtain short-lived access tokens from Google (when the list of properties is refreshed and when we sync) and to ask Google to revoke it when an account is disconnected or its workspace is closed, subject to the exception described under “Revoking access and deleting data”. Data travels between your browser, our servers and Google over encrypted connections. The providers that host and store this data for us are described in Section 8.

Who can see it. The product shows it only inside the workspace that connected the account. Within the workspace, only workspace administrators can connect or disconnect a Google account, link or unlink a property, or start a sync, and only they see the email address of the connected Google account and the list of properties it can see. A client’s Search Console data is visible to the workspace members who are assigned to that client and whose role allows viewing reports: that includes workspace administrators, and team members to whom an administrator has granted that permission. Those viewers see the linked property but not the email address. Client portal users cannot see Search Console data. Before the administrator is sent to Google, the product shows who will see the data and asks for their confirmation.

Developer API keys. A workspace with developer API access can create API keys. Only someone who can view reports and is allowed to manage the workspace’s integrations (an administrator, or a team member an administrator has allowed) can create a key with access to report data, and a key can be limited to one client. A key with report access can read a client’s Search Console figures: the daily totals and, when it asks for them, the top queries, pages, countries and devices, totalled over the period requested. It does not return the email address of the connected Google account. A key keeps working until someone revokes it.

How long we keep it. Daily totals are kept for as long as the workspace keeps the property linked to the client, or chooses to keep the history after unlinking the property or disconnecting the account. Each day’s breakdowns by query, page, country and device are deleted when that day is more than 25 months old. The technical sync log, which records when each sync ran and whether it succeeded, is deleted after 90 days.

When a workspace is closed. Automatically, and normally within minutes, we delete the stored refresh token and ask Google to revoke the Search Console access we held for the workspace, except where revoking could also end another connection, as it can whenever another of our Google integrations shares Search Console’s Google project, or we cannot tell. The token is deleted in every case, even if Google cannot be reached. The Search Console data we synced stays until the workspace is permanently deleted, and is deleted with it; the 25-month and 90-day limits above still apply.

Revoking access and deleting data. You can:

• choose Disconnect on the Google Search Console report (a workspace administrator can do this at any time). Disconnect deletes the stored refresh token and asks Google to revoke our access, except where revoking could also end another connection, as it can whenever another of our Google integrations shares Search Console’s Google project, or we cannot tell; then only our copy of the token is deleted. Disconnect and Unlink property each also offer to delete the Search Console data already synced;
• remove our access yourself in your Google Account at myaccount.google.com/permissions. That stops all further syncing, but it does not by itself delete the data we have already stored, so use one of the other options for that;
• have the workspace permanently delete the client. The Search Console data synced for that client is deleted with it; as described in Section 9, some deletions finish in the background; or
• email contact@xamtac.com to ask us to delete Search Console data or the stored refresh token. We verify requests as described in Section 11.

A CSV export of the stored Search Console data is available in the report. Data that has been deleted can remain in routine encrypted backups for a limited period, as Section 9 describes.

Google Ads. A workspace administrator signs in on Google’s own screen, which names the app “AI Marketing Dashboard”, and approves Google’s one Google Ads permission (https://www.googleapis.com/auth/adwords). Google offers no narrower one, and it also allows changes. Reporting only reads. The Service changes a Google Ads account only when someone launches a plan that has been approved, through Launch, while Google Ads launches are switched on for the Service: a launch creates the campaign the plan describes (its budget, ad groups, ads and, for Search, keywords) and starts it paused, and, if the person launching agrees, uploads the plan’s videos to YouTube as unlisted videos. The workspace can then turn what it launched on or off, and when a launch stopped before its campaign was created, someone can clean up, which removes the videos it uploaded; the Service does not edit or delete a campaign after creating it. Before the administrator is sent to Google, the product shows what is stored, who will see it, how long it is kept and how to disconnect, and asks for their confirmation.

What we store (Google Ads). From Google we store:

• the Google Ads accounts the sign-in can reach: for each, its customer ID, name, currency, time zone, status and whether it is a manager account;
• for each advertiser account an administrator links to a client: daily performance for the account and by campaign, ad group, asset group, ad, keyword, search term, audience, age, gender, household income, device and hour, with the names and statuses of those items, the keyword and search term text, and figures such as impressions, clicks, cost, conversions and their value, video views and impression share;
• for the ads of a linked account: the web addresses of their images and the IDs of their YouTube videos, so a report can show them; the pictures themselves are fetched from Google when a report shows them;
• the audience lists of a linked account that Launch can target: their names, types, sizes and match rates;
• for each launch: the Google Ads IDs of what it created and the status, review status and ad strength Google reports for them, so they can be shown and turned on or off;
• a technical log of each sync: the dates covered, when it ran and whether it succeeded; and
• the refresh token Google issues, stored encrypted in a secrets vault and used only by our servers to obtain short-lived access tokens from Google. We do not store the Google account’s email address or Google’s identifier for the account.

Who can see it (Google Ads). A client’s Google Ads data is visible to the workspace members who are assigned to that client and whose role allows viewing reports; exporting it as a CSV file also needs the export permission. Only workspace administrators, and team members an administrator has allowed, can connect or disconnect a Google account or link an advertiser. Client portal users cannot see Google Ads data. Google Ads data is not available to developer API keys unless we switch that on for the Service; when it is on, a key with report access can read a client’s Google Ads figures. A key that can read launches sees the name of the Google Ads account each launch used.

How long we keep it (Google Ads). The figures a report shows stay while the advertiser stays linked to the client. Figures a newer sync has replaced are deleted 90 days after the sync that stored them, with that sync’s technical log. After Disconnect, unlinking the advertiser or choosing another, the client’s figures are no longer shown, and the same clean-up deletes them within 90 days. The list of accounts the sign-in could reach, the web addresses of ad pictures, the audience lists and the launch records stay until the client or the workspace is permanently deleted, or until you ask us to delete them.

Revoking access and deleting data (Google Ads). A workspace administrator can choose Disconnect on the Google Ads report at any time. Disconnect deletes the stored refresh token at once and clears the synced figures of every client that uses that sign-in; it does not ask Google to revoke our access, because revoking could also end other connections made through the same Google sign-in. To revoke it, remove our access in your Google Account at myaccount.google.com/permissions; that stops us reading anything further from Google, but it does not by itself delete what we have already stored. An administrator can also unlink a client’s advertiser, or permanently delete the client. To ask us to delete Google Ads data or the stored token, email contact@xamtac.com; we verify requests as described in Section 11.

The other three products. For Google Analytics, Google Merchant Center and Google Business Profile, a workspace administrator signs in on Google’s own screen, which names the app “AI Marketing Dashboard”, and approves access to that product. Before the administrator is sent to Google, the product shows what is read, who will see it, how long it is kept and how to disconnect, and asks for their confirmation.

What we read and store (the other three). For each product:

• Google Analytics: read-only. We can view Google Analytics reports and property settings and never change them. We store the Google account’s email address, its property list and, for the linked property, the reports people open: users, sessions, engagement, key events (by name) and revenue, broken down by channel, source and medium, campaign name, landing page, page, event name, country, city, device, browser and operating system, plus new versus returning users and, when that tab is opened, users by age bracket and gender as Google reports them;
• Google Merchant Center: Google’s Merchant Center permission also allows changes, but this app only reads reports and product statuses and never edits products, feeds or settings. We store the Google account’s email address, its Merchant Center account list and, for the linked account, product titles, prices, availability, statuses and issues, data sources and their latest uploads, the clicks, impressions and click-through rate Google reports by product, brand, category, product type, country and traffic method, and the conversions, conversion value and conversion rate Google reports for free listings; and
• Google Business Profile: Google’s Business Profile permission also allows changes, but this app only reads performance figures, search keywords and reviews and never edits a profile, replies to a review or posts. We store the Google account’s email address, its locations (name, town, category, website) and, for the linked ones: Search and Maps impressions, calls, directions, website, messaging, booking and menu clicks, search keywords, the rating, and the latest reviews with their star rating, text, date, the reviewer’s name and whether each was answered (never a reply’s text or a photo).

Who can see it (the other three). Agency team members with access to a client see that client’s figures; only workspace administrators see the email address of the connected Google account. The client portal never shows them.

How long we keep it (the other three). A loaded Google Analytics or Google Merchant Center report is kept until it has gone 90 days without being opened. Google limits how long Google Business Profile content may be kept, so it is deleted within 7 days by default and never kept longer than 30 days; for Google Business Profile, nothing is fetched until someone opens the report.

Revoking access and deleting data (the other three). A workspace administrator can choose Disconnect on the report at any time. Disconnect deletes our token, offers to delete the stored reports and asks Google to revoke access unless that could end another connection; for Google Business Profile it offers to delete the stored figures. You can also remove our access yourself in your Google Account at myaccount.google.com/permissions; that stops us reading anything further from Google, but it does not by itself delete what we have already stored. To ask us to delete this data or the stored token, email contact@xamtac.com; we verify requests as described in Section 11.

What we do not do. We do not sell Google user data. We do not use it for advertising, including retargeting and personalized or interest-based advertising, and we do not transfer it to advertising platforms, data brokers or other information resellers. We do not use it to determine creditworthiness or for lending. We do not use it to train AI models, and we do not send it to the AI providers described in Section 6. The one exception is the workspace’s own advertising: Launch creates the campaigns a workspace approves in that workspace’s own Google Ads account, and may target audiences from that account, at the workspace’s direction. We never use Google user data for our own advertising or anyone else’s.

When our staff read it, and when we share it. Our staff do not read Google user data unless the customer asks us to or agrees to it (for example, to help with a support request), where it is necessary for security purposes such as investigating abuse, or where it is necessary to comply with law. We transfer Google user data to others only to provide the reporting features the workspace has asked for (for example, to the service providers that store and process it for us, listed in Section 8), for security purposes, to comply with law, or as part of a merger, acquisition or sale of assets after we have obtained your explicit prior consent.

Questions about Google user data can be sent to contact@xamtac.com (Section 19).

5B. LinkedIn Data (LinkedIn Ads and LinkedIn Page)

This section describes the information we receive from LinkedIn (“LinkedIn data”) when a workspace connects LinkedIn Ads or a LinkedIn Page to reporting in the Service. It covers those two reports only. It adds to the rest of this policy, and where it is stricter than another section, this section governs LinkedIn data.

LinkedIn Ads reporting uses LinkedIn’s Advertising API to show an agency how a client’s LinkedIn ad account is performing. LinkedIn Page reporting uses LinkedIn’s Community Management API to show how a client’s LinkedIn Page is performing.

What we access. A workspace administrator starts the connection in the Service. A LinkedIn member then signs in on LinkedIn’s own screen and approves what the app asks for. For LinkedIn Ads, that member holds a role on the ad account. For a LinkedIn Page, that member is a Super admin of the Page.

LinkedIn Ads asks for two permissions, r_ads and r_ads_reporting. They let us read the member’s ad accounts and their reports. LinkedIn Page asks for one permission, rw_organization_admin. It is the only permission LinkedIn’s Community Management API grants for Page analytics, and LinkedIn will ask the member to let the app manage the Page. We use it only to read figures. We never post, comment or change anything on a Page, and we never change anything in an ad account. We request no other LinkedIn permission. We do not read or store any member’s profile, the content of comments, or messages.

What we store. From LinkedIn we store:

• the ad accounts, or the Pages, that the signed-in member can see: for each, its name (for a Page, also the name in its LinkedIn web address), its LinkedIn ID, its status and the member’s role on it, and for an ad account its currency and type;
• a one-way hash of the member’s LinkedIn identifier (the identifier itself is not kept), which can be used to tell whether two connections belong to the same LinkedIn member. We do not store the member’s name, email address or photo;
• for each ad account an administrator links to a client: daily results for the account, each campaign and each ad (such as impressions, clicks, spend, conversions, leads and engagement counts); the names, status, objective and format of its campaign groups, campaigns and ads; and totals for the people the ads reached, grouped by job function, seniority, industry and company size;
• for each Page an administrator links to a client: daily Page views, new followers, the follower total, post impressions, clicks and engagement counts, and totals for who follows the Page, grouped by job function, seniority, industry and company size;
• a technical log of each sync (the dates covered, when it ran, how many rows LinkedIn returned and whether it worked) and a ledger of which days have been synced, which holds no figures; and
• the tokens LinkedIn issues: an access token and, when LinkedIn provides one, a refresh token. They let us keep reading after the member has left the page (see “How it is stored and protected”).

Why we use it. Only to build and refresh the LinkedIn Ads or LinkedIn Page report for the client the ad account or Page is linked to, including that report’s CSV export, and to show the status of a sync. We use it for no other purpose.

When we collect it. We read the list of ad accounts or Pages when the member signs in, when an administrator refreshes the list, and about once a day to check that the sign-in still works. We read figures only after an administrator has linked an ad account or Page to a client: when an administrator presses Sync and, once a day, if the daily refresh is on. We never read figures older than 12 months.

How it is stored and protected. LinkedIn data is stored in our database in the United States, with the other data of the workspace that connected the account. It is kept separate from other workspaces, and every read goes through our servers, which check the person’s permission first (Section 10). The tokens are stored encrypted in a secrets vault. They are never shown back in the product, and our servers use them only to list the ad accounts or Pages the member can see, to keep the sign-in working and to read the reports a workspace has linked. Data travels between your browser, our servers and LinkedIn over encrypted connections. The providers that host and store this data for us are described in Section 8. LinkedIn limits how long a sign-in lasts. When it ends, syncing stops until the member signs in again.

Who can see it. The product shows it only inside the workspace that connected the account. Within the workspace, only workspace administrators can connect or disconnect a LinkedIn sign-in, link or unlink an ad account or Page, or start a sync, and only they see the list of ad accounts or Pages a connected member can see. A client’s LinkedIn report is visible to the workspace members who are assigned to that client and whose role allows viewing reports: that includes workspace administrators, and team members to whom an administrator has granted that permission. Clients do not see these reports, and client portal users cannot see LinkedIn data. Before the administrator is sent to LinkedIn, the product shows who will see the data and asks for their confirmation.

Exports. People with export permission can download the report’s tables and daily figures as CSV files. The audience breakdowns (job function, seniority, industry and company size) are shown on screen only and cannot be exported.

Developer API keys. Our developer API, including the version built for AI agents, does not return LinkedIn data.

How long we keep it. These are deleted automatically, whether or not anyone unlinks or disconnects anything:

• each day’s figures and each audience breakdown, after 12 months (365 days);
• the names and status of campaigns and ads, once 12 months pass without LinkedIn returning them;
• a Page’s name, if it has not been refreshed for eight weeks (it is replaced with a plain label);
• the technical sync log, after 90 days, and the ledger of synced days, after 400 days; and
• after a disconnect, the record of the sign-in, which holds the one-way hash and no tokens: after 90 days for LinkedIn Ads and after 400 days for LinkedIn Page.

The list of ad accounts or Pages a member can see is kept while the sign-in is connected. After a disconnect it is deleted once the figures for those accounts or Pages are gone.

When an administrator unlinks or disconnects. An administrator can unlink an ad account or Page from a client, or disconnect a whole LinkedIn sign-in, at any time. Syncing stops at once for the clients affected. Their stored LinkedIn data is hidden from the report at once and deleted 7 days later: the figures, the audience breakdowns and the campaign and ad names. If the same ad account or Page is linked to the same client again within those 7 days, nothing is deleted. Disconnecting also deletes the tokens we store, at once. Unlinking keeps the sign-in, so other clients can keep reporting through it.

Both actions have a box, “Delete the stored LinkedIn data now”. When it is ticked, the data is deleted at the next hourly clean-up instead of after 7 days. A very large set can take more than one clean-up.

Revoking access and deleting data. You can:

• choose Unlink or Disconnect on the LinkedIn Ads or LinkedIn Page report (a workspace administrator can do this at any time), and tick the box to have the stored data deleted at the next clean-up. Disconnect deletes the tokens we store. It does not contact LinkedIn, so also remove the app in LinkedIn, as the next option describes;
• remove the app yourself in LinkedIn, under Settings and Privacy, Data privacy, Other applications, Permitted services. The app is listed under the name LinkedIn showed when the member approved it. This stops all further syncing, but it does not by itself delete the data we have already stored, so use one of the other options for that;
• have the workspace permanently delete the client. The LinkedIn data stored for that client is deleted with it; as described in Section 9, some deletions finish in the background; or
• email contact@xamtac.com to ask us to delete LinkedIn data or the stored tokens. We verify requests as described in Section 11.

If a sign-in ends, or the app is removed in LinkedIn, syncing stops but the data already stored stays until an administrator unlinks or disconnects it or it reaches the limits above. Data that has been deleted can remain in routine encrypted backups for a limited period, as Section 9 describes.

What we do not do. We do not sell LinkedIn data. We do not use it for advertising or marketing, and we do not pass it to advertising platforms, data brokers or other information resellers. We do not use it to train AI models, and we do not send it to the AI providers described in Section 6. We do not share it with anyone outside the workspace, except the service providers that store and process it for us (listed in Section 8), where the law requires it, and for security purposes.

LinkedIn’s terms. LinkedIn’s API terms and Data Storage Requirements also apply to LinkedIn data. We chose the retention and deletion limits in this section to meet them.

Questions about LinkedIn data can be sent to contact@xamtac.com (Section 19).

6. AI Features

Some features send the content you are working on to third-party AI service providers so they can generate a draft, a summary, a suggestion or a transcript. Those providers currently include OpenAI and, as we expand these features, Anthropic. They act as our service providers and may use the content only to return a result to us.

Under our agreements with these providers, content submitted through their business APIs is not used to train their models. AI output is generated automatically and may be inaccurate, so review it before you rely on it. Please do not enter sensitive personal information into an AI-assisted field unless the feature needs it.

Data we receive from Google Search Console is not sent to these providers and is not used to train AI models (Section 5A).

Data we receive from LinkedIn is not sent to these providers either, and is not used to train AI models (Section 5B).

7. Cookies, Analytics and Advertising Technology

Essential cookies. The Service uses cookies that are necessary for it to work: sign-in and session cookies set by our authentication provider Clerk, the cookie that records which client portal you are viewing, and cookies used for security. These cannot be turned off within the product.

Functional storage. We keep small preferences in your browser’s local storage, such as the client you last selected, the layout of a list, and dismissed notices. This information stays in your browser.

Product analytics and error monitoring. We use PostHog for product analytics and session replay, served through our own domain, and Sentry for error and performance monitoring. These help us understand how the Service is used and diagnose faults.

Marketing and advertising technology on our public pages. On our public marketing pages we use, or plan to use, Google Analytics, the Google Ads tag and remarketing pixel, the Meta Pixel, Microsoft Advertising UET and the LinkedIn Insight Tag. These measure the performance of our own campaigns and let us show our ads to relevant audiences, including people who have visited our site (remarketing). Depending on where you live, this activity may be treated as “sharing” or “targeted advertising” under state privacy law.

Your choices. Most browsers let you block or delete cookies through their settings, though blocking essential cookies will stop the Service from working. You can also use the ad-platform and industry controls below:

• Google: adssettings.google.com;
• Meta: the ad preferences and ad topic controls in your Facebook or Instagram account settings;
• LinkedIn and Microsoft: the advertising and interest-based advertising controls in your LinkedIn and Microsoft account settings;
• Network Advertising Initiative: optout.networkadvertising.org; and
• Digital Advertising Alliance: optout.aboutads.info.

8. How We Share Information

We share information with service providers who help us run the Service, and only for that purpose. By function, they are:

• Clerk, for authentication, organization membership and subscription billing;
• the payment processors engaged by our billing provider, such as Stripe, for processing payments;
• Supabase, for our database and file storage;
• Vercel, for application hosting, delivery and AI request routing;
• Amazon Web Services, for email delivery through Amazon SES and for supporting infrastructure;
• LiveKit, for video meetings and recordings;
• Twilio, for voice calls and telephony;
• OpenAI and Anthropic, for the AI processing described in Section 6;
• PostHog, for product analytics and session replay, and Sentry, for error monitoring; and
• Google, Meta, Microsoft and LinkedIn, when you connect one of their accounts to the Service or when you interact with our advertising.

We review a provider before we adopt it, give it only the information it needs to perform its function, and require it by contract to protect that information and to use it only for us. This list changes as the Service evolves; the current set is described by function above rather than pinned to a version of this page.

We also share information inside a customer’s own workspace according to that customer’s settings: agency team members see what their roles and client assignments allow, and portal users see the client-scoped content the agency has shared with them. We may share information with our professional advisors (such as lawyers, accountants and auditors); where we believe disclosure is required by law or legal process, or is necessary to protect the rights, property or safety of Xamtac, our customers or the public; and in connection with a merger, acquisition, financing or sale of assets, in which case we will continue to protect the information under this policy or give notice before it becomes subject to a different one.

We do not sell your personal information.

To be precise about one point: the advertising and analytics technology on our public pages described in Section 7 may be treated as “sharing” for cross-context behavioral advertising or as “targeted advertising” under some state privacy laws, even though no money changes hands. You can opt out using the cookie and platform controls in Section 7, by sending a recognized opt-out preference signal (Section 12), or by emailing us at contact@xamtac.com.

9. Data Retention

We keep account information and Customer Content for as long as the account and subscription are active, and afterwards for as long as we need it to comply with legal obligations, resolve disputes, enforce our agreements and maintain security.

Google Search Console data is also kept for the periods stated in Section 5A, LinkedIn data for the periods stated in Section 5B, and SEO Site Audit results for the period stated in Section 5. The rest of this section, including what happens after an account is terminated, applies to them as well.

After an account is terminated, Customer Content remains available for export for the window described in our Terms & Conditions, after which we may delete it. Deleted data may persist for a limited period in routine encrypted backups before those backups expire. Aggregated and de-identified information that can no longer be linked to you may be kept indefinitely.

When you delete a record, a file or a client inside the Service, it is removed from your workspace. Some deletions are completed in the background, including the removal of stored files that belonged to the deleted record, so a large deletion may take a short while to finish. Logs kept for security and diagnostics are retained on their own schedule and are not a copy of your workspace.

10. Security

We protect information with measures appropriate to the Service, including encryption in transit, per-workspace data isolation enforced at the database layer, role and capability-based access controls, and vaulting of the credentials used for connected accounts and payroll details so that secrets are never displayed back in the product.

No method of transmission or storage is completely secure, and we cannot guarantee absolute security. Keeping your own credentials safe and managing who has access to your workspace are your responsibility. If you believe you have found a security issue, please report it to contact@xamtac.com.

11. Your Rights and Choices

Depending on where you live, including in California, Colorado, Connecticut, Texas and Virginia among other states, you may have the right to request access to the personal information we hold about you, to correct it, to delete it, to receive a portable copy, and to opt out of targeted advertising and of any “sale” or “sharing” of your personal information. You also have the right not to be discriminated against for exercising these rights.

To make a request, email us at contact@xamtac.com and tell us what you would like to do. We will verify your identity before acting, usually by confirming control of the email address on the account or by asking for information that matches our records; a request we cannot verify will be declined. An authorized agent may submit a request on your behalf with proof of authority. If we decline a request you may appeal by replying to our response, and we will review the appeal and explain the outcome.

We answer within the period the applicable law allows, which in several states is 45 days from a verified request, extendable where the law permits and we tell you why. There is no charge for a reasonable request. Deleting information that we need in order to keep your account running may mean closing the account, and we will say so before we act.

You can opt out of our marketing email at any time using the unsubscribe link in the message or by emailing us; we will still send service, billing and security messages about your account.

If your information is in a workspace operated by an agency, that agency controls it. Contact the agency first; if you contact us, we will route the request to them and help them respond.

12. Opt-Out Preference Signals

We do not respond to the legacy Do Not Track browser setting, because there is no common standard for it. Where applicable law requires it, we will treat a recognized opt-out preference signal, such as Global Privacy Control, as a request to opt that browser out of targeted advertising.

13. Meeting and Call Recordings

Meetings and calls held through the Service may be recorded and transcribed when a participant with the right permission turns recording on. Recordings and transcripts are stored in the workspace that created them and are visible to the people that workspace allows.

The workspace that starts a recording is responsible for giving notice and obtaining the consent the law requires. Some jurisdictions, including Illinois, require the consent of every party to the conversation. If you are a participant and do not want to be recorded, say so and leave the meeting or call.

14. Biometric Information

We do not use the Service to collect or process biometric identifiers or biometric information, such as fingerprints, voiceprints, retina or iris scans, or scans of hand or face geometry. Meeting and call recordings are stored and transcribed as audio and video; they are not used to generate a voiceprint or a face template, and we do not perform facial recognition.

15. Children

The Service is a business product. It is not directed to children, is not intended for anyone under 18, and we do not knowingly collect personal information from children under 13. If you believe a child has provided us with personal information, contact contact@xamtac.com and we will delete it.

16. International Users

We operate in the United States, and information we handle is processed and stored there. If you access the Service from another country, you understand that your information will be transferred to and processed in the United States, where data protection laws may differ from those in your own country.

17. Agency Portals and Published Pages

Agencies use the Service to run white-labeled client portals and to publish landing pages, forms and booking pages, sometimes on their own domains and under their own branding. Those surfaces are operated by the agency.

The agency’s own privacy practices govern its relationship with its clients and with the visitors to the pages it publishes, and the agency is responsible for the notices and consents those pages require. This policy governs how Xamtac handles information as the provider of the underlying platform.

18. Changes to This Policy

We may update this policy. When we do, we will change the “Last updated” date at the top of this page, and for material changes we will give notice by email to the administrative contact on an account or through an in-app notice before the change takes effect. Continuing to use the Service after a change takes effect means you accept the updated policy.

19. Contact Us

For privacy questions, requests or complaints, contact us at contact@xamtac.com or by mail:

For the agreement that governs use of the Service, read the Terms & Conditions.