Privacy Policy

1. Who we are and how to contact us

This website is operated by Ossea trading as AI Ready Websites. This notice covers this website, not other business systems or services that may have separate notices.

• Privacy email: iamnikfox@gmail.com
• Current website contact: Contact us.

Use the privacy email or existing contact form and mark your message “Privacy enquiry”. Please do not include passwords, payment-card details, identity documents or sensitive personal information.

2. Information collected through forms

• Contact enquiries: your name, email, message and any optional phone number or business name, together with a reference and submission time. We use this to respond to your enquiry.
• Fair Go Rewards referrals: we store your name, email and optional website, and the names, business emails and optional business names of people you introduce. Please first check they are happy for us to contact them about a website and mention your name. We record that confirmation and the submission time, plus a content fingerprint to handle retries. Our team uses these details to follow up, review referrals and track rewards in a private owner dashboard. Owner updates, customer links and follow-up notes are recorded. Submitting an introduction does not automatically send a message or award a discount. Contact us to correct details or request removal.
• Website change requests: your name, email, website and optional page link, change type, instructions, reference and submission time. An optional PNG, JPG or WebP image of up to 5 MB is stored with the request. We use these details to understand and handle the requested website work. A hashed retry token and content fingerprint help avoid duplicate or mismatched retries.
• Grant applications: when you submit the qualification form, we store your name, email, phone number, optional website, industry, turnover and ABN answers, submission reference and time, and an initial eligibility indication. Our team uses this information to review your application and contact you about the outcome. Receipt is not approval. A random submission token is kept in your current browser tab; only its one-way hash is stored to verify retries. Explicit owner test submissions are labelled tests and store the owner account ID instead. Normal signed-in submissions use the customer flow.
• Website onboarding: we store the business, private project contact, approved public contact details, audience, website, social media profiles, services, customer questions, claims and evidence notes, testimonial permissions, policy information, design preferences, domain/DNS and business-email setup information, integrations, intended enquiry destination and redirect requirements you submit. Every question needs a response, with none, NA or no response available where appropriate. File uploads remain optional. Never provide passwords, access codes, secret keys, identity documents or sensitive personal information. Attachments, file names, types, sizes, submission time, a hashed retry token and a content fingerprint are stored. Limits are eight files, 5 MB per file and 20 MB combined. Owner test briefs are labelled separately. A brief does not itself approve an application or start production.

Share only material you are authorised to provide. Optional fields on other forms can be left blank. Onboarding questions require a response, including none, NA or no response where appropriate. Without contact or request details we may not be able to respond to an enquiry or carry out website work. Form contents are not included in A/B experiment records.

Your website brief email copy

For new real submissions, a complete copy of your written answers, including private project details, and a list of uploaded file names, types and sizes is queued to the private contact email you provide. The final form step shows the destination for you to check. If you provide none, NA or no response instead of an email address, no copy is sent. Original uploaded files are not attached or made public. Explicit owner tests and submissions begun before this feature do not trigger a customer copy.

Resend processes the recipient address and email content to send this copy from support@ossea.app. We retain a frozen copy of the email, destination, submission reference and sending status to support safe retries and avoid duplicates. Provider acceptance does not confirm delivery or that the email was read. A failed email does not undo your saved brief. The email may contain private information, so check the address carefully and avoid forwarding it unnecessarily.

Approval emails and onboarding reminders

Approval emails sent by our team may include a unique onboarding link that connects your completed brief to that application. The link does not let anyone read your application or brief. Keep it private and do not share it with another applicant. We record the invitation, its issue and expiry times, the linked submission and email sending status.

If an approved applicant has not completed the linked brief, scheduled reminders may be sent two and three Sydney business days after the approval email is accepted by Resend. The final reminder gives an additional 24 hours. Reminders use the latest saved wording at the start of sending; retries retain the original message to avoid duplicates. We use Resend to process the recipient address and email content and retain a private sending record. Provider acceptance is not proof of delivery or reading. Contact us if you need more time or used a different link to submit your brief.

Saved onboarding drafts

If you choose Save draft, text answers are encrypted in this browser’s local storage using a new draft passphrase. The passphrase and encryption key are not stored, and draft answers are not sent to our server until you submit. Files are not saved in drafts and must be reattached. Drafts expire after 30 days and are removed when next read. You can discard a draft or clear this site’s browser storage. We cannot recover a forgotten passphrase. On shared devices, close the page when finished: encryption does not hide answers visible in an open page.

3. A/B testing and cookies

First-party A/B measurement is on by default unless you opt out. This includes qualifying homepage views, engaged time and successful real application completions. Existing saved declines remain off. Use Measurement preferences below to opt out at any time. There is no automatic pop-up. This does not enable OpenAI advertising measurement, which remains a separate, explicit choice.

The homepage compares two visual designs with the same marketing content. Version A uses the original character design. Version B uses different typography, colours and a website-example hero. New visits to the normal homepage are randomly allocated A or B with equal probability. A directed share link with ?design=A or ?design=B selects that design instead. Layout and assignment cookies remember that choice separately from your measurement preference.

Layout cookie: arw_hero_v1

Stores only “A” or “B” for up to 30 days. Directed share links update the choice. Explicit previews using ?variant=A or ?variant=B do not change it.

Assignment cookie: arw_hero_source_v1

Stores only “random” or “directed” for up to 30 days. It contains no visitor identifier.

Preference cookie: arw_measure_choice

Stores an explicit “allow” for up to 30 days or “decline” for up to one year. Existing older declines remain effective while their cookie is present. No explicit permission is assumed or recorded when default measurement starts.

Measurement cookie: arw_measure_v1

Set automatically on eligible homepage visits unless you have opted out. It contains a random browser identifier and lasts up to 30 days. The database stores a one-way hash, not the cookie value. Owner visits and explicit preview visits do not enroll.

