Your data is stored in your own AWS account, inside a private VPC that the CloudFormation stack creates, in the AWS Region you chose at installation. Personalisation Hub is not a multi-tenant SaaS service: there is no shared database, and nothing about your stores, campaigns or customers is held by Personalisation Hub itself. This page explains where each kind of data lives, how access is controlled, and which settings you own.

Where the data lives

The Installation Wizard provisions the full platform stack in your account. Data is held in these AWS services, all in private subnets:

  • Amazon RDS (PostgreSQL) — the core application database: stores, users, campaigns, queue and appointment records.
  • Amazon S3 — campaign assets, logos, reports, logs and backups.
  • Amazon OpenSearch Service — logs and analytics data.
  • Amazon ElastiCache (Redis) — cache and session data.
  • Amazon MSK (Kafka) — the event stream between services.

Data is encrypted at rest with customer-managed KMS keys (RDS, S3, EBS, MSK and ElastiCache) and in transit with TLS. The only intentionally public endpoints are the Application Load Balancer that serves your platform domain and specific S3 objects such as campaign creative. Backups follow AWS defaults — automated RDS backups with point-in-time restore, and snapshot options for OpenSearch and ElastiCache — and are yours to extend. See AWS deployment: resources provisioned and AWS deployment: lifecycle management.

Because the platform runs on your primary domain (for example ph.yourdomain.com), the first-party cookies that connect a customer's website visit to their store visit are also yours.

How the platform is built

The platform is a set of microservices on Amazon EKS: authentication, campaign and location APIs, HQ Admin, Retail Admin, store queueing, MIST, background tasks and monitoring (Prometheus and Grafana). External calls — to AI model providers, Google, MIST or your CDP — leave through a Squid proxy. See AWS deployment: architecture.

Who can reach the platform

  • IP restrictions. Under Platform Admin → Security (IP Restrictions) you approve the CIDR ranges — offices, VPN, stores, connected partner platforms — that can open the platform, up to 400 records. Until a record is added and activated, every IP address has access. Add your own current address first. See Step 7 — Restrict platform access by IP address.
  • Behind your CDN. Alternatively place the instance behind a CDN such as Akamai and approve only the CDN's addresses. The paths used by mobile store sites, virtual queueing and appointment bookings must remain reachable by visitors' phones.
  • Access Denied. A blocked address sees an Access Denied page rather than the sign-in page. See I see an Access Denied error.

How people sign in

  • Master Admin is created in the Installation Wizard and must set a strong password at first login. Use a shared mailbox so access does not depend on 1 person.
  • HQ users are invited by email as Admin, Marketing or Helpdesk users from Company Settings → Platform Set-up. Invitation links expire after 24 hours. Any change on that page requires the Admin password to be entered again. See Add HQ Admin, Marketing and Helpdesk users.
  • Store staff sign in to Retail Admin either through your SAML single sign-on, so provisioning follows your identity provider, or with a CSV upload and a first-time password they must change at first login. See Integrate single sign-on (SAML) for store staff and Upload Retail Admin users for your stores.

How integrations authenticate

Each third-party system that connects — your CDP or app calling the Visitor API, a menu board, the playback analytics feed — gets its own secret/token under Platform Admin → API Authentication, which you can view, rotate or delete. Visitor data sent to a display is cleared from that display after a period you set on the same page (2 minutes in the demo tenant). Google Business Profile and MIST are connected with your own account credentials. See Create API authentication credentials for an integration.

The AI agents call the model providers you register under Platform Admin → AI Models / Integrations at the base URL shown, using your own provider account. Campaign briefs, copy and brand guidelines are sent to those providers to generate content.

Computer vision and visitor data

The vision model runs at the edge, on the player attached to the display. No images or sensitive data leave the device; the platform receives anonymous audience attributes such as gender and age range. See Does computer vision store images of shoppers?.

Visitors who join a queue give their name and mobile number and, in doing so, consent to the platform personalising their visit. Queue and appointment records are kept for the period set by Retain Queueing/Appointment Data for under Platform Admin → Queueing / Appointments → Queue Settings (90 days by default), and campaign playback analytics for the number of days set under Campaign Monitoring Settings. See Queue settings reference and Configure campaign playback monitoring.

The Privacy Policy URL you enter under Company Settings → Platform Set-up is the policy your visitors are pointed to; Retail Admin also links to Personalisation Hub's own privacy policy in its footer.

Patches and upgrades

Updates are announced on the AWS Marketplace product page with release notes and migration guidance; nothing is pushed into your account automatically. IAM credentials and KMS keys created by the stack are yours to rotate. See AWS deployment: lifecycle management.