1Scope of this policy

This policy explains how Safli Technologies Ltd (“Measura”, “we”, “us”) handles personal data in the Measura mobile measurement platform. It covers the Measura SDKs, the event ingestion and attribution services, the deep link redirector, and the developer and administrator dashboards.

It describes actual system behaviour. Where a control is not yet built, this policy says so rather than describing an intention.

Two audiences are addressed. If you are a customer, meaning a company that has integrated our SDK, sections 2 through 11 describe what we do with data collected through your app. If you are an end user of an app that uses Measura, section 12 explains your rights and how to exercise them.

2Our role: processor and controller

For data collected through a customer’s app, Measura acts as a data processor. The customer decides what to collect and why, and we process it on their documented instructions. The customer is the controller and is responsible for having a lawful basis and for giving notice to their users.

For a limited set of platform level processing, principally fraud detection signals evaluated across our whole customer base, and for account data belonging to our own customers, Measura acts as a controller.

Being direct about this

Advertising identifiers and device fingerprints are personal data under Nigeria Data Protection Act 2023 (NDPA) and under the GDPR. Masking IP addresses reduces what we hold, but it does not remove us from the scope of either regime, and we do not claim that it does.

3What the SDK collects

Measura ships a single SDK, for Android. The following fields are sent with every event.

event_typestring

The kind of event, for example install, open, session start or purchase.

timestampinteger

When the event occurred, from the device clock.

sent_atinteger

When the request was signed. Used to reject replayed requests outside a ten minute window.

customer_id, app_iduuid

Which customer and which application the event belongs to. Resolved from the API key, not supplied by the device.

event_idstring

A generated identifier used to deduplicate retried events.

sdk_versionstring

The SDK version that produced the event.

device_model, os_name, os_version, app_versionstring

Device model, platform, operating system version and the host application version.

device_fingerprint_componentsobject

Device model, operating system version, screen resolution, application version, and a user agent string that the SDK constructs itself. This is not the browser user agent and contains no browsing history.

signaturestring

A cryptographic signature over the payload, proving it came from a holder of the customer’s secret.

Fields sent only in specific circumstances

Field	When it is sent
`event_properties`	Only when the app developer attaches properties to an event. The contents are chosen entirely by the app developer, not by Measura.
`revenue, currency`	When a purchase event carries a monetary value.
`user_id`	Only after the app developer calls identify(). See section 5 for an important limitation.
`referrer`	Once, on first launch. The install referrer string provided by the app store, which carries the click identifier through the install.
`click_id`	When the install can be traced to a Measura link the user opened.

4What we add on our servers

Three things are recorded by our servers rather than by the SDK.

A masked IP address. We take the source address of the request and truncate it before storage. IPv4 addresses lose their final octet, becoming a /24 network. IPv6 addresses are truncated to a /48 block. The full address exists only in memory for the duration of the request.
The HTTP user agent header. Used for fraud signals such as detecting automated clients.
A computed fingerprint hash. A one way hash of the masked IP address, user agent, device model, screen resolution and operating system version, used for probabilistic matching when no deterministic identifier is available.

No raw IP addresses

No unmasked end user IP address is written to any table in the Measura platform. This applies to event ingestion, the deep link redirector and the historical data importer alike.

5What we do not collect

Stated explicitly, because the absence is as important as the presence.

No location data. No GPS, no coarse location, and no IP based geolocation lookup.
No contacts, photos, messages, calendar or file access. The SDK requests none of these permissions.
No browsing history and no cross app tracking beyond the attribution of a click to an install within a single customer’s account.
No Google Advertising ID. Although our ingestion endpoint would accept one, the current Android SDK does not read or transmit it.
No raw IP address in storage, as described above.

Identify has a limitation worth knowing

If your app calls identify() with a user identifier, the SDK attaches it to outgoing events, but our ingestion service does not currently persist it. No user identifier or email address is stored against event data. This has a practical consequence covered in section 12: a deletion request that arrives identified only by an email address cannot be resolved to event records today.

7How we use the data

Purpose	What it involves
Attribution	Matching an install to the click that preceded it, and computing a confidence score with a written record of the reasoning.
Fraud detection	Scoring each event against a set of published rules covering request velocity, automated client signatures, timestamp anomalies and emulator indicators. Flags are recorded for review. Nothing is blocked automatically.
Analytics for the customer	Aggregating installs, retention cohorts and return on ad spend for display in the customer dashboard.
Postbacks to advertising networks	Where a customer configures it, forwarding conversion notifications to the network that served the ad. See section 9.
Service operation	Rate limiting, quota metering, debugging and security monitoring.

We do not sell personal data. We do not use customer event data to build cross customer advertising profiles, and we do not share one customer’s data with another.

8Legal basis

Where Measura acts as processor, the lawful basis is established by our customer as controller. Under Nigeria Data Protection Act 2023 (NDPA) and the GDPR this is typically consent for advertising identifiers, and legitimate interests for fraud prevention and service security.

Where Measura acts as controller, for platform security and fraud prevention, we rely on legitimate interests. For our own customer account and billing records we rely on contractual necessity.

9Who we share data with

We use the following sub-processors. Each has a defined role and receives only what that role requires.

