Hacker News Reader

Comment by FireBeyond | Hacker News Reader

I’m not sure my understanding of this is correct. It seems to be crying about the problems this will cause. Ostensibly, it’s saying that there’s a problem with the identifier for ads being requested in apps that don’t have ads (i.e. being used as a surrogate identifier).

But, more nefariously (again, if my understanding is correct) it’s saying that many ad networks rely on this info being passed to advertisers (despite the policy being that it shouldn’t), and how problematic it’s going to be if Apple enforces this policy.

If this is the case, my sympathy is close to zero. Not because “advertising = bad”, but because this was a known no-no. Don’t cry foul when you can’t do what you were told you couldn’t.

View on HN

I think what they're saying is that for something as simple as analytics (just an example), apps need some sort of unique identifier for the user, but that the only unique identifier iOS provides is the advertising ID of the user. Of course the correct answer is to stop doing any sort of analytics, or anything else that requires a unique identifier. But the point I think the author is making is that that is a bad solution.

Of course this all ignores the possibility of creating user accounts or generating a unique identifier whenever the use installs the app, so maybe there is something more to it that I'm not understanding. Because I tend to agree with you, that developers shouldn't be doing something with user data that is prohibited.

> Of course this all ignores the possibility of creating user accounts or generating a unique identifier whenever the use installs the app

Which is exactly what Apple recommended when they stopped letting apps get a hold of the UDID.

I can't think of a really good legit reason for wanting a cross-app unique ID.

> I can't think of a really good legit reason for wanting a cross-app unique ID.

The use case that's affected the most by this change is that of advertisers who want to track the performance of ads they buy from publishers, which I think is a legitimate need. The fact that the IDFA uniquely identifies an iOS device (unless the user resets it) is a side effect of Apple's implementation of it; all app advertisers really want is the same kind of first-party conversion tracking for their apps that's standard everywhere else on the web.

Agreed - app advertisers are playing a performance marketing game with their install ads. This change is going to make user acquisition more tedious in several ways: - some networks will become straight CPC, which will be a pain in the ass to arbitrage to a CPI - there will be a lot of campaign monitoring required - other methods of install attribution simply aren't as reliable. This will affect the eCPMs of in-app advertising that consisted of app-install demand.

If you are doing analytics of your users (instead of measuring your advertising), then you can use IDFV and should not be using the IDFA. The IDFV should always be the same whenever your app looks at it, whereas the IDFA is subject to change depending on the user's privacy configuration.

IDFV would be perfect. Just need to be aware of one caveat, if the user deletes all apps from a developer (or is on another device) and reinstalls an app, the IDFV will be different. Seems like they could come up with a solution that hashes some company and user attributes to provide a consistent ID across all of a single developers apps.

The issue is that many libraries still used this function to uniquely identify devices for analytics (e.g. content-based advertising?) or for legitimate functionality (TestFlight, cross app communication). Many people might drag-and-drop a library into their app, it all works, and then suddenly their next update is now rejected and it wasn't "their fault". Some, as on stackoverflow, don't even know where to begin to address the issue.

Reply on news.ycombinator.com