Privacy Policy

Skiprr is a business-to-business platform used by marketing agencies. An agency operates one portal containing separate client workspaces, which we call subaccounts. Each subaccount belongs to one of the agency's clients and is isolated from every other subaccount at the database level by PostgreSQL row-level security.

Inside a subaccount, the platform can:

• read marketing, advertising and analytics data from third-party accounts that the client has connected;
• run AI automations over that data to produce written reports and recommendations;
• generate marketing content — video, images, carousels and blog posts — using third-party AI models; and
• publish that content to the client's own connected social accounts.

The operator of record is WALL.AI, LLC, registered at 2470 S Dairy Ashford Rd, Unit #572, Houston, TX 77077, USA. Questions about this policy go to wali@wallai.org.

Under the EU and UK General Data Protection Regulation, our role depends on the data in question.

• We are a controller for account and administrative data we need in order to run the service at all: the names, email addresses and roles of the people who log in, billing records, support correspondence, and security and audit logs.
• We are a processor for the data a workspace pulls in from connected accounts and for the content generated inside a workspace. The agency (and, depending on their arrangement, the agency's client) is the controller. We act on their documented instructions, which take the form of the actions they perform in the portal.

If you are an individual whose personal data appears inside a workspace — for example, as a contact in a connected email-marketing or e-commerce account — and you want that data accessed, corrected or erased, your request should normally go to the agency or client who controls that workspace. If you send the request to us instead, we will pass it on to the relevant controller and support them in answering it, but we generally cannot act on it unilaterally. See section 15.

A data processing agreement covering this relationship is available from wali@wallai.org.

Account information

When an account is created we collect a name, an email address, an encrypted password verifier (we never store passwords in plain text), the organisation and subaccount the user belongs to, and their role — owner, admin or member. If a user is invited, we record who invited them and when the invitation was accepted.

Workspace content

We store what users create in the portal: automation requests and their parameters, generated reports and their revisions, brand profiles and brand assets, uploaded files and media, generated video, images, carousels and written posts, schedules, comments and internal notes.

Connected-account credentials

We store the credentials needed to reach the third-party accounts a client connects. This means OAuth access tokens and refresh tokens, or API keys and tokens that a client pastes in. See section 4 for how these are protected.

Data retrieved from connected accounts

When an automation runs, we read data from the connected accounts and store the retrieved values, along with the report derived from them, in the workspace. See sections 4 and 5.

Technical and usage information

Our hosting and infrastructure providers record standard operational data: IP address, user-agent string, request paths, timestamps, and error traces. We use this to keep the service running, to diagnose faults, and to detect abuse. We also record job execution logs, token consumption and cost figures for each automation run so that usage can be attributed and billed.

What we do not collect

• We do not collect special-category data (health, biometric, political, religious or similar) as an intended feature. Do not upload it into a workspace.
• We do not buy personal data from data brokers or list vendors.
• We do not sell personal data. See section 16.
• We do not operate advertising trackers or third-party ad pixels on the portal.

The portal is useful only once a client connects their own third-party accounts. Nothing is connected by default; every connection is an explicit action taken by a user of the workspace. Connections can be removed at any time from Settings → Integrations.

Services that can currently be connected:

• Google — Google Analytics 4, Google Search Console, Google Ads, Google Drive, Google Sheets, Google Docs (see section 5).
• Commerce and email — Shopify, Klaviyo, HubSpot.
• Advertising and social — Meta Ads, TikTok Ads, TikTok Shop. We read ad performance from these accounts (campaigns, spend and results) in order to produce advertising and cross-channel performance reports; we do not create, edit or publish ads and we do not change budgets. See the dedicated section below.
• Experimentation and workflow — Convert.com, Figma, Notion.

How credentials are protected

Every credential set — whether it came from an OAuth flow or was pasted in as an API key — is encrypted with AES-256-GCM before it is written to the database. OAuth access tokens and refresh tokens are stored inside that same encrypted blob. The encryption key is held in the runtime environment, not in the database, so a database compromise on its own does not yield usable credentials.

Credentials are decrypted only in memory, only at the moment a background job needs to call the corresponding API, and only for the workspace that owns them. Credentials are never returned to the browser and are never included in a generated report, a prompt sent to an AI model, or a log line.

This section describes specifically how Skiprr handles advertising data obtained from Meta (Facebook and Instagram) and from TikTok when a user connects those accounts. As with every connection, nothing is connected by default and access can be revoked at any time from Settings → Integrations.

Meta: how access is granted

A user connects Meta by authorising Skiprr through Meta's own login and permissions dialog, or by supplying a system-user access token they generated in Meta Business settings. We never ask for, receive or store a Meta account password. We request the ads_read permission and a long-lived token so that a scheduled report can keep reading performance data after the user closes the browser.

Meta: exactly what we read, and what we do not

Through the Meta Marketing API, using ads_read, we read advertising performance data from the ad accounts the user connects: campaigns, ad sets and ads, spend, impressions, clicks, conversions, and the standard result and attribution metrics Meta reports. We read this data only.

Skiprr does not create, edit, pause, publish or delete ads, does not change budgets or targeting, and takes no action in your Meta account on your behalf. It has no write access.

Meta: how we use it

Meta advertising data is used for one purpose: to produce the advertising and cross-channel performance reports the requesting user asked for and that are visible and prominent in their Skiprr workspace. It is used for nothing else. We specifically do not:

• sell Meta data, or transfer it to data brokers or information resellers;
• use Meta data for advertising of any kind, including retargeting or interest-based advertising;
• use Meta data to create, train or improve any generalised machine-learning or artificial-intelligence model (see section 9); or
• combine it with data from other users for any purpose beyond the requesting workspace.

Meta: how we store it and how you revoke it

The Meta access token is encrypted with AES-256-GCM before it is written to our database, and the performance metrics we retrieve are stored alongside the generated report, isolated per workspace by PostgreSQL row-level security. All data is encrypted in transit with TLS and at rest by the storage provider. Disconnecting the integration inside Skiprr deletes the stored token and immediately stops all further reads; you can also remove Skiprr's access from your Meta Business settings independently of us. Deleting a report removes it and the Meta data stored with it, and closing an account deletes its workspace content in accordance with section 14.

TikTok advertising and shop data

When a user connects a TikTok Ads or TikTok Shop account, we read advertising and shop performance data through TikTok's Marketing and Shop APIs on the same read-only basis: campaigns, creatives, spend and results, and, for TikTok Shop, order and product performance. We use it solely to build the reports requested in the workspace, store it under the same AES-256-GCM encryption and row-level isolation, and never post content, run ads, move budget or take any other action in the connected account. Our use of TikTok data adheres to the TikTok for Business and TikTok Developer terms.

This section describes, specifically and exhaustively, how Skiprr handles data obtained through Google APIs. It is written to meet the disclosure obligations in the Google API Services User Data Policy and the Google Workspace User Data and Developer Policy.

How access is granted

A user connects a Google service by clicking through Google's own OAuth consent screen. We never ask for, receive or store a Google account password. All six Google services share one OAuth client, and connecting an additional service widens the existing grant through incremental authorization rather than creating a second one. We request offline access so that a scheduled automation can keep reading data after the user closes the browser; this is why Google issues us a refresh token.

Exactly which scopes we request, and why

We request the minimum scopes needed for the features described, and no others. We do not request scopes speculatively for features that do not exist.

Every Google scope we request is read-only with respect to your Google data. Skiprr does not create, edit or delete anything in your Google account, and does not take any action in Google on your behalf.

How we use Google user data

Google user data is used for one purpose: to produce the analytics, SEO, advertising and content outputs that the requesting user asked for and that are visible and prominent in the Skiprr interface — the reports, dashboards and generated content in their workspace. It is used for nothing else.

We specifically do not:

• sell Google user data, or transfer it to data brokers or information resellers;
• use Google user data for advertising of any kind, including retargeting, personalised or interest-based advertising;
• use Google user data to determine credit-worthiness or for lending purposes;
• use Google user data to create, train or improve any generalised machine-learning or artificial-intelligence model (see section 9);
• aggregate or analyse Google user data for display, sale or distribution to any third party conducting surveillance.

How we store Google user data

Google OAuth access tokens and refresh tokens are encrypted with AES-256-GCM and stored in our Supabase-hosted PostgreSQL database, isolated per workspace by row-level security. Data retrieved from Google APIs — for example GA4 metrics or Search Console query rows — is stored in the same database alongside the report generated from it, so that reports remain readable after the fact. Media and file artefacts are stored in Supabase object storage. All data is encrypted in transit using TLS and at rest by the storage provider.

How and with whom we share Google user data

We do not share Google user data with third parties for their own purposes. It is disclosed only in these circumstances:

• To the workspace itself. Users authorised in the subaccount that made the connection — and administrators of the parent agency — can see reports built from that data. Row-level security prevents any other tenant from reading it.
• To infrastructure subprocessors that host or transport the data on our behalf under contract, listed in section 10.
• To AI model providers, where the relevant excerpts are included in a prompt in order to generate the report or content the user requested. This is a transfer made to provide the user-facing feature they asked for. Section 9 sets out the limits that apply.
• For security purposes, such as investigating abuse or a suspected breach.
• To comply with applicable law, a valid legal process, or an enforceable governmental request.
• In a merger, acquisition or sale of assets, only after obtaining explicit prior consent from the affected users.

Human access to Google user data

Our personnel do not read Google user data. The only exceptions permitted by our internal policy mirror the exceptions in Google's policy: where the user has given explicit, documented affirmative agreement for us to look at specific data (for example, when they ask us to debug a specific failing report); where it is strictly necessary to investigate a bug, a security incident or abuse; where the data is aggregated and anonymised and used for internal operations consistent with applicable law; or where we are legally compelled. Access under these exceptions is limited to personnel who need it and is logged.

You can withdraw Skiprr's access to your Google account at any time, and you can have the data we already retrieved deleted. These are two separate things, and you can do both.

Revoking access

• From inside Skiprr. Go to Settings → Integrations, find the Google connection, and disconnect it. This deletes the stored encrypted credential record, including the access token and refresh token, and the platform immediately stops being able to call Google on your behalf.
• From your Google Account, independently of us. Visit myaccount.google.com/permissions, select Skiprr, and choose to remove access. This revokes the grant at Google, so our tokens stop working whether or not you also disconnect inside Skiprr.

Deleting data already retrieved

Revoking access stops future reads; it does not by itself erase reports already produced. To have previously retrieved Google data deleted:

• Delete the individual reports and generated assets in the workspace. Deleting a report removes it and its associated stored data.
• Or email wali@wallai.org and ask us to delete all Google-derived data for a named workspace. We will confirm the request with the workspace owner, action it, and confirm completion in writing. Our target is to complete verified deletion requests within 30 days of verifying the request.
• Closing an account deletes the account and its workspace content in accordance with section 14.

Deleted records are removed from active systems immediately and expire from encrypted backups within 30 days, after which they are unrecoverable.

We require our employees, agents, contractors and successors to comply with the Google API Services User Data Policy on the same terms.

Where we rely on legitimate interests, we have assessed that our interest in operating a secure, functioning, correctly billed service does not override the rights and freedoms of the individuals concerned. You can object to that processing — see section 15.

Skiprr's core function is to run large language models and generative media models over your marketing data. That means excerpts of workspace data — including data retrieved from connected accounts — are transmitted to AI model providers as part of a prompt, so that the requested report, image, video, carousel or blog post can be produced. Access is routed through an LLM gateway and through media-generation providers, all listed in section 10.

• We do not train models on your data. Skiprr does not build, train, fine-tune or improve any machine-learning model of its own using your workspace data or your Google user data. We are a user of third-party models, not a trainer of them.
• We rely on our providers' standard terms — we have no special agreements. We do not hold negotiated, custom or zero-retention data-processing agreements with the AI providers listed in our Subprocessors list. Your data is handled under each provider's own standard, publicly published terms, which we encourage you to review. We do not independently control or guarantee those providers' internal practices beyond the commitments in their published terms. Where a provider's standard terms permit them to use submitted data to improve their services, that provider's terms govern.
• Google user data is a special case. Google's API Services User Data Policy prohibits Google user data from being used to train or improve generalised AI/ML models. We treat Google-derived data accordingly and limit how it flows to model providers, consistent with the Limited Use commitment in section 7.
• Credentials are never sent to a model. API keys and OAuth tokens are excluded from every prompt.
• Outputs are probabilistic. AI-generated reports and content can be wrong. They are drafts for a human to review, not verified fact, and no automated decision producing legal or similarly significant effects on an individual is made by the platform.
• Minimise what you feed it. Do not paste personal data into a prompt or a brief unless the workspace controller has a lawful basis for processing it that way.

We rely on a set of third-party service providers (“subprocessors”) to operate the platform — for hosting, database and storage, AI model inference, media generation, social publishing and email delivery. Each processes data only to provide its service to us.

We do not hold special or negotiated agreements with these providers. Your data is handled under each provider's own standard, published terms. We name every current subprocessor, grouped by the purpose it serves, on a dedicated page:

View the full list of subprocessors →

Which providers actually process data for a given workspace depends on the features that workspace uses. A workspace that never generates video, for example, sends nothing to the video providers.

Outside the subprocessors above, we disclose information only:

• to the agency and subaccount the data belongs to, according to the roles configured in that workspace;
• to a third-party service at your direction — for example, publishing a generated post to a social account you connected;
• where required by applicable law, a valid legal process or an enforceable governmental request, after reviewing the request and, where we are lawfully able to, notifying the affected customer;
• where necessary to investigate suspected fraud, abuse or a security incident; and
• in connection with a merger, acquisition or sale of assets. Google user data is transferred in that scenario only with explicit prior consent from the affected users, and we will give notice before any personal data becomes subject to a different privacy policy.

We do not sell personal data, and we do not share it for cross-context behavioural advertising.

Our infrastructure and our subprocessors operate in multiple countries, including the United States. If you are in the European Economic Area, the United Kingdom or Switzerland, your data may therefore be transferred outside your home jurisdiction.

Where we transfer personal data out of the EEA or the UK, we rely on the European Commission's Standard Contractual Clauses (with the UK International Data Transfer Addendum where applicable), an adequacy decision, or another lawful transfer mechanism, and we apply supplementary technical measures including encryption in transit and at rest.

Primary hosting region: the United States. Transfer mechanism relied upon: the Standard Contractual Clauses, together with the UK International Data Transfer Addendum where the transfer is subject to UK law

• Encryption in transit. All traffic to the portal and to third-party APIs uses TLS.
• Encryption of credentials at rest. Third-party credentials, including Google OAuth access and refresh tokens, are encrypted with AES-256-GCM before storage. The key lives in the runtime environment, separate from the database.
• Tenant isolation. PostgreSQL row-level security enforces separation between subaccounts at the database layer, not merely in application code. The background worker runs with elevated privileges by design and scopes every query to the workspace that owns the job it is executing.
• Least privilege. We request read-only scopes wherever the feature allows it, and we deliberately use the narrow drive.file scope rather than broad Drive access.
• Secret hygiene. Credentials are never returned to the browser, never written to logs, and never included in prompts sent to AI providers.
• Access control. Administrative access to production is limited to personnel who need it.

No system is perfectly secure. If we become aware of a personal data breach affecting your data, we will notify the affected controllers without undue delay and, where required, the relevant supervisory authority, consistent with GDPR Art. 33 and 34 and any other applicable breach-notification law.

Security contact for vulnerability reports: wali@wallai.org.

If you are in the EEA or the UK, you have the rights below. They apply to the controller of the data in question — see section 2 to work out whether that is us or the agency operating your workspace.

• Access — obtain confirmation of whether we process your personal data and receive a copy.
• Rectification — have inaccurate data corrected.
• Erasure — have your data deleted where one of the grounds in Art. 17 applies.
• Restriction — have processing limited while a dispute about accuracy or lawfulness is resolved.
• Portability — receive data you provided in a structured, commonly used, machine-readable format.
• Object — object to processing based on legitimate interests.
• Withdraw consent — where processing relies on consent, withdraw it at any time without affecting processing already carried out.
• Complain — lodge a complaint with your local supervisory authority.

To exercise a right, email wali@wallai.org. We will verify your identity before acting, and we will respond within one month, extendable by two further months for complex requests, as permitted by Art. 12(3). We do not charge for these requests unless they are manifestly unfounded or excessive.

Data protection officer or Art. 27 representative, if one has been appointed: we have not appointed one and are not currently required to; if that changes we will designate a representative and update this policy

If you are a California resident, the California Consumer Privacy Act as amended by the California Privacy Rights Act gives you the rights below. When we handle data on behalf of an agency customer, we act as a service provider as that term is defined in the CCPA, and we are contractually restricted from retaining, using or disclosing that personal information for any purpose other than performing the services.

Categories in the last 12 months

Your rights

• Know what personal information we collect, use, disclose and retain.
• Access a copy of that information, and delete it.
• Correct inaccurate personal information.
• Opt out of the sale or sharing of personal information. We do not sell personal information and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of, and we do not offer financial incentives tied to personal information.
• Limit the use of sensitive personal information. We do not collect it.
• Be free from retaliation for exercising any of these rights. We will not deny service, change prices or degrade quality because you exercised a right.

Submit a request to wali@wallai.org. We will verify your identity before acting and respond within 45 days, extendable once by a further 45 days. An authorised agent may submit a request on your behalf with written proof of authorisation.

The portal uses cookies that are strictly necessary to make it work: a session cookie that keeps you signed in, and a cookie recording which workspace you are currently viewing so that server-side requests resolve to the right tenant. We also use local browser storage to remember interface preferences.

We do not run advertising cookies, third-party ad pixels or cross-site tracking on the portal. Blocking the necessary cookies will prevent you from signing in.

Analytics or product-telemetry cookies, if any are added later: none — we use only strictly necessary cookies for authentication and session management, and no advertising or third-party analytics cookies

Skiprr is a business tool. It is not directed at children, we do not knowingly collect personal data from anyone under 16, and accounts may only be created by adults acting for a business. If you believe a child has provided us with personal data, contact wali@wallai.org and we will delete it.

We may update this policy as the product changes. When we do, we revise the Last updated date at the top and keep the previous version available on request.

If we intend to access or use a type of Google user data that was not disclosed here when you originally authorised access, or to use Google user data in a new way or for a different purpose than described here, we will update this policy and prompt you to consent to the change before making that new use of your data, as required by the Google API Services User Data Policy. For material changes generally, we will give notice by email or in the portal before the change takes effect.

Privacy questions, rights requests and deletion requests:

This policy is governed by the laws of the State of Texas, USA, without prejudice to any mandatory rights you have under the law of your own country of residence.