2v2

Data Inventory

Last updated: June 27, 2026

About This Inventory

This inventory describes what 2v2 collects, why it is collected, where it is stored, who can access it, and how long it is retained. For the full privacy statement, see our Privacy Policy. For location-specific detail, see the Location Data Disclosure. For account and data deletion procedures, see Account and Data Deletion.

Where implementation does not yet enforce exact deletion timelines, this inventory says so rather than stating a deadline that is not yet implemented.

Account and Profile Data

Collected: Display name, home area, profile photo URL, account status, date of birth, activity interests, skill comfort preference, availability preferences, user role, account timestamps.
Why: Operate your account, display your profile to challenge participants, enforce the 18+ age requirement, support moderation and role-based access.
Stored: Supabase database (public.profiles). Profile photos stored in Supabase storage bucket (profile-avatars).
Access: You can read and update your own profile. Other authenticated users see your display name, home area, activity interests, and avatar in challenges you participate in. Moderators and admins can access profiles for trust and safety review. Row-level security (RLS) enforces access.
Retained: Retained while your account is active. After deletion is requested, retained for a period to support dispute resolution and legal obligations. Exact deletion timelines are covered separately.
Notes: Date of birth is used for age verification only and is not shown to other users.

Authentication Data

Collected: Email address, password hash, auth session tokens.
Why: Create and secure your account, verify your identity, maintain your login session.
Stored: Supabase Auth (auth.users table and session management). Not in the public profiles table.
Access: You can update your email and password through account settings. 2v2 does not have direct access to password hashes. Supabase processes authentication data under its own privacy and security policies.
Retained: Retained while your account exists. Deleted when your account is removed.
Notes: Passwords are stored as hashed credentials, not in plain text. Your email is not visible to other users.

Challenge Data

Collected: Challenge title, description, category, format, rules, skill level, participant limit, visibility setting, status, scheduled time, cancellation or completion data. Venue: location name, neighborhood, city, geocoded latitude and longitude.
Why: Display challenges to participants, power the discovery feed, connect hosts with participants, record challenge outcomes, support dispute resolution and moderation.
Stored: Supabase database (public.challenges). Venue coordinates stored in the same row as text fields.
Access: Public challenges are readable by any authenticated user. Private challenges by the host and invited participants. Moderators and admins can access all challenge data. RLS enforces access.
Retained: Retained while the challenge record exists. After host account deletion, records may be retained for dispute resolution. Exact timelines are covered separately.
Notes: Venue coordinates are geocoded from location text entered by the host, not the host's device GPS.

Participation Data

Collected: Participation records: challenge ID, user ID, status (joined / left / removed), join and leave timestamps. Participant removal records: challenge ID, removed participant, removing host, reason, details. Challenge invites and invite grants.
Why: Track who is in each challenge, enforce participant limits and leave deadlines, record host removals, support dispute resolution, power participant notifications.
Stored: Supabase database (public.participations, public.participant_removals, public.challenge_invites, public.challenge_invite_grants).
Access: You can read your own participation records. Hosts can read records for their challenges. Hosts and removed participants can read removal records. Moderators and admins can access all participation and removal data. RLS enforces access.
Retained: Retained while the challenge record or your account is active. Exact deletion timelines are covered separately.
Notes: Removal reasons are stored and accessible to moderators. Direct INSERT on participations is revoked; joins go through backend RPCs.

Location Data

Collected: Discovery area: area name (manual mode) or approximate GPS coordinates (GPS mode) stored on your device. Challenge venue: location name, neighborhood, city, geocoded coordinates stored server-side. Location snapshots: venue details and coordinates stored in reports for location concerns.
Why: Show challenges near you in the discovery feed, display venue details to joined participants, support moderation review of location reports.
Stored: Discovery location: on-device only (not stored server-side). Venue location: Supabase database (public.challenges). Location snapshots: Supabase database (public.reports).
Access: Your discovery location is not stored as a server-side user record. Venue neighborhood and city are visible to all users. Full venue name is visible only to joined participants and the host. Venue coordinates are not shown to users. Moderators and admins can view location snapshots in reports.
Retained: Discovery location: cleared when you switch to manual mode or uninstall the app. Venue location: retained with the challenge record. Location snapshots: retained with the report record.
Notes: 2v2 requests foreground location access only, at balanced accuracy. See the Location Data Disclosure for full detail.

Reports and Safety Data

Collected: Reporter account ID, reported user ID or challenge ID, report type (user / challenge / location), reason, optional details, report status, priority, location snapshot (for location reports).
Why: Review safety concerns, enforce community guidelines, support moderator decisions, prevent abuse, maintain a record of safety actions.
Stored: Supabase database (public.reports).
Access: You can read reports you submitted. Moderators and admins can access all reports. Reported users cannot read reports filed about them. RLS enforces access.
Retained: Retained for the lifetime of the report record. Exact deletion timelines are not yet defined.
Notes: In-app reports are not a substitute for emergency services. Contact local emergency services for immediate danger.

