adId is not available or arrives very late for many users, causing "Device not found" errors when sending events

[iremguner]

We are facing a recurring issue with ADID availability in our Flutter application.

For a significant number of users (approximately 1,000 users within the last week), the ADID is either:

• not available at all, or
• becomes available very late (around 15–20 minutes after app open).

Because of this delay, when we try to send Adjust events, we frequently receive "Device not found" errors.

Implementation details:

• We are calling getAdid() asynchronously.
• However, in many cases, the user completes a purchase before the ADID becomes available.
• Since the ADID arrives much later, the purchase events cannot be sent retroactively, and the events are effectively lost.

Question:
What could be the underlying reason for this behavior affecting such a large portion of users?
Is this related to OS-level privacy restrictions, SDK initialization timing, or something specific to the Flutter Adjust SDK?

Are you also suggesting using the adjustConfig.externalDeviceId method to identify users when the ADID is not yet available?

Environment:

Flutter version: 3.35.7

Adjust Flutter SDK version: adjust_sdk 5.5.0

Any guidance or recommended best practices to avoid losing critical events (especially purchase events) in this scenario would be highly appreciated.

[uerceg]

Hey @iremguner,

adid is a server-side generated Adjust identifier for given device. In order for adid to be generated, Adjust SDK needs to track an install from that device which means that it needs to send a request to our backend in response to which it will be informed about the adid value for this device. After obtaining the adid and persisting it locally, getAdid getter will be able to obtain that value and send it back to your callback.

Is this related to OS-level privacy restrictions, SDK initialization timing, or something specific to the Flutter Adjust SDK?

So the adid not being available on the SDK/app side of things is pretty much caused by the SDK still not obtaining it from the backend for whatever reason which should be related to the SDK initialization timing.

Are you also suggesting using the adjustConfig.externalDeviceId method to identify users when the ADID is not yet available?

If set, externalDeviceId is just a custom defined identifier for the device which our SDK will send to backend in the install request (after which backend generates adid on its end). So sending it will just mean that on our end, we'll know the mapping between the adid for this device and your custom defined external_device_id identifier. However, if the event is for some reason sent before install has been tracked, it the event request would contain external device ID or not.

• When are you initializing the SDK in your app in respect to timing of when those purchases are happening?
• You say you're getting "Device not found" errors -> where do you see those errors? In responses to SDK requests or are you trying to track something server to server?

[iremguner]

Hi @uerceg , thank you for your detailed response.

To clarify, the SDK initialization and event flow in our app is as follows:

• The Adjust SDK is initialized during the native splash screen.
• On iOS, the ATT prompt is shown immediately after initialization.
• Right after that, without waiting for the ATT response, we call the Adjust getAdid() method.
• If the returned adid is not null, we set it as a subscriber attribute in RevenueCat.

We are sending revenue events to Adjust via RevenueCat using their webhook (server-to-server).
If the adid has already been set in RevenueCat by the time the user makes a purchase, the revenue event is sent successfully.
However, if the adid is not yet set at purchase time, we receive a “Device not found” error on the Adjust side.

We have also observed cases within the same session where:

• The initial purchase fails because the adid was not available yet.
• A second purchase succeeds later in the same session, after the adid becomes available and is set in RevenueCat.

Based on this behavior, it seems that in some cases the install tracking and adid generation on the backend side is delayed, even though the SDK has already been initialized very early in the app lifecycle.

Given this setup:

• The “Device not found” errors are coming from Adjust as a result of S2S revenue events sent by RevenueCat.
• We are not sending any purchase events directly from the SDK.

From your explanation, we understand that using externalDeviceId would mainly help establish a mapping once the install is tracked, but it would not prevent “Device not found” errors if the revenue event arrives before the install/adid is registered.

Looking forward to your guidance.

[uerceg]

Hey @iremguner,

Thanks for the clarifications. Is any of these situations locally reproducible on your end (where you'd see RevenueCat s2s event to fail due to lack of adid)? If yes, running that scenario locally and sending the SDK verbose logs over would be helpful to see and to try to understand what's happening with the SDK in your app which might be causing this.

If you don't feel like sharing the logs in here, feel free to send them over to my email (you can find it on my profile).

[iremguner]

Hi @uerceg, thanks for the follow-up.

We were not able to reproduce this behavior locally in a debug environment. In our tests, the adid is obtained very quickly, usually within a few seconds after SDK initialization.

In addition, we have implemented the Adjust session success callback in the app.
When this callback is triggered, we send a corresponding event to BigQuery.

After reviewing our logs, we noticed that for users who later result in “Device not found” errors on the RevenueCat S2S revenue events, there is no session success callback triggered at all. Based on this, we are interpreting that for these users the session install request may not have been successfully tracked or acknowledged on the Adjust side.

Is this interpretation correct, i.e., that the absence of a session success callback indicates that the session/install was never successfully registered, which would also explain why the adid was not available at the time of the S2S revenue event?

Additionally, if it would help your investigation, we may be able to share the adid values for those users that were eventually obtained by the Adjust SDK at a later point.

Happy to provide logs if needed, but so far we have not been able to reproduce this scenario reliably in debug builds.