Privacy-safe product analytics in Saudi Arabia and the UAE
A production architecture for SDK gates, event contracts, regional processors, retention and deletion.
Product analytics often starts with a harmless request: count sign-ups, find the broken funnel, learn which feature people use. Then the SDK grows teeth. It collects device identifiers, page URLs, free-text properties and session traces. Copies reach a warehouse, a dashboard, a support tool and somebody's CSV export. The privacy notice may still describe "usage data" as if it were one tidy database.
Teams shipping in Saudi Arabia and the UAE need a better boundary. The safest design is to treat analytics as a controlled data product, with an event contract, a reviewed purpose, an identity boundary and an executable deletion path.
This guide is practical engineering information, not legal advice. Your legal basis and obligations depend on the entity, sector, free zone, data and use case.
Start with purpose, not the SDK
An analytics vendor can tell you what its library supports. It cannot decide why your company may process personal data.
The UAE's official government portal says the federal Personal Data Protection Law applies to electronic processing inside and outside the country. It describes consent as the default, subject to stated exceptions, and gives people rights to correct inaccurate data and restrict or stop processing. The law also sets requirements for cross-border transfers. Read the official UAE overview before turning a vendor's regional hosting option into a compliance claim.
Saudi Arabia's SDAIA data-protection guidance is more explicit about operational design. It lists purpose limitation, data minimisation, retention, technical protection and rights including access, correction, destruction and withdrawal of consent. Its scope includes processing related to people in the Kingdom by entities outside the Kingdom.
Do not convert those rules into one analyticsAllowed boolean. A product can have several purposes with different conditions:
- service diagnostics needed to keep a feature working;
- product measurement used to improve the interface;
- fraud signals used to protect an account;
- marketing attribution or audience building.
Review each purpose separately. If consent is the basis, store the purpose, notice version, language, time, interface and resulting state. Saudi Arabia's PDPL Implementing Regulation says consent must be provable and separate for each purpose. It also says withdrawal should be as easy as, or easier than, giving consent.
That makes a single "accept all" timestamp a weak audit record. It cannot show which purposes the person accepted or which notice they saw.
Put a gate before collection
Many implementations load the analytics SDK on app start, send an anonymous event, and ask for consent later. The user interface says "off" while the network says otherwise.
Move the decision in front of SDK initialisation. On a cold start with no stored decision, block optional analytics libraries and their network destinations. After the user makes a choice, initialise only the allowed modules. On withdrawal, stop collection, clear local identifiers and start the server-side workflow required by the product's policy and legal review.
Mobile platform files help with discovery but do not replace runtime tests. Apple's privacy manifest documentation requires apps and qualifying SDKs to declare collected data, tracking domains and required-reason APIs. Apple says requests to declared tracking domains fail when tracking permission has not been granted. That is useful platform enforcement, but your backend, web client and undeclared destinations still need testing.
OWASP's MASVS-PRIVACY-1 gives a good acceptance test: third-party SDKs should not collect before consent is confirmed, and the app remains responsible for the SDK supply chain. Capture traffic from a clean install, before a choice, after each choice and after withdrawal. Compare destinations and payload fields, not just request counts.
Make events boring on purpose
A safe event is narrow enough to understand without opening a dashboard. Give every event a versioned schema with an owner, purpose, retention class and prohibited fields.
type AnalyticsEvent<T extends Record<string, unknown>> = {
name: string;
schemaVersion: number;
occurredAt: string;
subjectKey?: string;
purpose: "product_measurement" | "service_diagnostics";
properties: T;
};
type EventPolicy = {
owner: string;
allowedProperties: string[];
prohibitedProperties: string[];
retentionDays: number;
destinations: string[];
};
Reject unknown properties at ingestion. Do not allow arbitrary JSON "for flexibility." It eventually captures names, phone numbers, support messages and full URLs containing tokens or search terms.
Keep raw email addresses, phone numbers, national identifiers and access tokens out of analytics payloads. If the product needs cohort continuity, issue a rotating analytics subject key and hold the account mapping in a separate service with tighter access. Hashing an email is not anonymity; the input space is predictable and the same hash links records across systems.
The same separation applies to device fingerprints. OWASP MASVS-PRIVACY-2 warns against reusing fraud signals for audience measurement. A fingerprint built to stop account abuse should stay inside that control path, with its own purpose and retention policy.
Treat region and processors as runtime configuration
"Hosted in the Middle East" is not an architecture diagram. Record the exact processing region, storage region, backup location, support-access path, subprocessors and outbound integrations for each destination.
Saudi Arabia and the UAE are separate legal markets. A regional data warehouse does not erase cross-border transfer questions, and a vendor's local endpoint does not prove that support telemetry, crash attachments or exports stay in that location.
Build a processor registry that code and procurement can both read:
processor: example-analytics
purposes: [product_measurement]
primary_region: me-central
backup_regions: [documented-and-reviewed]
subprocessors: [versioned-reference]
export_destinations: [warehouse-prod]
retention_days: 90
contract_owner: privacy-ops
last_verified: 2026-08-27
Fail deployment when a production destination has no owner, purpose or retention class. Recheck the registry when an SDK, plan or region changes. Vendor settings drift quietly; your deployment control should not.
Deletion is a distributed job
Deleting the account row is the easy part. Analytics records may sit under a pseudonymous key in a warehouse, object storage, dashboard cache, support export and processor backup.
The Saudi Implementing Regulation makes this concrete. Article 8 describes destruction when data is no longer needed, when a valid request applies, when consent is withdrawn and is the sole basis, or when processing violates the law. It calls for appropriate steps toward recipients and stored copies, including backups, while preserving other legal requirements. Article 3 sets a 30-day response period for rights requests, with a possible further 30 days in specified cases and with notice.
Do not hard-code that deadline as a global UAE rule. Instead, build a policy engine that selects the applicable workflow by entity, jurisdiction, purpose and legal hold.
A deletion orchestrator should:
- verify the requester without collecting unnecessary new evidence;
- resolve account identifiers into analytics subject keys;
- find every registered destination and export;
- delete, restrict or retain under the selected policy;
- send processor instructions where required;
- record completion, exceptions and evidence without copying the deleted payload.
Google Play's account-deletion guidance adds a product requirement: users who removed the app should still have a web route to deletion, and the interface should explain what happens. A support-only email address may satisfy neither discoverability nor automation expectations.
Backups need an expiry design, not a promise of instant mutation. If immutable backups cannot be edited safely, document when the record becomes inaccessible in normal systems, when the backup expires, how a restore suppresses deleted subjects and which legal exceptions apply. Test that suppression during recovery exercises.
Sources: UAE Government; Saudi Data & AI Authority and PDPL Implementing Regulation; Apple Developer; Google Android Developers; OWASP MASVS. Graphic: SultanByte editorial artwork.
Aggregation is not automatic anonymity
A weekly chart can still expose a person when the cohort is small or the dimensions are unusual. NIST's de-identification research summary notes that de-identification can reduce risk, but some de-identified data can be re-identified.
Set minimum cohort sizes, remove rare dimensions, cap query granularity and review exports. Keep the re-identification assessment with the dataset version. Saudi Arabia's Implementing Regulation also requires anonymisation controls to account for changing techniques and the possibility of re-identification.
This is where product teams often overreach. They remove an account ID, call the table anonymous and retain it forever. Pseudonymous event data is still linkable. Give aggregates a purpose and retention policy too.
Tests that catch the real failures
Add privacy checks to release QA instead of relying on an annual questionnaire:
- A clean install sends no optional analytics before the applicable decision.
- Every outbound analytics domain appears in the approved processor registry.
- Payload inspection rejects raw identifiers, free text and unknown fields.
- Consent and withdrawal records preserve purpose and notice version.
- Fraud identifiers never enter product-measurement events.
- Retention jobs remove expired raw events and produce auditable counts.
- A rights request reaches the warehouse, dashboards, exports and processors.
- A backup restore does not resurrect a deleted subject into active systems.
- Small cohorts and rare dimensions fail the release threshold.
Log control outcomes, not personal payloads. SultanByte's privacy-safe application logging guide shows how to keep reason codes and operational evidence without rebuilding the sensitive dataset in telemetry.
Build the control plane first
A privacy banner cannot repair an analytics pipeline that has no event inventory, no destination map and no deletion path. Start with the control plane: purpose records, SDK gates, schemas, processor registry, retention jobs and rights orchestration.
Then add dashboards. The charts will be less flexible, which is usually a good sign. Engineers can explain where each field came from, why it exists, where it went and when it disappears.
Cover credit: SultanByte editorial artwork, based on official UAE and Saudi data-protection guidance and platform documentation reviewed 27 August 2026.
