在APP的使用場景中有一種情景,在某款APP中看到一種活動轉發好友註冊可賺取佣金,因而直接在應用內點擊分享發送給微信好友,微信好友看到的是個URL連接形式的消息,點擊連接,微信內置瀏覽器打開H5頁面並提示是否在應用內打開,點擊打開按鈕,假如手機裏有安裝該應用,則會無縫打開,註冊後轉發者將會獲取5枚金幣;無應用跳轉至App Store應用市場。html
### 一鍵拉起(applink) URL Schemes (ios 9.4以前) Universal Link (ios 9.4以後) ### 記錄用戶鏈 ??? 複製代碼
咱們利用apple原生提供的Universal Link咱們能夠實現吊起應用,相關的技術點可參考蘋果官方文檔或相應的技術棧博客這裏就再也不贅述。ios
由於咱們無論不管用戶A與用戶B如何去創建起來連接,中間必定要有一層中間件用於保存二者的公共信息用做比較從而肯定其惟一性。這個中間件能夠視做爲服務器,或者是手機本地緩存。web
咱們先來分析一下咱們能夠用哪些方式來實現這個功能算法
這種情景的實現須要用戶A在分享出去的連接並同時發送一個註冊邀請碼,可由後臺生成並綁定用戶A的ID做爲惟一標識,用戶B在打開連接後看到頁面的同時也能夠看到該邀請碼,當打開應用後的註冊階段,須要填入邀請碼,註冊成功,並上傳至服務器信息包含新用戶ID + 邀請碼。服務器開啓規則判斷,若是存儲的邀請碼中有跟以前重複的字段,則開啓查找邀請者,並下發用戶A以相應的獎勵數據api
這種實現場景其實跟上條中的方案大同小異,只不過是將邀請碼轉換爲圖片的形式進行處理,邏輯上少了新用戶手動輸入邀請碼的步驟,但卻多了須要用戶將此二維碼保存相冊或開啓相機掃描的步驟瀏覽器
上述的兩種方案中確實能夠實現如何將用戶關係進行聯繫起來,現有的APP中也有這種作法並規模化的。然而暴露出的問題是繁瑣性及用戶有感知體驗緩存
而如何要求其是用戶無感知,咱們想到如下的一些方案安全
這種場景的實現方式爲,用戶A分享連接中攜帶有隱藏拼接的邀請碼,新用戶在H5頁面中打開時同步操做對此連接進行隱藏複製。繼而新用戶在打開APP的註冊頁面時,利用[UIPasteboard generalPasteboard]系統API剪貼板方法進行查找複製,過濾出該邀請碼以後連同註冊請求一塊兒上發到服務器,進行對比查找可對應上用戶關係bash
該方案有個前提是須要用戶Safari瀏覽器打開H5頁面,獲取到該設備的UDID+用戶A的 ID後上傳服務器,在註冊階段時再利用iOS原生獲取該設備的UDID+新用戶ID上傳,服務器對比後下發信息。參考連接:www.skyfox.org/safari-ios-…服務器
iOS系統基於OSX,其也有文件系統的訪問權,/private/var/folders。具體實現思路爲新用戶在打開H5頁面以後同時保存用戶A的ID保存至該文件下(不知道具體怎麼作),打開APP以後註冊階段再利用iOS方法獲取到該文件夾下的信息+新用戶ID上傳服務器,作用戶ID校驗。
上圖爲利用愛思助手打開的iPhone文件管理
在用戶之間的關係鏈被創建起來的基礎之上,還需爲其加固確保鏈條之間的穩固性 諸如:
1.用戶之間是否爲辦公室同事或家庭成員(獲取WiFi網絡IP做爲協助參數)
2.用戶之間是否位於同一區域(獲取地理座標做爲協助參數)
3.是否能夠在H5頁面上作文章已實現web端對設備的個性化採集更爲豐富
...
複製代碼
在這諸多的條框以外還要有更多的額外需求:
而爲了如何確保全部場景下都能打通;
而如何肯定其穩定性及準確度;
而如何確保相同設備重複不斷的安裝惡意刷單等
故無感知記錄關係鏈中最重要的核心是準確度。而要達到這種看似簡單的邏輯下是須要通過一套複雜的算法來加持,能在H5頁獲取到該用戶的信息越多,其在鎖定用戶的標準閾值越高,就會越準確。
如今市面上已經有一些比較成熟的三方SDK庫來較好的實現需求,然而對於技術的追求應該是一種態度,學而不思則罔,即便作到儘量準確也是對於技術瓶頸的突破。