bGuru

bGuru Cookie & Ad-Tech Policy

Version 0.1.8published

Last updated: 2026-06-02

§0 Plain-language summary

bGuru is built to do the bare minimum tracking. What tracking we actually use: essential cookies on the mini-site, a push token (only if you opt in), crash reporting (Sentry, EU region), and non-personalized contextual ads via Google AdMob.

About the ads: we show non-personalized ads inside the mobile app. These are non-personalized contextual ads served through Google AdMob — they are based on the app you are using (sports content), not on a profile of you. bGuru does not request IDFA or pass GAID to AdMob, and configures all AdMob requests for non-personalized ads. We do not build a behavioral profile of you for advertising. Gambling, sportsbook, casino, and fantasy-sports ad categories are blocked at the Google AdMob console and monitored through bGuru's internal kill-switch process. A remote kill-switch lets us disable all ads from the admin panel if a prohibited ad ever slips through.

What we never do: no cross-app tracking, no behavioral analytics, no IDFA or GAID read, no profiling-based ads to anyone, no behavioral ads to users under 18 at any version.

If you're in the EU, UK, or Israel, our mini-site shows a consent banner where you can accept or reject non-essential cookies. The "Reject all" button is as prominent as the "Accept all" button on the first layer (no dark patterns). No ATT prompt is shown because no IDFA is read in NPA mode.

If personalized advertising is introduced in a future version (switching from NPA to behavioral mode), we will: (a) update this Policy via the 30-day material-change notice flow, (b) add the Apple ATT prompt, (c) add a "Do Not Sell or Share My Personal Information" link for US users, (d) honour the Global Privacy Control (GPC) signal, (e) wire a registered IAB TCF v2.2 CMP (Google UMP) for EU/UK users — BEFORE any personalized ad serves.

§1 Definitions

  • Cookie — a small data file stored by your browser when you visit a website (the bGuru mini-site at bguru.app). The mobile app does not use cookies; it uses tokens.
  • Identifier — any data point that uniquely tags a device or session (a session JWT, OneSignal player_id, Sentry session ID, IDFA, GAID, IDFV, etc.). Identifiers are the mobile-app equivalent of cookies.
  • Strictly necessary — cookies or identifiers without which the Service cannot function as you requested (e.g., authentication session). No consent required under PECR reg. 6(4) (UK), ePrivacy Directive Art. 5(3) (EU), or PPL equivalents (IL).
  • Functional / analytics / advertising — cookies or identifiers that improve, measure, or monetise the Service but are not strictly necessary. Consent required under PECR, ePrivacy, and most equivalent regimes.
  • NPA (Non-Personalized Ads) — an advertising mode in which the ad server (Google AdMob) does not use behavioral data, device identifiers (IDFA/GAID), or a user profile to select ads. Instead, ads are matched to the app's content category (contextual targeting). No interest graph is built. No cross-app tracking occurs. bGuru enforces NPA mode at every ad request via the npa=1 request parameter.
  • Contextual advertising — ads matched to the content or sport being viewed, without using any personal identifier or behavioral history. Distinct from "behavioral" or "interest-based" advertising, which relies on profiling.
  • CMP (Consent Management Platform) — software that collects, records, and signals your cookie choices to bGuru and any third-party sub-processors. At this version of the Service, bGuru uses a bespoke first-party consent banner (no third-party CMP SDK) — see §4.1. We believe this is sufficient at NPA-only mode because bGuru does not pass any behavioral identifier from the user's device to AdMob, so we do not believe ePrivacy Art. 5(3) consent is triggered for the ad serving itself at this version; we will reassess before any personalized advertising activation. If and when bGuru introduces personalized advertising, the consent architecture will be upgraded to a registered IAB TCF v2.2 CMP (Google UMP) before any personalized ad serves.
  • IAB TCF v2.2 — the Interactive Advertising Bureau Europe Transparency and Consent Framework version 2.2, the industry standard for capturing and signalling EU/UK cookie consent in a machine-readable format. bGuru does not implement IAB TCF v2.2 at this version of the Service because NPA mode does not require signalling consent to behavioral advertising vendors — there are none; see §4.1 for detail.
  • GPC (Global Privacy Control) — a browser-level signal indicating a consumer's universal opt-out of sale/sharing of personal information. Required to be honoured under CPRA (CA), CPA (CO), and certain other US state laws.
  • ATT (App Tracking Transparency) — Apple's framework requiring an explicit user grant before an iOS app may read the device IDFA (Identifier for Advertisers).
  • IDFA / GAID / IDFV — Apple Identifier for Advertisers / Google Advertising ID / Apple Identifier for Vendor (vendor-scoped, no third-party access). bGuru reads NONE of these at MVP.

Cross-reference: see Privacy Policy, §1 Definitions, for terms used in both documents.

§2 Cookies and similar technologies we use

§2.1 Mini-site cookies (bguru.app) — at MVP

At MVP, bGuru's mini-site uses only strictly necessary cookies. No analytics cookies. No advertising cookies. No fingerprinting.