Sub-processor	Purpose	Data handled
Supabase	Primary platform: Postgres database, authentication, edge functions, object storage and secret vault.	All event, device, attribution and account data. This is the principal store.
Cloudflare	Hosting, DNS and content delivery for the marketing site and both dashboards. Every page is served from Cloudflare Pages.	HTTP request metadata including IP address and user agent at the edge. No event, device or attribution data is stored here.
Google (OAuth)	Optional single sign-on for dashboard accounts.	Authentication assertion containing email address and profile name.
GitHub (OAuth)	Optional single sign-on for dashboard accounts.	Authentication assertion containing email address and profile name.
Resend	Transactional email delivery for team invitations sent from the dashboard.	The invited person’s email address, the inviting team name, the assigned role and the single-use invitation link. No event, device or attribution data.
Google (Play Integrity)	Device and app attestation, only for customers who enable integrity checking.	The Play Integrity token issued on the device, exchanged for a verdict covering app and device recognition and licensing. No advertising identifier.
Google (Firebase Cloud Messaging)	Uninstall detection, only for customers who enable it. Token liveness is checked; no message is delivered to the end user.	The FCM registration token for the device.

Advertising network postbacks

If a customer configures a postback to an advertising network such as Meta or Google, we send that network a conversion notification when an attribution resolves. This notification includes the event type, attribution and install identifiers, the confidence score, the campaign identifier, and the advertising identifier where one is present.

This transfer happens only when the customer enables it, and the receiving network is an independent controller of what it receives. Customers should review the network’s own terms before enabling postbacks.

We may also disclose data where required by law, or to establish or defend legal claims.

10How long we keep data

The following windows are enforced by scheduled jobs in our database.

Data	Retention	How it is enforced
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.

How the windows are measured

Retention is measured from when we received a record, not from when the underlying event occurred. This matters if you import historical data from another platform: that history is kept for the full window from the date of import, rather than being deleted immediately because the original events are old.

Account and billing records are retained for as long as the account is active and afterwards as required for legal and accounting purposes.

11Where data is stored

Platform data is stored in a managed Postgres database operated by Supabase, in the us-west-2 region (Oregon, United States). Our application layer runs as edge functions on the same platform, and our web properties are hosted on Cloudflare’s global network.

This means personal data collected through your app is transferred to and processed in the United States, outside Abuja, Nigeria. Where a customer’s use of Measura brings data within the scope of the GDPR or UK GDPR, we will put an approved transfer mechanism in place, such as the European Commission’s standard contractual clauses or the UK International Data Transfer Agreement, as part of the data processing agreement for that engagement. Customers with cross-border transfer requirements should raise them before integrating so the right mechanism is agreed up front.

Available worldwide, hosted in the United States

Measura is available worldwide and is not scoped to any one region. Our current infrastructure is hosted in the United States, and we do not currently guarantee geographic data residency. We are not claiming one, and we would rather state where your data actually sits than imply otherwise. Regional hosting can be introduced where a contract or regulator requires it, so if regional storage is a requirement for your organisation, raise it before integrating and we will tell you plainly whether we can meet it.

12How we protect data

The following controls are implemented and in use.

IP truncation at ingestion, so raw addresses are never stored.
Row level security on every tenant table, enforced by the database itself. Access is scoped by a server controlled identity claim, so one customer cannot read another’s data even if application code were wrong.
API keys stored as hashes only. The plaintext key is shown once at creation and cannot be recovered afterwards.
Cryptographically signed events. Every event carries a signature computed with a per customer secret, and requests outside a ten minute window are rejected.
Advertising network credentials held in a secret vault rather than in application tables.
Hardened security headers including a content security policy on both dashboards.
An append only administrative audit log recording every administrative change with its previous and new values.

Data is encrypted in transit over TLS, and encrypted at rest by our hosting platform. We do not currently apply application level column encryption on top of that, and we do not claim to.

No system is perfectly secure. If you believe you have found a vulnerability, please report it to security@measura.dev.

13Your rights

Under Nigeria Data Protection Act 2023 (NDPA) and, where applicable, the GDPR, you have the right to request access to your personal data, correction of inaccurate data, deletion, restriction of processing, portability, and to object to processing. You may also withdraw consent at any time where processing relies on it.

How to exercise them

If you are an end user of an app that uses Measura, direct your request to that app’s operator first. They are the controller of the data and we act on their instructions. If you cannot reach them, contact us at privacy@measura.dev and we will help identify the right party.

If you are a Measura customer, the developer dashboard includes a form for submitting data subject requests on behalf of your users.

How requests are processed

Access and portability requests run automatically. A job checks for new requests every five minutes and compiles a complete document of every record we hold about the subject, across devices, events, clicks, installs and attributions.

Erasure requests are held for human approval before they run. Deletion is irreversible, so we do not let a timer execute it unreviewed. Once approved, the erasure removes every matching record and writes down exactly what was deleted.

One limitation you should know about

Email addresses cannot be matched to event data. As described in section 5, we do not store user identifiers or email addresses against event records. A request must therefore identify the person by advertising identifier or device identifier. A request submitted with only an email address is rejected with that explanation rather than silently returning nothing.

You also have the right to lodge a complaint with the Nigeria Data Protection Commission (NDPC) or with your local supervisory authority.

14Children's data

Measura is a business to business service and is not directed at children. We do not knowingly collect personal data from children. Customers operating apps aimed at children are responsible for complying with the applicable rules in their market, including obtaining any required parental consent, and should not enable advertising identifier collection in such apps.

15Changes to this policy

We may update this policy as the platform changes. Material changes will be communicated to customers through the dashboard or by email to the registered billing address. The revision date at the top of this page records the most recent change.

16Contact us

Questions about this policy, or about how we handle personal data, can be sent to privacy@measura.dev.

Safli Technologies Ltd
RC 9615785
Plot 2 Hunkuyi Close, Garki
Abuja, Nigeria

Privacy and data protection enquiries, including requests to access or delete your data, are handled by our privacy team at privacy@measura.dev.

Privacy Policy