Customer Disclosure Template
Pre-vetted language your privacy team can paste into your own
privacy policy to disclose Crossdeck. Three flows are covered:
the standard processor-relationship disclosure (Flow A — our
role over your end-user data), the SDK diagnostic-telemetry
disclosure (Flow B — our independent-controller role), and the
opt-out mechanism that mirrors the SDK's setConsent()
surface.
This template is offered as a starting point. Substitute the bracketed placeholders for your own service's specifics and have your counsel review against the privacy regimes that apply to your end users. Crossdeck makes no warranty that pasting this template satisfies your disclosure obligations in every regime — but it is drafted to the GDPR / CCPA floor, names the regime-specific overlays, and matches the technical reality of what our SDK actually collects.
Short version — one paragraph
Use this in a "Service providers" or "Third parties" section of
your privacy policy. Replace [YOUR SERVICE] with
your service's name.
Crossdeck. We use Crossdeck (VistaApps (Pty) Ltd, trading as Crossdeck — cross-deck.com/legal/privacy) to capture product analytics, identity resolution, error monitoring, and subscription / entitlement state for [YOUR SERVICE]. Crossdeck processes Personal Data we transmit to it as our data processor under a signed Data Processing Addendum. Crossdeck also independently receives a narrow set of diagnostic telemetry from its SDK about the SDK's own operation; for that telemetry, Crossdeck acts as an independent controller (see cross-deck.com/legal/privacy/#sdk-diagnostic). You may opt out of Crossdeck analytics at any time via the opt-out mechanism described below.
Long version — Flow A (processor)
Use this in a "Sub-processors" / "Service providers" table in your privacy policy if you maintain one, or as an expanded paragraph in your "Third parties we share data with" section.
Crossdeck (VistaApps (Pty) Ltd, trading as Crossdeck) — data processor.
Purpose: Crossdeck provides product analytics, identity resolution across our web and mobile surfaces, error capture with paying-user impact attribution, and subscription / entitlement state synchronisation over our payment rails.
Categories of data: identifiers (anonymous device IDs we generate, the user ID we assign you, your email address where you have supplied it); behavioural data (the pages you view in our service, the buttons you press, session start and end events, custom-event properties we record for product analytics); error data (exception types, stack traces with personal data redacted at the SDK level, breadcrumbs of recent activity that preceded an error); commercial data (your purchase and subscription events, the entitlements they unlock, plan tier and renewal state); device data (browser, operating system, device class, locale, timezone, application version we have installed on); and approximate geographic location (country, derived from your IP at our service edge).
Categories of recipients: Crossdeck and its sub-processors (Google LLC for hosting and storage; ClickHouse, Inc. for analytical aggregation; Resend Inc. for transactional email; Stripe Inc. for billing of Crossdeck's own subscription; Cloudflare, Inc. for content delivery). The current list is published at cross-deck.com/legal/sub-processors.
International transfers: data is stored in the United States (Google Cloud's
us-central1region). Transfers outside the European Economic Area, the United Kingdom, and Switzerland are governed by the European Commission Standard Contractual Clauses (Module 2, June 2021), the UK International Data Transfer Addendum (where UK data is involved), and the Swiss FDPIC adaptation (where Swiss data is involved).Retention: raw event data is retained for up to 13 months; aggregated data may be retained longer once anonymised beyond re-identification. Customer Personal Data is deleted within 60 days of our termination of the Crossdeck service, with backups expiring within a further 90 days.
Your rights: see the "Your rights" section of this policy. We honour data subject rights requests directly; where Crossdeck holds the data on our behalf, we instruct Crossdeck to act on your request. Crossdeck additionally publishes its own rights-handling matrix at cross-deck.com/legal/dpa/#annex-d.
Long version — Flow B (diagnostic telemetry, independent controller)
This is the section that follows the Breyer-line analysis (IP address is personal data even when not persisted; transmission itself is processing). Include it as a distinct disclosure — even if the payload contents are diagnostic, the transmission sends end-user IP to Crossdeck for a purpose Crossdeck itself determines.
Crossdeck — independent controller for SDK diagnostic telemetry.
In addition to our processor relationship described above, Crossdeck's SDK transmits a narrow set of diagnostic telemetry to Crossdeck about the SDK's own operation in our application. Crossdeck acts as an independent controller for this telemetry, with the legitimate interest of operating reliable software for all of its customers.
When the SDK transmits: a transmission occurs when a contract that the SDK enforces about itself — per-user cache isolation, idempotency-key determinism, error-envelope shape, payload schema-lock, and similar structural guarantees documented at cross-deck.com/docs/contracts/ — is detected violated. The detection happens in three ways: an external test harness in our continuous-integration pipeline; the SDK's own boot self-test on
Crossdeck.init(...); or a hot-path verifier observing a real operation (anidentify(),syncPurchases(), or error-envelope parse). Pass results do not transmit. Failure transmissions are rare in practice because the verified guarantees are structural and the verifier has no observation latency.Payload contents: contract identifier, SDK version, SDK platform, machine-readable failure reason, run context (continuous-integration / dogfood / customer-app), opaque run identifier (not stable across runs and not linked to an end user), optional test references, and the verification phase (
bootif produced by the boot self-test,hot_pathif produced by an observation of a real SDK operation). The payload does not contain any end-user identifier, email address, free-form text, exception message, or stack trace. The contents are locked by a contract published at github.com/VistaApps-za/crossdeck/tree/main/contracts and enforced by automated tests on every SDK release.Envelope: as with any HTTP request, the transmission carries network-layer metadata: the requesting IP address and the SDK's User-Agent header. Crossdeck minimises its handling of this metadata: the IP is truncated to network prefix (/24 for IPv4, /48 for IPv6) before any application-level logging, the User-Agent is read for SDK-version validation then discarded, no geolocation is derived, and operational logs are retained for 7 days for anti-abuse purposes only.
Lawful basis: Crossdeck's legitimate interest under GDPR Article 6(1)(f) and the equivalent grounds in other regimes that apply to you, balanced against the minimal footprint of the transmission and the no-payload-personal-data guarantee.
Your rights: for data Crossdeck holds about you as an independent controller for this telemetry, contact Crossdeck directly at [email protected]. The full framework is described at cross-deck.com/legal/privacy/#sdk-diagnostic.
Opt-out mechanism
Your privacy policy should describe how the user can opt out of
Crossdeck analytics. The SDK exposes setConsent()
on every platform; the user-facing surface is your responsibility.
A common pattern is a toggle in your account settings (or a
cookie-banner option for web). Suggested copy:
Opting out of analytics and error monitoring. You may opt out of analytics and error monitoring at any time from the [Privacy] section of your account settings. Opting out flips a consent flag the Crossdeck SDK reads on every event — once flipped, no further analytics or error events are transmitted to Crossdeck on your behalf, and any locally queued events are discarded. Note that opting out does not prevent the narrow SDK diagnostic telemetry described in [link to the diagnostic-telemetry section] from being sent, because that telemetry contains no personal data of yours and is necessary for the SDK's operational reliability.
Code reference for the setConsent() calls is at
cross-deck.com/docs/track-events.
Per-category breakdown to reference
If your privacy policy enumerates data categories in a table, cite the Crossdeck-collected categories as follows. The full per-event breakdown lives at cross-deck.com/legal/sdk-data.
- Identifiers: anonymous device IDs we assign, the user ID we assign once you sign in, email address where you have supplied it.
- Internet activity: the pages you view in our service, the buttons you press, session start and end events, the referring URL when you arrive.
- Commercial information: purchases, subscriptions, refunds, entitlements unlocked.
- Device information: browser / operating system / device class, locale, timezone, application version.
- Geolocation (approximate): country derived from IP address at our service edge.
- Inferences: drawn from the above for product-analytics purposes (cohort assignment, session attribution); never sold or shared for advertising.