Cookie / identifier Set by Purpose Retention Consent required?
__cf_bm, cf_clearance Cloudflare (CDN + bot-detection) Distinguish human visitors from automated bots; required for DDoS protection and basic availability Session / up to 30 min / up to 24 hours No — strictly necessary; PECR reg. 6(4) + ePrivacy Art. 5(3) exemptions apply
Session JWT (sb-* if served via cookie) bGuru (first-party) Maintains your login state Session; cleared on sign-out No — strictly necessary
bg_consent (consent-state cookie) bGuru (first-party) Records your cookie choice (accepted or rejected) so the banner is not re-shown on every page load 6 months No — strictly necessary (per EDPB Guidelines 05/2020 §93; ICO 2024 cookie guidance)
CSRF token bGuru (first-party) Prevents cross-site request forgery Session No — strictly necessary
Language preference (if implemented) bGuru (first-party) Stores your preferred display language 12 months Yes — functional (opt-in required)
Analytics / performance NONE at MVP bGuru does not use Google Analytics, Plausible, Matomo, or any analytics SDK — —
Advertising / targeting NONE at MVP bGuru does not use any ad-network or retargeting cookie — —

Why the consent-state cookie is strictly necessary. Without it, you would be asked for cookie preferences on every page load — recording your choice is an integral part of giving effect to that choice. The EDPB Guidelines 05/2020 on consent §93 and the ICO's 2023 cookie report both confirm this analysis.

Per-jurisdiction classification:

  • EU/EEA (ePrivacy Directive Art. 5(3) + GDPR). All four "strictly necessary" cookies above qualify for the Art. 5(3) exemption (the Service is technically unavailable without the bot-detection cookie; cannot function in an authenticated state without the session cookie; cannot honour your consent choice without the consent-state cookie; cannot prevent CSRF attacks without the CSRF token). Per-MS divergences: Germany TDDDG §25 (renamed from TTDSG, May 2024) requires reject-as-prominent-as-accept on the first layer; Italy Garante 2021 provvedimento requires the same; France CNIL délibération 2020-091 requires "Refuser tout" in one click (France is a deferred market at MVP); Belgium APD-GBA engagement-as-consideration WATCH (Belgium is a deferred market at MVP).
  • United Kingdom (PECR reg. 6). Same exemption applies (reg. 6(4) — strictly necessary for a service explicitly requested by the user). ICO 2024 cookie-banner design guidance requires reject-as-prominent-as-accept. Crown Dependencies (Isle of Man, Jersey, Guernsey, Gibraltar) apply materially equivalent regimes; bGuru's MVP strictly-necessary-only posture satisfies all four.
  • Israel (PPL Amendment 13 + Communications Law §30A). Israel has no standalone cookie law; cookie obligations arise from the PPL's general consent + lawful-basis framework + the §30A opt-in rule for marketing identifiers. Strictly necessary cookies that do not store personally identifying information fall outside PPL scope; cookies linked to an authenticated user record fall within the contract-performance lawful basis. No Israeli-specific cookie banner is required; the first-party consent banner shown to EU/UK visitors equally satisfies PPL transparency obligations for Israeli visitors. The PPA's 2024 guidance is consistent.
  • United States (no federal cookie law). No federal-level cookie consent statute exists. State laws (CCPA/CPRA, VCDPA, CPA, CTDPA, etc.) treat cookies that collect personal information as personal-data processing subject to general transparency obligations. bGuru's strictly-necessary-only posture creates no current opt-out trigger; see §8 for state-level rights detail.

§2.2 Mobile app — no cookies; identifier inventory

The bGuru mobile app does not use cookies. It uses tokens (JWT) and identifiers, all classified below:

Identifier Purpose Lawful basis Retention
Supabase Auth JWT Authenticates your requests Contract performance Lifespan controlled by Supabase Auth; rotates on sign-out
OneSignal player_id Push notification subscription Consent (explicit opt-in via system permission prompt) Until you revoke push permission or account deletion completes
Sentry session identifier Crash reporting + performance monitoring (anonymised; no email or display name per §3.1 of Privacy Policy) Legitimate interest (EU/UK/IL) 30 days
Apple IDFV (Identifier for Vendor) Vendor-scoped, not third-party readable — used by OS; not actively read by bGuru code N/A (OS-level) Persistent for app install
Apple IDFA (Identifier for Advertisers) NOT requested at this version of the Service. bGuru does not request IDFA access; AdMob is configured for non-personalized ads (npa=1) only. No ATT prompt is shown because no IDFA read is requested. N/A —
Google GAID (Advertising ID) NOT passed to AdMob at this version of the Service. bGuru configures all AdMob requests with npa=1 and does not pass GAID to AdMob. N/A —

§3 How our advertising works at this version of the Service

bGuru shows non-personalized contextual ads inside the mobile app, served by Google AdMob in NPA (non-personalized ads) mode.

