Privacy Policy

This policy explains what data RiseWake (grow.zalize.com, operated by Zalize) processes, why, for how long, and the rights you have. We follow data minimization: no ads, no data selling, no third-party analytics.

1. Data we process

Section last updated 2026-09-07

• Waitlist: the email you submit and the submitting IP (used only for anti-abuse rate limiting).
• Account data: login email and login timestamps.
• Cookies: only two strictly-necessary cookies — the session cookie ge_session (authentication) and the language cookie ge_lang (remembers your manually chosen UI language for one year). No analytics or third-party cookies; public article pages set no cookies at all. Our public pages (home, preview, pricing and this page) also load no third-party scripts, fonts or analytics — same-origin resources only.
• Search performance data: Google Search Console metrics you authorize (which may include search query strings); retention is described in section 6.
• Business data: product, directory, submission and article records. We do not collect personal data about your end users.
• BYOK keys: LLM API keys you configure are encrypted at rest and used only for generation tasks you initiate.

2. What the public /preview page stores

Section last updated 2026-09-07

The directory-match preview runs without an account. This is exactly what it writes, keyed and retained as in the source code (worker/src/preview.ts, worker/src/landing.ts):

• The domain you type is normalised (lower-cased, scheme and path stripped) and used for two things only: fetching the homepage of that domain once, and matching it against our directory library. It is not written to a database and not tied to your IP, cookies, or any identifier. It appears in the page URL (?domain=) and in the edge-cache key below.
• Homepage signal cache: the result of fetching https://<domain>/ (title, meta description, meta keywords, first H1, and the category tags we infer from them — at most 160 / 300 / 200 / 200 characters each, from at most the first 200 KB of HTML) is stored in the Cloudflare edge cache under the same-origin key /__preview/site/<domain> for 3,600 seconds (about one hour) after a successful fetch, or 600 seconds after a failed one. The cache is per Cloudflare data centre and holds nothing about the visitor — only public data from the third-party homepage. The fetch itself follows at most 3 redirects, refuses private/internal network targets, identifies itself as GrowthEngine-Preview/1.0, and aborts after 4 seconds per hop.
• Rate-limit counter: to stop the preview being abused as a fetch proxy, we keep a counter per visitor IP in Cloudflare KV under the key lpv:ip:<ip>. The IP is taken from the CF-Connecting-IP header and stored in plaintext, not hashed; the value is a small integer (the number of outbound fetches you triggered), and the key is written with a KV expirationTtl of 600 seconds, after which Cloudflare deletes it automatically. Only requests that actually trigger an outbound fetch are counted (10 per 10 minutes); cache hits are not counted and write nothing; the manual “Show results re-ranked by category” link on a pending page (r=1) counts like any other lookup if it misses the cache and has to fetch again. When the limit is reached you see a 429 page; nothing else is recorded.
• Landing-page sample snapshots: the home page shows a live sample preview for a fixed, hard-coded domain (notion.so). Its homepage signals are stored in KV under lpv:sample:notion.so and refreshed in the background about every 24 hours (a failed refresh is kept for only 600 seconds). Reachability checks for the "listed at" proof links are stored under lpv:proofs (URL → last HTTP status). Neither key contains visitor data.
• Timing headers: the preview response carries a Server-Timing header with the durations of the directory lookup, KV read, and homepage fetch, and the page shows the same total. These are per-request numbers and are not stored.
• No cookies, no logs of your input: the preview page sets no cookie, includes no analytics, and we do not write the domains people look up to any log or table. Responses that depend on your input are sent with Cache-Control: no-store.

3. Waitlist: fields, invite links, and deletion

Section last updated 2026-09-07

Joining the waitlist (POST /api/waitlist, worker/src/routes/waitlist.ts) writes the following to our Cloudflare D1 database:

