接下來，我們會逐步分析前文所述的各種ad fraud的特征并說明我們可以采取的應對策略。當然純靠開發者自身依然無法保證百分百避免作弊流量，所以我會再介紹一下不同MMP平臺提供了哪些工具以及如何利用這些平臺提供的功能做出我們自己獨特的解決方案。
設備農場：作弊平臺通過模擬器重置設備ID的方式，反復刷新并虛擬點擊廣告主廣告，批量大規模下載安裝廣告主應用。機器人：作弊平臺通過惡意代碼，實現反編譯歸因等平臺的SDK，實現模擬安裝的行為。（常見于開源SDK）本質上這兩種方法產生的用戶都不是真實的用戶，所以對廣告平臺的風險極大。我們先探討設備農場的進化史：虛擬機->刷機/改機->設備農場->云端設備->積分墻->混量->more......虛擬機指的是利用電腦模擬手機等移動設備，實現偽裝。刷機：通過修改設備上的Device ID如GAID、IMEI和OS Version等移動設備信息實現偽裝。目前簡單的刷機基本逃不過風控和MMP的檢測。改機：簡單來說，就是通過逆向排查應用設備的環境參數去獲取設備參數位置，然后偽造信息、協議后就可以實現定制化偽裝真實設備。設備農場：用單個的真實實體移動設備去實現偽裝。常見的場景如下：當然聰明的作弊者為了規避被檢出率會去洗白設備。作弊者為了繞過MMP的檢測機制，會通過走代理的方式，直接刷頭部Ad Network+大App的量來洗白自己的設備。這個方法去年被海外的MMP設置了渠道和代理雙向握手驗證。不過路是死的，人是活的，所以......積分墻：這個內容不好說。目前國內對這個的定義很模糊。比如網賺產品尚且可以定義為違規，但是地推流量、常見的Digital Turbine、Tapjoy這些大型積分墻業務公司又是合規的正向產品（如果流量下游審核嚴謹，不來自網賺/刷機的話）。混量：目前很多作弊渠道在流量采買上是多種形式混合而成的。它不一定全部是虛假安裝的流量，往往是一部分真實流量再加一些歸因劫持/大點擊/虛假設備的量。這樣混裝起來，能夠實現甲方的KPI要求，同時自己也有利潤空間。接著，我們梳理一下機器人：作弊平臺通過惡意代碼，由隱藏在用戶設備中另一個應用程序上的惡意軟件執行，實現反編譯歸因平臺或者其他廣告平臺的SDK，實現模擬安裝的行為。具體來看，作弊者劫持SDK（假設為應用程序內數據分析的SDK）及其后端服務器的SSL加密通信，進行MITM攻擊。一旦攻破SDK通信后，就可以利用該應用的SDK把標準的安裝URL發送給MMP服務器平臺。這個URL并不是一開始就能夠準確確定的，所以需要不斷試錯并調整URL中的動態/靜態參數（詳見歸因基礎知識了解更多，比如寫死上報數據的siteid，測試廣告ID等動態變化的部分），通過類似“撞庫”的過程，最終捕獲實時請求的結果。如果成功地追蹤到了MMP的安裝事件，則可以證明已經成功破解了SDK的安裝事件的上報邏輯。對于投放&運營來說：在足夠了解自己的產品基礎上，我們可以利用一些基本的行業經驗和簡單的規則去判斷是否有虛假安裝的流量：貨不對板：比如最為基礎的一個邏輯驗證，投放米國的產品出現大量霓虹設備語言的安裝。OS Version：假設我們上架的應用只能在Android9+以上版本的設備上才能正常使用。但是分析渠道的時候，發現某些渠道的流量來源于一些非常低OS版本/特別集中的設備供應商，那可以初步判斷渠道是有問題的。New Device Rate：對于一個廣告來說，是有概率投放到新設備比例上的，這當然很正常，但是過高的新設備比例則明顯不正常。畢竟海外Appsflyer平臺是拿到了市場上98%的設備信息。即使是國內，神策和數美等平臺也拿到了足夠多的數據。所以你的應用99%的情況下，新舊設備分布是遵守大盤的，不會全部都是新設備，高于20%就已經是一個危險的數據指標了。IP和VPN檢驗：VPN的工作原理是通過選定的VPN的專用服務器而不是互聯網服務提供商（ISP）路由設備互聯網連接。作弊者使用VPN來掩蓋他們的操作并隱藏他們的IP地址，以避免被列入MMP和Ad Network平臺的黑名單。MMP平臺本身提供了IP驗證的套件（如Adjust中的MaxMind）。素材維度：了解所有素材類型和尺寸，拒絕一切非正常規格驗證的素材上報點擊和曝光。具體來看，比如在明確我們在所有廣告平臺都沒有圖片類型素材的話，如果后續中有上報來自image的點擊，則可以判定渠道有問題。規則驗證：Appsflyer提供了廣告主自行設置Rule防作弊的功能，投放同學可以和運營同學一起根據用戶的數據表現，設置規則。比如IP/OS Version的黑白名單。對于產品同學來說，更需要從技術層面給予一些支持，避免更為復雜的作弊方式：建立風控系統：這可能是XJD產品最為熟悉的環節，不過現在作弊的情況，其他的品類也可以考慮加入基礎風控模型。一般風控系統和MMP的Protect高級服務都會包括識別用戶行為，將程序化、非人類行為模式的安裝排除歸因。說到建立風控模型，就一定逃不過通過時序等各種算法定義用戶，將不同的用戶分到不同的驗證池子，這個后續有時間再寫。設備傳感器驗證：一般產品（常見于安卓）可以收集用戶設備上安裝的app、屏幕尺寸分辨率、系統亮度、是否打開了usb調試、所有音量、陀螺儀、是否有設備指紋、是否root、是否充電、電量、手機網絡(wif/4G)等字段驗證用設備是否有問題。閉源SDK：與開源不同，閉源技術開發的SDK源代碼對作弊者來說，相對難以模擬和反編譯。一般來說，反編譯后上報URL的行為通常會從應用程序使用的SDK版本以外的SDK版本發送點擊和安裝，我們需要定期更新并及時留意某些特定SDK版本的安裝是否不合理。CUID埋點：這里是以Appsflyer為例，從應用開始準備發包前，就埋好CUID這個收集字段。官方推薦當用戶完成注冊后就生成一個CUID給這個用戶。確實我們可以利用字段有無去識別一些渠道。但是部分渠道可能依然不承認用戶為虛假用戶，沒關系，還有2.0版本，直接通過CUID和用戶安裝事件深度綁定，將Application SDK引入。這時候大量沒有任何CUID的用戶的渠道一定是虛假流量。我們知道事件的上傳可以包括SDK和S2S兩種。之前有部分渠道可以做到機刷SDK事件，但是現在有的作弊者可以刷S2S事件了，對此只能說真心佩服。我也遇到過，給一個純IAA的游戲刷出IAP付費事件的情況，甲方自己都懵了，我也只能建議作弊者多長點心，刷之前看看產品類型再說。SDK作弊，常見于安裝（安裝是一個事件）、偽造廣告收入。安裝上述已有探討。這里多提一句，如果你接入了外置network或者mediation的SDK平臺，可以設置一步S2S激勵回調的驗證，識別一些作弊流量。另外，Appsflyer應該是目前歸因后驗證數據做的最全面的MMP了，你可以識別歸因后的用戶行為是否合規。如果產品規模也比較大的客戶，可以考慮購買附加的服務。不過需要注意的是，如果發現渠道流量質量有問題需要核減的情況，建議在次月8號之后再去統一核減上個月的流量。這是因為雖然Appsflyer是實時去檢查歸因后數據的，但是Appsflyer次月8號后，即便檢測出之前的流量仍然有問題，也不會體現在PAF報告中了。此外就是，盡量從S2S走事件，SDK相對不太安全。對于S2S的放作弊，暫時沒有什么特別好的方法，只能從風控下手。不過不排除暴力打端口的可能性？
