Data & Privacy
The short version, for someone filling in a Play Data Safety form, an App Store privacy label, or a vendor questionnaire. The privacy policy is the binding document; this page is the engineering view of the same facts.
One setting decides it. Levels are cumulative, and every field is listed per platform.
| Attribution level | Device signals sent |
|---|---|
| NONE | No device signals. Events still carry the name and the parameters your code passes. |
| Minimal | Install and device identifiers, timestamps, link identity, your custom user ID, iOS ATT state, Android install referrer. |
| Reduced | Minimal, plus OS and environment, locale, time zone, network type, emulator flags, campaign and ad-click identifiers. |
| Full (default) | Reduced, plus hardware characteristics and, where available, the platform advertising or vendor identifier. |
The exact field list for the version you have installed ships in the package itself, so it can never drift from what that build actually sends: Flutter, Android, iOS, React Native.
setTrackingEnabled(false) stops new device signals, new events and error reports, and discards anything queued for retry. It is not a kill switch for the SDK: resolving a link and generating a link are still network calls, so they still reach us with your tenant key, the request itself, and the ordinary transport metadata any HTTPS request exposes — source IP, time, endpoint, response status.
setUserData() accepts email, phone, first and last name, date of birth, gender, and address. These are sent at every level except NONE, because the attribution levels govern what the SDK observes about a device, not what your app chooses to pass in. They are hashed when a conversion is forwarded to an advertising destination.
This is your lawful basis, not ours
Everything else here is a pseudonymous observation. These fields are a person. If you call setUserData(), we hold directly identifying data on your behalf: the consent or other lawful basis for each field is yours to establish, and the fields are in scope when one of your users makes an access or deletion request.
clearUserData() erases the values on the device and tells the service to erase its copy — the one erasure path an SDK call can trigger directly. For a request that arrives outside the app, use the dashboard flow described under Retention and deletion.
A click on a Deeplinkly link is recorded with its identifier, the link, the time, the source IP, the user agent, and the original query string — captured as requested. If a campaign URL carries an email address, an order number, or anything else identifying, that value is stored because it was in the link, not because the SDK collected it. Treat campaign URLs as a channel that can carry personal data, and keep out of them whatever you would not want recorded.
Essential. Sign-in and session, your theme, and the record of your cookie choice. No opt-in, because the site does not work without them.
Analytics. Firebase Analytics, which does not load at all until you allow it. Page addresses are stripped before they are sent: campaign tags survive, everything else in the query string is dropped, and the fragment is never sent. Change your mind at any time with in the footer. Withdrawing stops collection and clears the analytics cookies in your browser; it cannot reach what was already recorded.
The dashboard is a normal authenticated application: it holds your account, your projects, and your billing details. Card numbers are never stored — the payment gateway returns a token, a brand, the last four digits, and an expiry.
Your plan’s retention window sets the period available for reporting, analytics, and export. Personal data is encrypted in transit and at rest.
Making a deletion request
Sign in and open Privacy in the dashboard. Identify the person by the user ID your app passes to setUserData(), by email address, by device ID, or by the Deeplinkly user ID shown on the Users page, and the erasure runs immediately. Matching on your user ID reaches every install we have linked to that person, not only their current device. Each request is recorded so you can evidence it later; the record stores a one-way hash of the identifier rather than the identifier itself, so the audit trail does not hold the data the request removed.
Access is limited to members whose role can edit app settings. clearUserData() remains the erasure path an SDK call can trigger directly, for the setUserData() fields.
Erasing a list of people at once
The same page takes a CSV of up to 1,000 subjects, or a pasted list of identifiers. One file can mix identifier kinds — a subject_type,identifier header — or name the kind once for the whole file with an identifier header.
It runs in two steps, and the first is not optional. Every row is validated before anything is cleared, and a file with any invalid row is refused whole: we will not erase the valid half of your list and hand you back the rest, because you would then have no way to say which subjects were done. You are then shown how many installs the list actually matches, before you confirm — the check that catches a well-formed file built against the wrong column. Each subject is recorded as its own audit entry, grouped under one batch, so a request from one person in the file can still be evidenced on its own.
Answering an access request
Users in the dashboard lists your installs and opens one person’s record: the details your app supplied, the campaign the install was attributed to along with any claim that superseded, the device and its last reported consent state, and a timeline of that person’s events and clicks. Search matches a whole email address or the start of one, your own user ID, a device ID, or the Deeplinkly user ID.
It is a separate permission from the rest of the dashboard, because reading a chart and reading your users’ contact details are different things. Personal details are masked until someone chooses to reveal one record. The CSV export is a further permission again, and every export is recorded — who took it, when, how many rows and which columns — with any search term stored as a one-way hash rather than in the clear.
What an erasure removes, and what it does not
It removes the identifying fields your app supplied and the device identifiers we matched the person by. The install record itself is kept with nothing identifying left on it, so your reporting totals do not change — an erasure is not a correction to your analytics.
It does not reach database snapshots taken before the request, which are encrypted and expire on their own schedule; data already forwarded to an advertising destination on your instruction; or your own exports and warehouse copies. Those need to be handled where they live, and the response times you promise your users should allow for it.
Recipients and subprocessors, legal bases, international transfers, retention commitments, and your rights are set out in the Deeplinkly Privacy Policy. Where this page and the policy disagree, the policy is correct and this page is a bug — tell us.