What "NPA mode" means for you:

  • Ads are chosen based on the app's content category (sports, predictions) — not on a profile of you.
  • Google does not read your Apple IDFA or Android GAID to select ads.
  • No interest graph or behavioral profile is built about you for advertising.
  • No cross-app tracking occurs.
  • No targeting based on your prediction history, group memberships, or leaderboard position.

Ad formats at this version: banner ads on certain screens; possibly an interstitial on certain navigation transitions. Frequency capped. Tapping an ad opens the advertiser's URL in an in-app browser. No video, playable, or native feed ads at MVP.

Gambling-category block: The following ad categories are blocked at the Google AdMob console and monitored through bGuru's internal kill-switch process: gambling, sports betting, casino, fantasy sports (paid entry), prediction markets with monetary stakes, lottery, binary options, crypto trading with leverage, and adjacent high-risk categories (payday lending, adult content). A remote kill-switch in the admin panel lets us disable all ads instantly if a prohibited ad ever slips through.

What we still do NOT use at this version:

  • No behavioral analytics SDK. No Mixpanel, no Amplitude, no PostHog, no Heap, no Segment-based analytics pipeline.
  • No retargeting / remarketing pixels. No Meta Pixel, no Google Ads conversion pixel.
  • No conversion-tracking / attribution SDK. No AppsFlyer, no Adjust, no Branch, no Singular, no Kochava.
  • No cross-app tracking via IDFA. bGuru does not request IDFA access and configures AdMob requests for non-personalized ads (npa=1); an ATT prompt is not currently triggered.
  • No cross-app tracking via GAID. bGuru does not pass GAID to AdMob and configures AdMob requests for non-personalized ads (npa=1).
  • No fingerprinting. No canvas, audio, font, hardware, or network-level fingerprinting.
  • No programmatic header bidding, no IAB TCF v2.2 vendor list integration — NPA mode routes only through Google's own ad inventory; no OpenRTB auction with third-party DSPs occurs at NPA-only mode.
  • No interest-based audience segments. No retargeting lists built from bGuru user data.

If personalized advertising is introduced in a future version, this Policy will be amended via the §9 material-change notice flow — including the addition of an ATT prompt, a registered IAB TCF v2.2 CMP (Google UMP), GPC honouring, and a "Do Not Sell or Share" link — all BEFORE any personalized ad serves.

§4 Your consent and the cookie banner

§4.1 EU/EEA + UK users — opt-in consent

bGuru's mini-site shows a first-party consent banner served directly from bguru.app to all EU/EEA and UK visitors. The banner is implemented as a bespoke first-party component — no third-party CMP SDK (such as Google UMP) is loaded at MVP. It records your choice in a single first-party cookie (bg_consent, values accepted or rejected, max-age 6 months, SameSite=Lax, host-only on bguru.app). Until you have clicked a button, no non-essential cookies are set and no third-party scripts are loaded. The banner is structured to satisfy ePrivacy Directive Art. 5(3) (EU/EEA) and PECR reg. 6 (UK) simultaneously.

Note on IAB TCF v2.2 and NPA mode. bGuru does not implement the IAB TCF v2.2 framework at this version of the Service. The reason is specific: bGuru does not use behavioral advertising or pass any behavioral identifier from the user's device to AdMob — we do not believe ePrivacy Art. 5(3) consent is triggered for the ad serving itself at this version, and there are no behavioral advertising vendors to whom consent must be signalled via the TCF. We will reassess this posture before enabling any personalized advertising, additional ad vendors, or ad-tech features that require consent. The bespoke first-party consent banner remains in place and is sufficient for the strictly-necessary-cookies disclosure that is its primary function. If/when personalized advertising is introduced, the consent architecture will be upgraded to a registered IAB TCF v2.2 CMP (Google UMP) before any personalized ad serves — as stated in §3 and §9 of this Policy. If platform policy, Google policy, or applicable local law requires consent for any non-personalized ad delivery, measurement, frequency-capping, or related storage/access operation in a launch market, bGuru will adjust the consent flow or disable ads in that market.

Consent standard (ePrivacy + GDPR Art. 7 / PECR + UK GDPR Art. 7). Consent must be freely given, specific, informed, unambiguous, and as easy to withdraw as to give. Pre-ticked boxes are NOT valid consent (CJEU C-673/17 Planet49, ICO confirmation). Continued-browsing is NOT consent. Cookie walls (conditioning access on cookie acceptance) are unlawful (EDPB Opinion 5/2019; confirmed by BfDI, Garante, AEPD, ICO).

Banner design constraints (non-negotiable):

  • "Reject all" must be at the same visual prominence as "Accept all" on the first layer (ICO 2024 + EDPB Guidelines + NOYB 700+ complaints since 2022).
  • No colour, size, or positioning steering toward acceptance.
  • No "I understand" mapped to acceptance.
  • No multi-click reject path while accept is one-click.
  • Granular consent per category (functional / analytics / advertising — at MVP all three are empty buckets).
  • Withdrawable at any time via the "Cookie preferences" link in the mini-site footer.

