Cookie & Tracking Notice

Use the existing V10 Tracking/Tag/Conversion architecture and ONE consent/preference truth. CURRENT SUPPORTED/CONFIGURABLE CAPABILITIES: - Google Tag Manager; - Google Analytics 4 where enabled; - Google Ads; - Meta Pixel; - Meta Conversions API. They are not automatically active. Categories shown to the user must reflect actual use: - Necessary; - Analytics; - Advertising/Marketing; - Personalization only if actually used. Where prior consent is required: NON-ESSENTIAL TRACKING MUST NOT LOAD OR TRANSMIT BEFORE THE REQUIRED CONSENT STATE EXISTS. This applies to browser tags, advertising pixels, non-essential SDKs and covered server-side conversion delivery. Meta CAPI / another server-side path is not a consent bypass. Preference Center where applicable: - shows current state; - permits later change/withdrawal; - makes refusal operationally real; - updates future tag/server behavior; - keeps versioned evidence where required; - does not require a paid account merely to manage public-site preferences. Where legally required, do not pre-tick optional categories and do not make Reject materially harder than Accept. GTM is a tag-delivery/control mechanism, not permission to deploy arbitrary tracking. It must respect V10 consent state and must not bypass category policy. Unrestricted privileged arbitrary JavaScript remains prohibited. Paid conversion truth remains server-authoritative under existing §§54–56: provider/server confirmation → verified normalized V10 payment/subscription event → consent/policy gate → configured destination. A success page alone never proves a paid conversion. Browser event + server/CAPI delivery for the same logical conversion must use stable deduplication. Keep separate: A. browser/app tracking consent; B. aggregated ad-platform reporting/account-data ingestion; C. server-side conversion delivery. One does not automatically imply the legal treatment of the others. Where applicable, support region/policy-aware prior-consent, opt-out and recognized GPC/similar signals when actually triggered by law and SolaroCall processing. Do not expose a “Do Not Sell or Share” claim/mechanism as universally required, and do not omit it when actually required. Mobile tracking is separate from browser cookie mechanics. App-store privacy/Data Safety and tracking permission must match actual mobile SDK behavior. Do not intentionally send passwords, API keys, payment-card data, authentication/SIP credentials, raw sensitive call content, unnecessary transcripts/audio, PHI or other sensitive regulated data to analytics/advertising platforms unless a separately approved lawful design exists. Cookie/analytics retention resolves through RetentionPolicyRegistry. Do not invent a provider- default period as SolaroCall policy. CONSENT EVIDENCE Where consent evidence is required, preserve only enough authoritative metadata to show: - consent/preference ID; - policy/version; - categories chosen; - timestamp; - source surface; - locale; - applicable region/policy where useful; - withdrawal/change timestamp; - anonymous/session/account association only as necessary. Do not create unnecessary fingerprinting data merely to prove consent. OWNER / ADMIN Reuse ADMIN → SECRETS & INTEGRATIONS → TRACKING & TAGS. Per supported integration expose where applicable: - provider/type and environment; - configured/enabled; - consent category/policy requirement; - public ID and secure credential reference; - mapped events and allowed page/app scope; - last test/event/conversion; - accepted/failed state; - consent-blocked count where useful; - health/error; - disable/revoke. Routine supported configuration must not require source-code edits. SENSITIVE VERTICALS For healthcare/legal/other sensitive professions, do not send sensitive caller/business content to advertising platforms merely because a generic conversion exists. Prefer normalized events such as SIGNUP_COMPLETED or SUBSCRIPTION_ACTIVATED without sensitive profession/caller details unless explicitly approved and lawful. Public Cookie/Tracking Notice/provider inventory must be generated from the active production stack, not from disabled/future integrations.