Compliance
Our regulatory position and the security controls behind it.
1. Our approach
Safli Technologies Ltd’s compliance posture: the regulation we operate under, and the controls that are implemented.
2. Data protection regulation
Nigeria Data Protection Act 2023 (NDPA)
Measura operates under Nigeria Data Protection Act 2023 (NDPA) and is subject to oversight by the Nigeria Data Protection Commission (NDPC). Our platform includes fields for tracking the registration status of customer organisations with the regulator, reflecting that many of our customers carry their own obligations.
GDPR
Where a customer processes data belonging to individuals in the European Economic Area or the United Kingdom, GDPR applies. In that relationship the customer is the controller and Measura is the processor. Our Data Processing Agreement is written to satisfy Article 28 and includes the processing details required by Article 30.
Advertising identifiers and device fingerprints are personal data under both regimes. We do not claim that truncating IP addresses changes that analysis.
Platform policies
Measura ships a single SDK, for Android, designed to comply with Google Play’s developer policies. It does not read or transmit the Google Advertising ID, or any other advertising identifier, so the Play Data Safety declaration for advertising ID collection does not apply to it. Attribution relies on the Play Install Referrer instead.
Where an advertising identifier does reach us, through a direct server to server integration or a historical data import, an all zero value signalling limited ad tracking is discarded rather than stored.
Meeting the disclosure requirements of each app store, including privacy nutrition labels and data safety declarations, is the responsibility of the customer publishing the app. We will provide the field level detail you need to complete them accurately, and our Privacy Policy documents exactly what the SDK transmits.
3. Security controls
Current state of the technical controls in the platform.
| Control | Status | Detail |
|---|---|---|
| IP address minimisation | In place | Truncated to a /24 or /48 network before any database write. No raw end user IP address is stored anywhere. |
| Tenant isolation | In place | Row level security enforced by the database on every tenant table, scoped by a server controlled identity claim. |
| Credential hashing | In place | API keys stored as SHA-256 hashes. Plaintext shown once and unrecoverable thereafter. |
| Request authentication | In place | HMAC-SHA256 signature per event with a per customer secret, plus a ten minute replay window. |
| Secret management | In place | Advertising network credentials held in a managed vault, referenced by identifier. |
| Transport encryption | In place | TLS on all connections to the Service. |
| Encryption at rest | In place | Provided by the managed database platform. No additional application level column encryption. |
| Security headers | In place | Content Security Policy, frame denial, MIME enforcement, referrer and permissions policy, HSTS on both dashboards. |
| Administrative audit log | In place | Append only, recording actor, action and prior and new values for every administrative change. |
| Rate limiting | Partial | Enforced on the deep link redirector and key resolution. Event ingestion relies on signature verification, payload size caps and monthly quotas instead of a request rate limit. |
| Configurable data retention | In place | Raw event retention is configurable from 7 to 90 days per account with plan defaults. Derived records (devices, clicks, installs, attributions, fraud flags) follow a 90 day floor. Operational metrics and rate limit counters are also scheduled. Four nightly jobs enforce this. |
4. Privacy controls
| Control | Status | Detail |
|---|---|---|
| No advertising ID collection | In place | The Android SDK does not read or transmit any advertising identifier. Attribution uses the Play Install Referrer. |
| Opt out handling | In place | The all zero advertising identifier that signals limited ad tracking is discarded after signature verification and cleared retroactively. |
| Tracking toggle | In place | disableTracking and enableTracking are available in the SDK. The setting is persisted to disk immediately, so an opt-out survives an app restart. |
| Data minimisation | In place | No location data, no contacts, no browsing history. The Android SDK transmits no advertising identifier at all. |
| Data subject request intake | In place | A submission form in the developer dashboard records requests against the account. |
| Data subject request fulfilment | In place | A scheduled job processes requests every five minutes. Access and portability requests compile automatically. Erasure is held for human approval before running, then executes across every table holding the subject and records the deleted counts. No contractual turnaround is offered yet. |
| Per-subject data export | In place | A data subject request produces a complete machine readable export of every record held about that person. The export is deleted seven days after it is generated and can be regenerated on request. |
| Account-wide data export | In place | Self-service and immediate. Settings then Export in the developer dashboard produces a single JSON file covering apps, campaigns, links, installs, attributions with their confidence breakdown, raw events, fraud flags and payments. No notice period and no fee. |
| Account closure and erasure | In place | Closing an account stops event collection immediately and is reversible for 30 days. After that a scheduled job deletes the account and its data permanently. A minimal accounting record is preserved for six years under CAMA 2020 s.375(2), and an anonymised record that a data subject request was completed is preserved as evidence of compliance. Neither remains readable by the closed account. |
| Data residency | Partial | Infrastructure is hosted in the United States. Regional hosting where a contract or regulator requires it: ask us. |
5. Data retention
Retention windows enforced by scheduled database jobs.
| Data | Retention | Mechanism |
|---|---|---|
| Raw events | 7 to 90 days, configurable | Retention is set per account, defaulting to 14 days on Free and 90 days on paid plans. A job at 04:00 UTC drops whole monthly partitions past the 90 day maximum, and a second job at 04:30 UTC removes rows for accounts on a shorter window. Only events that have completed attribution are removed, so an unprocessed backlog is never discarded. |
| Derived records (devices, clicks, installs, attributions, fraud flags) | 90 days minimum, or your raw window if longer | A job at 05:00 UTC removes derived records once we have held them past the window. Retention is measured from when we received a record, not when the event occurred, so imported historical attribution is not purged on import. A device is only removed once it has no remaining events or installs. |
| Operational metrics | 30 days | A scheduled job deletes older rows daily at 03:00 UTC. |
| Rate limiting counters | 1 hour | A scheduled job clears expired windows every 15 minutes. |
| Data subject request exports | 7 days from generation | The export document assembled for a data subject request is the most concentrated copy of one person’s data we hold, so it is not kept once it has served its purpose. A job at 03:40 UTC deletes any export older than seven days and clears the download reference. Re-submitting the request regenerates it from live data within five minutes. |
| Closed accounts | 30 days, then permanent deletion | Closing an account stops event collection immediately and starts a 30 day window in which it can be cancelled and fully restored. A job at 02:00 UTC permanently deletes accounts past that window, including apps, devices, events, attribution and your end users’ payment records. |
| Accounting records after closure | 6 years | A minimal record of which plan an account held and over which periods survives closure, because section 375(2) of the Companies and Allied Matters Act 2020 requires accounting records to be preserved for six years. It carries no end user data and no contact details, is not readable by any customer account, and is deleted automatically once the six years elapse. |
Windows are measured from when we received a record, not from when the underlying event occurred. Historical data imported from another platform is therefore retained for the full window from the date of import, rather than being deleted immediately because the original events fall outside it.
Any retention figure quoted elsewhere that differs from the table above should be treated as out of date. The values here reflect what scheduled jobs actually enforce.
6. Fraud detection and automated decisions
Every event is scored against a set of rules covering request velocity from a network block, missing or automated client signatures, low entropy user agents, implausible timestamps, device level install velocity, and emulator indicators.
Each flag records the rule that fired, the rule version, the signal values that triggered it, and the score contributed. The reasoning is reviewable rather than opaque.
7. Sub-processors and supply chain
Our sub-processors are listed in full, with their purpose and the data each handles, in the Data Processing Agreement.
We give at least thirty days’ notice before adding or replacing a sub-processor, and customers may object on data protection grounds.
Where you enable a postback to an advertising network, that network receives conversion data as an independent controller. It is not our sub-processor, and the transfer happens on your instruction.
8. Incident response
We will notify affected customers without undue delay after becoming aware of a personal data breach, with the detail required under Article 33 of the GDPR to the extent it is known at the time, supplemented in phases as more becomes available.
Notification to a supervisory authority or to affected individuals remains the controller’s responsibility. We will assist.
- Report a security vulnerability or suspected breach to privacy@measura.dev.
- Live operational status is published at /status.
We ask that you give us a reasonable opportunity to remediate a reported vulnerability before disclosing it publicly. We will not pursue action against researchers who report in good faith and avoid accessing customer data.
9. Vendor diligence
We respond to written security questionnaires and will complete a reasonable assessment for prospective customers. Since we hold no certification to offer in place of one, this is the route we can actually support.
Audit rights, including notice periods and conditions, are set out in the Data Processing Agreement.
For diligence requests, contact hello@measura.dev.
Safli Technologies Ltd
RC 9615785
Plot 2 Hunkuyi Close, Garki
Abuja, Nigeria
AI tools