Per-member-state enforcement landscape (EU/EEA — at MVP scope):

  • Germany — TDDDG §25 (renamed from TTDSG, May 2024). Strictest national enforcement in the EU. Max administrative fine €300,000 per violation under TDDDG (in addition to GDPR fines).
  • Italy — Garante 2021 provvedimento + 2023 enforcement. Active enforcement against small-to-medium operators, not only large platforms.
  • Ireland — DPC. Lead supervisory authority for several of bGuru's US sub-processors (OneSignal, Cloudflare).
  • Spain — AEPD Circular 1/2022. Reject = 1 click on the first layer. €250M+ cumulative cookie-related fines in 2024.
  • Netherlands — Autoriteit Persoonsgegevens. Cookie walls unlawful.

United Kingdom — PECR + UK GDPR. ICO 2024 cookie-banner guidance applies. PECR's reg. 6(4) "strictly necessary" exemption is interpreted narrowly. The TikTok £12.7M fine (2023) for children's data confirms ICO willingness to fine substantial sums.

Crown Dependencies. Each Crown Dependency (Isle of Man, Jersey, Guernsey, Gibraltar) applies materially equivalent regimes. bGuru's strictly-necessary-only MVP posture satisfies all of them without modification.

§4.2 Israel — opt-in consent for marketing identifiers (PPL + Communications Law §30A)

Israel has no standalone cookie law equivalent to ePrivacy. Cookie obligations arise from two overlapping sources: (a) the PPL Amendment 13 consent + lawful-basis framework, treating cookies linked to identifiable information as personal data; and (b) Communications Law §30A (the 2008 Spam Amendment), which imposes opt-in consent for marketing communications via electronic means — including push-notification marketing where the device identifier is treated as the operative addressee.

For Israeli visitors: the first-party consent banner shown to EU/UK visitors equally satisfies PPL transparency obligations. No Israeli-specific banner is required. For push notifications (OneSignal player_id), bGuru's existing explicit-opt-in soft-prompt + system-permission-prompt architecture satisfies both PPL consent and §30A opt-in standards.

Important framing note: Israel's standard is opt-in, the same substantive standard as EU ePrivacy — NOT implied consent. Earlier industry guides that classified Israel as an "implied consent" jurisdiction are outdated (pre-Amendment 13).

§4.3 Rest of world — notice + general data-protection consent posture

For visitors outside the EU/EEA, UK, and Israel, the first-party consent banner functions as a transparency-and-notice mechanism that satisfies general data-protection-law obligations across the rest-of-world portfolio:

  • Australia (Privacy Act 1988, APP 5). Notification-of-collection requirement; consent banner + Privacy Policy satisfy. APP 7 direct-marketing opt-out for push notifications satisfied by Settings → Notifications. eSafety Commissioner Basic Online Safety Expectations 2022 (BOSE) compliance via minimal-tracking posture.
  • Japan (APPI + PPC 2022 guidance). Cookies linked to identified individuals are personal information. APPI Art. 27 cross-border transfer disclosure (Cloudflare US + OneSignal US) made via the consent banner link to Privacy Policy §6.
  • South Korea (PIPA + IT Network Act). Strictest opt-in regime in Asia. Bundled consent invalid (PIPA Art. 22). Push notifications: explicit opt-in via system prompt satisfies the IT Network Act marketing-opt-in standard.
  • Singapore (PDPA Part III). Notification Obligation 4 satisfied via consent banner + Privacy Policy. DPO contact = legal@bguru.app.
  • New Zealand (Privacy Act 2020, IPP 3). Collection-notice requirement satisfied by consent banner.
  • South Africa (POPIA s. 18 + s. 69). Notification obligation satisfied; direct-marketing opt-in for push satisfied by system prompt. POPIA s. 35 under-18 parental-consent gap for 16-17 users noted as a calibrated risk acceptance per Privacy Policy §9.4.
  • UAE (UAE PDPL + DIFC DPL 2020 + ADGM DPR 2021). Federal PDPL notification satisfied. DIFC/ADGM use GDPR-aligned standards; bGuru's strictly-necessary-only posture satisfies.
  • Mexico (LFPDPPP). Aviso de privacidad obligation satisfied by consent banner + Privacy Policy.
  • Other LATAM (AR / CL / CO / PE). General notice + transparency obligations satisfied; no LATAM-specific opt-in for non-essential cookies at MVP (none deployed).
  • Other MENA (SA / EG / MA / QA / KW). General notice + transparency obligations satisfied.
  • Switzerland (revFADP Art. 45c). Device-storage consent equivalent to ePrivacy Art. 5(3); strictly-necessary-only posture satisfies.

Deferred markets (Canada, France, Belgium, Brazil, India): these markets are not available at MVP. The v1.1 expansion (FR-CA + FR-FR + NL/Flemish + DE/Belgian + LGPD/DPDP work) will include re-evaluation of cookie-banner obligations for each market before it opens.

