Privacy by design, with jurisdictional limits.

Stored by default

• 30-day rolling UTC-hour aggregates: views, status classes, redirects, 404s, latency buckets, allowlisted platform/content kinds, and optional coarse device counts when the customer enables them.
• Experiment aggregates: exposure, click, selector miss, and unsupported/CSP transformation counts by experiment/version/variant.
• Canonical paths with query strings/fragments removed, sensitive segments redacted, length bounded, and durable breakdown rows withheld below five observations.

Not stored by default

• IP addresses, hashed IPs, persistent analytics cookies, cross-day analytics identity, cross-site identity, raw user-agent strings, raw referrers, search terms, raw URLs, request bodies, or raw event streams. Known sensitive identifiers are redacted before canonicalization; ordinary slugs are not guaranteed product-ID-free.
• The experiment assignment cookie is a separate, daily-expiring first-party cookie containing only experiment/version/variant/expiry data. It is not an analytics identity cookie.
• Yabby does not infer sessions, unique visitors, journeys, abandonment, conversion, or legal compliance from page counts.

GDPR and CCPA boundary

Yabby is designed to minimise retained data; it does not make a GDPR, CCPA/CPRA, APP, COPPA, PIPEDA, or other legal determination.

• The customer generally determines the purpose and lawful basis; Yabby may act as a processor or service provider depending on the signed service and instructions.
• The customer owns notices, cookie disclosures, consent/CMP decisions, data-subject requests, jurisdictional restrictions, and any required transfer-impact assessment.
• The daily experiment assignment cookie must be disclosed and assessed under the customer’s jurisdictional analysis. Yabby does not label it essential or consent-exempt.
• Subprocessors, Cloudflare’s role, international transfers, deletion windows, incident contacts, and rights assistance must be completed in the negotiated documents before production.

Reference points for legal review

• GDPR: a customer may be controller and Yabby processor depending on the service instructions. Counsel should map Article 28 terms, data minimisation, rights assistance, security, breach handling, subprocessor controls, and any international transfer mechanism. See European Commission controller/processor guidance and Commission Article 28 clauses.
• Australia: the Privacy Act 1988 and 13 Australian Privacy Principles may apply to an APP entity. Counsel should review APP 1, 3, 5, 6, 8, 11, 12, and 13, cross-border disclosures, notices, access/correction, and breach handling. See OAIC APP text and OAIC APP Guidelines.
• California: CCPA as amended by CPRA has specific service-provider/contractor contract requirements and consumer-rights implications. Counsel should classify the customer relationship and service configuration; Yabby must not sell or share customer data. See California Privacy Protection Agency guidance.
• COPPA: the FTC Rule applies to child-directed services and general-audience services with actual knowledge of collecting personal information from children under 13. Yabby is not a child-safety determination; customers serving children must obtain a separate review and configure the service accordingly. See FTC COPPA FAQ.
• Canada: PIPEDA remains the current federal private-sector privacy statute; the proposed Consumer Privacy Protection Act in Bill C-27 is not a live replacement. Provincial substantially similar laws, including Quebec’s Law 25, may also apply. See current PIPEDA text and Bill C-27 status.

Privacy review deliverables

• Customer-specific data-flow and records-of-processing description.
• Lawful-basis/consent and notice analysis by jurisdiction and site type.
• Subprocessor and transfer-impact review; deletion, rights, incident, and support workflows.
• A decision on whether any experiment cookie requires consent or a separate disclosure under the customer’s jurisdictional analysis.