11.13更新
廣告标示符,适用于對外:例如廣告推廣,換量等跨應用的使用者追蹤等。
是iOS 6中另外一個新的方法,提供了一個方法advertisingIdentifier,通過調用該方法會傳回一個NSUUID執行個體,最後可以獲得一個UUID,由系統存儲着的。不過即使這是由系統存儲的,但是有幾種情況下,會重新生成廣告标示符。如果使用者完全重置系統((設定程式 -> 通用 -> 還原 -> 還原位置與隐私) ,這個廣告标示符會重新生成。另外如果使用者明确的還原廣告(設定程式-> 通用 -> 關于本機 -> 廣告 -> 還原廣告标示符) ,那麼廣告标示符也會重新生成。關于廣告标示符的還原,有一點需要注意:如果程式在背景運作,此時使用者“還原廣告标示符”,然後再回到程式中,此時擷取廣 告标示符并不會立即獲得還原後的标示符。必須要終止程式,然後再重新啟動程式,才能獲得還原後的廣告标示符。
在同一個裝置上的所有App都會取到相同的值,是蘋果專門給各廣告提供商用來追蹤使用者而設的,使用者可以在 設定|隐私|廣告追蹤 裡重置此id的值,或限制此id的使用,故此id有可能會取不到值,但好在Apple預設是允許追蹤的,而且一般使用者都不知道有這麼個設定,是以基本上用來監測推廣效果,是戳戳有餘了。
注意:由于idfa會出現取不到的情況,故絕不可以作為業務分析的主id,來識别使用者。
是以,IDFA就是用來跟蹤廣告推廣的,而UUID雖然每次不同,但是可以自己手動存入Keychain來進行唯一性的確定,這麼說來IDFA就是如果廣告商投放的時候使用,而UUID就是自己背景來判斷使用者是否換了裝置,或者資訊不一緻需要重新登入的業務
知乎上看到一個非常詳細介紹IDFA的文章
IDFA看這個就夠了
IDFA
可以了解為廣告id,apple公司提供的用于追蹤使用者的廣告辨別符。缺點:如果使用者完全重置系統((設定程式 -> 通用 -> 還原 -> 還原位置與隐私) ,這個廣告标示符會重新生成。
另外如果使用者明确的還原廣告(設定程式-> 通用 -> 關于本機 -> 廣告 -> 還原廣告标示符) ,那麼廣告标示符也會重新生成
這是iOS 6中另外一個新的方法,advertisingIdentifier是新架構AdSupport.framework的一部分。ASIdentifierManager單例提供了一個方法advertisingIdentifier,通過調用該方法會傳回一個上面提到的NSUUID執行個體。
// 擷取
//需要導入AdSupport.framework這個庫
#import <AdSupport/AdSupport.h>
NSString *idfa = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
// 判斷是否開啟
// 判斷是否開啟 限制廣告跟蹤選項(該選項在設定-隐私-廣告-限制廣告隐私)
Boolean on = [[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled];
1
2
3
4
5
6
7
8
ios10之前開關限制廣告追蹤選項的确沒什麼用,ios10之後,如果手機開啟限制廣告追蹤的話就不能再得到廣告辨別符,得到的是下面的0。這個開關是一個簡單的boolean标志,當将廣告标示符發到任意的伺服器端時,你最好判斷一下這個值,然後再做決定。
//開啟的時候
2016-01-05 15:22:19.218 sss[1773:60b] 41B2FD07-695A-4A27-8D26-C30ECE6F7EAD
2016-01-05 15:22:19.233 sss[1773:60b] 0
//關閉的時候
2016-01-05 15:19:57.502 sss[1763:60b] 7773E145-26FF-4304-A60F-60C948D52B40
2016-01-05 15:19:57.516 sss[1763:60b] 1
1
2
3
4
5
6
7
開啟和關閉切換的話,idfa會變,如果不切換,保持開啟狀态,每次都是不會變的,當切換了下之後就會變,或者還原的話會變
// 擷取IDFA的方法
+ (NSString *)getIDFA
{
SEL advertisingIdentifierSel = sel_registerName("advertisingIdentifier");
SEL UUIDStringSel = sel_registerName("UUIDString");
ASIdentifierManager *manager = [ASIdentifierManager sharedManager];
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
if([manager respondsToSelector:advertisingIdentifierSel]) {
id UUID = [manager performSelector:advertisingIdentifierSel];
if([UUID respondsToSelector:UUIDStringSel]) {
return [UUID performSelector:UUIDStringSel];
}
}
#pragma clang diagnostic pop
return nil;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
UUID
CFUUID—>2.0出現
NSUUID—>6.0出現
這兩個一個是CF架構下的,一個更加面向對象,擷取的時候更友善而已,其實擷取到的都是同一個東西
針對CFUUID需要注意的是:獲得的這個CFUUID值系統并沒有存儲。每次調用CFUUIDCreate,系統都會傳回一個新的唯一标示符。如果你希望存儲這個标示符,那麼需要自己将其存儲到NSUserDefaults, Keychain, Pasteboard或其它地方。
由于我們背景判斷App登入時根據uuid來判斷的在不同終端登入的,雖然上面提到UUID是擷取的時候一直在變化的,而且不是系統級别的存儲,那麼我們就需要自己存儲到系統,用到SSKeyChain,我們自己來保證一個手機理論狀态下對應一個UUID
+ (NSString *)getUUID{
NSString *openUUID = [[NSUserDefaults standardUserDefaults] objectForKey:OpenSessionID];
// NSLog(@"openUUID 一: %@",openUUID);
if (openUUID == nil) {
CFUUIDRef puuid = CFUUIDCreate(kCFAllocatorDefault);
CFStringRef uuidString = CFUUIDCreateString(kCFAllocatorDefault,puuid);
NSString *udidStr = (NSString *)CFBridgingRelease(CFStringCreateCopy( NULL, uuidString));
CFRelease(puuid);
CFRelease(uuidString);
openUUID = [udidStr MD5Hash];
// NSLog(@"openUUID 二: %@",openUUID);
NSString *uniqueKeyItem = [SSKeychain passwordForService:kUniqueIdentifier account:kUniqueIdentifierValue];
if (uniqueKeyItem == nil || [uniqueKeyItem length] == 0) {
uniqueKeyItem = openUUID;
[SSKeychain setPassword:openUUID forService:kUniqueIdentifier account:kUniqueIdentifierValue];
}
[[NSUserDefaults standardUserDefaults] setObject:uniqueKeyItem forKey:OpenSessionID];
[[NSUserDefaults standardUserDefaults] synchronize];
// NSLog(@"uniqueKeyItem: %@",uniqueKeyItem);
openUUID = uniqueKeyItem;
}
// NSLog(@"openUUID 三: %@",openUUID);
return openUUID;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
1.首先從沙盒擷取,沒有的話就調用CF方法擷取,然後再去keychain擷取,如果沒擷取到,把剛才擷取到的UUID存儲到Keychain,由于keychain你不刷機,存儲的東西會一直存在,是以保證了唯一性,每次擷取的都是從keychain擷取到的第一次存儲進去的值,那麼請求的時候,背景根據使用者主鍵盤點uuid是否更改進而判斷是否換了終端登入,進行彈框提示
總結:
1.idfa在使用者重置廣告标志符的時候會變化,是以可以把第一次生成的idfa存放到keychain裡面,以後就直接讀取keychain值就可以了,這樣就能避免使用者重置廣告标志符造成idfa的變化,而keychain的值隻有在使用者重置系統的時候才會删除,是以很适合用idfa+keychain的方案
2.那麼第二種方法也可以用,UUID+Keychain的方式也行,上面介紹了,我們就用的第二種,總之,keychain是個好東西,根據app的鍵,來存儲對應的使用者資訊,密碼等重要資訊還是不錯的,這裡簡單記錄下之前一直疑惑的知識點,友善以後查閱
IDFA送出Appstore選項相關
如何确定是否需要選擇IDFA???先看看下面的終端使用判斷是否需要勾選
iOS稽核中如何正确填寫APP廣告辨別符IDFA
1、在 App 内投放廣告
2、将此 App 安裝歸因于先前投放的特定廣告
3、将此 App 中發生的操作歸因于先前投放的特定廣告
4、對使用廣告辨別符做确認
1.serve advertisements within the app
服務應用中的廣告。如果你的應用中內建了廣告的時候,你需要勾選這一項。
2.Attribute this app installation to a previously served advertisement.
跟蹤廣告帶來的安裝。如果你使用了第三方的工具來跟蹤廣告帶來的激活以及一些其他事件,但是應用裡并沒有展示廣告你需要勾選這一項。
3.Attribute an action taken within this app to a previously served advertisement
跟蹤廣告帶來的使用者的後續行為。如果你使用了第三方的工具來跟蹤廣告帶來的激活以及一些其他事件,但是應用裡并沒有展示廣告你需要勾選第2項和第3項。
下邊還有一項
4.Limit Ad Tracking setting in iOS
這一項下的内容其實就是對你的應用使用idfa的目的做下确認,隻要你選擇了采集idfa,那麼這一項都是需要勾選的。
總結一下,
(1)如果你的應用裡隻是內建了廣告,不追蹤廣告帶來的激活行為,那麼選擇1和4;
(2)如果你的應用裡沒有內建廣告,但是需要追蹤廣告帶來的激活行為,那麼選擇2,3和4;
(3)如果你的應用裡內建了廣告,而且使用了sdk等用來追蹤廣告帶來的激活行為,需要選擇1,2,3和4 。
個人了解:當你有用到IDFA的時候,你是必須要勾選YES的,14年的時候很嚴格,剩下四個選項如果你選錯了很容易悲劇,現在感覺如果你選了YES,然後在找個合适的理由勾選,基本上沒問題了,例如你內建了UMENG的IDFA SDK,然後你有啟動廣告,你選1和4,一樣OK了
參考部落格,還介紹了其他辨別符
---------------------
版權聲明:本文為CSDN部落客「Deft_MKJing宓珂璟」的原創文章,遵循CC 4.0 by-sa版權協定,轉載請附上原文出處連結及本聲明。
原文連結:https://blog.csdn.net/Deft_MKJing/article/details/72911744