§5 Apple App Tracking Transparency (ATT)

ATT is Apple's framework requiring an explicit user grant before an iOS app may read the device IDFA (Identifier for Advertisers). The IDFA is the primary cross-app advertising identifier on iOS.

bGuru's current posture: NO ATT prompt at this version of the Service. bGuru does not request IDFA, so an ATT prompt is not currently triggered. bGuru configures AdMob for non-personalized ads only (npa=1) and deliberately does not request IDFA access — not displaying an unnecessary tracking prompt is the cleanest user-trust posture and aligns with Apple's "minimum data collection" preference. If we ever introduce features that require IDFA access, we will surface an ATT prompt before any read.

On Android, the equivalent identifier is the Google Advertising ID (GAID); bGuru does not read GAID at this version of the Service.

What changes if personalized advertising is introduced (a future version, requiring a separate decision and 30-day notice). In this exact order, BEFORE any personalized ad serves:

  1. ATT prompt string written (NSUserTrackingUsageDescription in Info.plist), approved for clarity per Apple's guidance, and added to App Store Connect privacy-nutrition-label declaration.
  2. ATT prompt displayed BEFORE the ad SDK is initialised in personalized mode. If the user denies, IDFA is all-zeros, no cross-app tracking occurs, the app continues to function normally (App Store Review Guideline 5.1.2(iv) prohibits degrading functionality on ATT denial).
  3. CCPA/CPRA "Do Not Sell or Share" link + GPC-signal honouring activated in the same release. IDFA-based ad integration constitutes a "share for cross-context behavioural advertising" under Cal. Civ. Code § 1798.140(ah). These requirements are NOT triggered by NPA mode (see §3 and the Privacy Policy §5).
  4. This Policy updated via the §9 material-change notice flow before activation.
  5. Google UMP (IAB TCF v2.2 registered CMP) wired to replace the bespoke first-party banner for advertising consent for EU/EEA and UK users.

Under-18 ATT gate (engineering constraint). When ATT activates, bGuru will not request IDFA access from any account that has self-reported being 16 or 17 at registration. This satisfies California SB-976 (KOSMA) and Maryland MODPA prohibitions on processing under-18 personal data for advertising.

§6 Sub-processor tracking and identifiers

Each sub-processor that touches user-identifiable data is listed below. Full DPA links + data-residency details are at bguru.app/legal/subprocessors.