• Table waitlist: your email (trimmed and lower-cased, at most 254 characters, must match a basic email pattern), the submitting IP from CF-Connecting-IP, and the creation timestamp. Both email and IP are stored in plaintext. The email column is unique: submitting the same email twice does not create a second row and returns the same success response, so the response does not reveal whether an address is already on the list.
• Table waitlist_rate: one row per IP with a submission count and the start of the current window, used to allow at most 5 submissions per IP per rolling hour. The IP is stored in plaintext. Rows are not deleted on a schedule; a row is reset by the next submission from the same IP once its hour has passed. This is a D1 table rather than KV so that the limit cannot be bypassed by racing cache reads.
• Self-serve invite link: after a successful submission we may issue a one-time invitation URL (/invite/<token>) valid for 7 days, capped at 20 per UTC day across all visitors. The token is a random 64-hex-character string shown to you once in the response (or the redirect back to the landing page); the database stores only its SHA-256 hash together with your email, the expiry time, and a source = self_serve marker. Re-submitting the same email replaces your earlier unused self-serve link. If the daily cap is reached, your waitlist row is kept and no invite is created.
• Audit events: invite issuance and waitlist deletions write an events row with a masked email (a***@example.com) — the full address never enters the audit log.
• Who can see it: the operator console shows the total count, a 7-day trend, and the 10 most recent entries with masked emails; the full address is only read when an operator turns a waitlist entry into an invitation.
• Deletion: an operator can hard-delete a waitlist row (DELETE /api/waitlist/:id). The row is removed from waitlist and an audit event with the masked email is written; the plaintext email and IP are gone from the database at that point. To have your entry deleted, contact us (section 10) — see section 6 for the service level.

4. Purposes

Section last updated 2026-08-07

Waitlist invites and onboarding notices, authentication, SEO/GEO performance measurement, content generation and publishing operations, and anti-abuse rate limiting. Never for advertising or profiling.

5. Processors and where data lives

Section last updated 2026-09-07

• Cloudflare, Inc. runs everything you touch on grow.zalize.com: the application executes as a Cloudflare Worker; structured data (waitlist, accounts, directories, submissions, articles, audit events) lives in Cloudflare D1 (SQLite); short-lived keys (preview rate-limit counters, landing samples, session tokens, job status) live in Cloudflare KV; and homepage signals for the preview live in the Cloudflare Cache at the edge. Cloudflare also terminates TLS and, as our network provider, sees request metadata (IP, URL, headers) in the ordinary course of serving traffic.
• No third-party scripts, fonts, pixels or analytics are loaded on any public page (home, preview, pricing, legal pages); every resource is served from our own origin, and our Content-Security-Policy is set to enforce that. There is no Google Analytics, no tag manager, no chat widget, and no social embed.
• The websites you preview: when you run a preview we make one server-side request to the homepage of the domain you entered, from Cloudflare's network, with the user agent GrowthEngine-Preview/1.0. That site sees our request, not your browser or IP.
• Console-only processors (never involved on public pages): the LLM API provider you configure yourself under BYOK (content generation, called with your key), Google Search Console (only if you connect your property), and Brave Search and Perplexity (GEO visibility checks on your own queries). Each receives only the minimum data required for its function.
• We do not use any advertising network, data broker, or cross-site tracking service, and we do not sell or share personal data for advertising.

6. Retention and deletion

Section last updated 2026-09-07

On narrow screens this table scrolls sideways: swipe, or focus it and use the ← → arrow keys to reach the Retention column.

Deletion service level: deletion requests (including "remove me from the waitlist") are executed within 30 days of receipt. A waitlist deletion is a hard delete of the row and leaves only a masked-email audit event (section 3). Cloudflare, as our infrastructure provider, processes request metadata under its own privacy policy; that is outside our database and not affected by a deletion here.

7. Your rights

Section last updated 2026-08-07

You can request access to, correction of, or deletion of your personal data at any time (including leaving the waitlist). Contact us below and we will respond and act within 30 days.

8. Security

Section last updated 2026-08-07

TLS everywhere in transit; key material encrypted at rest; least-privilege admin access. If a data incident affects your rights, we will notify you promptly as required by law.

9. Changes

Section last updated 2026-08-07

Changes update the "Last updated" date on this page; material changes are additionally announced by email or in the console.

10. Contact

Section last updated 2026-08-07

Zalize — zalize.com