Privacy Policy

1.1 Account information

When you sign up we collect your email address, hashed password (managed by our authentication provider, Supabase), and any profile details you choose to enter. We use this to identify you, authenticate you, and contact you about the Service.

1.2 Credentials for connected integrations

When you connect a third‑party tool — Stripe, Google Analytics, PostHog, Calendly, or custom webhooks — we store the credential needed to access that tool on your behalf. Depending on the tool, this is either an OAuth access token + refresh token (revocable from your account at the provider) or an API key you paste in. Credentials are scoped read‑only wherever the third party supports it. Every credential is encrypted before it's written to our database — see Section 5 for details.

1.3 Data fetched from connected integrations

To render the metrics you choose, we fetch data from your connected tools. Most providers' data is queried live on every dashboard renderand never persisted server‑side; the exception is Stripe, where we mirror a subset (charges, customers, subscriptions, products, line items) to support fast historical queries. Scope:

• Stripe— charges, customers, subscriptions, products, and the line items needed to attribute revenue (read‑only, mirrored locally). We never write to your Stripe account.
• Google Analytics — pageviews, sessions, users, and traffic source breakdowns for the property you select. Live every render; never persisted.
• PostHog— event counts, funnel results, retention matrices, and the live values you choose to track. Live every render; only the cached “today's tile value” for daily counters is briefly stored.
• Calendly — meeting counts and basic meeting metadata. Live every render.

We fetch only what's needed for the views you create, and you can disconnect any integration at any time to stop fetching immediately. See Section 6 for the deletion behaviour.

1.4 Usage analytics

We use PostHog to understand how the Service is used in aggregate (which pages people visit, which connections they create, which views are popular). This includes IP addresses and device/browser metadata. We do not sell or share this data with third‑party advertisers, and the events here contain no Google user data.

Databerry's Google Analytics integration uses the Google Analytics Data API and Google Analytics Admin API to read property‑level metrics on properties you explicitly authorise. This section gives an exhaustive accounting per Google's required disclosures. Section 3 covers the equivalent commitments under Google's Limited Use requirements.

2.1 Data accessed

The application requests exactly one OAuth scope:

• https://www.googleapis.com/auth/analytics.readonly — read‑only access to your Google Analytics properties.

The Google Analytics integration does not request openid, userinfo.email, or userinfo.profile. The analytics‑readonly scope by itself does not expose your Google account's email or profile name to Databerry.

Separately, if you choose to sign into Databerry using “Continue with Google” (a different OAuth flow, handled by our authentication provider Supabase), Databerry receives your email address — that's the email associated with your Databerry account, covered by §1.1. The Google Analytics integration does not piggyback on that sign‑in or share its data with the GA integration; the two are independent OAuth flows with independent scopes and tokens.

Through that scope, we call two Google APIs:

• Google Analytics Admin API (analyticsadmin.googleapis.com/v1beta) — once per OAuth callback, to list the GA4 properties under your account so you can pick which one to display.
• Google Analytics Data API (analyticsdata.googleapis.com/v1beta) — on every dashboard render, to fetch the metrics you've chosen for the selected date range. We use runReport for historical queries and runRealtimeReport for the “active users right now” tile.

The specific GA4 fields we query:

• Metrics: totalUsers, sessions, screenPageViews, activeUsers (realtime).
• Dimensions: sessionSource, dateHour, date.
• Property identifier and human‑readable display name (so we can label which property a tile is showing).

We do not request, fetch, or store any user‑level identifiers (e.g. clientId, userId) or events that could identify a specific website visitor.

2.2 Data usage

The data described above is used onlyto render your Databerry dashboard — the metric tiles and traffic breakdowns you configured. It is not aggregated across users, not used for advertising, retargeting, or model training, and not sold or shared with any party other than the operational sub‑processors listed in Section 4.

2.3 Data sharing

See Section 4 for the full sub‑processor list, which notes specifically which sub‑processors handle Google user data. In summary:

• Encrypted Google OAuth credentials (access token + refresh token) live in Supabase.
• Google API responses transit through Railway (our backend host) on their way to your browser; nothing is persisted server‑side.
• PostHog (product analytics on Databerry itself) does not receive Google user data at all.

2.4 Data storage & protection

The only Google user data we persist is the OAuth credential pair (access token, refresh token) plus the GA4 property ID and display name you select. Storage protection runs four layers deep:

• Application‑layer encryption— Tokens are encrypted with AES‑256‑GCM (an authenticated encryption mode that detects tampering) before they leave the backend. The encryption key is derived per‑user using HKDF‑SHA256 over a master key that lives in our backend environment configuration, never in the database. A leaked database alone cannot be decrypted; an attacker would also need the master key, and would need to know each row's owning user UUID.
• Transport security— All traffic between your browser, our backend (Railway), and our database (Supabase), and outbound traffic to Google's APIs uses TLS 1.2 or higher.
• Database‑layer encryption at rest— Supabase additionally encrypts all stored data with AES‑256 at the disk level, including database backups.
• Access control— Production database access is limited to a single role key held by the backend service. On the human side, only the company's sole founder has access to production infrastructure. There are no other employees or contractors with production access today.

