Store detection and verification

Adjust detects and verifies which store an install came from across a wide range of app stores, including Google Play, the Apple App Store, Huawei AppGallery, and many others. This article explains how detection works by default, when you need additional signals for more precise results, and what happens with fallback and multiple signals.

Detection and verification

Adjust answers two questions for every install: which store did it come from, and can that be independently confirmed?

• Detection makes a best-effort match immediately, using whatever signals are available at install.
• Verification then checks that match against independent evidence, such as an install referrer API call or a store license check.

The verification result is recorded as an additional signal alongside the store type. For example, if an install is detected as Google Play but verification fails, the system still shows the store as Google Play, with a verification result of failed.

How detection works by default

Detection starts from the operating system reported by the device. For most operating systems, there's exactly one store associated with it, so detection is deterministic without any extra integration on your part. For example, iOS installs are matched to the Apple App Store, tvOS installs to the Apple App Store (TV), and this holds for CTV and Console platforms.

A small number of platforms, most notably Android but also PC, don't have a single store associated with them. Google Play, Huawei AppGallery, Xiaomi GetApps, Samsung Galaxy Store, and others all run on Android, so the OS alone isn't enough to tell them apart. This is where additional signals, described below, improve precision. Skipping them doesn't break detection — it just means Adjust can't tell the specific store apart on its own. What you'll actually see instead depends on your settings: the default store you've configured for that operating system, or Unknown if you haven't set one. Fallback behavior covers this in detail.

Additional signals for multi-store platforms

These signals aren't required — the system works out of the box. But without them, Adjust can only report the safe default: a less-precise detection, or a skipped verification, not a real result for your setup. Adjust has no way to know in advance which stores or verification methods you actually use, so tuning means telling it what to check for your integration.

All five referrer methods above are controlled by the same Referrer check setting in Store verification configuration, set independently per store.

What you need to integrate

Each additional signal depends on a minimum SDK version, and in some cases a plugin or configuration step. If you're behind on SDK version, you won't see an error. The signal is just never sent, and detection continues to work using whatever signals are available.

For S2S integrations, the intended store name and app ID can be shared via the store_name_from_client and store_app_id_from_client request parameters.

Fallback behavior

When Adjust can't determine a specific store for an install, Fall back to platform default when undetected falls back to the store you've configured as your app's default for that operating system, rather than marking the install as unknown. This fallback is on by default and can be turned off if you'd rather see installs marked as unknown than have them attributed to your default store.

If you turn fallback off and also turn on Require SDK/S2S store type signal, an install with no client-declared store name is marked as unknown outright, with no fallback attempted. See Configuring store detection and verification for where to change this.

How multiple signals are resolved

Most installs only ever produce one store signal, so there's nothing to resolve. Occasionally, though, more than one signal comes in for the same install — for example, an initial detection followed later by a verification check, or two separate signals that each point to a different store. When that happens, Adjust follows this priority:

1. Pre-install always wins. If an install is identified as pre-loaded, that answer sticks — any other signal is ignored, whether it's present in the very same request or arrives separately, later.
2. The first usable signal is accepted, if nothing is on record yet.
3. A verified result is protected. For example, once an install is confirmed as Google Play through the install referrer check, a later, unverified signal suggesting a different store doesn't change it — Google Play stays on record. Only another verified result can override an already-verified one.
4. On Android, the system-reported store wins over your configured store, by default. If store_name_from_system and store_name_from_client disagree in the same request, Adjust uses the system-reported value, since it comes from the OS itself rather than from your integration. Unlike the other cases here, this isn't an unresolved standoff — it's a deterministic, per-request choice, and you can flip it with Require SDK/S2S store type signal to prioritize your configured value instead. See Additional signals for multi-store platforms.
5. A genuine standoff is reported as unknown. If two different, unrelated signals — neither one verified — point to two different stores, whether they arrive in the same request or in separate ones (say, one looks like Steam and another looks like Epic Games), Adjust has no way to pick a winner. The install is marked unknown, the same result you'd see if no usable signal had arrived at all. Unlike the other cases above, this one doesn't self-correct: once an install lands here, it stays unknown even if more signals arrive afterward.

Outcome reference

