setTestDeviceAdvertisingIds not working for non-development environment

[padge]

MAX Module Version

5.7.2

React Native Version

0.71.3

Device/Platform Info

iOS 16.6.1

Current Behavior

The mediation debugger shows Select Test Mode Network - Enable (test mode NOT enabled), and presents a real/live interstitial ad on TestFlight. Calling setTestDeviceAdvertisingIds works fine in development mode.

import { requestTrackingPermission } from "react-native-tracking-transparency";

// ...

const trackingStatus = await requestTrackingPermission(); // press "Allow"
console.log(`[Ads] got tracking status: ${trackingStatus}`);

if (isDev || isStaging) {
  const myIdfa = await getIDFA(); // returns UUID from native module (calls ASIdentifierManager advertisingIdentifier)
  console.log(`[Ads] got IDFA: ${myIdfa}`); // confirmed not empty
  AppLovinMAX.setTestDeviceAdvertisingIds([myIdfa]);
}

const config = await AppLovinMAX.initialize(APPLOVIN_SDK_KEY);

It's not really feasible to have my testers open the Mediation Debugger and enable the Test Mode Network every time the app is launched. I don't want to show live ads either and have my account disabled.

On another note, requiring the IDFA isn't ideal either, since it requires pressing Allow for requestTrackingPermission which testers might not feel comfortable with. It would be nice to be able to call AppLovinMAX.setTestMode(true) or similar and not have to worry about it.

Thanks.

Expected Behavior

No response

How to Reproduce

See above.

Additional Info

No response

[philippeauriach]

I have the same issue here - we have a "staging" build of the app and I want to force test mode on this build, so that we don't get flagged. We tried setting the IDFA using the same method AppLovinMAX.setTestDeviceAdvertisingIds([myIdfa]); and the debugger still shows that we are live. What could be done ? thanks

[thomasmso]

@padge - unfortunately, we used to have that API in the past but have seen publishers release with that flag set to true. Thus, we opted for a more restrictive API. If you are still having issues with this, we can try to think of another solution.

@philippeauriach - what do you mean the "debugger still shows that we are live"? You can check if you're in test mode via our SDK's init logs:

...
===SDK Settings===
...
Test Mode On: false
Verbose Logging On: true
...

[padge]

@thomasmso that sounds like a one-off problem on their end? I wonder if that should have been caught in App Review. It's not that hard to do AppLovinMAX.setTestMode(__DEV__ || isTestFlight);. One would think that test ads in production would be less severe than production ads in development/staging? The flow of having to enable Test Mode in the Meditation Debugger (and allowing IDFA) is quite obnoxious and prone to error (the testing user forgets to enable test mode, and a live ad is displayed).

If you decide to not alter the behaviour, at least adding a note to the docs with all of those "gotchas" listed above would be great so developers aren't surprised.

I've been using a different ad library for now, since it doesn't require IDFA for test ads, and also allows for easily showing test ads in TestFlight (and I imagine also production, by mistake).

[thomasmso]

@padge - Having been in this industry for a decade, Murphy's Law definitely applies :). I agree that competent devs would be able to easily set the flag intelligently as you described though.

In the next SDK release, we can add a new row into the Mediation Debugger to indicate whether the device is currently in test mode or not.

Which ad library did you end up using that doesn't require IDFA for test ads?

[padge]

@thomasmso lol right, Murphy's Law 😆.

The library is invertase/react-native-google-mobile-ads. While they don't use IDFA, they do use IDFV, which is easier to get by using getUniqueIdSync from react-native-device-info, and it doesn't require a prompt. I think that's only for testing more production-like ads though, using production ad identifiers. Another difference is that they have an approval step that needs to be completed before showing ads in production (see here). Once admob approves the app to serve production ads, I wonder if test ads would still show in TestFlight or not 🤔 (not sure since I haven't released ads to prod yet).

[thomasmso]

@padge - We can also update our API to take in IDFV as well, that's trivial work and I'll add that. Also, AdMob test mode should work in TF, they despise dev teams showing live ads anywhere.

Let me know if you decide to come back to AppLovin MAX - we can support/advise you closer if needed - thomas.so@applovin.com. In the meantime, closing out this ticket.

[padge]

Thanks @thomasmso, I appreciate it!

[philippeauriach]

@thomasmso we don't have access to the logs in our staging build (this is a non public release build). What I want to achieve is to have a build where no one will ever see a production ad, only test ads, and I want to force that programmatically. How could I achieve that ?

[philippeauriach]

@thomasmso we don't have access to the logs in our staging build (this is a non public release build). What I want to achieve is to have a build where no one will ever see a production ad, only test ads, and I want to force that programmatically. How could I achieve that ?

[thomasmso]

@philippeauriach - You will have to wait until the next SDK update coming first half of Jan. Then for Android you can pass us IDFA and iOS you can pass us IDFV instead of IDFA which requires the ATT prompt and user interaction.

[JasonPan]

Hi @thomasmso - is this SDK update available now?

I noticed this PR but from some testing on my device, it seems like only IDFA works (test ads shown, isTestModeEnabled true); when I use only IDFV, I see that the conf's isTestModeEnabled is still returning false and live ads are shown.

Any ideas?

[thomasmso]

@JasonPan - As long as you are on the underlying iOS SDK v12.2.0 or higher which is bundled in our plugin v6.1.1+, it should work. If it still doesn't work, you can enable and send over our verbose logs and @alhiwatan can check it out during the workweek.

[JasonPan]

@thomasmso Thanks for confirming. I checked the plugin version and underlying SDK, versions are 6.3.0 and 12.2.1 respectively.

I got the logs as you mentioned, where is best to send?

I did have a look and I think I can see the issue, the IDFV returned by the library I'm using (react-native-device-info's getUniqueIdSync) returns a different ID compared to what AppLovin's logs say to use for IDFA / IDFV. What method do you recommend to get the correct IDFV? I just followed what was mentioned in the discussion

[thomasmso]

@JasonPan - Yeah, that's not the IDFV. This is it: https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor, I'm not sure of RN libraries that easily provide it but I'm sure they exist.

[JasonPan]

@thomasmso Thanks for your help - I figured it out now by diving deeper into the library's code. Need to use syncUniqueId to get IDFV, not getUniqueIdSync - subtle! 😄