This is a relic of how IDFAs were handled pre-iOS 10. At that time, you could still access the IDFA when LAT was enabled, but you had to pinky-promise not to use it for advertising tracking (although frequency capping, fraud detection, and other uses were still permitted). With iOS 10, IDFAs were zeroed out when LAT was enabled, meaning SDKs were free to pull the IDFA without first checking isAdvertisingTrackingEnabled. Many widely used SDKs understandably continued the legacy practice though.
For some SDKs, that practice continues to this day. When Apple pushed out iOS 14 a week ago, they deprecated the isAdvertisingTrackingEnabled property. See the relevant Apple docs here.Â Â As you can see, now it always returns “no”. Unfortunately, “no” isn’t just a default value that tells app developers that LAT is a thing of the past. To some pre-iOS 14 SDKs, it means that LAT is very much alive and enabled on the device (or advertising tracking is disabled).
For anyone using an SDK that has not yet been updated to support iOS 14, there is a chance that it checks isAdvertisingTrackingEnabled prior to accessing the IDFA. If it does, you will see LAT rates quickly increase since iOS 14 dropped a week ago. This can have a lot of significant ramifications for attribution, campaign optimization, and ad monetization, depending on the purpose of the SDK.
Upgrade your SDKs as soon as possible. Stay in touch with the vendors who haven’t yet provided an iOS 14 update. Continue to be vigilant during this 3+ month IDFA deprecation reprieve. Test thoroughly. Submit a meeting request below if you’d like feedback on your testing approach.Â The winners will be those that evaluate and adopt the solutions of the future while everyone else is still exhaling.