Documentation

What to declare in your privacy manifest

Exactly what the SDK collects, what that means for your App Store submission, and how to handle an erasure request.

@quberoute/sdk is a pure JavaScript package and ships no privacy manifest of its own. Apple’s manifest requirement applies to binary frameworks and to a published list of commonly-used SDKs; a JavaScript package bundled into your web layer is neither. Nothing in your build will prompt you.

That makes this your disclosure to make, on our behalf, and this page exists so you can make it accurately in about five minutes.

Everything the SDK sends us

Every field the SDK transmits, with an example and why it is sent
Field	Example	Why
`platform`	ios	Matching, and your report
`osMajor`	17	Matching. Major version only — never 17.4.1
`deviceClass`	phone	Matching. A class, never a model
`locale`	en	Matching. Primary subtag only — never en-GB
`timezoneOffsetMinutes`	60	Matching
`screenClass`	compact	Matching. A bucket, never a pixel count
`installToken`	random	Joining a later purchase to the install
`sdkVersion`	0.1.0	Tying odd behaviour to a release
`url`	the link tapped	Only when resolving a link the app was opened by. On the web the query string and fragment are stripped first.

Our server additionally records a salted hash of the network address the request came from. The address itself is never written to disk anywhere in our system.

What the SDK does NOT collect

Stated explicitly, because these are the questions App Store Connect asks you and the answer to every one of them is no:

No advertising identifier (IDFA) and no App Tracking Transparency prompt. The SDK never calls it and never will.
No vendor identifier (IDFV), device name, model, or serial.
No location, precise or coarse. We record a two-letter country only when a CDN has already worked it out for us.
No contacts, no photos, no list of installed apps, no carrier, no battery.
The clipboard, only if you switch clipboard matching on — and then only once, on the first launch of an install, and only to look for a token we put there ourselves. Anything else on the clipboard is discarded on the device: not sent, not logged, not shown to your error handler.

The one permission the SDK can cause to be asked for

This page said the SDK requested no permissions. That stopped being true when clipboard matching shipped, and it is corrected here. Reading the clipboard is permission-gated on iOS 16 and later: the system asks your user, and your user can say no. A refusal costs nothing — the SDK reports that it looked and found nothing, and matching carries on without it.

It is the only permission any part of the SDK can cause to be requested, it happens at most once per install, and it does not happen at all unless you turned clipboard matching on in your app settings, where it is off by default. What your users actually see.

Your App Store answers

With a default integration, the honest answers are: Identifiers → User ID: collected, linked to the user, used for app functionality and analytics — that is the install token — and Usage Data → Product Interaction if you call track, plus Purchases if the events you track carry a value.

Answer no to tracking, in Apple’s sense of the word: we do not link this data to third-party data, and we do not build a device graph across apps. Two apps using QubeRoute on one phone hold two unrelated tokens and neither can see the other’s.

If you add a privacy manifest anyway — many teams do, for their own record — the reasons that fit are below.

PrivacyInfo.xcprivacy — the entries that describe our collectionxml

<key>NSPrivacyCollectedDataTypes</key>
<array>
  <dict>
    <key>NSPrivacyCollectedDataType</key>
    <string>NSPrivacyCollectedDataTypeUserID</string>
    <key>NSPrivacyCollectedDataTypeLinked</key>
    <true/>
    <key>NSPrivacyCollectedDataTypeTracking</key>
    <false/>
    <key>NSPrivacyCollectedDataTypePurposes</key>
    <array>
      <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
      <string>NSPrivacyCollectedDataTypePurposeAnalytics</string>
    </array>
  </dict>
</array>

The install token, in one paragraph

A random value the SDK generates the first time your app runs, kept in your app’s own storage. It exists so a purchase six weeks later can be attributed to the link that produced the install. It is not derived from anything about the device, it is not readable by any other app, it does not survive deleting your app — a reinstall is a new install — and it is never used for matching. It is functionally what Apple’s own identifierForVendor does.

Erasure requests

For this data you are the controller and we are the processor, so a “delete my data” request arrives at you. One line satisfies it:

In your “delete my data” handlertypescript

await qr.reset()

In one transaction on our side, that deletes:

the install record, including its attribution;
every event ever recorded against it, and the money with them;
the match candidate that attributed it, if one is still inside its 60-minute window.

It then deletes the local token, the first-launch marker and any queued events from the device — even if our server cannot be reached, because somebody who asked to be forgotten should not stay identifiable on their own phone because we were having a bad minute.

What it does not delete, honestly: the click itself. A click record holds a salted hash of an address and no identifier at all, so there is nothing in it that can be tied back to a person — including by us — and therefore nothing to erase. Your aggregate click counts do not change.

Retention

Match candidates: 60 minutes, then deleted. Not filtered out — deleted.
Installs and events: kept until you delete them, because they are your reporting data.
All of it is stored in the United Kingdom. See security.

Next: Cordova, React Native and the web.

Ask the documentation

It answers from these pages only, and links what it used. If the answer is not here it says so rather than guessing — then email [email protected].

← All documentation