Sub-processor Identifier / cookie Lawful basis Data residency
Supabase (Frankfurt) Session JWT (sb-*) Contract performance EU (no cross-border transfer for EU/UK/IL users)
OneSignal (US) player_id + push token Consent US (SCCs + DPF for EU/UK; PPL DPA-equivalent for IL)
Sentry (EU region) Anonymised session ID + crash trace Legitimate interest EU (no cross-border transfer for EU/UK/IL users)
Google LLC (AdMob) — NPA mode only Ad-impression metadata (slot, timing — anonymous, no user ID linked); rough geolocation (country/region, inferred from IP by AdMob); app context (content category). bGuru does not pass to AdMob: IDFA, GAID, bGuru account ID, email, display name, Picks, group memberships, behavioral profile, or cross-app history. Legitimate interest (NPA contextual ads; no behavioral profiling; we believe ePrivacy Art. 5(3) consent is not triggered at NPA-only mode — we will reassess before any personalized advertising activation) Google global infrastructure. Transfer mechanism: Google's Standard DPA + EU-US Data Privacy Framework (DPF) certification + SCCs as contractual backstop for EU/UK. Google DPA: policies.google.com/privacy/frameworks.
Cloudflare (US-based CDN + global edge) __cf_bm + cf_clearance bot-detection Strictly necessary (PECR reg. 6(4) + ePrivacy Art. 5(3)) Global edge; SCCs + DPF for EU/UK; PPL DPA-equivalent for IL
Apple / Google OS-level telemetry; Apple ID / Google account Platform-tier processor relationship Worldwide; controlled by Apple/Google's own privacy policies
API-Football NONE — server-side only N/A France (API-Football's servers); no user PII transmitted

§7 Children and ad-tech

bGuru's 16+ flat minimum age (per Terms of Service, §3 Age eligibility, and Privacy Policy, §9 Children's data) means no users under 16 should be present on the platform. For users aged 16–17 (who are still minors under most jurisdictions' civil law), bGuru applies a blanket no-behavioural-targeting policy globally:

  • (a) Behavioural and profiling-based advertising (IDFA, GAID, advertising cookies, fingerprinting, interest-graph targeting) will never be applied to any user under 18, across any version of the Service. This is a permanent commitment — bGuru will not serve behavioural advertising to under-18 users regardless of what advertising model ships in future versions. This commitment reflects mandatory obligations under DSA Art. 28, the ICO Children's Code, KOSMA, MODPA, and equivalent regimes, and bGuru adopts it as a product design principle independent of those obligations.
  • (b) Contextual non-personalized advertising (AdMob NPA mode) does appear to users under 18 at this version of the Service. For users registered as 16 or 17, bGuru applies Google's current age-restricted ad-treatment settings available in the Google Mobile Ads SDK. These settings: (i) confirm to Google that the request comes from an app used by a child; (ii) cause Google to serve only COPPA-compliant non-personalized ads; (iii) ensure IDFA and GAID are not read for those users; (iv) apply Google's own additional protections for child-directed ad requests. Gambling-adjacent, adult-content, alcohol (where user is under 18), and payday-lending ad categories are blocked at the Google AdMob console and monitored through bGuru's kill-switch regardless of the age-restricted ad-treatment settings. The net result: users aged 16–17 see contextual sports-content ads with no profiling, no IDFA/GAID read, and with Google's child-directed ad protections active.
  • No algorithmically-personalised content feed served to users under 18 (not applicable at MVP — no such feed exists).
  • No push notifications for marketing purposes to users under 18 (only transactional notifications — prediction resolution, group invite — sent pursuant to explicit opt-in).
  • Data collected from under-18 users strictly limited to what is necessary to provide the core Service.

United Kingdom (ICO Age Appropriate Design Code — Children's Code). The Children's Code applies to any service likely to be accessed by users under 18, regardless of the sign-up age. bGuru applies the Code's 15 design standards to users aged 16–17: Standard 4 (data sharing) — only strictly-necessary sub-processors; Standard 5 (geolocation) — city-level only, never precise; Standard 8 (profiling) — off by default; Standard 9 (nudge techniques) — banner reject-as-prominent-as-accept design standard applied. Recent ICO enforcement (TikTok £12.7M, 2023) confirms the standard is live.

United States — state minor-data laws.

  • California KOSMA (Cal. Civ. Code § 1798.99.29 et seq., effective Jan 2025). Prohibits algorithmic addictive feeds to under-18 users without parental consent; restricts push notifications to under-18s without time-of-day controls and consent; restricts data collection of under-18s for addictive-design purposes. bGuru does NOT operate an algorithmic feed and applies the blanket no-behavioural-targeting-of-under-18s policy — substantively compliant. Re-evaluate before any algorithmic-feed feature ships.
  • New York SAFE for Kids Act (N.Y. Soc. Serv. Law § 496-a, 2024). Same analysis: not currently in scope (no algorithmic feed). Re-evaluate on feed activation.
  • Maryland MODPA (Md. Code Com. Law § 14-4604(c), effective Oct 2025). Prohibits processing under-18 data for targeted advertising, sale, or profiling. bGuru's NPA-only advertising (no profiling, no targeted advertising via IDFA/GAID) combined with Google's age-restricted ad-treatment settings for users registered as 16 or 17 satisfies MODPA's prohibition.
  • Colorado CPA (C.R.S. § 6-1-1306(4)). Same. UOM honouring per § 6-1-1315 applies if/when targeted advertising activates.
  • Florida HB 3 (Fla. Stat. § 501.1736 et seq., 2024). Under-14 ban + under-16 parental consent for "social media platforms" with algorithmic feeds. bGuru's 16+ gate + no algorithmic feed = not currently in scope. Re-evaluate on feed activation.

European Union — DSA Art. 28. Online platforms must implement appropriate and proportionate measures to ensure high privacy, safety, and security for minors. DSA Art. 28(2) prohibits profiling-based advertising to known minors. bGuru satisfies this because: (a) AdMob NPA mode is not profiling-based — no behavioral profile is built for anyone; (b) for users registered as 16 or 17, bGuru applies Google's current age-restricted ad-treatment settings available in the Google Mobile Ads SDK, providing an additional hard enforcement signal to Google's ad-serving systems; (c) the gambling-category block (Google AdMob console + kill-switch) applies to all users. DSA Art. 28 does not prohibit contextual non-profiling ads for minors on its face — it specifically prohibits profiling. If personalized (profiling-based) advertising is ever introduced, the engineering pre-requisite is age-signal-based suppression of behavioural-advertising segments for under-18 users.

Israel. PPL Amendment 13 minor protections + Israeli Consumer Protection Law §4A.5 plain-language obligation. bGuru's 16+ gate + max-protection treatment for 16–17 users + zero ad-tech posture exceeds Israeli legal requirements (Israel has no standalone children's online-design code at MVP).

Rest of world. ZA POPIA s. 35 + UAE PDPL Art. 8 + MX LFPDPPP + LATAM/MENA civil-law minor protections all require parental consent for under-18 processing in their respective regimes. The 16–17 gap is a calibrated risk acceptance documented in Privacy Policy §9.1 + §9.4 (same magnitude as Art. 27 deferral). The v1.1 parental-consent provider integration closes the gap.

§8 Your rights and how to opt out

§8.1 Universal opt-out mechanisms (every jurisdiction)

  • Re-show cookie banner via the "Cookie preferences" link in the mini-site footer (bguru.app)
  • Clear cookies + local storage via your browser's settings
  • Push notifications: Settings → Privacy → Notifications (in-app) OR device system Settings → Notifications → bGuru → Off
  • Account deletion: Settings → Account → Delete account (per Terms of Service, §10 Account deletion)
  • All other rights: email legal@bguru.app with your account email + the right you're exercising

§8.2 Jurisdiction-specific opt-out + regulatory contact

United Kingdom — PECR withdrawal + UK GDPR Art. 21 objection. Withdraw cookie consent via the footer link or by deleting the bGuru consent-state cookie. Object to legitimate-interest processing (Sentry) via email subject "UK Art. 21 Objection". Complaints to the ICO: Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF; casework@ico.org.uk; 0303 123 1113; ico.org.uk/make-a-complaint. Crown Dependencies: Isle of Man Information Commissioner (inforights.im); Jersey Office of the Information Commissioner (jerseyoic.org); Guernsey ODPA (odpa.gg); Gibraltar GRA Data Protection Commissioner (gra.gi).

European Union / EEA — ePrivacy + GDPR Art. 21 objection. Withdraw cookie consent via the footer link (equally easy as giving). Object to legitimate-interest processing (Sentry) via email subject "GDPR Art. 21 objection". Complaints to your member-state DPA — see Privacy Policy, §8.2 Jurisdiction-specific rights for full table. Switzerland: FDPIC (edoeb.admin.ch).

Israel — PPL Amendment 13 + §30A. Withdraw cookie consent via footer link; withdraw push consent via Settings → Notifications. Complaints to the PPA (רשות להגנת הפרטיות): 3 Kaplan Street, Jerusalem 9195020; rmot.regulation@justice.gov.il; gov.il/en/departments/the_privacy_protection_authority. Israeli-resident consumers retain the right to bring proceedings in their local Israeli court per ToS §14.1.

United States — CCPA/CPRA + state-by-state.

  • California: CCPA/CPRA Sale/Share opt-out — NOT currently triggered (bGuru does not sell or share at MVP); pre-activation commitment to add the "Do Not Sell or Share" link and to honour the GPC signal before any ad SDK ships. Complaints to the California Privacy Protection Agency (CPPA) at cppa.ca.gov/complaints.
  • Colorado: CPA Universal Opt-Out Mechanism (UOM) — same pre-activation commitment to honour UOM before any targeted-advertising capability ships. Colorado AG enforces.
  • Virginia, Connecticut, Utah: VCDPA/CTDPA/UCPA opt-out for sale, targeted advertising, profiling — same channel (legal@bguru.app), same posture.
  • Texas TDPSA (elevated AG enforcement): same opt-out rights, same channel.
  • Oregon, Montana, New Jersey, Indiana, Kentucky, Rhode Island, Tennessee, Delaware, Iowa, Nebraska, New Hampshire, Minnesota, Maryland (MODPA): same VCDPA-template opt-out rights; channel legal@bguru.app, 45-day response.
  • New York: SHIELD Act + GBL §349–350 private right of action; no comprehensive privacy law yet enacted. Channel: legal@bguru.app.
  • Florida: FDBR revenue thresholds (>$1B) not met at MVP scale; HB 3 minor-data covered in §7.

US response time: 45 days from verified receipt, with one 45-day extension for complex requests.

Rest of world — opt-out + regulator contact (see Privacy Policy, §8.2 Jurisdiction-specific rights, for full detail):

§9 Changes to this Policy

We may change this Cookie & Ad-Tech Policy from time to time. For material changes — including the addition of any third-party advertising SDK, any IDFA/GAID read, any behavioural-analytics SDK, or any new sub-processor that processes identifiers — we will give you at least 30 days' notice before the change takes effect, via an in-app banner shown the next time you sign in and (where you have provided an email address) by email.

Specific triggers for amendment of this Policy:

  1. Personalized advertising activation (switching from NPA to behavioral/personalized mode — e.g., enabling AdMob personalization, disabling npa=1) → substantial rewrite of this Policy required, plus 30-day material-change notice to all users before any personalized ad serves. ALL of the following pre-conditions must be completed before the first personalized ad serves:

    Engineering pre-conditions:

    • iOS ATT prompt integrated and approved (NSUserTrackingUsageDescription written + App Store Connect privacy-nutrition-label updated; IDFA read gates behind ATT grant — all-zeros on denial; app continues to function normally on denial per App Store Guideline 5.1.2(iv)).
    • Android GAID handling: GAID accessed only if user has not opted out via Android Privacy settings.
    • npa=1 parameter removed from ad requests for users who have granted ATT/consent; retained for users who have denied ATT, rejected consent, or are under 18.
    • Google UMP (User Messaging Platform) wired as the IAB TCF v2.2 registered CMP — replaces the current bespoke first-party consent banner for users in the EU/EEA and UK.
    • Under-18 child-directed-treatment flag continues: users aged 16–17 → child-directed (non-personalised only, npa=1 always); users aged 18+ → personalised-eligible (subject to ATT/GAID/UMP consent). Must be fail-safe: if age is unknown or ambiguous, default to child-directed.
    • "Do Not Sell or Share My Personal Information" link live in the mobile app Settings screen and in the mini-site footer (CCPA/CPRA §1798.120; GPC signal honouring activated in the same release).
    • GPC signal honoured (mobile + mini-site).
    • Apple Privacy Nutrition Label updated: "Data Used to Track You" + "Data Linked to You" fields.
    • Play Store Data Safety section updated.
    • Remote kill-switch remains in place (already exists at NPA phase; must remain functional for personalized phase).

    Gambling-adjacent ad blocking (continues from NPA phase; contractual block must be verified to still cover personalized inventory before personalized activation): the contractual block on gambling, sports betting, casino, fantasy sports, daily fantasy, lottery, prediction markets, and crypto/binary-options trading categories must be confirmed to apply to both NPA and personalized programmatic inventory before personalized ads activate.

    Legal doc rewrites (at personalized activation): Privacy Policy §4.1 (update lawful basis from legitimate interest to consent for behavioral processing); Cookie & Ad-Tech Policy §3 (update from NPA description to personalized description); Cookie & Ad-Tech Policy §4.1 (update consent architecture to UMP); Cookie & Ad-Tech Policy §5 (update ATT section); Sub-processors list (update Google LLC AdMob entry to describe behavioral data categories including IDFA/GAID).

    Per-jurisdiction triggers also engaged at personalized activation: KOSMA + NY SAFE Act + MODPA + CO CPA UOM + FL HB 3 re-evaluation + DSA Art. 28 under-18 profiling-suppression engineering re-verification + KR PIPA opt-in + APPI Art. 27 disclosure + AU APP 7 opt-out + IL §30A / POPIA s. 69 / LGPD Art. 18 review.

  2. Algorithmic content-recommendation feed activation → KOSMA + NY SAFE Act + FL HB 3 + DSA Art. 28 all engaged; substantial §7 rewrite.

  3. Any new sub-processor with personal-data flow → §6 inventory update + GDPR Art. 28 sub-processor obligations + cross-border transfer reassessment.

  4. Apple IDFA / Google GAID read activation → §5 ATT prompt + Privacy Policy update to name the new identifier use.

  5. Belgian Gaming Commission engagement-as-consideration theory expansion → §4.1 BE-specific re-evaluation (Belgium is a deferred market at MVP; trigger applies when BE re-opens).

Non-material changes (typographical corrections, link updates, clarifications) may be published without 30-day notice; the updated last_updated date in the document header is the controlling indicator.

For changes required by mandatory law or by a genuine security or safety obligation that cannot reasonably be delayed, we may make the change effective immediately and notify you within 7 days.

EU/EEA users (DSA Art. 12). During the 30-day notice period for any material change, you have the right to terminate your use of the Service and delete your Account (see Terms of Service, §10 Account deletion) free of any penalty.

§10 Contact us

For any cookie or ad-tech inquiry, contact us:

Email: legal@bguru.app In-app: Settings → Help → Contact Us

We respond within one month of receiving your inquiry per GDPR Art. 12(3), UK GDPR equivalent, IL PPL Amendment 13, and equivalent obligations. Faster on urgent matters.

Sole-proprietorship posture. bGuru is currently operated as a sole-proprietorship project of an Israeli resident (see Privacy Policy §2). The legal@bguru.app channel is staffed personally by the founder until the entity decision lands post-MVP.

EU/EEA Art. 27 representative + UK Art. 27 representative: appointment deferred (cost-driven, target MVP+1). legal@bguru.app is the interim channel.

§11 Changelog

Version Effective date Changes
0.1.8 2026-06-02 Refined the age-restricted ad-treatment description (§7) to use generic public wording rather than naming a specific Google SDK flag. The substantive behaviour is unchanged. Collapsed the public changelog's pre-launch drafting iterations into a single summary entry for clarity.
0.1.7 2026-06-02 Refined AdMob NPA-mode IDFA/GAID descriptions in §3 to focus on what bGuru configures. Refined gambling-category blocking description (§0, §3, §7) to match current configuration (console + kill-switch). Added consent fallback safety commitment in §4.1.
0.1.6 2026-06-02 Refined AdMob NPA-mode descriptions to focus on what bGuru configures. §0 / §1 / §2.2 / §4.1 / §5 / §6 reframed.
0.1.5 2026-06-02 Updated for AdMob NPA live. §0 / §1 / §2.2 / §3 / §4.1 / §5 / §6 / §7 / §9 all updated to reflect NPA contextual ads as active.
0.1.4 2026-06-02 Clarified no-ads posture as applying to this version. Permanent no-behavioural-ads-to-under-18 commitment reinforced (§7). §9 amendment trigger 1 updated to name Google AdMob and list all pre-conditions.
Pre-launch drafting iterations 2026-05-30 → 2026-06-01 Multiple internal drafting iterations during the pre-launch review period. The substantive provisions described above were drafted, refined, and consolidated through this period.