Moderation and Audit Data

Collected: Moderation queue items: status, severity, assigned reviewer, lock state, timestamps. Moderator actions: actor, action type, target user, reason, metadata. Audit log entries: actor, action, entity type, entity ID, metadata. Content moderation flags.
Why: Track moderator review decisions, maintain accountability for moderation actions, support appeal review, detect abuse patterns, preserve audit records.
Stored: Supabase database (public.moderation_review_queue, public.moderation_actions, public.audit_logs, public.content_moderation_flags).
Access: Moderators and admins can access moderation queue and action data. Regular users cannot read moderation records directly. Users can access their moderation history through appeals. Moderator role is required for most operations.
Retained: Retained for the lifetime of the moderation records. Exact deletion timelines are not yet defined.
Notes: Audit logs are append-only. This data is not visible to regular users.

Appeals

Collected: Your account ID, the queue item or moderation action being appealed, appeal reason, optional details, appeal status, reviewer notes, reviewer account ID, review timestamp.
Why: Allow users to contest moderation decisions, support fair review of appeals, maintain a record of appeal outcomes.
Stored: Supabase database (public.appeals).
Access: You can read your own appeal records. Moderators and admins can access all appeals. Direct INSERT and UPDATE are revoked; appeals are submitted through backend RPCs. RLS enforces access.
Retained: Retained for the lifetime of the appeal record. Exact deletion timelines are not yet defined.
Notes: Appeals can be submitted from the Profile section or by emailing support@2-v2.com.

Blocks

Collected: Your account ID, the account you blocked, optional reason, block timestamp.
Why: Prevent blocked users from contacting or joining challenges with you, support safety controls, enforce join restrictions.
Stored: Supabase database (public.blocks).
Access: You can read blocks you created. The account you blocked cannot see that they are blocked. Moderators and admins can access block data for trust and safety review. RLS enforces access.
Retained: Retained until you unblock the user or your account is deleted. Exact post-deletion timelines are covered separately.
Notes: Blocking a user does not remove them from a challenge they have already joined.

Support Contact Data

Collected: Emails sent to support@2-v2.com: email address, message content, and any context you include. Data export requests submitted in the app are tracked in the database.
Why: Respond to support requests, account help, appeals, and safety concerns. Track data export request status.
Stored: Support emails: handled through standard email infrastructure, not stored in the 2v2 database. Data export requests: Supabase database (public.data_export_requests).
Access: 2v2 team members with email access can read support emails. Data export request status is readable by the user who submitted it.
Retained: Support emails: retained per standard email practices, not in the 2v2 database. Data export request records: retained while the account is active.
Notes: Support is email-based only. If a future in-app support ticket system is added, this inventory will be updated. Data export fulfillment is not yet automated.

Device, App, and Diagnostics Data

Collected: Device type and model, operating system version, app version, error and crash data, sanitized app session breadcrumbs (console breadcrumbs filtered), Sentry event metadata. In-app notification records: type, title, body, read status, timestamps.
Why: Diagnose errors and crashes, monitor app stability, improve the app, deliver in-app challenge notifications and reminders.
Stored: Error and crash data: Sentry (third-party service). In-app notifications: Supabase database (public.notifications).
Access: 2v2 team members with Sentry access can review error reports. Sentry processes data under its own privacy and security policies. You can read your own in-app notification records.
Retained: Sentry data: governed by Sentry's own retention policies. In-app notifications: retained while your account is active.
Notes: We do not collect device advertising identifiers. Push notification tokens are not currently stored.

Local Device Storage

Collected: Selected area name, location mode status, GPS coordinates (when GPS mode is active), onboarding state flags.
Why: Persist your location preference and app state between sessions without a server round-trip.
Stored: On your device only (AsyncStorage). Keys: 2v2:selectedArea, 2v2:locationStatus, 2v2:selectedLatitude, 2v2:selectedLongitude, 2v2:onboardingIntroDismissed, 2v2:onboardingLocationPrompted. Not transmitted to 2v2 servers as a user record.
Access: Only the 2v2 app on your device. 2v2 servers do not store or access this data as a user record.
Retained: Cleared when you change settings, switch area mode, or uninstall the app.
Notes: GPS coordinates stored locally may be at a higher precision than the balanced accuracy level requested from the device.

Data Not Currently Collected

2v2 does not currently collect:

Push notification tokens: notifications are in-app database rows. External push delivery is not implemented.
Payment or subscription data: no paid features exist yet.
Ratings or reviews: deferred to a future release.
Background location: foreground access only.
Advertising identifiers: no IDFA, GAID, or equivalent.
Detailed behavioral analytics: beyond Sentry error and crash reports.

If any of these are added, this inventory and the Privacy Policy will be updated.

Contact

For questions about this data inventory or your personal information, contact support@2-v2.com.