Security & Privacy
The BI model is designed for operational analytics while limiting unnecessary exposure of sensitive data.
Data Exposure Rules
| Area | Public BI Behavior |
|---|---|
| Customer profiles | Not exposed. BI uses opaque customer_id values only. |
| Customer contact details | Names, emails, phone numbers, and demographics are not included in the public analytics model. |
| Review text | Not exposed in ANALYTICS. Review content exists upstream but is not part of the public reporting tables. |
| Employee data | Employee IDs, names, and emails may be exposed where needed for recognition reporting. |
| Internal/demo locations | Marked with internal; exclude these from external reporting unless intentionally included. |
| Customer exports | Scoped to configured customer brands and locations. |
Access Model
Most reporting access uses read-only access to the ANALYTICS schema. Customer exports are delivered to dedicated customer S3 buckets.
For all reporting, use the curated ANALYTICS tables. Other layers are internal and not part of the public model.
Customer Export Storage
Customer export buckets are private and customer-specific. Files are written under the analytics-export/ prefix and retained according to the customer’s configured retention policy.
Safe Usage
- Do not attempt to enrich opaque
customer_idvalues with customer contact data unless that use has been approved. - Do not publish review text from non-public layers into dashboards or exports.
- Filter out
internal = TRUElocations for customer-facing reporting. - Use aggregated daily tables when a business question does not require row-level facts.
If a requested analysis requires fields listed as not exposed, treat it as a data access review rather than a query-writing task.