Google API query results (pageviews, sessions, source breakdowns) are neverpersisted. Each chart re‑queries the Google Analytics Data API live, and the response is forwarded to your browser without being saved server‑side.

2.5 Data retention & deletion

• On disconnect— when you click the trash icon next to a Google Analytics connection in Databerry's Connections page, the encrypted credential row is deleted from our primary database immediately (within the same HTTP request). Any in‑flight queries already in progress finish out and discard their results.
• Database backups— Supabase retains point‑in‑time recovery snapshots for up to 14 dayson our current plan, after which they're automatically purged. Even within that window, credentials remain in their application‑layer encrypted form (AES‑256‑GCM, per‑user derived key) and are unusable without the master key, which is not stored in Supabase.
• Backend logs — Railway retains runtime logs for up to 30 days by default. Logs do notcontain full credentials: access tokens are masked (e.g. sk_test_…ibr2c) before any log line is emitted, and our codebase encrypts tokens at rest regardless. We never log Google API response payloads.
• Account deletion — to delete the entire account and every associated record, email team@heavenmade.org. We process deletion requests within 48 hoursof receipt. The action wipes: the account record, every connection and its encrypted credentials, every project / folder / view you created, every cached integration data row, and the per‑user settings record. Backup snapshots referenced above continue to age out per Supabase's retention window.

You can also revoke Databerry's access to your Google Analytics account directly at myaccount.google.com/permissions — our stored credentials become unusable the moment Google revokes them, and our next refresh attempt will prompt you to reconnect.

Databerry's use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements:

• We use Google user data onlyto provide and improve user‑facing features within Databerry — specifically, displaying your Google Analytics metrics in your dashboard.
• We do nottransfer Google user data to third parties except to the operational sub‑processors listed in Section 4 (each of whom is bound to confidentiality and security obligations under their own customer contracts), to comply with applicable law, or as part of a merger or acquisition with appropriate user notice.
• We do notuse Google user data for serving advertisements, including retargeting or personalised‑ads use cases.
• We do not allow humans to read your Google user data, except: (a) with your explicit consent for a specific support request; (b) when necessary for security (e.g. investigating abuse); (c) to comply with applicable law; or (d) where the data has been aggregated and anonymised, and is used for internal operations.
• We do notuse Google user data to develop, improve, or train generalised AI or machine‑learning models.

We rely on the following sub‑processors to operate Databerry. Each has its own privacy and security commitments under its standard customer terms.

We may also disclose data when required by law, to protect rights and safety, or in connection with a merger, acquisition, or sale of assets (in which case we'll notify you in advance).

Every credential we store — OAuth tokens (Stripe, Calendly, Google Analytics) and API keys (Stripe Manual, PostHog) — is protected with the same multi‑layer scheme described in §2.4: AES‑256‑GCM application‑layer encryption with a per‑user derived key, on top of TLS in transit and AES‑256 disk encryption at rest in Supabase. The master encryption key lives in our backend environment configuration and is never written to any database.

Webhook signing secrets (used by some custom integrations) are stored as one‑way SHA‑256 hashes — we never need to recover the original value, only verify an incoming signature.

We use the data described above to:

• Provide, maintain, and operate the Service.
• Authenticate you, secure your account, and prevent fraud or abuse.
• Render the dashboards, charts, and lists you've set up.
• Respond to support requests and communicate updates about the Service.
• Improve the Service in aggregate (which features get used, which break).
• Comply with legal obligations.

We do not sell your data, share it with advertisers, or use the contents of your connected tools to train AI/ML models.

We use cookies (or equivalent local storage) for authentication (keeping you signed in) and for analytics via PostHog. We don't use third‑party advertising cookies.

Depending on where you live, you may have rights under privacy laws like the GDPR (EU/UK) or CCPA (California) including:

• Access — request a copy of the personal data we hold about you.
• Correction— ask us to fix data that's inaccurate.
• Deletion— ask us to delete your account and associated data (we process within 48 hours; see §2.5).
• Portability— request your data in a machine‑readable format.
• Withdraw consent — disconnect any integration at any time, immediately wiping its credentials.
• Lodge a complaint — with your local data protection authority.

To exercise any of these, email team@heavenmade.org. We respond within 48 hours.

The Service is not directed to children under 16, and we don't knowingly collect personal information from anyone under 16. If you believe we've done so, contact us and we'll delete the relevant data.

HeavenMade LLC (operating Databerry) is registered in Wyoming, USA. Where your data is transferred across borders, we rely on appropriate safeguards (such as the EU Standard Contractual Clauses) where required by law. Our sub‑processors (Section 4) maintain their own cross‑border transfer compliance.

We may update this policy from time to time. The “Last updated” date at the top of the page reflects the most recent change. Material changes will be announced via email or in‑app notice before they take effect.

Questions about privacy or this policy? Email team@heavenmade.org.