Experiment records contain the identifier hash, experiment/design, enrollment and expiry times, measurement start times and the first qualifying hero exposure for each design and random/directed source. At least 25% of the hero must be visible for one second in a visible browser tab. Each browser counts once overall and once per design/source while its record remains active; rows may overlap. Directed traffic is observational, not random assignment. Crossovers are identified in the owner dashboard.

Engaged time: each qualifying homepage load creates a random visit reference stored as a hash, with start and update times and cumulative engaged milliseconds. Time counts only in a focused, visible tab, pauses after 30 seconds without interaction and is capped at 30 minutes per visit. Zero-second measured visits are included in the average. Other pages are not timed. Activity is used only to pause the timer; clicks, keystrokes and what was typed are not stored.

Application completions: a successfully saved real application after a qualifying exposure can record a completion time and a one-way hash of its application reference against the measured browser. One browser counts at most once overall, attributed to the design and source of the submitting page, even if another tab shows a different design. A signed page context binds measurement to that page without storing its URL. Owner tests, explicit previews, failed submissions and applications before a qualifying exposure do not count. Earlier unmeasured visits or applications are not reconstructed. You can apply after opting out.

These records are pseudonymous, not guaranteed anonymous. They contain no names, email addresses, phone numbers, form answers, IP addresses, user agents, page URLs or referrers. First-party experiment records are not sent to advertising services. The separate OpenAI advertising option is described below.

Opting out stops future measurement and removes your matching experiment record when storage is available. Layout, assignment and opt-out preference cookies remain. Clearing the opt-out cookie returns a later visit to default-on measurement. Blocking or deleting measurement cookies may prevent counting, change allocation or make an earlier record impossible to link to your browser. An unexpired existing record keeps its original expiry; revisits do not extend it. After expiry, a later eligible visit can start a new 30-day record unless you have opted out. Signing into owner areas uses OpenAI/ChatGPT authentication cookies. Hosting providers may process technical security information such as IP addresses; the excluded fields above describe our experiment records, not all provider processing.

OpenAI advertising measurement

This is separate from our first-party A/B statistics. It is off unless you choose to allow it. Allowing it lets our OpenAI Measurement Pixel record homepage views and successful grant applications to measure ChatGPT ads. OpenAI receives browser and network information, advertising identifiers and the page/referrer path. We do not include your form answers in event payloads or use automatic contact-detail matching. You can apply without allowing this.

Our preference cookie lasts up to 30 days. The pixel may use its own attribution cookies or storage after permission. OpenAI may process information outside Australia under its privacy policy. Declining stops future measurement; it does not recall events already sent. Browser controls can also clear provider storage.

Current preference: Not chosen (off).

4. Access, hosting and disclosure

Form records and experiment records are held in a Cloudflare D1 database. Uploaded files are held in Cloudflare R2. The site runs through OpenAI Sites and Cloudflare infrastructure. Owner access uses ChatGPT sign-in and a server-side administrator allowlist.

Authorised site administrators can view the relevant private dashboards. Service providers may process data as needed to provide hosting, storage, authentication and security. Records and uploads are not provided through a public listing. Onboarding attachments are served only through authorised attachment downloads and are not displayed inline.

The exact provider processing countries, support access and backup/log retention have not yet been confirmed. Data may be processed outside Australia. We will update this policy when these details are confirmed.

5. How long information is kept

Experiment records: expire 30 days after enrollment and are excluded from reports at expiry. Associated visit-time and design/source exposure records share that expiry and are deleted with the participant record. Physical deletion runs on the next participant enrollment or owner analytics read; there is no guaranteed daily deletion schedule. Opting out removes the matching record when storage is available. If deletion cannot be completed immediately, collection stops and expiry cleanup removes the old record later.

Other form records and files: no automatic retention deletion period is currently configured for contact enquiries, website changes, grant applications or onboarding briefs and attachments. Owner deletion moves applications and website briefs into recoverable Trash, rather than permanently erasing them. Saved answers, attachments, customer email-copy snapshots and sending records, and deletion/restore audit history remain stored. Moving a brief to Trash stops copies that have not yet started sending; it cannot recall an email already sent or in progress. Deleted applications are excluded from active counts and their linked A/B completion count; visitor totals and engaged time remain unchanged. Restoring an application restores its linked completion only while the experiment record remains eligible and unexpired. Incomplete upload reservations are retained so the same request can be retried safely; they are marked incomplete in the private inbox. Application review decisions, manual brief build-readiness decisions, change-request progress and enquiry response updates, together with their administrator/time history, are also retained. The operator still needs to define and implement appropriate retention and deletion periods.

6. Your choices, access and correction

You can ask us what personal information we hold about you, request access or correction, or ask for deletion where applicable. Use the privacy contact above, explain what you are requesting and provide enough context to locate the relevant record. Do not send identity documents unless a suitable verification process has been agreed.

Requests are not handled automatically by this website. The operator will need to verify the request and assess it under applicable obligations. Deleting a browser cookie does not delete a contact enquiry or uploaded file.

7. Privacy concerns and complaints

Contact us using the details above and describe your concern. If the matter is not resolved, you can seek guidance from the Office of the Australian Information Commissioner, including whether it can consider your complaint. The application of the Privacy Act depends on the operator’s circumstances.

8. Security and changes to this notice

The website uses access checks, input and file-size limits, basic submission quotas and restricted downloads. Quotas and hidden spam checks do not guarantee protection from bots or abuse. These measures do not guarantee security. Upload validation is not antivirus scanning; uploaded material remains untrusted. Avoid supplying sensitive information that is not needed for your request.

We will update this notice to reflect approved changes to collection, providers, retention and contact details. The date above identifies this version.