Integration Method: Any
Xcode Version: Any
Library Version: 4.x, most likely earlier releases too
Platform: iOS
Language: Any
Description:
AppClips have an annoying behavior where identifierForVendor on UIDevice silently returns a zero'd out UUID. This means that anybody passing true for useUniqueDistinctId will end up with all events rolled up under a single identifier, breaking any reports relying on unique events (typically, funnels).
useUniqueDistinctId is also confusingly named. false implies don't use a unique distinct ID, which is kind of weird for an analytics library featuring unique/total for each event, specially given that it's the default value. Looking at the implementation, it's of course not what it does, what it really means is "use device specific distinct identifier" (as opposed to "use a completely random distinct identifier").
You may say "well, don't pass in true for that param in an app clip then", and you wouldn't be entirely wrong. However, a case can be made for either of the following:
rename useUniqueDistinctId to useIdentifierForVendor which would help clue consumers of the API that something is about to go wrong (I guess the macOS variant of defaultDistinctId can make that renaming problematic). Or at the very least document a little bit better what useUniqueDistinctId actually does in the init/sharedInstance methods
additionally, if useUniqueDistinctId is true and the identifierForVendor comes back zero'd out, fall back to NSUUID generation (which is currently done if the identifier is nil) or at the very least log a big warning to the console for the developers to be aware that something bad is happening
I'm happy to send out a PR for this, I'm just not sure which (if any) suggestion you'd rather go with.
Integration Method: Any Xcode Version: Any Library Version: 4.x, most likely earlier releases too Platform: iOS Language: Any Description:
AppClips have an annoying behavior where
identifierForVendoronUIDevicesilently returns a zero'd out UUID. This means that anybody passing true foruseUniqueDistinctIdwill end up with all events rolled up under a single identifier, breaking any reports relying on unique events (typically, funnels).useUniqueDistinctIdis also confusingly named.falseimplies don't use a unique distinct ID, which is kind of weird for an analytics library featuring unique/total for each event, specially given that it's the default value. Looking at the implementation, it's of course not what it does, what it really means is "use device specific distinct identifier" (as opposed to "use a completely random distinct identifier").You may say "well, don't pass in true for that param in an app clip then", and you wouldn't be entirely wrong. However, a case can be made for either of the following:
useUniqueDistinctIdtouseIdentifierForVendorwhich would help clue consumers of the API that something is about to go wrong (I guess the macOS variant ofdefaultDistinctIdcan make that renaming problematic). Or at the very least document a little bit better whatuseUniqueDistinctIdactually does in the init/sharedInstance methodsuseUniqueDistinctIdis true and theidentifierForVendorcomes back zero'd out, fall back toNSUUIDgeneration (which is currently done if the identifier is nil) or at the very least log a big warning to the console for the developers to be aware that something bad is happeningI'm happy to send out a PR for this, I'm just not sure which (if any) suggestion you'd rather go with.