I can't access to "Ad-ID" in the first session

[Mustafax06]

I need Ad-ID within 1 minute of the first session. But I could never get the ID in the first session, in the second session, it retrieves immediately. Can I get it in the first second? Here's my code (I'm initializing the SDK automatically, not manually);

private IEnumerator CheckAndSetAdID() { while (string.IsNullOrEmpty(Adjust.getAdid())) { yield return new WaitForSeconds(0.5f); } _purchases.SetAdjustID(Adjust.getAdid()); Debug.Log("Adjust ID has been set: " + Adjust.getAdid()); }

I need this ID because most of our users make their first purchases within the first minute of the first session. And RevenueCat receives the purchase and logs it to Adjust. So I need the Ad-ID ASAP in the first session but I could never get it.

Edit: sorry for the badly formatted code, I couldn't arrange it, sorry

[uerceg]

Hi @Mustafax06,

adid is a backend-side generated identifier which Adjust SDK gets only after it communicates for the first time ever with our backend and then gets this back in the answer we receive from the backend. When Adjust SDK is launched in the app for the first time ever, it sends a package we call a session to the backend. After backend responds to it, this is the first moment in which SDK gets the adid value, caches it locally and as of that moment on, provides it back if Adjust.getAdid() getter is called. We still do have a (nowadays) misfortunate implementation of this getter which is synchronous and will provide you with null back until SDK obtains the adid value, but this will change with the upcoming major SDK v5 release.

If one would want to capture the moment in which SDK is getting in possession of adid for the first time ever without the need to loop the "poll the getter -> get null -> retry" sequence, way to do that would be to implement session tracking callbacks. These callbacks would get pinged when session sending attempt succeeds / fails and if you'd check AdjustSessionSuccess and AdjustSessionFailure instances, they should contain the field which contains the adid value.

So I'd advise you maybe to give these callbacks a shot and double check if that works for your use case. Feel free to ping in case you have any further questions.

[Nawfel-bel]

Hello there @uerceg,
Can you please make sure that the SessionSuccessCallback and the SessionFailureCallback are working? because they dont seem to be invoked at all despite setting the delegates, just a simple log statement isnt even excecuted. which makes it difficult to understand when the adId is being cached

[Mustafax06]

It has been over a year, and this issue is still not resolved. As @Nawfel-bel pointed out, the callbacks are not being triggered at all. I can't even perform a simple check to see if the SDK is initialized.

It's incredibly frustrating to deal with a system that lacks such basic functionality. This isn't just an inconvenience; it significantly affects the usability and reliability of the SDK.

[uerceg]

Hey @Mustafax06 and @Nawfel-bel,

Sorry for the delay in replying to this one.

Session callbacks are going to be triggered when the session is attempted to be tracked. Not sure if there's maybe a misconception in what the session definition is. Session is a type of package that SDK will try to send to backend once it's initialized for the first time ever inside of an app. Once a session has been tracked, subsequent session will be tracked only if app spends more than 30 minutes outside of foreground. You can background the app, you can kill it - SDK doesn't make a difference between these two scenarios. But after the app has left the foreground, new session will be fired the next time the app enters foreground, if more than 30 minutes has passed in between. The fact that you are not seeing session callbacks being fired could be because in your tests the time for the session to be tracked has not come. How are you trying to see session callback being tracked in your tests? The easiest way to see the session being fired each time you run your app is if you reinstall it. Reinstalling the app will wipe all the SDK data it keeps track of and it will cause it to trigger new session upon initialization after reinstall.

Also, @Nawfel-bel, not sure if you saw it, but exactly in attempt to address the situation described in this issue, changes have been made in getAdid getter in the SDK v5 where it was made to be asynchronous so that users don't need to worry about the internals of the SDK's behavior when it comes to obtaining adid. In case you haven't, maybe you can try it out to see if it's now more suited for your use case?

[Nawfel-bel]

Hey @uerceg
Yep, took a look at that and using it thanks 👍 I had previously made a hacky workaround but this is much better

[Mustafax06]

Yes, uninstall did the trick for the callback. And for the ID, I got it in the callback so both of the issues are resolved. But getAdId still won't work on both iOS and Android, says adjust must initialized first.

If anyone encounters the same issue, just set a session tracking callback, and read the ID from the session. Thanks for the reply @uerceg

[uerceg]

As soon as the first session has been tracked by the SDK, adid is available (you can obtain it from the session tracking callback as well, but in case you have invoked the getter before the SDK has tracked the session, the getter callback will be pinged with the adid value pretty much around the same time as the session tracking callback). But yes, as you noticed it, in order for the SDK to return the adid value to the getter callback, the SDK needs to be initialized. We can try to check if we can improve on this and potentially make the getter to work regardless of the SDK initialized state after the adid is obtained from the backend.