Product Analytics & Privacy

What RocketVault Records

RocketVault keeps a limited activity record for signed-in use. It may include the page you were on (without search terms), the kind of action, whether it finished, how long it took, the device type, and a random error reference. A separate random reference connects the steps of one action without using your name or email address.

It does not include what you type, card names or images, search terms, payment data, submitted form contents, sign-in credentials, email addresses, IP addresses, or identifiers you provide.

Third-Party Analytics Consent

On the web, RocketVault sends product-usage events to PostHog only after you accept analytics. Declining does not disable RocketVault or the basic records we need to keep the product reliable. To withdraw consent, choose Decline in the Cookies and Analytics section of the privacy policy on that website.

When you accept, PostHog receives a random account reference rather than your email address or sign-in identifier. RocketVault does not use these events to build an advertising profile.

The native iOS app does not load Google Analytics or Microsoft Clarity. It sends a small set of reliability events to PostHog so RocketVault can find problems with app startup, connectivity, camera capture, uploads, offline sync, and other important actions. A new random reference is used for each app session. These events exclude clicks, field activity, card data, filenames, customer text, submitted form data, and error messages. They are not used for advertising or tracking across other companies' apps or websites.

Retention

Detailed activity records are kept for 90 days. After that, RocketVault keeps only daily totals such as page views, interactions, uploads, and errors. PostHog data follows RocketVault's configured analytics retention period.

How the Data Is Used

RocketVault uses this information to see where people stop, which steps are slow, where retries happen, and whether an update caused a new problem. Reports call out when there is not enough information to draw a conclusion. Groups smaller than five people are never shown on their own. Product-analytics data is not sold or used to build advertising profiles. The separately optional Meta advertising measurement described below helps measure and optimize ads.

For the full policy and data-rights details, see the Privacy Policy.

Campaign attribution

Signup attribution keeps the landing-page path and campaign/referral tags. It removes ad-click identifiers and other query fields before saving or sending the landing-page value. Advertising identifiers use the separate consent-controlled storage described below.

RocketVault also reviews aggregate ad delivery against campaign-tagged signups, seller setup and published Marketplace listings. The ad platform and RocketVault may count conversions differently because their attribution rules differ. This review does not send card details, payment information or contact details to the ad platform.

Optional Meta advertising measurement

RocketVault's websites offer Decline, Analytics only, and Analytics & ads. Existing analytics consent does not grant Meta advertising consent. You can change these choices in the Cookies and Analytics section of the privacy policy on each website. Declining stops future sharing and deletes the ad-click and browser cookies. It also clears queued guest-purchase measurement, including after returning from payment or opening a recovered order link. It does not recall events already sent.

After advertising opt-in, a real Meta ad click can be retained in a first-party cookie for up to 90 days across rocketvault.io and app.rocketvault.io. Each website still requires its own consent. Only database-confirmed account creation and the first published Marketplace listing qualify. Meta receives the event, time, opaque deduplication ID, page path, browser user agent and ad-click identifier. Names, email addresses, IP addresses, card details and payment data are excluded. Ordinary page views, clicks and failed listing attempts are not sent to Meta. RocketVault keeps a delivery status for these two milestones in its existing 90-day activity records to prevent duplicate conversions. Those records do not store the ad-click identifier or browser user agent.

Global Privacy Control disables Meta measurement. The native iOS app does not participate. Advertising consent is optional and does not change access to RocketVault, seller offers or buyer credits.

On web guest checkout, advertising opt-in can also measure a purchase after our payment system confirms it. This uses the browser user agent, a random first-party browser identifier and, when present, a real ad-click identifier. Consented attribution is encrypted for up to 24 hours while awaiting payment, then removed when sent, withdrawn or expired. The delivery receipt retains only an opaque event reference and delivery state. Contacts, card details and payment amounts are excluded.

Understanding workflow outcomes

A successful upload request means the transfer was accepted. A separate card processing completed or failed event comes from the processing service. Saved review decisions, listing publication, payments, delivery, and payout outcomes come from committed records. These operational events use a service actor and opaque order or listing keys. They contain no customer content, contact information, provider tokens, or account identifiers.

With analytics consent on the web, signup intent can be recorded before login under a temporary operation actor. That actor is not a person or account. A client signup completion and a committed account-created outcome are separate observations. Reports must filter sources and actor scope, and join by the opaque operation ID instead of adding these observations together. Native reliability actors remain sessions and cannot be counted as distinct people.

Expected empty or pending responses have controlled reasons such as briefing empty and capture session pending. Genuine unexpected failures remain visible. The first-party database remains authoritative; delivery to product analytics is best effort. Terminal correlation must be measured over 14 complete days after release; local validation does not prove that target.