What we do with your data.

1. Who we are

PillarSEO.ai is a content operations tool for Shopify stores. It tracks what each of your pages earns in search, decides where the next post should go, drafts it, and publishes it to your store only after you click to approve.

The person responsible for the data described here (the “controller” under UK and EU data protection law) is Mohammed Joraid, an individual based in Texas, United States, trading as PillarSEO. The business is expected to be incorporated, and this page will be updated to name the company when it is.

The way to reach us is hello@pillarseo.ai. A person reads it. Our postal address is [postal address in Texas]; until it appears there, email is the working route for everything on this page, including the requests in clause 9.

2. What we collect when you join the waitlist

The form on our home page is the only place this site asks a visitor for anything. This is the whole list of what it sends us. Nothing else is collected, and the one field you cannot see is described below rather than left out. (The waitlist and the early-access list our terms refer to are the same list.)

email

Required. Stored lowercased, so that two spellings of the same address are recognised as one person. It is the only way we can write back to you.

store_url

Required. The web address of your store. It has to be an ordinary http or https address.

role

Required. One of three fixed values: brand owner, consultant, or agency. It is not a free text field.

full_name, company

Optional. Left out of the stored record entirely if you skip them, rather than saved as blanks.

monthly_posts, client_count, team_size

Optional. One short answer, chosen by which role you picked, so we know roughly what size of thing you are running. Skipping is a visible button and costs you nothing.

The form also contains one field that is hidden from people and only ever filled in by automated form fillers. If it comes back filled in, we throw the whole submission away without saving any of it.

Alongside what you typed, we store the time you submitted, a label recording which page the form was on, and your browser’s user agent string (the line every browser sends that names itself and its version). We also store a flag noting whether the same email had submitted before, so a person who signs up twice does not get two replies.

One more thing is stored, and it is there for your benefit: a short code naming the version of the price list that was on screen when you joined, and the date we recorded it. It is not personal data about you, it is a note of what we showed you, and it is what makes the founding price commitment in clause 8 of our terms something you can hold us to. No price you have to pay is stored, and no plan is chosen for you.

3. What we collect when you connect a store

None of this applies until you are a customer and you have connected a store yourself. Nobody on the waitlist has any of this.

Shopify

Connecting a store grants us four permissions and no others: read_content, write_content, read_files and write_files. In plain terms: we can read and write blog articles and pages, and upload images to your store’s files.

There is one further permission we ask for separately, and only you can grant it: read_orders. It is not part of connecting a store — you can connect, use the product, and never grant it. If you do grant it, we read your orders from the window you choose on that screen — up to 60 days, 30 by default — each time the revenue screen is opened, to match an order back to the page the buyer first landed on. Those orders carry your customers’ data, including order totals, so we ask for it on its own rather than bundling it into the connection. We do not store the orders or the figures we compute from them: the totals shown on that screen are recomputed from Shopify every time the screen loads, and nothing from that read is written to disk. If you have granted it, and Shopify later rejects the read anyway (for example because you revoked access), the screen says so rather than showing stale numbers. If you have not granted it, we do not call Shopify’s orders endpoint at all, and the screen says so. The one exception is a store connected with a hand-entered Admin API token rather than through the button above: we have no record of what that token can do, so we attempt the read and stop as soon as Shopify refuses it — the token’s own permissions decide, not a grant we track. You can withdraw read_orders at any time from your Shopify admin; the rest of the product keeps working either way.

We do not ask for, and cannot see, your payouts or your product inventory.

We store the resulting access token so the connection keeps working, along with the list of permissions Shopify told us you granted, and we store the drafts we write for you plus a record of what has been published.

Google Search Console

If you connect Search Console, we request read-only access (Google’s webmasters.readonly scope). We can read the search performance figures for the site you connect: which queries brought people to which page, how many clicks and impressions, and where you ranked. We cannot change anything in your Search Console account, and we never see your Google password.

We keep periodic snapshots of those figures so the product can show you a page slipping over time rather than only its position today.

4. What we work out from your visit

Your signup record does not contain your IP address. It is not saved alongside what you typed, and there is no second place we keep it and could join back to you.