Detection always resolves to exactly one store_type value per install — this table lists every value it can take. Verification is tracked separately, as its own result per method (LVL, install referrer, Adjust SDK Signal), and doesn't change which store_type value is shown here — see Where this shows up for how store_type and verification results are each made available in callbacks and reporting.

store_type can show any store Adjust supports — detection recognizes these automatically from the signals available, whether or not you've added that store in Platform settings. Preinstall, Custom, and Unknown are different: they aren't store names at all, but labels Adjust assigns automatically when an install doesn't map to a specific, supported store.

Configuring store detection and verification

You don't need to change any settings for detection and verification to work. Adjust detects stores using the available signals and default settings automatically, and the results are already available in your reporting.

If you want to improve precision for specific stores, or control how strict verification is, you can adjust this under AppView > Protection > Store detection and verification settings:

• App level configuration, which covers detection settings such as Fall back to platform default when undetected and Require SDK/S2S store type signal.

• Store verification configuration, which applies per store type. This is separate from detection — detection recognizes any supported store automatically, regardless of Platform settings (see Outcome reference) — but to turn verification checks on or off for a specific store, that store needs to be configured in your platform settings first. Verification configuration is available for: Google Play, Google Play (TV), Google Play (PC), Huawei AppGallery, Xiaomi GetApps, Samsung Galaxy Store, Vivo Appstore, Apple App Store, and Apple App Store (TV). If you don't see a store here, add it from the Platforms tab — see Connect your platform.

These are the defaults before you make any changes:

We recommend reviewing your SDK or S2S integration, platform configuration, and these verification settings to improve the quality of the detection and verification process, even though none of it is required for the system to work.

LVL settings

Google Play License Verification (LVL) is a stricter verification method that checks an install against Google's licensing service directly, rather than relying on the referrer alone. It's a general check, required for any store in the Google Play family, turned on via Turn on License Verification Library (LVL) integration under General store checks. It's off by default, and you can only turn it on once you've configured your app's public key — the toggle isn't available until then.

Once enabled, Adjust evaluates each enabled verification method independently. If you also have referrer check enabled for the same store, the overall verification result is failed if either check fails, even if the other passes. The result is passed only if neither check fails and at least one passes.

Where this shows up

Detection and verification run for every install, whether or not you use any of the surfaces below. Store Rules in Conversion Rules are one way to act on the result — not a requirement to benefit from it. You can read store type and verification results directly, without setting up a Store rule, through raw data, callbacks, or reporting dimensions.

In client and partner callbacks, for apps using store-related placeholders:

• {store_info} returns a JSON object built from the raw signals Adjust received. The JSON field names differ from the request parameter names used earlier in this article: from_system corresponds to store_name_from_system, from_client corresponds to store_name_from_client, and app_id corresponds to store_app_id_from_client. On Android, from_system is the raw installer package name (for example com.android.vending for Google Play) — not the resolved store name. For example:

{
  "from_client": "google_play",
  "from_system": "com.android.vending",
  "app_id": "com.example.app"
}

Only fields with a value are included, so an install with no client-declared store returns a JSON object without from_client and app_id.

Two further fields, initiating_package_name and originating_package_name, may also appear in this object when the platform reports Android install-source information — they come from the same family of Android install-source APIs as from_system, capturing which package requested versus which package originated the install. They're passed through as received and don't affect detection.

• {store_type} returns the resolved store type as a single value, for example google_play, custom, or unknown.
• {store_verification_result} returns the overall verification result. Possible values: passed, failed, skipped.

{
  "store_verification_result": "passed"
}

• {store_verification_result_lvl} — verification result for LVL. Possible values: passed, failed, skipped.
• {store_verification_result_referrer_api} — verification result for the install referrer API. Possible values: passed, failed, skipped.
• {store_verification_result_app_store} — verification result for the App Store check based on Adjust SDK Signal. Possible values: passed, failed, skipped.

{
  "store_verification_result_lvl": "failed",
  "store_verification_result_referrer_api": "passed",
  "store_verification_result_app_store": "skipped"
}

As aggregated data, as dimensions:

• App store type (store_type), which lets you group by the detected store type for an install
• Platform (platform), which lets you group by the platform the store type belongs to (Android, iOS, CTV, PC, Console, Other)
  • OS name (os_name), which lets you group by the OS the install happened on

In Conversion Rules Store rule conditions, you can act on the resolved store type and verification results directly.