User advertisement id is not registered in Adjust

[Harits514]

A few of our user advertisement id is not registered in adjust.
When we send a s2s event request to adjust with the gps_adid of those user it will return 404 device not found error, even though those user already using our latest app version that has Adjust sdk in it.

We have already called onResume and onPause in didChangeAppLifecycleState function:

@override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    switch (state) {
      case AppLifecycleState.paused:
        Adjust.onPause();
        _bloc.dispatch(HomeEventGoingBackground());
        break;
      case AppLifecycleState.resumed:
        Adjust.onResume();
        _bloc.dispatch(HomeEventGoingForeground());
        break;
      default:
        break;
    }
    super.didChangeAppLifecycleState(state);
  }

The code works fine for nearly all of our users, only a few users are affected by this problem.
Some users gps_adid that returned 404 error before get a 200 ok response after a few hours, but there is also some users gps_adid that get 404 from the first time we integrated Adjust sdk up until now (around 7 days).
Currently we doesn't have any access to device or account that has this problem so we can't reproduce the problem and give you the logs.

We already know how to detect if the user is not registered via checking
Adjust.getAttribution() != null
so we can dodge s2s request that will give errors, but our team wants no data to be lost and all users behavior to be registered.

can you please help us with this problem?

[uerceg]

Hi @Harits514

Sorry for a bit delayed answer. Hm. In theory if you're just seeing issues with few devices, it does sound probable to happen in some cases, but also highly depends on tracking setup as well.

In cases where you get error on s2s event that device is not found, it happens for one simple fact - for some reason from that device, our backend still didn't get install session tracked, so by the time you track s2s event, we don't know about the device and this is what causes rejection. Retries to track s2s event are great way to go, but in theory if for some reason SDK failed to send install session (maybe at that time device had no internet connectivity) and before it managed to successfully send it, user uninstalled an app (or left it unopened ever since), but in time for your s2s event to get triggered, that might explain you not seeing this particular user still days after. If he eventually open an app and SDK tracks install session, you'll see him. If app gets uninstalled in the meantime, then probably not.

Checking for attribution value is not a bad criteria, but it's kinda manual since it's a simple synchronous getter. If timing of your s2s event tracking is not engraved in stone by your business logic but you can track it when ever as long as you are confident that we know about the device, maybe you can try this reasoning approach.

Upon first app launch after user has installed your app, first thing which SDK tries to do is to track session package. This tracking can succeed (will be counted as install if we see this device for the first time or just as a new session if we already know about the device) or fail (lack of internet connectivity or servers unreachable). If it succeeds, you have a way to register session tracking success callback in which upon triggering you will get information about Adjust identifier of that device (adid) and existence of this parameter should be pretty confident information that we know about this device so if you try to track s2s event with same gps_adid which was used when tracking install session with the SDK, things should be fine and s2s event should be tracked.

For session tracking failure you have similar callback you can register. But if this callback gets triggered if internet connectivity is off or servers unreachable, then you won't get adid in the reply. In that moment, our SDK will attempt to ask for attribution value just in case and if this call succeeds, attribution callback will be triggered if implemented with this information which would indicate that we know of this device. In case of failures, this is probably best way you can take. For the record - session tracking failure callback can be triggered even if session is successfully tracked, but backend rejected it because it was triggered too frequently (for example user uninstalling and reinstalling an app within 30 minutes since last session) - in this case you will have adid at your disposal.

So maybe trying to switch your logic to these callbacks since those are in theory places which once pinged are giving you earliest possible information that this device is known to our backend.

In case you have any further questions, feel free to ping.

Cheers

[Harits514]

Thanks for the answer mr @uerceg, by the way i have some question and context on how our system works

Retries to track s2s event are great way to go

what retries here refer to? Do we need to retry our s2s request? If so, how do we know when to resend it?

If for some reason SDK failed to send install session (maybe at that time device had no internet connectivity) and before it managed to successfully send it, user uninstalled an app (or left it unopened ever since), but in time for your s2s event to get triggered, that might explain you not seeing this particular user still days after.

Our s2s event triggered when a transaction is successful, the transaction itself is triggered in app. We use s2s request so we could know exactly when the transaction is successful. The transaction might take a lil' bit of time to complete but it should not be that long. We assume there is nearly no way that the user uninstalled the app while the transfer is on progress, because they should already know that it will be really non beneficial for them to uninstall the app when they already send their money and it will also make them never know when the transaction is successful(we only register successful transaction to Adjust). There is also this particular user who do a lot of transaction in a week (>70), and all of his transaction is not registered because of the 404 error, its safe to assume that this user is not uninstalling the app on each of his transaction.

Will the SDK do retries to track session package even if we doesn't include sessionFailureCallback in the program? Which parameter in sessionFailureCallback that can help us know why the tracking is unsuccessful?

[uerceg]

Hi @Harits514

Oh, with retries I was referring to this sentence of yours:

Some users gps_adid that returned 404 error before get a 200 ok response after a few hours

I thought that getting 200 after few hours means that you retried s2s event at some later point from your end and got the answer?

If session package was not successfully sent upon initial attempt, we will trigger session failure tracking callback if you have implemented it and retry sending of that session package at some later time, regardless of the fact whether you have implemented the callback or not. Sole fact that session tracking failure callback was triggered indicates that session tracking failed. Once it gets successfully tracked, session tracking success callback would get triggered in this case.

[Harits514]

I thought that getting 200 after few hours means that you retried s2s event at some later point from your end and got the answer?

No, i mean the user that has unidentified id before is doing another action that triggers this s2s request, and they got 200 this time

@uerceg Is there any useful information in session failure tracking callback that can help your team to tackle this problem? If so our team will implement it so we can give the information to you.

[uerceg]

Hi @Harits514

Sorry again for a bit delayed answer. Unfortunately probably nothing much would have been of the assistance to us unless you maybe manage to get the SDK verbose logs when running test scenario in which you managed to get your s2s request rejected. In that case, if we would have verbose logs from entire SDK run prior to your attempt to track s2s even, we would be able to see what caused s2s event rejection. Is this something you can reproduce? (I assume it's probably really hard to reproduce this locally).

Alternative would be to either ping your dedicated account manager or write email to support@adjust.com with information about your app token and they can try to do deeper traffic analysis and hopefully discover something more.

[uerceg]

In case you need any further assistance on this one feel free to comment/reopen. Cheers.