What that does not cover is the web server itself. Like any web server, ours sees the address a request arrives from, and its ordinary request log can briefly contain it. That is operational plumbing, not a record we keep about you or ever look at next to your signup.

What the record stores instead is a marker: the connecting address is combined with a secret value only we hold, run through a one-way hash, and cut down to sixteen characters. It is a stable label rather than an address: the same connecting address always yields the same marker, which is all abuse checking asks for.

In practice it distinguishes less than that. We deliberately ignore the forwarded-address headers a client can set to anything it likes, so behind the proxy our site runs on, the address our server sees is the proxy’s and is the same for everyone. Today the marker therefore separates nobody from anybody. The error runs in your favour, and we would rather say so than describe the version of this that sounds more impressive.

The marker is not reversible by anyone who does not hold the secret, and we do not attempt to reverse it. That is the whole claim. We are not telling you it is beyond our own reach: whoever holds the secret could work forwards from a guessed address and find the match, which is exactly why the secret matters as much as the hash.

If that secret has not been configured on the server, the marker is left out of the record altogether. The code deliberately refuses to fall back to an unsecured hash, because a plain hash of an IP address can be unpicked on a laptop and would be an address in disguise rather than a marker.

5. Why we hold each of these

Under UK and EU data protection law every use of personal data needs a lawful basis. Here is ours, purpose by purpose.

Waitlist signups

To reply to you, to understand who the product is for, to invite you when onboarding opens, and to honour the founding price commitment in clause 8 of our terms. Our lawful basis is legitimate interest (Article 6(1)(f)): you asked us to get in touch, contact details are the minimum needed to do that, and you can tell us to delete them at any time. We do not use waitlist addresses for unrelated marketing, and we do not sell or rent them.

Running the product for a connected store

To read your store and Search Console data, draft posts, and publish the ones you approve. Our lawful basis is performance of a contract (Article 6(1)(b)): it is the service itself.

The address marker described above

To spot a burst of automated signups. Legitimate interest (Article 6(1)(f)) in keeping a public form usable. It is a pseudonym rather than an address precisely so this purpose costs you as little as possible.

The site access cookie

To remember that you passed the shared password while the site is in private preview. It is strictly necessary to deliver a service you asked for, so it does not need consent. See our cookie notice.

6. Where it is kept, and how it is protected

Everything runs on Railway, a hosting provider, as a backend service with a single storage volume attached to it. That volume is in Railway’s EU West region, in the Netherlands. There is one copy of customer data, on the production volume, in that region, and no second region anywhere. Our frontend service holds no data at all: it talks to the backend over a private network and stores nothing.

We also run a separate development environment, on the same provider and in the same region, with a storage volume of its own. It holds no customer data: at the last check its signup log was empty. We mention it because “one copy” would otherwise be a claim about a system with two disks in it, and you would have no way to tell which we meant.

Waitlist signups are a plain text file on the production volume, one record per line, written once and never edited. Reading it requires access to the server. There is also an authenticated page inside the app that lists signups; that page deliberately leaves out the address marker and the user agent, so the two most sensitive fields are not on anyone’s screen during ordinary use.

Store credentials are encrypted before they touch the disk, using Fernet (AES with an authentication tag) under a key held in the server’s environment and never written into the codebase. Read the file without the key and you get ciphertext.

7. Who else can see it

We do not sell your data, we do not rent it, and we do not share it for anyone else’s advertising. The following companies process some of it on our behalf, because the product cannot work without them. This is the complete list as the system stands today.

Railway

Hosting and storage. Everything described on this page sits on their infrastructure.

Shopify

Your own store platform. We read and write your blog content through their API using the connection you granted, and, if you have granted order access, read your recent orders to produce the revenue figures.

Google

Search Console, for the search performance data you connect. Also Google Fonts: this site loads its typefaces from Google’s servers on every page, including this one, which means your browser tells Google your IP address and user agent when it fetches them. That request sets no cookie. Google reCAPTCHA is built into the codebase but is switched off and makes no request until we turn it on; see the cookie notice for what changes when we do.

OpenAI

Text generation and image generation. Drafting a post sends the brief and the surrounding context to their API.

Anthropic

Text generation, when a customer’s configured writing model is one of theirs. The same brief goes there instead.

Neither AI provider is sent your waitlist details. They receive content briefs for a connected store, which can include your store name and your existing page text.

We would also disclose data where the law requires it, and to a buyer if the business were ever sold. If that second one happens we will say so on this page before it takes effect.

8. How long we keep it

Two things do expire on a schedule today:

• A post you delete goes to a recycle bin and is permanently removed 30 days later.
• A store you disconnect is permanently removed 60 days later, along with its stored credentials and content.

Everything else for a connected store is kept while the store is connected.

9. Your rights, and how to use them

If you are in the UK or the EU you have the right to ask us for a copy of what we hold about you, to have it corrected, to have it deleted, to receive it in a portable format, to restrict what we do with it, and to object to our processing where we rely on legitimate interest. We do not make any automated decisions about you.

To make a request, email hello@pillarseo.ai from the address you signed up with, or tell us which address to look for. We will reply within one month, which is the deadline the law sets.

If you are not happy with how we handle it, where you complain depends on where you are, and the routes are genuinely different. The two below are the ones that cover most of our readers. They are not a complete list of the world’s regulators, and if the place you live has one that supervises this kind of processing, that regulator is your route whether or not it is named here.

In the United States

We are based in Texas, and Texas has no data protection regulator of the European kind. What it has is the Attorney General: state privacy law there is enforced by his office and by nobody else, and it gives you no right to sue us over it yourself. So the route here is a complaint to his consumer protection division at texasattorneygeneral.gov. If you live in another US state, yours may give you more than that: several have their own privacy statutes and their own enforcers, and your state Attorney General — or, in California, the Privacy Protection Agency — is the route to use instead of the Texas one.

In the EU or the UK

You complain to your own national supervisory authority, which is the data protection authority for the country you live in, or the Information Commissioner’s Office if you are in the UK. You do not have to bring a complaint to a regulator in the United States, and none of them supervises us on your behalf.

Either way, we would rather hear from you first, at hello@pillarseo.ai. Complaining to a regulator does not require you to.

10. International transfers

Your data sits in the Netherlands, which is inside the European Economic Area. That is the production Railway volume described in clause 6, and it is the only copy of customer data.

Two things still cross a border. We are in Texas, so the one person who administers that server reaches it from the United States. And our other processors, named above, are global companies, several of them based in the United States, so the data we send them arrives there.

The first of those is the one people expect a paragraph about and rarely get. Under the European Data Protection Board’s guidance on what counts as a transfer, a transfer needs two different parties: someone sending and someone else receiving. One person reaching his own server from another country is not two parties, so this is arguably not a transfer at all and needs no separate safeguard. We raise it anyway, because it is the plainest true thing about where your data is looked at, and we would rather answer it than leave you to notice it.

For the second, where data leaves the UK or the European Economic Area we rely on the transfer terms in each provider’s own data processing agreement, which for all of the companies above are the European Commission’s standard contractual clauses and the UK addendum to them. We have not separately countersigned any of those agreements and are not claiming to have: they bind both sides as part of each provider’s own terms, which is how this kind of clause ordinarily takes effect. Any we do go on to execute by signature are [to be listed here once countersigned].

11. Children

This is a business tool. It is not directed at children, and we do not knowingly collect anything from anyone under 16. If you believe a child has sent us their details, write to us and we will remove them.

12. Cookies

This site sets one cookie, it is strictly necessary, and it holds no personal data. There are no analytics, no advertising pixels and no tracking scripts anywhere on the site. The full detail, including what would change if we ever switch on reCAPTCHA, is in the cookie notice.

13. Changes to this notice

When we change this page we update the date at the top. If a change materially affects what we do with data we already hold, and we have an email address for you, we will email you before it takes effect.

14. How to reach us

Write to hello@pillarseo.ai. A person reads it, not a queue.

That address is the working route for every request on this page. Postal address: [postal address in Texas].